JP2004280299A - コントローラ、開発装置及びシステム - Google Patents

Abstract

【課題】多くのリソースを必要としないコントローラであって、プログラミングモデルが固定化されておらず、かつ、複数のプログラミングモデルの混在が可能な柔軟性の高いコントローラを提供する。
【解決手段】アプリケーション層２０、フレームワーク層２１及び下位層２２から構成され、アプリケーション層２０は、下位のフレームワーク層２１によって生成され実行制御が行われるユーザが開発したプログラムであるオブジェクト（Ａ）及び（Ｂ）の集まりであり、フレームワーク層２１は、下位層２２によって生成され実行制御が行われる各種プログラミングモデルに対応したプログラムであるフレームワークオブジェクト（Ａ）及び（Ｂ）の集まりであり、下位層２２は、開発装置１０との通信に基づいて、各種プログラミングモデルに対応したフレームワークオブジェクト（Ａ）及び（Ｂ）を生成し実行制御するレイヤーである。
【選択図】 図４

Description

【０００１】
【発明の属する技術分野】
本発明は、機器を制御するコントローラ、そのコントローラで実行される制御プログラムを開発するための開発装置、及び、それらにより構成されるシステムに関する。
【０００２】
【従来の技術】
ＦＡ（Ｆａｃｔｏｒｙ Ａｕｔｏｍａｔｉｏｎ）を実現するために、工場等の製造現場では、ＰＬＣ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｃｏｎｔｒｏｌｌｅｒ）に代表される制御装置（以下、コントローラという。）が製造ライン等で使用される。コントローラは、ユーザによって開発された制御プログラムを開発装置からダウンロードして内蔵のメモリ等に保持し、その制御プログラムを実行することによって、接続された各種機器（デバイス）の状態を監視したり制御したりする。
【０００３】
このような制御プログラムの開発においては、高い生産性が求められる。特に、製造ラインにおいては、高いタクトを実現する効率的な制御プログラムが短期間で開発されることが求められる。また、製造ラインを構成する機器が新たな別種の機種に交換されたり、製造ラインを変更すべく機器が増設されたりしたときには、制御プログラムの改訂や追加作業等によって、可能な限り短期間で、製造ラインを再構築することが要求される。そのために、従来より、コントローラ用のプログラムの開発における生産性を向上させる各種開発手法が提案されている（たとえば、特許文献１参照）。
【０００４】
図２６は、上記特許文献１に開示されたシステムの構成を示す図である。このシステムは、コントローラ５０とツール５５により構成され、コントローラ５０にはデバイス５６が接続される。デバイス５６は制御プログラム５１により制御される。制御プログラム５１が実行されることによって、デバイス５６の通信アドレス、割り付けられたメモリアドレス等とデバイス名を関連付けた関連情報をオブジェクトデータベース５３に格納する。デバイス５６にアクセスする際には、デバイス名をキーに関連情報を参照し、具体的なアクセス先を認識することによりデータの送受を行う。再利用する際には、制御プログラム５１の変更をすることなく、各アドレスを再利用先のものに修正するだけで対応する。
【０００５】
つまり、この従来の開発手法では、デバイスごとに、固有のソフトとハードとを一体でオブジェクトとして扱い、複数のデバイスに対応するオブジェクト群を組み合わせることにより、制御システムを構築する。これによって、制御プログラムとデバイスとが一体でオブジェクトとして扱われ、再利用が容易かつ確実に行え、プログラムの開発における生産性が向上されるというものである。
【０００６】
【特許文献１】
特開２００２−２６８７０７号公報（第７頁、第３図等）
【０００７】
【発明が解決しようとする課題】
しかしながら、上記従来のシステムでは、コントローラのプログラミングモデルが予め固定されているために、以下のような問題がある。なお、プログラミングモデルとは、コントローラにおいて、ユーザが作成したプログラム（上記従来技術におけるオブジェクト）をどのような条件、タイミング、順番で実行するか、またコントローラの入出力をどのようなタイミングで行うかといった制御のことであり、同じ制御内容でもその制御方式、例えば、プログラムをスキャン実行するとともに入出力をＩ／Ｏ一括リフレッシュするいわゆるＰＬＣ方式、ＳＦＣ（Ｓｅｑｕｅｎｔｉａｌ Ｆｕｎｃｔｉｏｎ Ｃｈａｒｔ）に従ってプログラムを歩進的に実行するいわゆるＳＦＣ方式等に対応するプログラミングモデルがある（このようなコントローラの制御方式は、ユーザから見た場合に、どのようにプログラムを作成する（実行される）かということに関係するため、ユーザプログラミングモデルとも呼ぶ。）。
【０００８】
第１に、図２７（ａ）に示されるように、あるプログラミングモデル（コントローラＡ用のプログラミングモデル）で開発したプログラム（オブジェクトＡ）をそのまま別のプログラミングモデルのコントローラＢで動作させることができない。それは、各コントローラが持つ個別情報（号機番号、ネットワークアドレス、メモリ割付け等）が異なり、同じプログラムのままだとその個別情報の違いによって互換できないからである。従って、プログラム（オブジェクト）の再利用性がないという問題がある。
【０００９】
同様に、図２７（ｂ）に示されるように、同一のコントローラＡを使って異なるプログラミングモデル（例えば、コントローラＡ用のプログラミングモデルＰ１とは異なるプログラミングモデルＰ２）でプログラム（オブジェクトＢ）を実行させたい場合でも、既に存在するコントローラ（ハードウェア）Ａはプログラミングモデルが固定（Ｐ１）であるゆえ、このような他のプログラミングモデルのもとに開発されたプログラムの再利用ができない。また、プログラミングモデルごとにコントローラ（ハードウェア）が必要であり、コントローラを再利用することもできないという問題がある。このことは、システムの環境問題がクローズアップされる今日では望ましくない。
【００１０】
第２に、複数のプログラミングモデルを予めコントローラに組み込んでおくことで複数のプログラミングモデルに対応したコントローラを実現する方法が考えられるが、このような方法では、予め組み込んでおくプログラミングモデルの種類分だけコントローラのリソースが必要とされるという問題がある。つまり、複数のプログラミングモデルに対応した複数のハードウェアや複数のファームウェア等のリソースを組み込んでおく必要があり、極めて多くのリソースがコントローラ内に必要とされる。
【００１１】
第３に、アプリケーションによっては、コントローラのメーカが想定しているユーザプログラミングモデルでは対応できない、あるいは、対応できたとしてもプログラミングが冗長になってしまうというケースが存在する。つまり、プログラミングモデルが固定であるということは、メーカ側がユーザプログラミングモデルを想定してユーザに提供するということなので、ユーザのプログラム開発の生産性を向上させている反面、ユーザにとっては却って制約となり、アプリケーションによっては必要な制御を実現することができないか、あるいは、冗長なプログラミングになってしまうという問題がある。
【００１２】
第４に、アプリケーションによっては、複数のプログラミングモデルを１つのコントローラで動作させ、かつ、異なるプログラミングモデル間のプログラムどうしが情報交換をするような制御システムを構築したいという要求があるが、このようなケースに対応できないという問題がある。
【００１３】
そこで、本発明は、このような状況に鑑みてなされたものであり、多くのリソースを必要としないコントローラであって、プログラミングモデルが固定化されておらず、かつ、複数のプログラミングモデルの混在が可能な柔軟性の高いコントローラ、開発装置及びシステムを提供することを目的とする。つまり、ユーザにとって、コントローラの種類に依存することなく、所望のプログラミングモデルによるプログラムの開発をすることができるとともに、コントローラに実装させるプログラミングモデルを任意に選択することができ、さらに、１つのコントローラに対して複数のプログラミングモデルに対応したプログラムを混在させて実行させることができる高機能かつ柔軟性の高いコントローラ、開発装置及びシステムを提供することを目的とする。
【００１４】
【課題を解決するための手段】
上記目的を達成するために、本発明に係るコントローラは、機器を制御するコントローラであって、制御の流れを管理する第１フレームワーク手段と、前記第１フレームワーク手段による管理の下で前記機器に対する制御処理を実行する第１アプリケーション手段とを備えることを特徴とする。ここで、前記第１フレームワーク手段は、前記第１アプリケーション手段による制御処理の実行に関する条件、タイミング、順番、及び、前記機器との入出力に関するタイミングの少なくとも１つを管理する機能を備え、例えば、前記制御処理の実行をスキャン方式で行うとともに前記機器との入出力を一括Ｉ／Ｏリフレッシュ方式で行うことによって制御の流れを管理する第１の方式、シーケンス・ファンクション・チャートに従って制御の流れを管理する第２の方式、フローチャートに従って制御の流れを管理する第３の方式、状態遷移表に従って制御の流れを管理する第４の方式、イベント・ドリブン方式に従って制御の流れを管理する第５の方式の少なくとも１つの方式で前記制御の流れを管理する。
【００１５】
つまり、コントローラにおけるソフトウェアの構成として、各種制御方式（プログラミングモデル）に依存する処理を実行するフレームワーク層と、制御方式に依存しない制御ロジックを記述したアプリケーション層とに分離し、フレームワーク層の上でアプリケーション層を実行させる階層構造となっている。
【００１６】
これによって、ユーザが開発するアプリケーションは、プログラミングモデルに依存しない処理ロジックだけを規定するとともに、各種プログラミングモデルの管理下で実行されることとなるので、特定のプログラミングモデルだけに特化した従来のプログラムと異なり、各種コントローラや各種プログラミングモデル用のプログラムとして再利用することが可能となり、開発の生産性が向上される。
【００１７】
なお、「制御の流れ」とは、コントローラが機器を制御するときの制御方式の意味を含む。例えば、実施の形態におけるＰＬＣ方式、ＳＦＣ方式、フローチャート方式、状態遷移方式及びイベント・ドリブン方式等の各制御方式に固有する制御の流れである。この「制御の流れ」を管理する第１フレームワーク手段は、例えば、実施の形態におけるフレームワークあるいはフレームワーク層におけるフレームワークオブジェクトに相当する。また、「機器に対する制御処理」とは、「制御の流れ」に依存しない具体的な制御ロジックを意味し、例えば、実施の形態におけるアプリケーションあるいはアプリケーション層におけるオブジェクトに相当する。
【００１８】
ここで、前記コントローラには、開発装置が接続され、前記コントローラは、さらに、前記開発装置から情報をダウンロードするダウンロード手段と、前記ダウンロード手段によってダウンロードされた情報に基づいて、前記第１フレームワーク手段と異なる方式で前記制御の流れを管理する第２フレームワーク手段を前記コントローラに追加すること、及び、前記第１フレームワーク手段を、当該第１フレームワーク手段と異なる方式で前記制御の流れを管理する第２フレームワーク手段に置き換えることの少なくとも一方を行う第１更新手段とを備えてもよい。そして、前記第１更新手段は、前記第１アプリケーション手段を前記コントローラに保持させた状態で、前記第２フレームワーク手段の追加及び置き換えの少なくとも一方を行うようにしてもよい。
【００１９】
つまり、コントローラは、アプリケーション層を変更することなく、フレームワーク層だけを追加したり入れ替えたりする機能を備える。これによって、ユーザは、メーカから提供されるプログラミングモデルに拘束されることなく、独自のプログラミングモデルを開発し、コントローラに実装させることができる。また、ユーザが開発したアプリケーションをそのままコントローラに残したまま、プログラミングモデルを変更して新たな制御方式による制御をコントローラに実行させることができる。したがって、特に、制御方式の変更を伴う制御システムの設計変更や再構築においては、極めて短い期間で開発を終えることができる。
【００２０】
さらに、１つのコントローラに複数の異なるプログラミングモデルを実装させ、アプリケーションごとに異なる制御方式による制御を混在させることも可能となり、高機能かつ複雑な制御システムの構築が可能となる。
【００２１】
また、このようなフレームワークだけの追加・変更と同様に、アプリケーションだけの追加・変更も行うことができる。つまり、前記コントローラには、開発装置が接続され、前記コントローラは、さらに、前記開発装置から情報をダウンロードするダウンロード手段と、前記ダウンロード手段によってダウンロードされた情報に基づいて、前記第１アプリケーション手段と異なる制御処理を実行する第２アプリケーション手段を前記コントローラに追加すること、及び、前記第１アプリケーション手段を、当該第１アプリケーション手段と異なる制御処理を実行する第２アプリケーション手段に置き換えることの少なくとも一方を行う第２更新手段とを備えてもよい。そして、前記第２更新手段は、前記第１フレームワーク手段を前記コントローラに保持させた状態で、前記第１アプリケーション手段の追加及び置き換えの少なくとも一方を行うようにしてもよい。
【００２２】
これによって、ユーザは、コントローラに保持されたプログラミングモデルを残したまま、そのコントローラに、新たなアプリケーションを追加したりアプリケーションだけを入れ替えたりすることができるので、従来のように制御プログラム全体を更新することなくコントローラの機能変更や機能追加をすることができ、制御システムの設計変更や再構築における労力が軽減される。
【００２３】
なお、本発明は、このようなコントローラとして実現することができるだけでなく、このようなコントローラのためのアプリケーションやフレームワークを開発する開発装置として実現したり、それらコントローラと開発装置とからなるシステムとして実現したり、コントローラ及び開発装置を構成する各手段をコンピュータに機能させるプログラムとして実現することもできる。
【００２４】
たとえば、本発明は、機器を制御するコントローラで実行される制御プログラムを開発するための開発装置であって、前記制御プログラムには、前記機器に対する制御の流れを規定したプログラミングモデル情報と、前記機器に対する制御処理を規定したプログラムであるオブジェクトとが含まれ、前記コントローラは、前記プログラミングモデル情報によって規定される制御の流れの下で前記オブジェクトを実行する装置であり、前記開発装置は、ユーザからの指示に従って前記プログラミングモデル情報を作成するプログラミングモデル情報作成手段と、ユーザからの指示に従って前記オブジェクトを作成するオブジェクト作成手段と、作成された前記プログラミングモデル情報及び前記オブジェクトの少なくとも一方を前記コントローラにダウンロードするダウンロード手段とを備えることを特徴とする開発装置として実現することもできる。具体的には、図３に示される各種開発フローを支援する開発装置として実現することができる。
【００２５】
ここで、前記プログラミングモデル情報は、前記オブジェクトの実行に関する条件、タイミング、順番、及び、前記機器との入出力に関するタイミングの少なくとも１つを規定している、例えば、前記機器に対する制御の実行をスキャン方式で行うとともに前記機器との入出力を一括Ｉ／Ｏリフレッシュ方式で行うことによって制御の流れを管理する第１の方式、シーケンス・ファンクション・チャートに従って制御の流れを管理する第２の方式、フローチャートに従って制御の流れを管理する第３の方式、状態遷移表に従って制御の流れを管理する第４の方式、イベント・ドリブン方式に従って制御の流れを管理する第５の方式の少なくとも１つの方式で前記制御の流れを規定している。
【００２６】
そして、前記ダウンロード手段は、前記コントローラにプログラミングモデル情報が予め格納されている場合には、前記プログラミングモデル情報作成手段で作成された新たなプログラミングモデル情報を前記コントローラに追加すること、及び、前記コントローラに予め格納されているプログラミングモデル情報を、前記プログラミングモデル情報作成手段で作成された新たなプログラミングモデル情報で置き換えることの少なくとも一方を行ってもよい。このとき、前記コントローラにオブジェクトが予め格納されている場合には、当該オブジェクトを前記コントローラに保持させた状態で、前記プログラミングモデル情報の追加及び置き換えの少なくとも一方を行えばよい。
【００２７】
また、前記ダウンロード手段は、前記コントローラにオブジェクトが予め格納されている場合には、前記オブジェクト作成手段で作成された新たなオブジェクトを前記コントローラに追加すること、及び、前記コントローラに予め格納されているオブジェクトを、前記オブジェクト作成手段で作成された新たなオブジェクトで置き換えることの少なくとも一方を行ってもよい。このとき、前記コントローラにプログラミングモデル情報が予め格納されている場合には、当該プログラミングモデル情報を前記コントローラに保持させた状態で、前記オブジェクトの追加及び置き換えの少なくとも一方を行えばよい。
【００２８】
さらに、本発明は、従来では一体となって開発された制御プログラムを制御方式に依存するフレームワーク層と制御方式に依存しないアプリケーション層とに分離して開発し、コントローラにおいて、フレームワーク層の上でアプリケーション層を実行させるというコントローラ用制御プログラムの開発支援手法として実現することもできる。
【００２９】
【発明の実施の形態】
以下、本発明の実施の形態について図面を用いて詳細に説明する。
図１は、本発明に係るシステム１の全体構成を示す図である。このシステム１は、開発装置１０、コントローラ１２、デバイス１４ａ〜１４ｃ、開発装置１０とコントローラ１２とを接続するネットワーク１１、及び、コントローラ１２とデバイス１４ａ〜１４ｃとを接続するネットワーク１３から構成される。
【００３０】
デバイス１４ａ〜１４ｃは、製造ライン等を構成する入出力装置である。もう少し言うと、一般に入力装置は、接点動作によりオンオフするスイッチ、無接点の光電スイッチや近接スイッチがある。ほかに圧力センサや変位センサなどの計測器も含まれる。出力装置は、制御対象物に関わる装置であり、温度を制御する温度調節器もそのひとつである。またコントローラによって制御されるロボット、モータなども出力装置に含まれる。 コントローラ１２は、デバイス１４ａ〜１４ｃをハンドリングするＰＬＣ等の制御装置であり、図２に示される階層構造のように、下位層より、ハードウェア１２ｅ、ハードウェア抽象化層１２ｄ、ソフトウェア抽象化層１２ｃ、フレームワーク１２ｂ及びアプリケーション１２ａから構成される。
【００３１】
ハードウェア１２ｅは、コントローラ１２を構成するＭＰＵ、メモリ、通信チップ等のハードウェアである。ハードウェア抽象化層１２ｄは、ハードウェアを管理・制御するＲＴＯＳ（ＲｅａｌＴｉｍｅ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）等の基本ＯＳである。ソフトウェア抽象化層１２ｃは、各種ＲＴＯＳ等の基本ＯＳの相違を吸収するＪＶＭ（Ｊａｖａ（登録商標） Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）等の仮想プロセッサである。フレームワーク１２ｂは、プログラミングモデルを規定するミドルソフトである。アプリケーション１２ａは、ユーザが開発するプログラム（オブジェクト）であり、プログラミングモデルに依存しない処理ロジックを規定するように開発される。なお、本実施の形態では、フレームワーク１２ｂとソフトウェア抽象化層１２ｃとを併せて「アプリケーションフレームワーク１２ｆ」と呼ぶ。
【００３２】
開発装置１０は、ユーザがアプリケーション１２ａ及びアプリケーションフレームワーク１２ｆを開発するのに使用する装置であり、ここでは、コンピュータ装置等のハードウェアだけでなく、開発のためのソフトウェアツール等を含めた開発環境である。
【００３３】
図３は、開発装置１０における各種開発フロー、つまり、各種ケースにおけるユーザによる開発作業の流れを示すフローチャートである。
コントローラ１２内にプログラム（アプリケーション１２ａ）及びアプリケーションフレームワーク１２ｆが存在せず、かつ、アプリケーションフレームワーク１２ｆがメーカから予め複数用意されている場合には、図３（ａ）に示されるように、ユーザは、それら複数のアプリケーションフレームワーク１２ｆの中から所望のものを選択し（Ｓ１０）、プログラム（アプリケーション１２ａ）を開発した後に（Ｓ１１）、それらアプリケーションフレームワーク１２ｆ及びプログラム（アプリケーション１２ａ）をコントローラ１２にダウンロードする（Ｓ１２）。なお、上記ステップＳ１０とＳ１１とは、どちらが先でもよい。
【００３４】
また、コントローラ１２内にプログラム（アプリケーション１２ａ）及びアプリケーションフレームワーク１２ｆが存在せず、かつ、アプリケーションフレームワーク１２ｆをユーザが開発する場合には、図３（ｂ）に示されるように、ユーザは、アプリケーションフレームワーク１２ｆとプログラム（アプリケーション１２ａ）とを開発した後に（Ｓ１５、Ｓ１６）、それらアプリケーションフレームワーク１２ｆ及びプログラム（アプリケーション１２ａ）をコントローラ１２にダウンロードする（Ｓ１７）。なお、上記ステップＳ１５とＳ１６とは、どちらが先でもよい。
【００３５】
また、コントローラ１２内に既にプログラム（アプリケーション１２ａ）が存在し、かつ、後からアプリケーションフレームワーク１２ｆをコントローラ１２にダウンロードする場合には、図３（ｃ）に示されるように、ユーザは、アプリケーションフレームワーク１２ｆを開発又は変更した後に（Ｓ２０）、そのアプリケーションフレームワーク１２ｆをコントローラ１２にダウンロードする（Ｓ２１）。なお、ここでの「アプリケーションフレームワーク１２ｆの変更」とは、ＪＶＭ等のソフトウェア抽象化層１２ｃを変更することなく、フレームワーク１２ｂを変更することである。
【００３６】
また、コントローラ１２内に既にアプリケーションフレームワーク１２ｆが存在し、かつ、後からプログラム（アプリケーション１２ａ）をコントローラ１２にダウンロードする場合には、図３（ｄ）に示されるように、ユーザは、プログラム（アプリケーション１２ａ）を開発した後に（Ｓ２５）、そのプログラム（アプリケーション１２ａ）をコントローラ１２にダウンロードする（Ｓ２６）。
【００３７】
なお、図３（ａ）〜（ｄ）に示された開発フローは一例であり、アプリケーションフレームワーク１２ｆのダウンロードとプログラム（アプリケーション１２ａ）のダウンロードとは、それぞれ、図３（ｅ）及び図３（ｆ）に示されるように、独立に行うことが可能であり、順序を問わない。
【００３８】
図４は、コントローラ１２の機能ブロック図である。コントローラ１２は、機能的に、大きく３つのレイヤー、つまり、アプリケーション層２０、フレームワーク層２１及び下位層２２から構成される。
【００３９】
アプリケーション層２０は、図２に示されたアプリケーション１２ａに相当し、下位のフレームワーク層２１によって生成され実行制御が行われるプログラムであるオブジェクト（Ａ）及び（Ｂ）の集まりである。これらオブジェクト（Ａ）及び（Ｂ）は、ユーザが開発するプログラムであり、その種類として、プログラムオブジェクト、タスクオブジェクト及びデバイスオブジェクト等がある。
【００４０】
プログラムオブジェクトは、制御ロジック等を記述したオブジェクトであり、Ｊａｖａ（登録商標）言語であれば、Ｊａｖａ（登録商標）のクラスに相当する。タスクオブジェクトは、マルチタスクシステムにおけるタスクを記述したオブジェクトである。デバイスオブジェクトは、いわゆるドライバに相当し、プログラムオブジェクト内で、物理デバイス（デバイス１４ａ〜１４ｃ）にアクセスする場合に、物理デバイスににアクセスするために用いられるオブジェクトである。
【００４１】
フレームワーク層２１は、図２に示されたフレームワーク１２ｂに相当し、下位層２２によって生成され実行制御が行われるプログラムであるフレームワークオブジェクト（Ａ）及び（Ｂ）の集まりである。これらフレームワークオブジェクト（Ａ）及び（Ｂ）は、それぞれ、特定のプログラミングモデルに対応したオブジェクトであり、図３のフローに示されるように、ユーザによって独自に開発される場合と、メーカ側から予め用意される場合とがある。
【００４２】
メーカ側から予め用意されるフレームワークとして、図５（ａ）に示されるいわゆるＰＬＣ方式のフレームワーク、図５（ｂ）に示されるいわゆるＳＦＣ方式のフレームワーク、図５（ｃ）に示されるいわゆるフローチャート方式のフレームワーク、図５（ｄ）に示されるいわゆる状態遷移方式のフレームワーク、図５（ｅ）に示されるいわゆるイベントドリブン方式のフレームワーク等がある。
【００４３】
ここで、ＰＬＣ方式のフレームワークは、物理デバイス（デバイス１４ａ〜１４ｃ）とのデータ交換を一括Ｉ／Ｏリフレッシュ方式で行い、タスクオブジェクト（プログラムオブジェクト）の実行をスキャン方式で行う制御の流れを規定したフレームワークである。ＳＦＣ方式、フローチャート方式及び状態遷移方式のフレームワークは、それぞれ、ＳＦＣ、フローチャート及び状態遷移表に従った制御の流れを規定したフレームワークである。イベントドリブン方式のフレームワークは、物理デバイス（デバイス１４ａ〜１４ｃ）からの入力値で定義される条件が成立したときに対応するプログラムオブジェクトを起動させる旨を記述したイベント表に従った制御の流れを規定したフレームワークである。
【００４４】
下位層２２は、開発装置１０との通信に基づいて、各種プログラミングモデルに対応したフレームワークオブジェクト（Ａ）及び（Ｂ）を生成し実行制御するレイヤーであり、通信制御部２２ａ、記憶部２２ｂ及びフレームワーク制御部２２ｃから構成される。
【００４５】
通信制御部２２ａは、開発装置１０からダウンロードされてくる各種情報を記憶部２２ｂに格納したり、その情報に従ってフレームワーク制御部２２ｃを制御する通信インターフェース等である。
【００４６】
フレームワーク制御部２２ｃは、通信制御部２２ａからの指示及び記憶部２２ｂにダウンロードされた各種情報に基づいて、フレームワークオブジェクト（Ａ）及び（Ｂ）を生成し実行制御する処理部である。
【００４７】
記憶部２２ｂは、開発装置１０からダウンロードされてくる各種情報（システムコンフィグレーション情報３０、フレームワーク情報３１及び３２、オブジェクトコンフィグレーション情報３３ａ及び３３ｂ、オブジェクト情報３４ａ及び３４ｂ等）を記憶するためのメモリ等であり、コントローラ１２の電源がＯＦＦの場合でも記憶内容を保持する不揮発性メモリ等からなる。
【００４８】
システムコンフィグレーション情報３０は、コントローラ１２に登録しておくフレームワークに関する情報であり、具体的には、（ｉ）フレームワークの数、（ｉｉ）フレームワークオブジェクトファイル３１ａのファイル名等が含まれる。
【００４９】
フレームワーク情報３１及び３２は、フレームワークの実体に相当する情報であり、フレームワークオブジェクトファイル３１ａ及びフレームワークコンフィグレーション情報３１ｂからなる。フレームワークオブジェクトファイル３１ａは、フレームワークの処理が記述されたオブジェクトファイルであり、例えば、Ｊａｖａ（登録商標）言語であれば、フレームワークの処理を実装したｃｌａｓｓファイルに相当する。フレームワークコンフィグレーション情報３１ｂは、フレームワークを実行する上での各種条件等を記述した情報であり、例えば、フレームワークを実行するスレッド、タスクの優先順位等の情報が含まれる。
【００５０】
オブジェクトコンフィグレーション情報３３ａ及び３３ｂは、フレームワークとオブジェクトの関係を記述した情報であり、例えば、フレームワークで実行するオブジェクトの数、オブジェクトファイル名等の情報が含まれる。なお、このオブジェクトコンフィグレーション情報３３ａ及び３３ｂは、フレームワークに依存する情報であり、フレームワークの種類により、情報の内容は異なる。
【００５１】
オブジェクト情報３４ａ及び３４ｂは、アプリケーション層２０で実行させるオブジェクト（Ａ）及び（Ｂ）に関する情報であり、（ｉ）オブジェクトファイルと、（ｉｉ）オブジェクト設定ファイルとから構成される。オブジェクトファイルは、オブジェクトの処理が記述されたプログラムであり、例えば、Ｊａｖａ（登録商標）言語であれば、オブジェクトの処理を実装したｃｌａｓｓファイルに相当する。オブジェクト設定ファイルは、対応するオブジェクトに関する属性が記述されたファイルであり、例えば、対象のオブジェクトがデバイスオブジェクトである場合には、そのインスタンス名及び通信アドレス等が記述され、タスクオブジェクトである場合には、そのインスタンス名、タスクに登録されているプログラムオブジェクトの名前及びタスクオブジェクトの優先度等が記述され、プログラムオブジェクトである場合には、そのインスタンス名等が記述される。
【００５２】
図６は、以上のように構成されたシステム１におけるコントローラ１２の動作手順を示すフローチャートである。なお、このフローチャートの各ステップに付された符号は、図４における対応する矢印にも付されている。
【００５３】
まず、通信制御部２２ａは、開発装置１０からダウンロードされてきた各種情報３０〜３４ｂを記憶部２２ｂに格納する（Ｓ４０）。
次に、開発装置１０から開始指示を受信した時、あるいは、コントローラ１２の電源がＯＮとなった時に、フレームワーク制御部２２ｃは、記憶部２２ｂに格納されたシステムコンフィグレーション情報３０を参照することで（Ｓ４１）、ロードすべきフレームワーク、つまり、起動すべきフレームワークを決定した後に、決定したフレームワークに対応するフレームワーク情報３１及び３２をロードする、つまり、記憶部２２ｂから読み出す（Ｓ４２）。そして、フレームワーク制御部２２ｃは、読み出したフレームワーク情報３１及び３２をもとに、フレームワークオブジェクト（Ａ）及び（Ｂ）を生成する（Ｓ４３）。
【００５４】
生成されたフレームワークオブジェクト（Ａ）及び（Ｂ）は、それぞれ、フレームワーク依存の情報であるオブジェクトコンフィグレーション情報３３ａ及び３３ｂを参照することで（Ｓ４４）、オブジェクトの数や起動すべきオブジェクトファイル名等を決定し、決定したオブジェクトファイル名に対応するオブジェクト情報３４ａ及び３４ｂをロードする、つまり、記憶部２２ｂから読み出す（Ｓ４５）。そして、フレームワークオブジェクト（Ａ）及び（Ｂ）は、読み出したオブジェクト情報３４ａ及び３４ｂをもとに、オブジェクト（Ａ）及び（Ｂ）を生成する（Ｓ４６）。
【００５５】
続いて、開発装置１０からフレームワークを実行する旨の開始指示が発せられると、その開始指示は、通信制御部２２ａを介してフレームワーク制御部２２ｃに伝えられる。そして、その開始指示を受けたフレームワーク制御部２２ｃは、フレームワークオブジェクト（Ａ）及び（Ｂ）に対して処理の実行を指示する。その指示を受けたフレームワークオブジェクト（Ａ）及び（Ｂ）は、フレームワークの処理を実行する（Ｓ４７）。
【００５６】
以降、フレームワークオブジェクト（Ａ）及び（Ｂ）は、開発装置１０からフレームワークオブジェクト（Ａ）及び（Ｂ）宛に送られてきた命令（つまり、通信制御部２２ａ及びフレームワーク制御部２２ｃを介して送られてくる命令）に従った処理を行う。例えば、フレームワーク１２ｂ上のアプリケーション１２ａ、つまり、オブジェクト（Ａ）及び（Ｂ）の起動や停止等を行う。
【００５７】
以上のように、本実施の形態のシステム１におけるコントローラ１２によれば、ＦＡ等を実現する制御プログラムは、ユーザプログラミングモデルに依存する制御フローを記述したアプリケーションフレームワーク１２ｆと、ユーザプログラミングモデルに依存しない制御ロジックを記述したアプリケーション１２ａとに階層的に分離されている。したがって、各アプリケーション１２ａを、様々な種類のユーザプログラミングモデルに対応するアプリケーションフレームワーク１２ｆの上で実行させることができる。よって、ユーザが開発したアプリケーション１２ａは、ユーザプログラミングモデルの種類に依存することなく独立した処理モジュールとして利用することが可能であり、ユーザプログラミングモデルを変更した場合においても、再利用することができる。
【００５８】
次に、以上の実施の形態に係るシステム１の具体的な実現例を示す実施例について説明する。
（実施例１）
まず、アプリケーション１２ａについてはユーザが開発し、アプリケーションフレームワーク１２ｆについてはメーカが用意した複数のアプリケーションフレームワークから選択することによって制御プログラムを構築し、構築した制御プログラムをコントローラ１２に実行させる実施例１について説明する。この実施例１は、図３（ａ）のフローチャートに示されるケースの具体例に相当する。なお、本実施例１におけるシステム１の全体構成は、図１に示されたものと同一である。
【００５９】
図７は、実施例１におけるユーザによる作業手順を中心したフローチャートである。
ユーザは、まず、開発装置１０において、以下に示す初期開発の作業を行う（Ｓ５０）。つまり、ユーザは制御システムの構成を定義する（Ｓ５０ａ）。例えば、コントローラ１２に接続される物理デバイスを決定し、その旨を開発装置１０に指示する。本実施例では、図８に示されるように、コントローラ１２にネットワーク（ＤｅｖｉｃｅＮｅｔ）１３を介してデバイスＡ１４ｄ、デバイスＢ１４ｅ、デバイスＣ１４ｆが接続されているとする。
【００６０】
次に、ユーザは、デバイスオブジェクトを定義する（図７のＳ５０ｂ）。具体的には、コントローラ１２に接続される物理デバイス（デバイスＡ〜Ｃ）をアクセスするデバイスオブジェクトを選択、あるいは、開発する。本実施例では、図９の画面表示例に示されるように、開発装置１０との対話によって、デバイスＡ１４ｄ、デバイスＢ１４ｅ、デバイスＣ１４ｆに対する（予め、メーカで用意された）デバイスオブジェクトを選択し、そのデバイスオブジェクトに名前をつけている。ここでは、デバイスＡ１４ｄに対して”ＲｏｂｏｔＡ”、デバイスＢ１４ｅに対し”ＲｏｂｏｔＢ”、デバイスＣ１４ｆに対し”ＲｏｂｏｔＣ”という名前を付けている。
【００６１】
このようなデバイスオブジェクトの定義によって、開発装置１０により、以下のオブジェクトファイル（デバイスオブジェクトファイル）及びオブジェクト設定ファイル（デバイスオブジェクト設定ファイル）からなるオブジェクト情報３４ａ及び３４ｂが生成される。つまり、オブジェクトファイルは、ここでは、デバイスの処理を実装したＪａｖａ（登録商標）のｃｌａｓｓファイルであり、ＤｅｖｉｃｅＡ．ｃｌａｓｓ、ＤｅｖｉｃｅＢ．ｃｌａｓｓ、ＤｅｖｉｃｅＣ．ｃｌａｓｓというファイルである。また、オブジェクト設定ファイルは、図１０に示されるように、ここでは、デバイス名及びネットワークアドレスをデバイス毎に格納したＸＭＬ等のテキストファイルである。
【００６２】
次に、ユーザは、フレームワークを選択する（図７のＳ５０ｃ）。つまり、メーカが予め用意している複数のフレームワークの中からユーザが使用するフレームワークを選択する。選択された情報は、システムコンフィグレーション情報３０及びフレームワーク情報３１及び３２として格納され、コントローラ１２へのダウンロードの対象となる。
【００６３】
例えば、図１１の画面表示例に示されるように、ユーザがＰＬＣ方式のフレームワークを１つだけ選択した場合には、システムコンフィグレーション情報３０には、図１２に示されるように、システムでフレームワークが１つあり、そのフレームワークを実装したフレームワークオブジェクトファイル３１ａがＰｌｃ．ｃｌａｓｓである旨の情報が格納される。そして、開発装置１０により、以下のフレームワークオブジェクトファイル３１ａ及びフレームワークコンフィグレーション情報３１ｂからなるフレームワーク情報３１が生成される。つまり、フレームワークオブジェクトファイル３１ａは、ＰＬＣのフレームワーク処理を実装したＪａｖａ（登録商標）のｃｌａｓｓファイルであり、ここでは、Ｐｌｃ．ｃｌａｓｓというファイルである。また、フレームワークコンフィグレーション情報３１ｂは、例えば、図１３に示されるように、ＰＬＣのフレームワークを実装するＪａｖａ（登録商標）スレッドの優先度が４であることを示す情報が格納されたファイルである。
【００６４】
続いて、ユーザは、プログラムオブジェクトを定義する（５０ｄ）。言語がＪａｖａ（登録商標）であれば、Ｊａｖａ（登録商標）ファイルを編集することになり、Ｃ＋＋言語であれば、＊．ｈファイル、ｃｐｐファイルを編集することになる。編集後に、各ファイルは、Ｂｕｉｌｄされて実行形式となる（Ｊａｖａ（登録商標）の場合は、ｃｌｓｓファイル、Ｃ＋＋の場合は、．ｏファイルとなる）。なお、上記手順で選択したフレームワークにより、実装すべきメソッド（関数）が決まる。
【００６５】
ここでは、例えば、図１４の画面表示例（ダイアログ）に示されるように、プログラムオブジェクト名として”ＵｓｅｒＰｒｏｇｒａｍ１”を、インスタンス名として”Ｓｔａｔｅ１”を入力する。このような設定により、図１５に示されるようなオブジェクトファイルが生成される。なお、プログラムオブジェクトの制御ロジックを記述するには、ｅｘｅｃｕｔｅメソッドを編集すればよい。また、併せて、図１６に示されるようなインスタンス名等に関する情報がプログラムオブジェクト毎に格納されたＸＭＬ等のテキストファイルが、オブジェクト設定ファイルとして生成される。
【００６６】
次に、ユーザは、タスクオブジェクトを定義する（図７のＳ５０ｅ）。言語がＪａｖａ（登録商標）であれば、Ｊａｖａ（登録商標）ファイルを編集することになり、Ｃ＋＋言語であれば、＊．ｈファイル、ｃｐｐファイルを編集することになる。例えば、タスクオブジェクトに関する情報として、（ｉ）タスクに割り付けられているプログラムオブジェクト情報（プログラムオブジェクト名とその個数）や、（ｉｉ）タスク優先順位等を設定する。設定された情報は、オブジェクト情報３４ａ及び３４ｂの一部として記憶装置等に格納される。
【００６７】
例えば、ユーザは、図１７の画面表示例に示されるように、ダイアログに対して必要な情報を入力することによって、タスクオブジェクトを定義する。なお、１つのタスクオブジェクトに対して複数のプログラムオブジェクトを登録することが可能である。このようなダイアログの設定によって、オブジェクトファイル（タスクオブジェクトファイル）として、Ｊａｖａ（登録商標）の場合であれば、ｃｌａｓｓファイル、あるいは、Ｊａｖａ（登録商標）ファイルが生成される。さらに、オブジェクト設定ファイル（タスクオブジェクト設定ファイル）として、（ｉ）インスタンス名、（ｉｉ）タスクオブジェクトに登録されているプログラムオブジェクト名、（ｉｉｉ）タスク優先度、及び、（ｉｖ）タスクの種類等の情報が格納されたＸＭＬ等のファイルも生成される。
【００６８】
続いて、ユーザは、フレームワークとオブジェクトの関係を定義する（図７のＳ５０ｆ）。なお、この関係は、フレームワークに依存する情報である。本実施例では、ＰＬＣ方式のフレームワークが選択されているので、ユーザは、２種類の情報の設定、つまり、（ｉ）プログラムの実行に関する設定と、（ｉｉ）物理デバイスの入出力に関する設定とを行う。
【００６９】
まず、（ｉ）プログラムの実行に関する設定として、ユーザは、タスクオブジェクト名及びタスクオブジェクトの数、ここでは、タスクオブジェクト名として”ＵｓｅｒＴａｓｋ１”、タスクオブジェクトの数として１を設定する。設定された結果は、オブジェクトコンフィグレーション情報３３ａ等としてＸＭＬファイル等で記憶装置に格納される。
【００７０】
また、（ｉｉ）物理デバイスの入出力に関する設定として、図１８（ａ）の画面表示例に示されるように、ＩＮリフレッシュ（フレームワークの機能）でリードするデバイスの設定を行うとともに、図１８（ｂ）の画面表示例に示されるように、ＯＵＴリフレッシュ（フレームワークの機能）でライトするデバイスの設定を行う。なお、図１８（ａ）に示される画面表示例では、ＩＮリフレッシュの対象になるデバイスとして、デバイスＡ１４ｄ（名前：ＲｏｂｏｔＡ）、デバイスＢ１４ｅ（名前：ＲｏｂｏｔＢ）とすることを、開発装置１０で設定している例が示され、図１８（ｂ）に示される画面表示例では、ＯＵＴリフレッシュの対象になるデバイスとして、デバイスＣ１４ｆ（名前：ＲｏｂｏｔＣ）とすることを、開発装置１０で設定している例が示されている。
【００７１】
なお、物理デバイスの入出力に関する設定を行わない場合、つまり、ポーリング方式のように都度リフレッシュをする場合には、プログラムオブジェクトのｅｘｅｃｕｔｅメソッドの中でデバイスにアクセスする旨の処理、つまり、デバイスオブジェクトのメソッドを呼び出す処理をユーザが記述する。
【００７２】
以上の定義を終えると、ユーザは、コントローラ１２にフレームワークとオブジェクトをダウンロードする（図７のＳ５０ｇ）。つまり、ユーザの指示に基づいて、開発装置１０は、システムコンフィグレーション情報３０、フレームワーク情報３１等（フレームワークオブジェクトファイル３１ａ及びフレームワークコンフィグレーション情報３１ｂ）、オブジェクトコンフィグレーション情報３３ａ等、オブジェクト情報３４ａ等をコントローラ１２にダウンロードする。そして、コントローラ１２内の通信制御部２２ａは、開発装置１０からダウンロードされてきた情報を記憶部２２ｂに格納する。
【００７３】
このような初期開発を終えると、次に、ユーザは、フレームワークを実行する（図７のＳ５１）。具体的には、ユーザは、コントローラ１２の電源をＯＮ、あるいは、開発装置１０を介してコントローラ１２に指示する。これによって、コントローラ１２は、以下の手順によって、フレームワークを起動させる。
【００７４】
まず、フレームワーク制御部２２ｃは、システムコンフィグレーション情報３０を参照し、ロードすべきフレームワークを決定する。本実施例では、ロードすべきフレームワークは、Ｐｌｃ．ｃｌａｓｓなので、これをロードしてフレームワークオブジェクトを生成する。そして、ロードされたフレームワークオブジェクトは、フレームワーク依存の情報であるオブジェクトコンフィグレーション情報３３ａ等を参照する。ここでは、フレームワークで実行すべきタスクオブジェクトが１個でＵｓｅｒＴａｓｋ１．ｃｌａｓｓをロードすべきことを認識する。そして、ＵｓｅｒＴａｓｋ１．ｃｌａｓｓをロードし、タスクオブジェクトを生成する。タスクオブジェクトを生成する際、タスクオブジェクト設定ファイルを参照し、タスクオブジェクトに登録されているプログラムオブジェクト（ここでは、ＵｓｅｒＰｒｏｇｒａｍ１．ｃｌａｓｓ）が何であるかを獲得し、プログラムオブジェクトを生成する。
【００７５】
次いで、フレームワークオブジェクトは、デバイスオブジェクトを生成する。ここでは、ＤｅｖｉｃｅＡ．ｃｌａｓｓ、ＤｅｖｉｃｅＢ．ｃｌａｓｓ、ＤｅｖｉｃｅＣ．ｃｌａｓｓをロードする。また、フレームワークオブジェクトは、フレームワーク依存の情報であるオブジェクトコンフィグレーション情報３３ａ等を参照し、ＩＮリフレッシュ、ＯＵＴリフレッシュすべきデバイスオブジェクトが何であるかを認識する。
【００７６】
最後に、ユーザは、プログラムの実行を指示する（図７のＳ５２）。具体的には、ユーザは、開発装置１０を介してコントローラ１２内のプログラムの実行を指示する。その結果、ここでは、図１９に示されるように、ＰＬＣ方式、つまり、一括Ｉ／Ｏリフレッシュ方式による制御が実行される。
【００７７】
つまり、ＩＮリフレッシュにおいては（Ｓ６０）、フレームワークは、ＩＮリフレッシュで実行すべきデバイスオブジェクトのメソッドを呼び出することでＩＮリフレッシュを行う。ここでは、デバイスオブジェクトＲｏｂｏｔＡ（ＤｅｖｉｃｅＡ）とＲｏｂｏｔＢ（ＤｅｖｉｃｅＢ）のＲｅａｄメソッドをフレームワークが呼び出す。
【００７８】
また、命令実行においては（Ｓ６１）、フレームワークは、ユーザが定義した（常時実行）タスクオブジェクトを起床する（つまり、実行を開始する）。ここでは、フレームワークがＵｓｅｒＴａｓｋ１（タスクオブジェクト）を起床する。起床したＵｓｅｒＴａｓｋ１（タスクオブジェクト）は、タスクオブジェクトに登録されているプログラムオブジェクト（ここでは、ＵｓｅｒＰｒｏｇｒａｍ１）を実行する。そして、プログラムオブジェクトのｅｘｅｃｕｔｅメソッドが呼び出され、ユーザが記述した制御ロジックが実行される。
【００７９】
さらに、ＯＵＴリフレッシュにおいては（Ｓ６２）、フレームワークは、ＯＵＴリフレッシュで実行すべきデバイスオブジェクトのメソッドを呼び出すことでＯＵＴリフレッシュを行う。ここでは、デバイスオブジェクトＲｏｂｏｔＣ（ＤｅｖｉｃｅＣ）のＷｒｉｔｅメソッドをフレームワークが呼び出す。
【００８０】
最後に、フレームワークはリセット処理等の各種周辺処理を実行することで１サイクル分の処理を終えると（Ｓ６３）、再び、同様の処理を繰り返す（Ｓ６０〜Ｓ６３）。
【００８１】
以上のように、本実施例１によれば、ユーザは、ユーザプログラミングモデルに依存しない制御ロジックをプログラムオブジェクトとして記述し、一方、ユーザプログラミングモデルに依存する制御方式については、予め用意された複数のフレームワークの中から選択するとともに、それらの関係を定義することにより、目的とする制御プログラムを構築することができた。したがって、ユーザは、ユーザプログラミングモデルの種類を意識することなく、プログラムオブジェクトを開発することができるとともに、開発したプログラムオブジェクトを各種プログラミングモデルの下で実行させることができ、高い開発効率を実現することができる。
【００８２】
（実施例２）
次に、実施例１における手順等で作成された、コントローラ１２に格納されているプログラムオブジェクト、デバイスオブジェクト、タスクオブジェクトを変更することなく、フレームワークだけを変更する実施例２について説明する。この実施例２は、図３（ｃ）のフローチャートに示されるケースのうち、アプリケーションフレームワークの変更を行う具体例に相当する。
【００８３】
図２０は、実施例２におけるユーザによる作業手順を中心したフローチャートである。
まず、ユーザは、開発装置１０において、以下に示すフレームワークの変更作業を行う（Ｓ７０）。つまり、変更後のフレームワークを選択する（Ｓ７０ａ）。具体的には、メーカが予め用意してある複数のフレームワークの中からユーザが使用するフレームワークを選択する。選択した情報は、システムコンフィグレーション情報３０、フレームワーク情報３１等としてコントローラ１２へのダウンロードの対象となる。
【００８４】
例えば、図２１の画面表示例に示されるように、ユーザは、開発装置１０において、プログラムの実行方式として状態遷移方式を選択する。このような選択により、開発装置１０により、フレームワークオブジェクトファイル３１ａとして、状態遷移処理を実装したＪａｖａ（登録商標）のｃｌａｓｓファイル、ここでは、Ｓｔａｔｅ．ｃｌａｓｓが生成される。
【００８５】
次に、ユーザは、フレームワークとオブジェクトの関係を定義する（図２０のＳ７０ｂ）。なお、この関係は、フレームワークに依存する情報である。本実施例では、ユーザは、プログラムの実行に関する設定を行う。具体的には、（ｉ）状態遷移条件、（ｉｉ）状態遷移条件を満たした場合に遷移する遷移先の状態名とそのときに実行されるオブジェクト名（タスクオブジェクト、プログラムオブジェクト、デバイスオブジェクト）等を開発装置１０で設定する。設定された結果は、オブジェクトコンフィグレーション情報３３ａ等としてＸＭＬファイル等で記憶装置に格納される。
【００８６】
例えば、図２２の画面表示例に示されるように、ユーザは、デバイスオブジェクトＡの変数Ｘが１になったとき、状態がＢに遷移し、そのとき実行されるオブジェクトがＵｓｅｒＴａｓｋ１である旨を設定する。なお、本実施例では、ＵｓｅｒＴａｓｋ１が実行さされると、そのタスクオブジェクトが持つプログラムオブジェクト（ＵｓｅｒＰｒｏｇｒａｍ１）が実行される。
【００８７】
次に、ユーザは、コントローラ１２にフレームワークをダウンロードする（図２０のＳ７０ｃ）。つまり、ユーザからの指示に従って、開発装置１０は、（ｉ）システムコンフィグレーション情報３０、（ｉｉ）フレームワーク情報３１等（フレームワークオブジェクトファイル３１ａ及びフレームワークコンフィグレーション情報３１ｂ）、（ｉｉｉ）オブジェクトコンフィグレーション情報３３ａ等の情報をコントローラ１２にダウンロードする。なお、デバイスオブジェクト、プログラムオブジェクト、タスクオブジェクトは、実施例１で使用したものを使う場合には、既にコントローラ１２にダウンロードされているため、再度ダウンロードする必要はない。
【００８８】
以上の変更作業を終えると、ユーザは、フレームワークを実行する（図２０のＳ７１）。具体的には、ユーザは、コントローラ１２の電源をＯＮ、あるいは、開発装置１０を介してコントローラ１２に指示する。これによって、コントローラ１２は、以下の手順によって、フレームワークを起動させる。
【００８９】
まず、フレームワーク制御部２２ｃは、システムコンフィグレーション情報３０を参照し、ロードすべきフレームワークを決定する。ここでは、ロードすべきフレームワークは、Ｓｔａｔｅ．ｃｌａｓｓなので、これをロードしてフレームワークオブジェクトを生成する。そして、ロードされたフレームワークオブジェクトは、フレームワーク依存の情報であるオブジェクトコンフィグレーション情報３３ａ等を参照する。ここで、フレームワークで実行すべきタスクオブジェクトが１個でＵｓｅｒＴａｓｋ１．ｃｌａｓｓをロードすべきことを認識する。そして、ＵｓｅｒＴａｓｋ１．ｃｌａｓｓをロードし、タスクオブジェクトを生成する。タスクオブジェクトを生成する際、タスクオブジェクト設定ファイルを参照し、タスクオブジェクトに登録されているプログラムオブジェクト（この場合ＵｓｅｒＰｒｏｇｒａｍ１．ｃｌａｓｓ）が何であるかを獲得し、プログラムオブジェクトを生成する。
【００９０】
次いで、フレームワークオブジェクトは、デバイスオブジェクトを生成する。ここでは、ＤｅｖｉｃｅＡ．ｃｌａｓｓ、ＤｅｖｉｃｅＢ．ｃｌａｓｓ、ＤｅｖｉｃｅＣ．ｃｌａｓｓをロードする。また、フレームワークオブジェクトは、フレームワーク依存の情報であるオブジェクトコンフィグレーション情報３３ａ等を参照して、状態遷移表を認識する。つまり、どのような状態遷移条件が発生したら、どの状態に遷移し、どのようなオブジェクトを実行するかを認識する。
【００９１】
最後に、ユーザは、プログラムを実行する（図２０のＳ７２）。つまり、ユーザは、開発装置１０を介してコントローラ１２内のプログラムの実行を指示する。その結果、ここでは、図２３に示されるように、状態遷移方式による制御が実行される。具体的には、フレームワークは、システムの状態を管理するとともに、状態遷移条件を判定する（Ｓ８０）。もし、状態遷移条件を満たしている場合は（Ｓ８０でＹｅｓ）、フレームワークは、オブジェクトコンフィグレーション情報３３ａ等を参照し、実行すべきオブジェクト（プログラムオブジェクト、タスクオブジェクト、デバイスオブジェクト）を実行する（Ｓ８１）。そして、オブジェクトを実行した後、システムの状態をオブジェクトコンフィグレーション情報３３ａ等に格納されている状態とする。つまり、フレームワーク内の変数に新たな状態を格納する。
【００９２】
以上のように、実施例２によれば、ユーザは、制御ロジックを記述したプログラムオブジェクトをコントローラ１２に置いたまま、ユーザプログラミングモデルをＰＬＣ方式から状態遷移方式に切り替えることができた。これによって、採用するユーザプログラミングモデルの種類に拘わらずに、プログラムオブジェクトの再利用が可能となり、制御方式を変更した場合に生じるプログラム開発の作業量が削減される。
【００９３】
なお、本実施例２では、ＰＬＣ方式から状態遷移方式に切り替える例が示されたが、本システム１では、図５に示された全ての方式を対象として切り替えることができるのは言うまでもない。つまり、図５（ａ）に示されたＰＬＣ方式であれば、ＩＮリフレッシュ→命令実行→ＯＵＴリフレッシュ→周辺処理という制御の流れをフレームワークで規定し、個々のステップにおける具体的な対象デバイスや具体的な処理ロジックをプログラムオブジェクトで規定すればよい。同様に、図５（ｂ）に示されたＳＦＣＣ方式であれば、ＴｒａｎｓｉｔｉｏｎとＳｔｅｐとから構成される制御フロー及びＴｒａｎｓｉｔｉｏｎ Ｃｏｎｄｉｔｉｏｎ等をフレームワークで規定し、各Ｓｔｅｐにおける具体的な処理ロジックをプログラムオブジェクトで規定すればよい。また、図５（ｃ）に示されたフローチャート方式であれば、条件判断と処理ステップとから構成される制御フロー及び条件判断の内容等をフレームワークで規定し、各処理ステップにおける具体的な処理内容をプログラムオブジェクトで規定すればよい。また、図５（ｄ）に示された状態遷移方式であれば、遷移前の状態と遷移条件と遷移後の状態とをフレームワークで規定し、遷移後の処理ロジックをプログラムオブジェクトで規定すればよい。さらに、図５（ｅ）に示されたイベント・ドリブン方式であれば、イベントの内容と処理との対応付けをフレームワークで規定し、具体的な処理内容をプログラムオブジェクトで規定すればよい。
【００９４】
（実施例３）
次に、実施例１における手順等で作成された、コントローラ１２に格納されているプログラムオブジェクト、デバイスオブジェクト、タスクオブジェクトをそのまま利用し、フレームワークだけを独自に開発する実施例３について説明する。この実施例３は、図３（ｃ）のフローチャートに示されるケースのうち、アプリケーションフレームワークの開発を行う具体例に相当する。
【００９５】
図２４は、実施例３におけるユーザによる作業手順を中心したフローチャートである。
まず、ユーザは、フレームワークを作成するために（Ｓ９０）、開発装置１０において、フレームワーク情報を開発する（Ｓ９０ａ）。具体的には、フレームワークの処理を記述したフレームワークオブジェクトファイル３１ａ、例えば、Ｓａｍｐｌｅ．ｃｌａｓｓというファイルと、フレームワークコンフィグレーション情報とを作成する。
【００９６】
次に、ユーザは、システムコンフィグレーション情報を開発する（Ｓ９０ｂ）。例えば、図２５に示されるように、フレームワークはＳａｍｐｌｅの１つだけを示す旨のシステムコンフィグレーション情報３０を作成する。
【００９７】
続いて、ユーザは、オブジェクトコンフィグレーション情報３３ａ等を開発する（Ｓ９０ｃ）。このオブジェクトコンフィグレーション情報３３ａ等は、フレームワークとオブジェクトの関係の定義であり、フレームワーク依存の情報である。
【００９８】
そして、ユーザは、開発したフレームワークをコントローラ１２にダウンロードした後に（Ｓ９１）、開発装置１０からの指示、あるいは、コントローラ１２の電源ＯＮ等により、コントローラ１２を始動させる（Ｓ９２）。
【００９９】
これによって、まず、コントローラ１２内のフレームワーク制御部２２ｃは、システムコンフィグレーション情報３０を参照し、ロードすべきフレームワークを決定する（図４のＳ４１）。ここでは、Ｓａｍｐｌｅである。
【０１００】
そして、フレームワーク制御部２２ｃは、フレームワーク情報３１等をロードする（図４のＳ４２）。そして、フレームワーク制御部２２ｃは、ロードしたフレームワーク情報３１等をもとにフレームワークオブジェクトを生成する（図４のＳ４）。
【０１０１】
生成されたフレームワークオブジェクトは、フレームワーク依存の情報であるオブジェクトコンフィグレーション情報３３ａ等を参照し（図４のＳ４４）、コンフィグレーション情報、及び、ロードすべきオブジェクトファイル名を獲得し、ロードする（図４のＳ４５）。そして、フレームワーク制御部２２ｃは、ロードしたオブジェクトを生成する（図４のＳ４６）。
【０１０２】
そして、開発装置１０からフレームワーク実行の指示をうけた通信制御部２２ａは、その旨をフレームワーク制御部２２ｃに伝え、フレームワーク制御部２２ｃは、フレームワークオブジェクトにフレームワークの処理の実行を指示する。指示されたフレームワークオブジェクトはフレームワークの処理を実行する。
【０１０３】
以降、フレームワークオブジェクトは、開発装置１０からフレームワークオブジェクト宛て送られてきた命令（通信制御部２２ａ→フレームワーク制御部２２ｃ）に応じた処理を行う。例えば、フレームワーク上のアプリケーション１２ａの実行、停止等である。
【０１０４】
以上のように、実施例３によれば、ユーザは、制御ロジックを記述したプログラムオブジェクトをコントローラ１２に置いたまま、ユーザプログラミングモデルを独自に開発し、コントローラ１２にダウンロードすることによって、ユーザ独自のユーザプログラミングモデルの下でプログラムオブジェクトを実行させることができた。これによって、ユーザは、それまで開発した資産（プログラムオブジェクト）を無駄にすることなく、制御対象機器に合致した独自の制御方式を採用したユーザプログラミングモデルを独自開発して採用することができ、メーカから提供される定型的なユーザプログラミングモデルを採用した場合に生じるハードウェア及びソフトウェアの無駄を排除することができる。
【０１０５】
以上、本発明に係るシステムについて、実施の形態及び実施例に基づいて説明したが、本発明は、これらの実施の形態及び実施例に限定されるものではない。例えば、図１に示されたシステム１において、開発装置１０とコントローラ１２とを接続するネットワーク１１と、コントローラ１２とネットワーク１３とを接続するネットワーク１３とは異なる符号が付されていたが、これらネットワーク１１及び１３は、物理的に同一の伝送路であってもよいし、異なる伝送路であってもよい。また、コントローラ１２と開発装置１０とが１台のコンピュータ装置に収められて一体化されていてもよい。
【０１０６】
また、図４に示される階層構造において、フレームワークオブジェクト（Ａ）とフレームワークオブジェクト（Ｂ）とは同一の制御方式に係るフレームワークであってもよいし、異なる制御方式に係るフレームワークであってもよい。さらに、オブジェクト（Ａ）とオブジェクト（Ｂ）は、相互に情報交換のための通信を行ってもよいし、行わなくてもよい。フレームワークの種類や数、あるいは、プログラムオブジェクト間での通信を行うか否かは、対象とする制御システムに応じて適宜選択すればよい。
【０１０７】
【発明の効果】
以上の説明から明らかなように、本発明に係るシステムでは、一度作成したプログラム（オブジェクト）は、プログラミングモデルが変更されても再利用することが可能である。従って、制御プログラムの生産性が向上する。
【０１０８】
そして、ユーザは、コントローラのプログラミングモデルを変更することが可能であるため、コントローラの種類に拘わらず、制御対象機器に合致した最適なプログラミングモデルを選択して採用することができ、コントローラを有効利用することができる。
【０１０９】
さらに、ユーザは、フレームワークを独自に開発することができるので、様々なアプリケーションに対応したシステムを構築することができる、あるいは、ユーザが持っているノウハウを実装することができる。
【０１１０】
また、ユーザが作成したプログラム（オブジェクト）は、様々な種類のプログラミングモデルに対応するフレームワークと組み合わせて実行させることができるので、複数のプログラミングモデルに対応する複数の制御プログラムを予めコントローラ内に格納しておく方式に比べ、コントローラに実装しておくメモリ等のリソースが少なくて済む。
【０１１１】
また、本発明に係るシステムでは、コントローラが備えるプログラミングモデルの変更は、ユニットを変更する等のハードウェアの変更ではなく、ソフトウェアでの変更で済み、しかも、ネットワークを介して行うため、変更作業が極めて容易である。さらに、一旦、コントローラにダウンロードされたプログラムについては、コントローラ内にそのまま保持させた状態で、プログラミングモデルだけを変更することができるので、プログラミングモデルの変更に手間がかからない。
【０１１２】
以上のように、本発明により、制御システムの開発における生産性が飛躍的に向上され、特に、制御システムの機能変更や制御方式の変更を伴う再構築作業における労力が大幅に軽減され、その実用的価値は極めて高い。
【図面の簡単な説明】
【図１】本発明に係るシステム１の全体構成を示す図である。
【図２】コントローラを構成するソフトウェアとハードウェアの階層構造を示す図である。
【図３】各種ケースにおけるユーザによる開発作業の流れを示すフローチャートである。
【図４】コントローラの機能ブロック図である。
【図５】各種フレームワークの制御方式を示す図である。
【図６】コントローラの動作手順を示すフローチャートである。
【図７】実施例１におけるユーザによる作業手順を中心したフローチャートである。
【図８】実施例１における制御システムの構成を示す図である。
【図９】デバイスオブジェクトを定義するときの画面表示例である。
【図１０】オブジェクト設定ファイルの記述例を示す図である。
【図１１】フレームワークの種類を選択するときの画面表示例である。
【図１２】システムコンフィグレーション情報の例を示す図である。
【図１３】フレームワークコンフィグレーション情報の例を示す図である。
【図１４】プログラムオブジェクトを設定するときの画面表示例である。
【図１５】オブジェクトファイルの記述例を示す図である。
【図１６】オブジェクト設定ファイルの記述例を示す図である。
【図１７】タスクオブジェクトを定義するときの画面表示例である。
【図１８】デバイスの設定を行うときの画面表示例である。
【図１９】コントローラによるプログラムの実行制御の流れを示す図である。
【図２０】実施例２におけるユーザによる作業手順を中心したフローチャートである。
【図２１】フレームワークの種類を選択するときの画面表示例である。
【図２２】フレームワークとオブジェクトとの関係を定義するときの画面表示例を示す。
【図２３】コントローラによるプログラムの実行制御の流れを示す図である。
【図２４】実施例３におけるユーザによる作業手順を中心したフローチャートである。
【図２５】システムコンフィグレーション情報の例を示す図である。
【図２６】従来のシステムの構成を示す図である。
【図２７】従来のシステムにおけるプログラム開発の問題点を示す図である。
【符号の説明】
１ システム
１０ 開発装置
１１ ネットワーク
１２ コントローラ
１２ａ アプリケーション
１２ｂ フレームワーク
１２ｃ ソフトウェア抽象化層
１２ｄ ハードウェア抽象化層
１２ｅ ハードウェア
１２ｆ アプリケーションフレームワーク
１３ ネットワーク
１４ａ〜１４ｃ デバイス
１４ｄ デバイスＡ
１４ｅ デバイスＢ
１４ｆ デバイスＣ
２０ アプリケーション層
２１ フレームワーク層
２２ 下位層
２２ａ 通信制御部
２２ｂ 記憶部
２２ｃ フレームワーク制御部
３０ システムコンフィグレーション情報
３１、３２ フレームワーク情報
３１ａ フレームワークオブジェクトファイル
３１ｂ フレームワークコンフィグレーション情報
３３ａ、３３ｂ オブジェクトコンフィグレーション情報
３４ａ、３４ｂ オブジェクト情報

