(57)【要約】【課題】汎用ＰＣでユーザが作成した組み込みソフトウェアを、プログラマブルコントローラのアプリケーションソフトウェアとして呼び出すときに、  ・サブルーチンのような複数箇所から呼び出される組み込みソフトウェアの記述が出来ない  ・プログラマブルコントローラのアプリケーションソフトウェアと組み込みソフトウェアが非同期に動作するので、プログラマブルコントローラのアプリケーションからは、組み込みソフトウェアの処理や起動、完了のタイミングを把握出来ない。のような、組み込みソフトウェアとプログラマブルコントローラのアプリケーションソフトウェア間における「データ交換方法、及び起動方法」を解決し、その整合性を保証する。【解決手段】組み込みソフトウェアに付加するインスタンス情報、アプリケーションソフトウェアに付加するインスタンス情報を用いて両者を比較し、その正否によってプログラムの実行継続を判断する。【選択図】図１
2009245194.tif 000002
【特許請求の範囲】
【請求項１】
組み込みソフトウェアのファンクションブロックのオブジェクトコードと該オブジェクトコードに付与されている第１の付加情報とを格納する第１の記憶手段と、
前記組み込みソフトウェアのファンクションブロックを用いたアプリケーションソフトと該アプリケーションソフトに付与されている第２の付加情報とを格納する第２の記憶手段と、
前記第１、２の記憶手段に格納された情報を解釈し実行する実行手段とを備え、
前記実行手段は、前記アプリケーションソフトを実行する際に、該アプリケーションソフトに前記組み込みソフトウェアのファンクションブロックの呼び出し処理があるときは、前記第１の付加情報と前記第２の付加情報とを比較し、相違が無い場合に処理を継続することを特徴とするプログラマブルコントローラ。
【請求項２】
請求項１に記載のプログラマブルコントローラにおいて、
前記第１の付加情報及び前記第２の付加情報は、前記組み込みソフトウェアのファンクションブロックのインスタンスフォーマット情報であることを特徴とするプログラマブルコントローラ。
【請求項３】
請求項１に記載のプログラマブルコントローラにおいて、
前記第１の付加情報及び前記第２の付加情報は、版数情報、或いは前記組み込みソフトウェアのファンクションブロックを特定可能なタイムスタンプ情報であることを特徴とするプログラマブルコントローラ。
【請求項４】
組み込みソフトウェアのファンクションブロックをプログラミングする第１のプログラミング手段と、
該組み込みソフトウェアのファンクションブロックを用いたアプリケーションソフトをプログラミングする第２のプログラミング手段と、
前記ファンクションブロック及び前記アプリケーションソフトをコンパイルするコンパイル手段と、
前記組み込みソフトウェアのファンクションブロックのオブジェクトコードと、該オブジェクトコードを特定する第１の付加情報とを送信する第１の送信手段と、
前記アプリケーションソフトと、該アプリケーションソフトに含まれる前記組み込みソフトウェアのファンクションブロックのオブジェクトコードを特定する第２の付加情報とを送信する第２の送信手段とを備えることを特徴とするプログラマブルコントローラ支援装置。
【請求項５】
請求項４に記載のプログラマブルコントローラ支援装置において、
前記第１の付加情報及び前記第２の付加情報は、前記組み込みソフトウェアのファンクションブロックのインスタンスフォーマット情報であることを特徴とするプログラマブルコントローラ支援装置。
【請求項６】
請求項４に記載のプログラマブルコントローラ支援装置において、
前記第１の付加情報及び前記第２の付加情報は、版数情報、或いは前記組み込みソフトウェアのファンクションブロックを特定可能なタイムスタンプ情報であることを特徴とするプログラマブルコントローラ支援装置。
【請求項７】
プログラマブルコントローラとプログラマブルコントローラ支援装置とを具備するプログラマブルコントローラシステムにおいて、
前記プログラマブルコントローラ支援装置は、
組み込みソフトウェアのファンクションブロックをプログラミングする第１のプログラミング手段と、
該組み込みソフトウェアのファンクションブロックを用いたアプリケーションソフトをプログラミングする第２のプログラミング手段と、
前記ファンクションブロック及び前記アプリケーションソフトをコンパイルするコンパイル手段と、
前記組み込みソフトウェアのファンクションブロックのオブジェクトコードと、該オブジェクトコードを特定する第１の付加情報とを送信する第１の送信手段と、
前記アプリケーションソフトと、該アプリケーションソフトに含まれる前記組み込みソフトウェアのファンクションブロックのオブジェクトコードを特定する第２の付加情報とを送信する第２の送信手段とを備え、
前記プログラマブルコントローラは、
前記第１の送信手段により送信されてきた前記組み込みソフトウェアのファンクションブロックのオブジェクトコードと該オブジェクトコードに付与されている前記第１の付加情報とを格納する第１の記憶手段と、
前記第２の送信手段により送信されてきた前記組み込みソフトウェアのファンクションブロックを用いたアプリケーションソフトと該アプリケーションソフトに付与されている前記第２の付加情報とを格納する第２の記憶手段と、
前記第１、２の記憶手段に格納された情報を解釈し実行する実行手段を備え、
前記実行手段は、前記アプリケーションを実行する際に、該アプリケーションに前記組み込みソフトウェアのファンクションブロックの呼び出し処理があるときは、前記第１の付加情報と前記第２の付加情報と比較し、相違が無い場合に処理を継続することを特徴とするプログラマブルコントローラシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プログラマブルコントローラ(以下、ＰＬＣと略す場合もある)のファンクションブロック（以下、ＦＢと略す場合もある）に関し、特にユーザが作成した組み込みソフトウェアと該組み込みソフトウェアを扱うアプリケーションソフトウェアとにおける動作の保証に関する。
【背景技術】
【０００２】
従来、プログラマブルコントローラはシーケンス命令実行を高速に行わせるための専用ハードウェア（大規模専用ＬＳＩ：Large Scale Integrationなどに代表される）を備えるものが主流であった。これら専用ハードウェアにおいては、各コントローラのメーカーが提供する支援ツールによって、マシンコードを生成する必要があった。
しかし、「専用ハードウェアは高価である」、「専用のマシン語体系をもちシステムプログラム開発が比較的困難である」というデメリットも存在していた。
近年、パーソナルコンピュータ、携帯端末などの普及により、市販の汎用ＣＰＵ（Central Processing Unit）の技術革新が進み、高速実行が可能なＣＰＵを非常に安価に入手することが可能になってきた。そのため、汎用ＣＰＵを用いて専用ＬＳＩをエミュレートして実行しても、充分に所望の実行性能を得る事ができるようになった。
また、汎用であるためファームウェアの開発ツールも市場から調達できるようになってきたため、汎用ＣＰＵを使ったプログラマブルコントローラも作られるようになってきている。
このような汎用ＣＰＵをベースとしたプログラマブルコントローラにおいては、ユーザに提供するアプリケーション開発環境として、“プログラマブルコントローラに使用されている汎用ＣＰＵに対応した組み込みソフトウェア開発環境で汎用プログラム言語（Ｃ言語、マイコン対応アセンブラなど）を用いてプログラミングし、プログラマブルコントローラにダウンロードした後、実行する方法”が注目されている。
【０００３】
実際、近年では汎用ＣＰＵをベースとしながら従来の専用ＬＳＩを使用したものと全く同じ動作をするプログラマブルコントローラや、逆に従来の支援ツールを使用せずに組み込みソフトウェア開発環境でプログラミングを行うＣ言語コントローラなども発売されている。
このようなＣ言語コントローラにおいては、ユーザのプログラミング負荷を軽減するためにリアルタイム・オペレーティング・システム（以下、リアルタイムＯＳと呼ぶ）が搭載されている。リアルタイムＯＳでは、タスクと呼ばれる処理単位を複数並列に実行可能であり、タスク間の通信機能、タスクの生成及び起動などの実効制御の機能を備えている。タスクの時間管理をリアルタイムＯＳが行うので、ユーザはプログラミングする際にスケジューリングの負荷から開放される利点があげられる。
ところで、プログラマブルコントローラのアプリケーションソフトウェアは、プログラマブルコントローラを効率よく扱うために、制御ネットワークに接続されている外部接続機器（例えば、入出力モジュール）をメモリとして扱うなど、プログラマブルコントローラシステム固有のメモリアドレス体系を保持している。そのため、メモリ管理においては、汎用ＣＰＵの物理アドレスに直接依存していない。また、プログラマブルコントローラのアプリケーションソフトウェアの実行時には、プログラマブルコントローラのタスクとして登録されており、これらは定周期やイベントなどの指定されたタイミングで起動されるが、プログラマブルコントローラのアプリケーションソフトウェアの作成者は、それらのアプリケーションソフトウェアのタスクとシステムソフトを動かしているリアスタイムＯＳとの動作の関連を意識することが出来ない。
【０００４】
このことに起因し、以下の問題点が挙げられる。
・サブルーチンのような複数箇所から呼び出される組み込みソフトウェアの記述が出来ない（例えば、データ交換領域としてプログラマブルコントローラのアプリケーションメモリの固定番地を組み込みソフトウェア中で明示的に記述しようとすると、データ交換領域アドレスをそれぞれ個別に用意しなければならず、同じ処理にもかかわらず、別のプログラムになってしまう）。
・プログラマブルコントローラのアプリケーションソフトウェアと組み込みソフトウェアが非同期に動作するので、プログラマブルコントローラのアプリケーションソフトウェアからは、組み込みソフトウェアの処理や起動、完了のタイミングを把握出来ない。
このように、組み込みソフトウェアとプログラマブルコントローラのアプリケーションソフトウェアにおける「データ交換方法、及び起動方法」が問題になる。
特許文献１は、ユーザＦＢをメーカーの提供するシステムＦＢとして認識させる事によりデータ交換及び起動の問題を解決している。
特許文献２は、組み込みソフトウェアのユーザＦＢを先にＰＬＣ側にダウンロードし、これを用いたアプリケーションソフトウェアのコンパイル時にユーザＦＢ番号を全て発番することにより、先にダウンロードした組み込みソフトウェアのユーザＦＢを認識可能としている。
【０００５】
特許文献１、２のいずれも、ＦＢを一意に認識可能なＦＢ番号を用いている。また、これらを管理するＦＢテーブルの扱いに着眼した発明となっている。
以下に、このような管理方法について説明する。
始めに、図４〜６にて基本構成について説明する。次に、図７〜１３にてプログラマブルコントローラで使用するファンクションブロックの詳細について説明する。続けて、図１４〜１６にて組み込みソフトウェアのファンクションブロック作製方法について説明する。最後に、図１７〜２０にてＦＢテーブルとその使用方法について説明する。
図４は、プログラマブルコントローラシステムの構成の一例を説明したものである。パソコン１００は一般的なパソコンであり、このパソコン１００にはプログラマブルコントローラを支援する図示しない支援ツールが格納されている。パソコン１００と支援対象のプログラマブルコントローラ１０２は、ケーブル１１０で接続されている。また、プログラマブルコントローラ１０２〜１０６と制御対象となる入出力モジュール１０８とは、制御用ネットワーク１１２で接続されている。制御用ネットワーク１１２の一例としては、出願人の製品であるMICREX-SXシリーズで使用しているSXバスなどがある。
パソコン１００において、ファンクションブロック等を用いてプログラミングを行い、コンパイル後に実行ファイルをプログラマブルコントローラ１０２にケーブル１１０等を介してダウンロードする（このため、パソコン１００はローダと呼ばれることもある）。
【０００６】
なお、ここではプログラマブルコントローラシステムの一例として、一台のパソコン１００と複数のプログラマブルコントローラ１０２〜１０６、及び複数の入出力モジュール１０８とによる構成を示しているが、これは発明を限定するものではなく、それぞれ任意の台数によって構成されていても構わない。また、パソコン１００の支援対象はプログラマブルコントローラ１０２〜１０６のいずれか１つ／全てであっても構わない。
ここでは、パソコン１００と支援対象のプログラマブルコントローラ１０２〜１０６は、ケーブル１１０によって接続されているが、これに限ったものではなく、無線ＬＡＮであっても良いし、任意の媒体を介して情報を遣り取りしても構わない。
図５は、プログラマブルコントローラの概略ハード構成を説明したものである。プログラマブルコントローラ１２０は、システムプログラム及び／又はユーザプログラムを実行するＣＰＵ１２４を有し、ＣＰＵ１２４は内部バス１３４を介してプログラム、命令、各種データ等を遣り取りする。ここで、システムプログラム及び／又はユーザプログラムを電源断時も保存しておくために、不揮発性の書き換えメモリとしてフラッシュメモリ１２８を有する。一般に、フラッシュメモリはＳＲＡＭ等に比べ動作が低速である為、プログラムの保存に適していても、実行には向かない。そこで、フラッシュメモリ１２８からシステムプログラム及び／又はユーザプログラムを展開・実行するＳＲＡＭとして、プログラムメモリ１３０を有する。また、システムプログラム及び／又はユーザプログラムがリード／ライトする情報を管理・保存するメモリ領域（ＳＲＡＭ）として、データメモリ１３２も有する。
【０００７】
一方でプログラマブルコントローラ１２０には、大別して外部機器との通信機能を２つ有する。１つは、後述のプログラマブルコントローラ支援装置１４０からユーザの指示やプログラミング、実行ファイル等をＣＰＵ１２４と遣り取りするインターフェース機能であるドライバ／レシーバ１２２である。もう１つは入出力モジュール等の制御対象機器との通信を行う際に、専用線であるバスの調停等を行うバスコントローラ１２６である。
なお、フラッシュメモリ１２８、プログラムメモリ１３０、データメモリ１３２は、データ保存／管理の面や実行性の側面から複数のユニットに分けているが、十分な容量や速度性能および電源断時のデータ保証が可能なときは、例えば１つのメモリであっても構わない。
図６は、プログラマブルコントローラ支援装置の概略ハード構成を説明したものである。プログラマブルコントローラ支援装置１４０は、ユーザが所望の制御プログラムを作成する為に入力を行う入力デバイス１４６と、この入力内容等を表示する表示デバイス１４８、所定のプログラムを記憶するための記憶装置１５０、接続線や外部ネットワーク等を介し対象のプログラマブルコントローラと通信する通信Ｉ／Ｆ１４４等を有する。ＣＰＵ１４２は、内部バス１５２を介し、入力デバイス１４６より作成されたプログラムを必要に応じて記憶装置１５０に記憶し、また図示しない支援ツールのコンパイル機能により実行ファイルを作成し、これを通信Ｉ／Ｆ１４４を介して対象のプログラマブルコントローラに送信（ダウンロード）する。また、必要に応じて、後述のＦＢ番号も送信する。
【０００８】
ユーザは、プログラマブルコントローラ支援装置１４０における支援ツールを用いてプログラミングを行うことになるが、この際にファンクションブロックを使用することが多い。記述言語規格ＩＥＣ６１１３１−３に規定されているファンクションブロックでは、処理コードと処理を行う際に使用するデータ（インスタンス）とが一体になった処理構造になっている。
図７は、ファンクションブロックの入出力概略の一例を説明したものである。図７（ａ）の例では、矩形部分で表示したファンクションブロック本体１６０に対し、左側に入力端子１６２、右側に出力端子１６４が配置されている。ここでは、ファンクションブロック本体１６０の上部中央に記載のＣＴＵがファンクションブロック名称を、ＣＵ、Ｒ、ＰＶ、Ｑ、ＣＶは端子名称を表している。また、入力端子１６２、出力端子１６４に記載の情報（ＢＯＯＬ、ＩＮＴ）は端子のデータ型を表している。
同様に、図７（ｂ）の例では、矩形部分で表示したファンクションブロック本体１７０に対し、左側に入力端子１７２、右側に出力端子１７４が配置されている。ここでは、ファンクションブロック本体１７０の上部中央に記載のＵＦＢがファンクションブロック名称を、ＩＮ１、ＩＮ２、ＯＵＴ１、ＯＵＴ２は端子名称を表している。入力端子１７２、出力端子１７４に記載の情報（ＩＮＴ）は端子のデータ型を表している。
【０００９】
図８は、ファンクションブロックのインスタンスの構成の一例を説明したものである。図８（ａ）における最小の矩形は、ビット量を表す。ＣＵ、Ｒ、Ｑが１つの矩形から構成されているのは、データ型がＢＯＯＬ（図７（ａ）参照）であることを表し、ＰＶ、ＣＶが１６個分の矩形から構成されているのは、データ型がＩＮＴ（図７（ａ）参照）であることを表す。また、図８（ａ）における斜線の箇所は未使用領域であることを表す。同様に、図８（ｂ）のＩＮ１、ＩＮ２、ＯＵＴ１、ＯＵＴ２は、１６個分の矩形から構成されており、データ型がＩＮＴ（図７（ｂ）参照）であることを表す。
なお、ここでは模式的な表示としているが、実際には連続した領域としてメモリ割り付けが行われる。図５において、これらの単位でデータメモリ１３２にアドレスが割り付けられ、インスタンス領域として管理される。実行時のファンクションブロックのプログラムコードはプログラムメモリ１３０に、インスタンスの情報はデータメモリ１３２に配置される。これらの情報を連携して実行することによりファンクションブロックは機能する。
ところで、ファンクションブロックは、その性質から大きく分けると２つに分類される。ここではこれらをそれぞれ、ユーザファンクションブロック（以降、ユーザＦＢと略す）とシステムファンクションブロック（以降、システムＦＢと略す）と呼ぶ。
【００１０】
ユーザＦＢは、ユーザがファンクションブロックの中身（処理自体）も含めてプログラミングするもので、プログラマブルコントローラ支援装置でユーザＦＢ自体もコンパイルされた後、プログラマブルコントローラにダウンロードされる。
一方でシステムＦＢは、プログラマブルコントローラのメーカが提供するファンクションブロックである。その為、予めその機能がプログラマブルコントローラ本体のシステムプログラムに含まれており、ユーザはプログラマブルコントローラのアプリケーション内でそのシステムＦＢを呼び出すコードを記述するだけで、その機能を使用する事ができる。
また、システムＦＢではプログラマブルコントローラで使用されるマイコンや専用ＬＳＩに最適な設計がメーカによりなされているが、ユーザはこれらのシステムＦＢに手を加えることは出来ず、参照することのみ許されているのが一般的である。
なお、ユーザが作成した組み込みソフトウェアによるファンクションブロックは本来はユーザＦＢなので、プログラマブルコントローラにおいてはユーザＦＢとして扱うのが一般的だが、プログラマブルコントローラにシステムＦＢとして登録する方法を用いても構わない。
【００１１】
ここまでに説明した図７（ａ）、図８（ａ）はシステムＦＢの一例を、図７（ｂ）、図８（ｂ）はユーザＦＢの一例を示したものである。
図９は、ＦＢをプログラマブルコントローラのアプリケーションから呼び出した場合のプログラムの一例を説明したものである。図９（ａ）では、ＰＧ０というプログラムから図７（ａ）のファンクションブロックであるＣＴＵを呼び出している。インスタンス１８０は、ＰＧ０においてＣＴＵのインスタンスであることを表している。同一のファンクションブロックでも、インスタント名が異なれば処理も異なる。このため、インスタント名ごとに対応する対象データ領域を有し、ここではインスタンス名としてＣＴＵ#１となっている。変数１８２はＰＧ０内で定義されるが、インスタンス１８０の入力値として受け渡す。同様に、変数１８４はＰＧ０内で定義されるが、インスタンス１８０の実行結果である出力値を受け渡される。
図９（ｂ）も同様で、ＰＧ１というプログラムから図７（ｂ）のファンクションブロックであるＵＦＢを呼び出している。インスタンス１９０は、ＰＧ１においてＵＦＢのインスタンスであることを表している。ここではインスタンス名は、ＵＦＢ#１となっている。
変数１９２はＰＧ１内で定義されるが、インスタンス１９２の入力値として受け渡す。同様に、変数１９４はＰＧ１内で定義されるが、インスタンス１９０の実行結果である出力値を受け渡される。
【００１２】
図１０は、ＰＧ０の擬似的なプログラムコードを説明したものである。コード２００、２１０はプログラムの開始、終了を示すタグであり、実質上、無処理のコードになる。コード２０２は図９（ａ）の変数１８２と対応している。コード上では、Ａ、ＣＴＵ#１．ＣＵのような表記となっているが、実際にはこれらの変数（或いはインスタンス領域）には、プログラマブルコントローラのデータメモリのアドレスが割り付けられている。ここで、ＣＴＵ#１はインスタンス領域の先頭アドレス、ＣＴＵ#１．ＣＵはその構成要素（プロパティ）であるＣＵのアドレスが割り付けられている。ＣＴＵ#１．ＲやＣＴＵ＿１．ＰＶについても同様である。ここでは、Ａ、Ｂ、Ｃを入力値として、ＣＴＵ#１はインスタンス領域のＣＴＵ#１．ＣＵ、ＣＴＵ#１．Ｒ、ＣＴＵ#１．ＰＶに格納する。コード２０４はＰＵＳＨ命令であり、インスタンス領域のアドレスをスタック等に保存しておく命令である。コード２０６はＣＡＬ命令であり、ファンクションブロックＣＴＵのプログラムコードを呼び出す。コード２０８は、図９（ａ）の変数１８４と対応している。コード２０６で呼び出されたファンクションブロックＣＴＵの処理の終了後に、実行結果を出力値として、ＣＴＵ#１はインスタンス領域のＣＴＵ#１．Ｑ、ＣＴＵ#１．ＣＶから値を取り出し、Ｄ、Ｅに格納する。
【００１３】
図１１は、ＰＧ１の擬似的なプログラムコードを説明したものであり、図１０と同様な処理となる。コード２２０、２３０はプログラムの開始、終了を示すタグ、コード２２２にてＵＦＢ＿１のインスタンス領域に引き渡す値を入力し、コード２２４でＰＵＳＨ命令、コード２２６でＵＦＢを呼び出し、コード２２８で実行結果をインスタンス領域から受けとる。
図１２は、プログラマブルコントローラにおけるシステムＦＢの処理の一例を概略フローチャートで説明したものである。ここではプログラマブルコントローラのアプリケーションの処理の１つとして、ＰＧ０が実行されたとき、ＰＧ０におけるシステムＦＢ（ＣＴＵ）がどのように処理されるかについて、その概略を示す。
図から明らかなように、ＰＧ０の処理（フローＦ１００）において、ＣＡＬ処理（フローＦ１０２）が呼び出され、その後、ＣＴＵの実体が処理（フローＦ１０４）されて、フローＦ１００に戻り処理を完了する。
順を追って説明すると、ＰＧ０の実行中において、プログラマブルコントローラに予め実装されているＣＡＬ処理が呼び出される（ステップＳ１００）。また、ステップＳ１００の前処理として、システムＦＢ（ＣＴＵ）のインスタンス（ＣＴＵ＿１）のアドレスはデータメモリ上にスタックされ、インスタント領域に格納されている。ＣＡＬ処理では、始めにシステムＦＢ（ＣＴＵ）処理後の戻りアドレスを保存する（ステップＳ１０２）。その上で、スタックに格納されているインスタンス領域のアドレスを取り出し（ステップＳ１０４）、呼び出そうとしているシステムＦＢ（ＣＴＵ）のシステムＦＢ番号を後述のシステムＦＢテーブル（図１７参照）から検索し、アドレス情報を取り出す（ステップＳ１０６）。インスタンス領域のアドレスをパラメータにセットしてシステムＦＢ（ＣＴＵ）の処理にジャンプする（ステップＳ１０８）。システムＦＢ（ＣＴＵ）の処理終了後、ステップＳ１０２で保存しておいた戻りアドレスにジャンプした後、ＰＧ０の処理を継続する。
【００１４】
図１３は、プログラマブルコントローラにおけるユーザＦＢの処理の一例を概略フローチャートで説明したものである。基本的に図１２のシステムＦＢの処理と同様になる。ここではプログラマブルコントローラのアプリケーションの処理の１つとして、ＰＧ１が実行されたとき、ＰＧ１におけるユーザＦＢ（ＵＦＢ）がどのように処理されるかについて、その概略を示す。
図から明らかなように、ＰＧ１の処理（フローＦ１１０）において、ＣＡＬ処理（フローＦ１１４）が呼び出され、その後ＵＦＢの実体が処理（フローＦ１１２）されて、フローＦ１１０に戻り処理を完了する。
順を追って説明すると、ＰＧ１の実行中において、プログラマブルコントローラに予め実装されているＣＡＬ処理が呼び出される（ステップＳ１１０）。また、ステップＳ１１０の前処理として、ユーザＦＢ（ＵＦＢ）のインスタンス（ＵＦＢ＿１）のアドレスはデータメモリ上にスタックされ、インスタント領域に格納されている。ＣＡＬ処理では、始めにユーザＦＢ（ＵＦＢ）処理後の戻りアドレスを保存する（ステップＳ１１２）。その上で、スタックに格納されているインスタンス領域のアドレスを取り出し（ステップＳ１１４）、呼び出そうとしているユーザＦＢ（ＵＦＢ）のユーザＦＢ番号を後述のユーザＦＢテーブル（図１８参照）から検索し、アドレス情報を取り出す（ステップＳ１１６）。インスタンス領域のアドレスをパラメータにセットしてユーザＦＢ（ＵＦＢ）の処理にジャンプする（ステップＳ１１８）。ユーザＦＢ（ＵＦＢ）の処理終了後、ステップＳ１１２で保存しておいた戻りアドレスにジャンプした後、ＰＧ１の処理を継続する。
【００１５】
図１３と図１４における処理の相違点は、システムＦＢやユーザＦＢの実体の処理が、ＰＬＣのアプリケーション内で実行されるか、システムプログラム内で実行されるかの点にある。
ここまでは、基本的な構成とその処理について説明した。以降は、組み込みソフトウェアにおけるＦＢ（以降、組み込みソフトウェアＦＢと呼ぶ）の作成方法（図１４〜図１６参照）や、組み込みソフトウェアＦＢのプログラマブルコントローラへの展開処理（図１７〜図２０）に関する具体的な所作について説明する。
図１４は、作成対象のＰＯＵ（Program Organization Unit）を選択する画面を説明したものであり、この画面は図６のプログラマブルコントローラ支援装置１４０における図示しない支援ツールにおけるユーザインターフェースの一例である。
このメニュー画面では、従来のプログラム、ファンクションブロック、ファンクションに加えて、組み込みソフトウェアＦＢの作成を支援することを示している。
図１５は、組み込みソフトウェアＦＢの編集画面の一例を説明したものである。ここでは、ファンクションブロックの名称と、各変数の変数名、データ型、種類を入力する。ファンクションブロック名称は、入力規則に制限は無いが、既に登録済みの名称と重複しないようにする。変数名も入力規則に制限は無いが、同一ファンクションブロック内で重複しないようにする。データ型は、変数の型であるＩＮＴ型、ＢＯＯＬ型等を指定可能で、ファンクションブロックのインスタンスの構成（図８参照）にも反映される。種類は、ＩＮＰＵＴ、ＯＵＴＰＵＴのいずれかであり、変数がファンクションブロックの入力側、出力側のいずれかであるかを指定することになる。
【００１６】
図１６は、組み込みソフトウェアＦＢの雛形の一例を説明したものである。図１５で設定した変数を用い、Ｃ言語を用いた組み込みソフトウェアの雛形を作成する例を示す。コード２４０は、構造体の記述方式であり、ファンクションブロックにおいてはインスタンスに相当する。コード２４２は、構造体からの変数受け渡しと、実際の処理を記入する箇所であり、特に、“／＊  以下に処理を記入する  ＊／”の箇所以降に演算式や制御内容をユーザがＣ言語で記載する。なお、ここでは説明の関係で図１５で変数等の情報を入力してから図１６で雛形を作成する例を示したが、図１５の情報より、コード２４０やコード２４２の変数などの該当部分を自動的に反映しても構わないし、コード２４０、２４２をユーザが直接入力しても構わない。作成したコードを、組み込みソフトウェアの開発環境にてコンパイルし、オブジェクトファイル（組み込みソフトウェアＦＢのオブジェクトコード）を生成する。
ここまでの処理で、組み込みソフトウェアＦＢを、システムＦＢ或いはユーザＦＢとして作成し、これをプログラマブルコントローラに格納する準備は整う。図１７、図１９ではプログラマブルコントローラのシステムＦＢとして、組み込みソフトウェアＦＢを組み込む方法を、図１８、図２０ではプログラマブルコントローラのユーザＦＢとして、組み込みソフトウェアＦＢを組み込む方法を示す。ここでは説明の関係で、システムＦＢ／ユーザＦＢとしての格納方法を別々に説明するが、これらを併用しても構わない。
【００１７】
初めに各ＦＢテーブルについて説明する。
図１７は、システムＦＢテーブルの一例を説明したものである。プログラムメモリ上に、システムＦＢのオブジェクトコード９９個と、ユーザの作成した組み込みソフトウェアＦＢ一つとが格納されている。各システムＦＢのオブジェクトコードには、これらを一意に特定するシステムＦＢ番号が割り振られている。これはプログラマブルコントローラ側で、システムＦＢ番号で指定されたシステムＦＢを速やかに呼び出せるようにするものである。ここでは、これらのシステムＦＢ番号を管理する方法としてシステムＦＢテーブルを用いている。
システムＦＢテーブルは、システムＦＢ番号及びシステムＦＢのオブジェクトコードの格納先アドレスの一覧で構成される。図１７の例では、システムＦＢテーブルはデータメモリに格納されており、システムＦＢテーブルの各システムＦＢ番号を指定すればプログラムメモリ内の各オブジェクトコードの開始アドレスを特定できることを、図の各矢印は示している。一例として、システムＦＢ番号が“１”の場合は、システムＦＢテーブルのシステムＦＢ１に格納されているアドレスを参照し、ここではプログラムメモリの５０番地に格納されていることが分かる。
【００１８】
このシステムＦＢテーブルは、基本部分と拡張部分から構成され、メーカー指定のシステムＦＢ１〜９９（基本部分）は固定で、後続のシステムＦＢ１００〜ｎ（拡張部分）に組み込みソフトウェアＦＢや任意のユーザＦＢを登録する。図で示したように拡張部分には、登録の有無に応じて空き領域（リザーブ）を用意しても構わない。
なお、アドレスの指定方法は、オブジェクトコードの格納先の開始番地を用いるのが一般的であるが、開始番地・終了番地・オブジェクトコードを格納するアドレス長を指定しても構わない。アドレスの情報は、プログラムメモリ内のアドレスを絶対番地として登録しても構わないし、相対アドレスであっても構わない。
また、システムＦＢテーブルの構成自体を構造的にして、例えばシステムＦＢテーブルの頭から４バイト目にはシステムＦＢ番号１のアドレスを、８バイト目にはシステムＦＢ番号２のアドレス、・・・、４ｎバイト目にはシステムＦＢ番号ｎのアドレスを格納すれば、単なるアドレスの羅列で構成しても構わない。
ここでは、一例として、システムＦＢがｎ個あるものとして、実際にｎ個格納されているものを想定しているが、管理するシステムＦＢの個数はデータメモリやプログラムメモリ等の容量が許容すればｎ個に固定せずとも構わなく、未使用な番号があっても良いし、システムＦＢが連番である必要は無い。但し、実際に実行するシステムＦＢに応じて管理するのがメモリ資源やレンスポンスの面から好ましい。
【００１９】
いずれにせよ、システムＦＢ番号が分かれば、実行すべきプログラムメモリ内のシステムＦＢのオブジェクトコードのアドレスも一意に決まる。
図１８は、ユーザＦＢテーブルの一例を説明したもである。基本的には図１７のシステムＦＢテーブルと同様な構造なので、その差異について説明する。ユーザが作成したアプリケーションソフトウェアにおいて、そのコンパイル時に生成されたユーザＦＢ番号をユーザＦＢテーブルとして用いるので、基本的にはシステムＦＢのような空き領域は発生しない（必要ない）。また、コンパイル過程の最適化ルーチン等に基づき、ユーザＦＢ番号が発番されるので、組み込みソフトウェアＦＢの番号がどのような番号になるかは固定されない。図１８の場合、ユーザＦＢ番号９９に組み込みソフトウェアＦＢの番号が割り振られたので、その格納箇所はプログラムメモリの３００番地となっている。
続いて、プログラマブルコントローラ支援装置とプログラマブルコントローラとにおいて、どのように処理されているかを説明する。
図１９は、従来のプログラマブルコントローラシステムにおける組み込みソフトウェアＦＢ（システムＦＢ）の処理を概略フローチャートで説明したものである。ここではプログラマブルコントローラ支援装置側とプログラマブルコントローラ側とにおいて、どのような処理が行われているかを、受け渡しされる情報を中心に示している。
【００２０】
図から明らかなように、プログラマブルコントローラ支援装置側では、ユーザが組み込みソフトウェアＦＢを作成し、それを用いたアプリケーションソフトウェアを開発する処理（フローＦ１０）と、組み込みソフトウェアＦＢから実行コードを生成する処理（フローＦ１２）とが行われる。一方で、プログラマブルコントローラ側では、組み込みソフトウェアＦＢを格納する処理（フローＦ１４）とアプリケーションソフトウェアを格納する処理（フローＦ１６）とが行われる。
順を追って説明すると、ユーザはプログラマブルコントローラ支援装置において、支援ツールを用いて、組み込みソフトウェアＦＢを作成する。一例として先述の図１４〜１６のようなインターフェースによって、主に組み込みソフトウェアＦＢの入出力関係を定義する。これにより、組み込みソフトウェアＦＢの雛形１０が生成され、また、この組み込みソフトウェアＦＢを特定するシステムＦＢ番号１４を発番する（ステップＳ１０）。
次に、ユーザは組み込みソフトウェアＦＢの具体的な処理内容をプログラムする（ステップＳ２０）。結果、支援ツールは組み込みソフトウェアＦＢのプログラムコードをコンパイルし実行形式の組み込みソフトウェアＦＢのオブジェクトコード１６を生成する（ステップＳ２２）。
【００２１】
すると、支援ツールは、システムＦＢ番号１４と組み込みソフトウェアＦＢのオブジェクトコード１６とを、動作対象のプログラマブルコントローラに送信（ダウンロード）する（ステップＳ１２）。
続けてユーザは、組み込みソフトウェアＦＢを用いたアプリケーションソフトウェアを生成する（ステップＳ１４）。その後、このアプリケーションソフトウェアをコンパイルし実行形式のアプリケーションソフトウェア１８を生成する（ステップＳ１６）。そして、このアプリケーションソフトウェア１８を動作対象のプログラマブルコントローラに送信（ダウンロード）する（ステップＳ１８）。
プログラマブルコントローラにおいては、システムＦＢ番号１４と組み込みソフトウェアＦＢのオブジェクトコード１６とを受信すると、これをプログラムメモリ１３０の空いている箇所に格納する（ステップＳ２４）。続いて、組み込みソフトウェアＦＢのオブジェクトコード１６に付与されたシステムＦＢ番号１４をデータメモリ１３２のシステムＦＢテーブルに登録する（ステップＳ２６）。システムＦＢテーブルに登録する方法の一例は、先述の図１７の説明の通りである。
一方で、アプリケーションソフトウェア１８を受信すると、これをプログラムメモリ１３０の空いている箇所にに格納する（ステップＳ３０）。
【００２２】
このような処理により、プログラマブルコントローラはスタンバイ状態となり、任意のタイミングでアプリケーションソフトウェア１８が実行され、その処理の中で組み込みソフトウェアＦＢのオブジェクトコード１６が呼び出され実行される。
図２０は、従来のプログラマブルコントローラシステムにおける組み込みソフトウェアＦＢ（ユーザＦＢ）の処理を概略フローチャートで説明したものである。ここでもシステムＦＢのときと同様に、プログラマブルコントローラ支援装置側とプログラマブルコントローラ側とにおいて、どのような処理が行われているかを、受け渡しされる情報を中心に示している。
図から明らかなように、プログラマブルコントローラ支援装置側では、ユーザが組み込みソフトウェアＦＢを作成し、それを用いたアプリケーションソフトウェアを開発する処理（フローＦ２０）と、組み込みソフトウェアＦＢから実行コードを生成する処理（フローＦ２２）とが行われる。一方で、プログラマブルコントローラ側では、組み込みソフトウェアＦＢを格納する処理（フローＦ２４）とアプリケーションソフトウェアを格納する処理（フローＦ２６）とが行われる。
順を追って説明すると、ユーザはプログラマブルコントローラ支援装置において、支援ツールを用いて、組み込みソフトウェアＦＢを作成する。一例として先述の図１４〜１６のようなインターフェースによって、主に組み込みソフトウェアＦＢの入出力関係を定義する。これにより、組み込みソフトウェアＦＢの雛形２０が生成される（ステップＳ５０）。
【００２３】
次に、ユーザは組み込みソフトウェアＦＢの具体的な処理内容をプログラムする（ステップＳ６２）。結果、支援ツールは組み込みソフトウェアＦＢのプログラムコードをコンパイルし実行形式の組み込みソフトウェアＦＢのオブジェクトコード２６を生成する（ステップＳ６４）。
すると、支援ツールは、組み込みソフトウェアＦＢのオブジェクトコード２６を、動作対象のプログラマブルコントローラに送信（ダウンロード）する（ステップＳ５２）。
続けてユーザは、組み込みソフトウェアＦＢを用いたアプリケーションソフトウェアを生成する（ステップＳ５４）。その後、このアプリケーションソフトウェアをコンパイルし実行形式のアプリケーションソフトウェア２８を生成する（ステップＳ５６）。コンパイルの際に、このアプリケーションソフトウェア２８から呼び出す組み込みソフトウェアＦＢを特定するユーザＦＢ番号３０を発番する（ステップＳ５８）。そして、このアプリケーションソフトウェア２８とユーザＦＢ番号３０とを動作対象のプログラマブルコントローラに送信（ダウンロード）する（ステップＳ６０）。
プログラマブルコントローラにおいては、組み込みソフトウェアＦＢのオブジェクトコード２６とを受信すると、これをプログラムメモリ１３０の空いている箇所に格納する（ステップＳ６６）。
【００２４】
一方で、アプリケーションソフトウェア２８とユーザＦＢ番号３０とを受信すると、アプリケーションソフトウェア２８をプログラムメモリ１３０の空いている箇所にに格納する（ステップＳ７０）。続いて、組み込みソフトウェアＦＢのオブジェクトコード２６に付与されたユーザＦＢ番号３０をデータメモリ１３２のユーザＦＢテーブルに登録する（ステップＳ７２）。
このような処理により、プログラマブルコントローラはスタンバイ状態となり、任意のタイミングでアプリケーションソフトウェア２８が実行され、その処理の中で組み込みソフトウェアＦＢのオブジェクトコード２６が呼び出され実行される。
以上の図１９、２０の説明においては、組み込みソフトウェアＦＢのシステムＦＢ番号／ユーザＦＢ番号について処理を示したが、実際の処理では組み込みソフトウェアＦＢ以外のシステムＦＢ番号／ユーザＦＢ番号についても付与されプログラマブルコントローラに送信（ダウンロード）、反映されている。結果、図１７、１８のような各ＦＢテーブルが構築・保持される。
【特許文献１】特願2007-171535
【特許文献２】特願2007-083871
【発明の開示】
【発明が解決しようとする課題】
【００２５】
プログラマブルコントローラシステムを導入した後も、現場環境によってはソフトウェアの更新の必要性や顧客のニーズにより細かいメンテナンス事項は日常的に発生する。この際、例えば、組み込みソフトウェアだけを改善し、これを用いるアプリケーションソフトには手を加えない場合がある。一方で、組み込みソフトウェアの拡張に伴いメモリ管理が変わるので、アプリケーションソフトに手を加える場合もある。
いずれの場合も、ソフトウェアの変更量から見ると、部分的な変更の域で、大幅にプログラムに手を加えることは少ない。
ところで、上述の特許文献１、２においては、システムＦＢ、ユーザＦＢのいずれの場合においても、これらの呼び出しによって組み込みソフトウェアの起動とデータ交換を行っている。ここで交換されるデータは、作成された組み込みソフトウェアのＦＢのインスタンスメモリ上に存在する。もし、上述のプログラムの変更により誤ったＦＢを呼び出すと、アクセスするデータのインスタンス内での相対位置やインスタンスのサイズが異なるため、演算が異常終了してしまう恐れがある。
また、アプリケーションソフトから呼び出す組み込みソフトウェアのＦＢの名称が変わらないため、呼び出し元や呼び出し先に原因があるのか、呼び出し関係に原因があるのか等の原因特定も困難になる。
【００２６】
このように、上述の特許文献１、２においては、ＦＢ番号だけに管理体系が依存しているので、このようなプログラム変更に対応できない問題が発生する。
本発明は、このような問題点を鑑み、ユーザが作成した組み込みソフトウェアと、これらを呼び出すアプリケーションソフトウェアとにおける動作を保証したプログラマブルコントローラ、プログラマブルコントローラ支援装置、及びプログラマブルコントローラシステムを提供することを目的とする。
【課題を解決するための手段】
【００２７】
上記の課題を解決する手段として、本発明は以下のように構成する。
第１に、本発明のプログラマブルコントローラは、組み込みソフトウェアのファンクションブロックのオブジェクトコードと該オブジェクトコードに付与されている第１の付加情報とを格納する第１の記憶手段と、前記組み込みソフトウェアのファンクションブロックを用いたアプリケーションソフトと該アプリケーションソフトに付与されている第２の付加情報とを格納する第２の記憶手段と、前記第１、２の記憶手段に格納された情報を解釈し実行する実行手段とを備え、前記実行手段は、前記アプリケーションソフトを実行する際に、該アプリケーションソフトに前記組み込みソフトウェアのファンクションブロックの呼び出し処理があるときは、前記第１の付加情報と前記第２の付加情報とを比較し、相違が無い場合に処理を継続するように構成する。
第２に、前記プログラマブルコントローラにおいて、前記第１の付加情報及び前記第２の付加情報は、前記組み込みソフトウェアのファンクションブロックのインスタンスフォーマット情報であるように構成する。
第３に、前記プログラマブルコントローラにおいて、前記第１の付加情報及び前記第２の付加情報は、版数情報、或いは前記組み込みソフトウェアのファンクションブロックを特定可能なタイムスタンプ情報であるように構成する。
【００２８】
第４に、本発明のプログラマブルコントローラ支援装置は、組み込みソフトウェアのファンクションブロックをプログラミングする第１のプログラミング手段と、該組み込みソフトウェアのファンクションブロックを用いたアプリケーションソフトをプログラミングする第２のプログラミング手段と、前記ファンクションブロック及び前記アプリケーションソフトをコンパイルするコンパイル手段と、前記組み込みソフトウェアのファンクションブロックのオブジェクトコードと、該オブジェクトコードを特定する第１の付加情報とを送信する第１の送信手段と、前記アプリケーションソフトと、該アプリケーションソフトに含まれる前記組み込みソフトウェアのファンクションブロックのオブジェクトコードを特定する第２の付加情報とを送信する第２の送信手段とを備えるように構成する。
第５に、前記プログラマブルコントローラ支援装置において、前記第１の付加情報及び前記第２の付加情報は、前記組み込みソフトウェアのファンクションブロックのインスタンスフォーマット情報であることを特徴とするプログラマブルコントローラ支援装置。
第６に、前記プログラマブルコントローラ支援装置において、前記第１の付加情報及び前記第２の付加情報は、版数情報、或いは前記組み込みソフトウェアのファンクションブロックを特定可能なタイムスタンプ情報であることを特徴とするプログラマブルコントローラ支援装置。
【００２９】
第７に、プログラマブルコントローラとプログラマブルコントローラ支援装置とを具備するプログラマブルコントローラシステムにおいて、前記プログラマブルコントローラ支援装置は、組み込みソフトウェアのファンクションブロックをプログラミングする第１のプログラミング手段と、該組み込みソフトウェアのファンクションブロックを用いたアプリケーションソフトをプログラミングする第２のプログラミング手段と、前記ファンクションブロック及び前記アプリケーションソフトをコンパイルするコンパイル手段と、前記組み込みソフトウェアのファンクションブロックのオブジェクトコードと、該オブジェクトコードを特定する第１の付加情報とを送信する第１の送信手段と、前記アプリケーションソフトと、該アプリケーションソフトに含まれる前記組み込みソフトウェアのファンクションブロックのオブジェクトコードを特定する第２の付加情報とを送信する第２の送信手段とを備え、前記プログラマブルコントローラは、前記第１の送信手段により送信されてきた前記組み込みソフトウェアのファンクションブロックのオブジェクトコードと該オブジェクトコードに付与されている前記第１の付加情報とを格納する第１の記憶手段と、前記第２の送信手段により送信されてきた前記組み込みソフトウェアのファンクションブロックを用いたアプリケーションソフトと該アプリケーションソフトに付与されている前記第２の付加情報とを格納する第２の記憶手段と、前記第１、２の記憶手段に格納された情報を解釈し実行する実行手段を備え、前記実行手段は、前記アプリケーションを実行する際に、該アプリケーションに前記組み込みソフトウェアのファンクションブロックの呼び出し処理があるときは、前記第１の付加情報と前記第２の付加情報と比較し、相違が無い場合に処理を継続するように構成する。
【発明の効果】
【００３０】
本発明により、ユーザが作成した組み込みソフトウェアと、これらを呼び出すアプリケーションソフトウェアとの整合性を、プログラマブルコントローラにて確認してから実行するので、動作の保証が確保されるという効果を奏する。
また、確認の元となるインスタンスフォーマット情報を簡略化することにより、ユーザやシステムへの負担（負荷）を軽減することも可能である。
【発明を実施するための最良の形態】
【００３１】
以下、本発明を実施するための最良の形態について、図面を参照しながら説明する。
図１は、本発明のプログラマブルコントローラシステムにおける組み込みソフトウェアＦＢ（システムＦＢ）の処理を概略フローチャートで示したものである。また、図２は、本発明のプログラマブルコントローラシステムにおける組み込みソフトウェアＦＢ（ユーザＦＢ）の処理を概略フローチャートで示したものである。それぞれ、図１９、図２０で示した従来例と対応する部分は同一の符号を用いるものとする。以降、同符号の説明は省略し、本発明の特徴点について説明する。
図１において、ユーザはプログラマブルコントローラ支援装置における支援ツールを用いて、組み込みソフトウェアＦＢを作成する。この際に、組み込みソフトウェアＦＢの雛形１０、システムＦＢ番号１４の発番処理に加えて、後述のインスタンスフォーマット情報１２（図３参照）を生成する（ステップＳ１０ａ）。このインスタンスフォーマット情報１２は、システムＦＢ番号１４と組み込みソフトウェアＦＢのオブジェクトコード１６とを、動作対象のプログラマブルコントローラに送信（ダウンロード）する際に、同じくプログラマブルコントローラに送信される（ステップＳ１２ａ）。また、アプリケーションソフトウェア１８を動作対象のプログラマブルコントローラに送信（ダウンロード）する際にも、このインスタンスフォーマット情報１２は、プログラマブルコントローラに送信される（ステップＳ１８ａ）。
【００３２】
一方で、プログラマブルコントローラにおいては、システムＦＢ番号１４と組み込みソフトウェアＦＢのオブジェクトコード１６及びインスタンスフォーマット情報１２を受信すると、ステップＳ２４、ステップＳ２６の処理に続いて、受信したインスタンスフォーマット情報１２を、組み込みソフトウェアＦＢに対応付けて格納する。例えば、データメモリ１３２の空いている箇所にインスタンスフォーマット情報１２を格納し、このインスタンスフォーマット情報１２のインデックス情報としてシステムＦＢ番号１４を登録する。このことにより、組み込みソフトウェアＦＢが指定されれば、対応するインスタンスフォーマット情報１２の閲覧が可能となる（ステップＳ２８）。
また、アプリケーションソフトウェア１８及びインスタンスフォーマット情報１２を受信すると、ステップＳ３０の処理に続いて、受信したインスタンスフォーマット情報１２を、アプリケーションソフトウェア１８に対応付けて格納する。例えば、データメモリ１３２の空いている箇所にインスタンスフォーマット情報１２を格納し、このインスタンスフォーマット情報１２のインデックス情報として、このアプリケーションソフトウェア１８を特定する情報を登録する。このことにより、アプリケーションソフトウェア１８が指定されれば、対応するインスタンスフォーマット情報１２の閲覧が可能となる（ステップＳ３２）。
【００３３】
このような処理により、プログラマブルコントローラはスタンバイ状態となり、任意のタイミングでアプリケーションソフトウェア１８が実行され（ステップＳ３４）、その処理の中で組み込みソフトウェアＦＢのオブジェクトコード１６が呼び出されるタイミングで、メモリに格納されている“組み込みソフトウェアＦＢに対応するインスタンスフォーマット情報１２”と“アプリケーションソフトウェア１８に対応するインスタンスフォーマット情報１２”とを比較する。そして、内容が一致すれば処理を継続し、内容が異なる場合は異常等のメッセージをユーザに提示し、処理を終了する（ステップＳ３６）。
図２において、ユーザはプログラマブルコントローラ支援装置における支援ツールを用いて、組み込みソフトウェアＦＢを作成する。この際に、組み込みソフトウェアＦＢの雛形２０の生成に加えて、インスタンスフォーマット情報２２（図３参照）を生成する（ステップＳ５０ａ）。このインスタンスフォーマット情報２２は、組み込みソフトウェアＦＢのオブジェクトコード２６を、動作対象のプログラマブルコントローラに送信（ダウンロード）する際に、同じくプログラマブルコントローラに送信される（ステップＳ５２ａ）。また、アプリケーションソフトウェア２８とユーザＦＢ番号３０とを動作対象のプログラマブルコントローラに送信（ダウンロード）する際にも、このインスタンスフォーマット情報２２は、プログラマブルコントローラに送信される（ステップＳ６０ａ）。
【００３４】
一方で、プログラマブルコントローラにおいては、組み込みソフトウェアＦＢのオブジェクトコード２６を受信すると、ステップＳ６６の処理に続いて、受信したインスタンスフォーマット情報２２を、組み込みソフトウェアＦＢに対応付けて格納する。例えば、データメモリ１３２の空いている箇所にインスタンスフォーマット情報２２を格納し、このインスタンスフォーマット情報２２に、組み込みソフトウェアＦＢを特定する情報を登録する。このことにより、組み込みソフトウェアＦＢが指定されれば、対応するインスタンスフォーマット情報２２の閲覧が可能となる（ステップＳ６８）。
また、アプリケーションソフトウェア２８とユーザＦＢ番号３０、及びインスタンスフォーマット情報２２を受信すると、ステップＳ７０、ステップＳ７２の処理に続いて、受信したインスタンスフォーマット情報２２を、アプリケーションソフトウェア２８に対応付けて格納する。例えば、データメモリ１３２の空いている箇所にインスタンスフォーマット情報２２を格納し、このインスタンスフォーマット情報２２のインデックス情報として、このアプリケーションソフトウェア２８を特定する情報を登録する。このことにより、アプリケーションソフトウェア２８が指定されれば、対応するインスタンスフォーマット情報２２の閲覧が可能となる（ステップＳ７４）。
【００３５】
このような処理により、プログラマブルコントローラはスタンバイ状態となり、任意のタイミングでアプリケーションソフトウェア２８が実行され（ステップＳ７６）、その処理の中で組み込みソフトウェアＦＢのオブジェクトコード２６が呼び出されるタイミングで、メモリに格納されている“組み込みソフトウェアＦＢに対応するインスタンスフォーマット情報２２”と“アプリケーションソフトウェア２８に対応するインスタンスフォーマット情報２２”とを比較する。そして、内容が一致すれば処理を継続し、内容が異なる場合は異常等のメッセージをユーザに提示し、処理を終了する（ステップＳ７８）。
図３は、インスタンスフォーマット情報の一例を示したものである。ここでは、簡単な例として、インスタンス変数の属性情報とサイズ情報との一覧を用いる。属性情報とは、ＶＡＲ、ＶＡＲ＿ＩＮＰＵＴ、ＶＡＲ＿ＯＵＴＰＵＴを指し入力や出力の情報を意味する。サイズ情報とは、ＢＯＯＬ、ＩＮＴを指しデータ型によるメモリ占有サイズを指す（図８参照）。プログラマブルコントローラ支援装置の支援ツールで組み込みソフトウェアＦＢを作成中に、組み込みソフトウェアＦＢの変数構造より機械的に抽出可能なので、ユーザがこれらを意識的に用意する必要は無い。
インスタンスフォーマット情報の別の例として、例えば組み込みソフトウェアＦＢを作成時間（タイムスタンプ）を用いても構わない。或いは、ユーザが版数情報を直接用意し、入力しても構わない。このような簡易情報で代替えする事により、ステップＳ３６、Ｓ７８のプログラマブルコントローラにおける比較の処理時間軽減を優先しても構わない。
【００３６】
また、図１、２の説明ではインスタンスフォーマット情報をプログラムメモリ１３０に保存する方法を示したが、組み込みソフトウェアＦＢのオブジェクトコード１６、２６、アプリケーションソフトウェア１８、２８に直接埋め込む方式を用いても構わない。
以上、説明した構成を用いる事により、ユーザによる組み込みソフトウェアＦＢを汎用コントローラにおいて使用させつつ、アプリケーションソフトからの呼び出し時の異常等を回避することが可能となる。
【図面の簡単な説明】
【００３７】
【図１】本発明のプログラマブルコントローラシステムにおける組み込みソフトウェアＦＢ（システムＦＢ）の処理フローチャート
【図２】本発明のプログラマブルコントローラシステムにおける組み込みソフトウェアＦＢ（ユーザＦＢ）の処理フローチャート
【図３】インスタンスフォーマット情報の一例を示す説明図
【図４】プログラマブルコントローラシステムの構成の一例を示す説明図
【図５】プログラマブルコントローラの概略ハード構成を示す説明図
【図６】プログラマブルコントローラ支援装置の概略ハード構成を示す説明図
【図７】ファンクションブロックの入出力概略の一例を示す説明図
【図８】ファンクションブロックのインスタンスの構成の一例を示す説明図
【図９】ＦＢを呼び出すプログラムの一例を示す説明図
【図１０】図９（ａ）で示すプログラム（ＰＧ０）の擬似的なプログラムコードを示す説明図
【図１１】図９（ｂ）で示すプログラム（ＰＧ１）の擬似的なプログラムコードを示す説明図
【図１２】システムＦＢの処理の一例を示す概略フローチャート
【図１３】ユーザＦＢの処理の一例を示す概略フローチャート
【図１４】支援ツールのＰＯＵ選択画面を示す説明図
【図１５】組み込みソフトウェアＦＢの編集画面の一例を示した説明図
【図１６】組み込みソフトウェアＦＢの雛形の一例を示した説明図
【図１７】システムＦＢテーブルの一例を示す説明図
【図１８】ユーザＦＢテーブルの一例を示す説明図
【図１９】従来のプログラマブルコントローラシステムにおける組み込みソフトウェアＦＢ（システムＦＢ）の処理フローチャート
【図２０】従来のプログラマブルコントローラシステムにおける組み込みソフトウェアＦＢ（ユーザＦＢ）の処理フローチャート
【符号の説明】
【００３８】
１０、２０…組み込みソフトウェアＦＢの雛形
１２、２２…インスタンスフォーマット情報
１４…組み込みソフトウェアＦＢのシステムＦＢ番号
１６、２６…組み込みソフトウェアＦＢのオブジェクトコード
１８、２８…アプリケーションソフトウェア
３０…組み込みソフトウェアＦＢのユーザＦＢ番号
１００…パソコン
１０２、１０４、１０６、１２０…プログラマブルコントローラ
１０８…入出力モジュール
１１０…ケーブル
１１２…制御用ネットワーク
１２２…ドライバ／レシーバ
１２４…ＣＰＵ
１２６…バスコントローラ
１２８…フラッシュメモリ
１３０…プログラムメモリ
１３２…データメモリ
１３４…内部バス
１４０…プログラマブルコントローラ支援装置
１４２…ＣＰＵ
１４４…通信Ｉ／Ｆ
１４６…入力デバイス
１４８…表示デバイス
１５０…記憶装置
１５２…内部バス
１６０、１７０…ファンクションブロック本体
１６２、１７２…入力端子
１６４、１７４…出力端子
１８０、１９０…インスタンス
１８２、１８４、１９２、１９４…変数
２００〜２１０、２２０〜２３０、２４０〜２４２…コード
【図１】
2009245194.tif 000003
【図２】
2009245194.tif 000004
【図３】
2009245194.tif 000005
【図４】
2009245194.tif 000006
【図５】
2009245194.tif 000007
【図６】
2009245194.tif 000008
【図７】
2009245194.tif 000009
【図８】
2009245194.tif 000010
【図９】
2009245194.tif 000011
【図１０】
2009245194.tif 000012
【図１１】
2009245194.tif 000013
【図１２】
2009245194.tif 000014
【図１３】
2009245194.tif 000015
【図１４】
2009245194.tif 000016
【図１５】
2009245194.tif 000017
【図１６】
2009245194.tif 000018
【図１７】
2009245194.tif 000019
【図１８】
2009245194.tif 000020
【図１９】
2009245194.tif 000021
【図２０】
2009245194.tif 000022