Claims (12)

1. 機器を制御するコントローラであって、
   制御の流れを管理する第１フレームワーク手段と、
   前記第１フレームワーク手段による管理の下で前記機器に対する制御処理を実行する第１アプリケーション手段と
   を備えることを特徴とするコントローラ。
2. 前記第１フレームワーク手段は、前記第１アプリケーション手段による制御処理の実行に関する条件、タイミング、順番、及び、前記機器との入出力に関するタイミングの少なくとも１つを管理する
   ことを特徴とする請求項１記載のコントローラ。
3. 前記第１フレームワーク手段は、前記制御処理の実行をスキャン方式で行うとともに前記機器との入出力を一括Ｉ／Ｏリフレッシュ方式で行うことによって制御の流れを管理する第１の方式、シーケンス・ファンクション・チャートに従って制御の流れを管理する第２の方式、フローチャートに従って制御の流れを管理する第３の方式、状態遷移表に従って制御の流れを管理する第４の方式、イベント・ドリブン方式に従って制御の流れを管理する第５の方式の少なくとも１つの方式で前記制御の流れを管理する
   ことを特徴とする請求項１又は２記載のコントローラ。
4. 前記コントローラには、開発装置が接続され、
   前記コントローラは、さらに、
   前記開発装置から情報をダウンロードするダウンロード手段と、
   前記ダウンロード手段によってダウンロードされた情報に基づいて、前記第１フレームワーク手段と異なる方式で前記制御の流れを管理する第２フレームワーク手段を前記コントローラに追加すること、及び、前記第１フレームワーク手段を、当該第１フレームワーク手段と異なる方式で前記制御の流れを管理する第２フレームワーク手段に置き換えることの少なくとも一方を行う第１更新手段と
   を備えることを特徴とする請求項１〜３のいずれか１項に記載のコントローラ。
5. 前記第１更新手段は、前記第１アプリケーション手段を前記コントローラに保持させた状態で、前記第２フレームワーク手段の追加及び置き換えの少なくとも一方を行う
   ことを特徴とする請求項４記載のコントローラ。
6. 前記コントローラには、開発装置が接続され、
   前記コントローラは、さらに、
   前記開発装置から情報をダウンロードするダウンロード手段と、
   前記ダウンロード手段によってダウンロードされた情報に基づいて、前記第１アプリケーション手段と異なる制御処理を実行する第２アプリケーション手段を前記コントローラに追加すること、及び、前記第１アプリケーション手段を、当該第１アプリケーション手段と異なる制御処理を実行する第２アプリケーション手段に置き換えることの少なくとも一方を行う第２更新手段と
   を備えることを特徴とする請求項１〜３のいずれか１項に記載のコントローラ。
7. 前記第２更新手段は、前記第１フレームワーク手段を前記コントローラに保持させた状態で、前記第１アプリケーション手段の追加及び置き換えの少なくとも一方を行う
   ことを特徴とする請求項６記載のコントローラ。
8. 機器を制御するコントローラで実行される制御プログラムを開発するための開発装置であって、
   前記制御プログラムには、前記機器に対する制御の流れを規定したプログラミングモデル情報と、前記機器に対する制御処理を規定したプログラムであるオブジェクトとが含まれ、前記コントローラは、前記プログラミングモデル情報によって規定される制御の流れの下で前記オブジェクトを実行する装置であり、
   前記開発装置は、
   ユーザからの指示に従って前記プログラミングモデル情報を作成するプログラミングモデル情報作成手段と、
   ユーザからの指示に従って前記オブジェクトを作成するオブジェクト作成手段と、
   作成された前記プログラミングモデル情報及び前記オブジェクトの少なくとも一方を前記コントローラにダウンロードするダウンロード手段と
   を備えることを特徴とする開発装置。
9. 制御プログラムに従って機器を制御するコントローラと、前記制御プログラムを開発するための開発装置とから構成されるシステムであって、
   前記制御プログラムには、前記機器に対する制御の流れを規定したプログラミングモデル情報と、前記機器に対する制御処理を規定したプログラムであるオブジェクトとが含まれ、
   前記開発装置は、
   ユーザからの指示に従って前記プログラミングモデル情報を作成するプログラミングモデル情報作成手段と、
   ユーザからの指示に従って前記オブジェクトを作成するオブジェクト作成手段と、
   作成された前記プログラミングモデル情報及び前記オブジェクトの少なくとも一方を通信路を介して前記コントローラに送信する送信手段とを備え、
   前記コントローラは、
   前記通信路を介して前記開発装置から送信されてくるプログラミングモデル情報及びオブジェクトを受信する受信手段と、
   受信された前記プログラミングモデル情報によって規定される制御の流れの下で前記オブジェクトを実行することによって前記機器を制御する実行手段とを備える
   ことを特徴とするシステム。
10. 機器を制御するコントローラで実行される制御プログラムの開発支援方法であって、
    前記制御プログラムを、前記機器に対する制御の流れを規定したプログラミングモデル情報と、前記機器に対する制御処理を規定したプログラムであるオブジェクトとに分離した開発を支援し、
    開発した前記プログラミングモデル情報及び前記オブジェクトを前記コントローラにダウンロードし、
    前記コントローラに、前記プログラミングモデル情報によって規定される制御の流れの下で前記オブジェクトを実行させる
    ことを特徴とする制御プログラムの開発支援方法。
11. 機器を制御するコントローラのためのプログラムであって、
    制御の流れを管理するフレームワーク手段と、
    前記フレームワーク手段による管理の下で前記機器に対する制御処理を実行するアプリケーション手段と
    としてコンピュータに機能させることを特徴とするプログラム。
12. 機器を制御するコントローラで実行される制御プログラムを開発する開発装置のためのプログラムであって、
    前記制御プログラムには、前記機器に対する制御の流れを規定したプログラミングモデル情報と、前記機器に対する制御処理を規定したプログラムであるオブジェクトとが含まれ、前記コントローラは、前記プログラミングモデル情報によって規定される制御の流れの下で前記オブジェクトを実行する装置であり、
    前記プログラムは、
    ユーザからの指示に従って前記プログラミングモデル情報を作成するプログラミングモデル情報作成手段と、
    ユーザからの指示に従って前記オブジェクトを作成するオブジェクト作成手段と、
    作成された前記プログラミングモデル情報及び前記オブジェクトの少なくとも一方を前記コントローラにダウンロードするダウンロード手段と
    してコンピュータに機能させることを特徴とするプログラム。

Images