JP4366576B2 - プログラマブルコントローラ用機器 - Google Patents

Description

この発明は、プログラマブルコントローラ用機器に関するものである。

ファクトリーオートメーション（ＦＡ）の制御装置として、プログラマブルコントローラ（ＰＬＣ）が用いられている。このＰＬＣは、複数のユニットから構成される。すなわち、電源供給源の電源ユニット，ＰＬＣ全体の制御を統率するＣＰＵユニット，ＦＡの生産装置や設備装置の適所に取り付けたスイッチやセンサの信号を入力する入力ユニット，アクチュエータなどに制御出力を出す出力ユニット，通信ネットワークに接続するための通信ユニットなどの各種のユニットを適宜組み合わせて構成される。

ＰＬＣのＣＰＵユニットにおける制御は、入力ユニットで入力した信号をＣＰＵユニットのＩ／Ｏメモリに取り込み（ＩＮリフレッシュ）、予め登録されたユーザプログラム記述言語（例えばラダー言語）で組まれたユーザプログラムに基づき論理演算をし（演算実行）、その演算実行結果をＩ／Ｏメモリに書き込んで出力ユニットに送り出し（ＯＵＴリフレッシュ）、その後、いわゆる周辺処理を行うということをサイクリックに繰り返し処理するようになる。そして、上記したユーザプログラムは、ＣＰＵユニットのユーザメモリに格納される。

さらに、ＰＬＣにおける機能としては、上記したようにＰＬＣに直接或いはネットワーク等を介して間接的に接続された機器を制御するための制御プログラムを実行する機能と、係る機器制御を目的としない、通信機能，ファイル操作，パスワード管理などのサービス機能を持つサービスプログラムを実行する機能がある。そして、係る２つの機能を実行するＰＬＣがある。

しかしながら、このような従来のＰＬＣでは、以下に示す種々の問題を有している。すなわち、サービス機能を実行するサービスプログラムは、通常、ＰＬＣのファームウェアとして実装されているため、ファームウェア上に存在しない、使用環境に適した機能を付加する場合には、制御プログラムの中に上記機能を持つプログラムを実装する必要がある。

そのため、制御プログラム内にサービス機能を実装した場合には、制御プログラムがＰＬＣの実行状態にある場合にのみその機能は有効となり、ＰＬＣが停止状態にある場合は、サービス機能を利用することができなくなる。

さらに、サービスプログラムが制御プログラム内部に含まれる実装構造となるため、サービスプログラムの追加・削除・変更などを実施するためには、制御プログラムの構造が複雑になるばかりでなく、制御プログラムの実行処理性能に影響がでるおそれがある。

この発明は、制御プログラムの構造、実行状態に依存せず、サービスプログラムを実行・停止できるようなプログラマブルコントローラ用機器を提供することを目的とする。

この発明によるプログラマブルコントローラ用機器は、機器制御を行なうための制御プログラムを記憶する制御プログラム記憶手段と、前記機器制御に依存しないサービスプログラムを記憶するサービスプログラム記憶手段と、前記制御プログラム記憶手段に記憶保持された制御プログラムと、前記サービスプログラム記憶手段に記憶保持されたサービスプログラムを、それぞれ実行する手段を備えることを前提とする。

ここで、プログラマブルコントローラ用機器とは、制御プログラム等を実行する機能を備えたもので、ＣＰＵユニット等のプログラマブルコントローラを構成するユニットでも良いし、プログラマブルコントローラそのものも含む。そして、プログラマブルコントローラの場合、一体型のものと複数ユニットを連結して構成される両者を含む。

この前提の構成を採ることでは、制御プログラムとサービスプログラムを別々のプログラムとして作成し、各記憶手段に格納するとともに、それぞれを実行可能するようにしたため、制御プログラムの構造や実行状態に依存せず、サービスプログラムを実行・停止できる仕組みを提供することができる。

上記の前提のもとで前記サービスプログラムは、前記制御プログラムに依存しない独立して実行可能なプログラムとして記憶保持され、プログラマブルコントローラの動作状態に合わせて、実行，停止の制御が行なわれるようにする。動作状態とは、例えば、実施例で言う実行状態や停止状態さらにはシステム初期状態などがある。さらに、前記サービスプログラムは、前記制御プログラムに依存しない独立して実行可能なプログラムとして記憶保持され、プログラマブルコントローラが停止状態でも、前記サービスプログラムを常駐実行できるようにすることもできる。これらの発明は、第２，第３実施例で実現されている。

また、上記の前提のもとで前記サービスプログラムは、プログラマブルコントローラの動作状況に依存せずに、追加，削除，変更の少なくとも１つを行う手段を備えるようにするとよい。実施例では、係る手段は、オンラインエディット処理部４５等により実現される。この発明は、第４実施例で実現されている。サービスプログラムを制御プログラムと別のプログラムとして作成したため、プログラマブルコントローラの動作状態（制御プログラムの実行・停止状態等）に依存せず、対象となるサービスプログラムを追加，削除，変更（入替）ができる。

本発明では、制御プログラムの構造、実行状態に依存せず、サービスプログラムを実行・停止できるようになる。

図１は、本発明が適用されるネットワークシステムの一例を示している。図１に示すように、ツール１０と、ＰＬＣ２０と、上位コンピュータ３０がネットワークを介して接続されている。より具体的には、この例では、ツール１０と上位コンピュータ３０はイーサネット（登録商標）などのネットワーク３１で接続され、それらと、ＰＬＣ２０とは、インターネットなどの公衆回線網３２から上記と別のイーサネット（登録商標）等のネットワーク３３を介して接続される。このように公衆回線網３２を利用することにより、遠隔地からツール１０を操作してＰＬＣ２０に対して各種の設定・制御をしたり、上位コンピュータ３０を操作してＰＬＣ２０内部のＩ／Ｏデータを参照したり、収集されたＩ／Ｏデータを蓄積したりすることができる。もちろん、必ずしも公衆回線網３２を介する必要はなく、各種のネットワークを利用したり、ＰＬＣが接続されたネットワーク３３にツール１０や上位コンピュータ３０を接続したり、さらには、ケーブル等により、直接ＰＬＣ２０にツール１０や上位コンピュータ３０を接続したりすることもできる。さらには、ＰＬＣ２０のメール送信機能を用い、携帯電話３５に向けてメール（異常通知）を送信することもできる。

ここで、ツール１０（開発環境装置）は、開発環境であり、パソコン上に所定のアプリケーションプログラムをインストールすることにより実現され、プログラム開発環境と設定ツールの２つの機能を備えている。そして、プログラム開発環境は、ユーザがＰＬＣ上で動作するプログラムを作成するためのツールである。また、設定ツールは、ＰＬＣの操作・設定を行うためのツールであり、ユーザが作成したプログラムをダウンロードすることや、ＰＬＣの起動，状態変更などの制御やコンフィグレーション情報を設定するものである。

また、ＰＬＣ２０には、制御対象となる機器３６が接続されており、この機器３６は、ユーザが構築するシステムに依存するものであり、機器制御を行うためのセンサ，スイッチなどの入力機器と、モータ，ソレノイドなどの出力機器を含む。

図２は、ツール１０並びにＰＬＣ２０のソフトウェア概要構成図を示している。図２に示すように、ツール１０は、プログラムエディタ（プログラム開発環境）１１と、設定ツール１２を有している。プログラムエディタ１１は、ユーザプログラムを作成・編集するためのツールである。また、設定ツール１２は、ＰＬＣ２０の状態制御やユーザプログラムのＰＬＣ２０への送信（ダウンロード）、ユーザプログラムの設定情報の作成などを行うためのツールである。そして、この設定ツール１２の中に、サービスオブジェクト設定機能１３を備えている。このサービスオブジェクト設定機能１３は、サービスプログラムをＰＬＣ２０上でオブジェクトとして取り扱うための項目を設定するための機能である。

ＰＬＣ２０（ＣＰＵユニット）は、オペレーティングシステムとして、ＰＬＣ上で汎用のリアルタイムＯＳ２１が実装されている。そして、ユーザプログラムやコントローラの設定ファイルなどのファイル操作を行うためのドライバであるファイルシステム２２，コントローラを機器ネットワークに接続するための通信機能を持つドライバであるネットワークドライバ２３並びにコントローラに接続されるＩ／Ｏユニットとのデータ授受を行うためのドライバであるＩ／Ｏユニットバスドライバ２４を備えている。これらの基本構成は、従来と同様である。

そして、ユーザプログラムを動作させるコントローラとしての基本機能が実装されているミドルウェア部品たるフレームワーク２５としては、大別すると、オブジェクト管理部２６と、コントローラ状態管理部２７と、保守・障害管理部２８を備えている。

本実施の形態では、フレームワーク２５上で動作する機能をオブジェクト単位で持たせており、オブジェクト管理部２６は、それら各オブジェクトの情報を登録、管理するものであり、定義されるオブジェクトの種類に応じてイベント管理部２６ａ，制御プログラム管理部２６ｂ，サービスオブジェクト設定管理部２６ｃ並びにＩ／Ｏユニット管理部２６ｄの各管理部がある。

各管理部の機能を簡単に説明すると、イベント管理部２６ａは、制御プログラムの実行タイミングが定義されているイベントオブジェクトを管理し、制御プログラム管理部２６ｂは、制御プログラムをオブジェクトとして管理し、サービスオブジェクト設定管理部２６ｃはサービスプログラムをオブジェクトとして管理し、Ｉ／Ｏユニット管理部２６ｄは、コントローラに接続されるＩ／Ｏユニットのデバイスをフレームワークの階層で管理し、コントローラ状態管理部２６はコントローラの動作状態を管理し、保守・障害管理部２７は電断，電池異常，Ｉ／Ｏユニット異常などのコントローラの異常状態を検知し、メモリ情報の退避やエラーＬＥＤ点灯による障害通知などの対障害処理を行うものである。なお、必要な機能の詳細は後述する。

さらに、ＰＬＣ２０のユーザメモリ２９に格納されるユーザユーザプログラムには、制御プログラム記憶部２９ａに格納される制御プログラムと、サービスプログラム記憶部２９ｂに格納されるサービスプログラムを備えている。ここで、制御プログラムは、定義されたイベント（定期的な制御周期、または割込みなどの非定期なイベント）に基づいて実行されるプログラムであり、サービスプログラムは、イベントに基づかずに実行されるプログラムである。

ここで本実施の形態では、サービスプログラムが、制御プログラムと分離して作成・記憶保持するとともに、制御プログラムからサービスプログラムを起動可能とした。そこで、本発明の要部となるサービスオブジェクト並びにサービスプログラムについて説明する。

サービスプログラムは、１つ以上のアプリケーション実行プログラムと０個以上の設定関連ファイルで構成される１つのアプリケーションプログラムをＰＬＣ上で管理可能なサービスである。そして、サービスプログラムは、ＰＬＣのフレームワーク上で実行され、あるタイミング（周期による実行や、イベント発生時による実行）に基づいて実行される制御プログラムとは別の、アプリケーションプログラムであり、具体的には、以下のプログラムがある。
ユーザプログラム実行状態の時に、ユーザが作成した制御プログラムまたはサービスプログラムから呼び出し可能なライブラリとして扱われるプログラム；
ＰＬＣ２０の起動時に実行を開始し、ＰＬＣ２０の終了時に実行を終了するフレームワーク２５上で動作する１つのスレッドとして実行可能なプログラム；
ユーザプログラム実行開始時に実行を開始し、ユーザプログラム終了時に実行を終了する、フレームワークで動作する１つのスレッドとして実行可能なプログラムがある。

また、サービスプログラムをフレームワーク２５内で管理するための仕組みとして、サービスオブジェクトが定義される。サービスオブジェクトが提供する機能としては、以下のものがある。
サービスプログラムの取り扱いを、フレームワーク２５内でライブラリとして取り扱うか、スレッドプログラムとして取り扱うかを管理する機能；
ユーザプログラム実行状態の時に、ユーザが作成した制御プログラムまたはサービスプログラムから呼び出し可能なライブラリとして扱われるプログラム；
ユーザが作成した制御プログラムまたはサービスプログラムから、サービスプログラムを呼び出して実行する場合において、フレームワーク上にそのサービスが存在するか否かを検知する機能；
サービスプログラムをスレッドプログラムとして取り扱う場合、スレッドの生成・起動・終了・実行優先度の設定を制御する機能；
フレームワーク上で追加・削除・変更の対象となるサービスの構成要素となる、アプリケーション実行プログラムと設定関連ファイルを管理する機能等がある。

もちろん、上記した各種の機能がすべて実装されるわけではなく、必要に応じて適宜選択して実装される。そして、サービスオブジェクトは、具体的には「インスタンス名」，「実行プログラムファイル名のリスト」，「サービス設定管理ファイル名のリスト」，「サービス取り扱いフラグ」，「サービススレッド実行クラス名」，「サービススレッド実行優先度」などの項目により定義され、各項目をサービスオブジェクトのコンフィグレーション情報と称する。

ここで、「インスタンス名」は、サービスオブジェクトのインスタンス名であり、ユーザから任意に設定されるものである。「実行プログラムファイル名のリスト」は、ユーザアプリケーションの構成要素となる実行プログラムファイル名のリストである。「サービス取り扱いフラグ」は、定義したサービスプログラムをフレームワーク２５上でどのように取り扱うかを決めるフラグである。フラグの定義内容としては、（１）ユーザアプリケーションから呼び出し可能なライブラリとして取り扱うこと、（２）フレームワーク２５が制御可能なスレッドプログラムとして取り扱うことがある。そして、後者のスレッドプログラムとして取り扱う場合は、さらに（２−１）ＰＬＣ２０がシステム初期状態からユーザアプリ停止状態の遷移時点で実行し、逆の遷移時点で停止する場合と、（２−２）ＰＬＣ２０がユーザアプリ停止状態からユーザアプリ実行状態の遷移時点で実行し、逆の遷移時点で停止する場合を識別するものがある。

さらに、「サービススレッド実行クラス名」と「サービススレッド実行優先度」は、上記（２）の場合に有効な情報であり、前者が定義したサービスプログラムをスレッドプログラムとして取り扱う場合の実行スレッドが存在するプログラムファイル名であり、後者が、定義したサービスプログラムをスレッドプログラムとして取り扱う場合のスレッドを実行する場合の優先度である。

上記した基本構成を前提とし、必要な機能を適宜実装することにより、以下に示す各種の実施例を実現することができる。図３は、参考例を示している。この参考例は、ライブラリとしてサービスプログラムを利用（実行）する機能を実現するものであり、この参考例により、サービスプログラムを、入出力機器の制御を行う制御プログラムから、直接制御に関連しない汎用プログラムとして分離することができ、ユーザが作成するプログラムの再利用性が向上する。さらに、同じプログラム開発環境を利用する汎用プログラムに対して、汎用プログラムのソースコードの変更なく、ＰＬＣで実行するための設定追加と、制御プログラムからの呼び出し機能追加を行うことで、サービスプログラムを利用することが可能となる。

なお、本参考例で作成対象となるサービスプログラムは、ユーザ認証機能やファイルアクセス機能、不具合通知のメール送信機能など、常時実行の必要性が無くライブラリ呼び出しとして使用するプログラムである。そして、係る目的・作用効果を実現するための具体的な構成としては、図３に示すようになる。

まず、開発環境としてのツール１０は、ＰＬＣ上で動作する制御プログラム、サービスプログラムを作成または編集し、プログラム実行のための設定情報と合わせてコントローラに送信するものである。そして、開発環境は、通常、ＰＬＣにプログラムを送信する場合においてのみ接続される。

プログラムエディタ１１は、ＰＬＣ２０上で動作する制御プログラムやサービスプログラムをユーザが作成するために使用するものである。そして、ＰＬＣ２０にて実行可能な中間コードにコンパイルする機能も備える。そして、ユーザは、かかるプログラムエディタ１１を操作して、サービスプログラムを制御プログラムと別のプログラムとして作成するとともに、制御プログラム中にサービスプログラムの呼び出し記述を組み込み、制御プログラムの実行にともない所定のタイミングでサービスプログラムを呼び出して実行させるようなプログラムを作成する。なお、プログラムエディタ１１における各プログラムの作成・編集や、コンパイル等の各処理は、従来と同様のもの（市販のツール）を用いることができる。

サービスオブジェクト設定機能１３は、設定ツール１２の一機能であり、ユーザが作成したサービスプログラムをＰＬＣ２０のフレームワーク２５上でオブジェクトとして取り扱うために必要な項目を設定する機能である。本参考例では、「インスタンス名」，「実行プログラムファイル名のリスト」，「サービス設定関連ファイル名のリスト」並びに「サービス取り扱いフラグ」を設定する。そして、「サービス設定関連ファイル名のリスト」は、ユーザアプリケーションの構成要素となる全設定関連ファイル名のリストが設定される。さらに、サービス取り扱いフラグでは、ユーザアプリケーションから呼び出し可能なライブラリとして定義することになる。そして、作成された制御プログラム、サービスプログラム、コンフィグレーション情報は、設定ツール1２により、ＰＬＣ２０に送信（ダウンロード）される。

一方、ＰＬＣ２０は、ツール１０から制御プログラム，サービスプログラム並びに設定情報を受信し、各記憶部に格納する。制御プログラム（ユーザプログラム）はＰＬＣ２０がユーザアプリ実行状態に遷移した時に、そのプログラムの記述に従って実行する。そして、制御プログラム中にサービスプログラムの呼び出し記述がある場合に、オブジェクト管理部にサービスオブジェクトとして登録されているかどうかを参照した上で、登録されている場合はサービスプログラムの処理実行を行う。

以下、ＰＬＣ２０を構成する各機能ブロックの内、本参考例に関連する機能ブロックについて説明する。まず、通信機能部４０を備えている。この通信機能部４０は、ツール（開発環境）１０から送られてきたコマンドを受信し、その受信したコマンドを解析し、解析結果に応じて各機能ブロックの処理への依頼や、記憶部へのデータ格納を行うものである。本参考例で扱うコマンドとしては、プロジェクトダウンロードコマンドとユーザアプリ実行コマンドがある。

ここで「プロジェクトダウンロードコマンド」は、サービスオブジェクト初期化段階において、ユーザが作成したプログラムの実行ファイルをＰＬＣ２０に送信するためのコマンドである。そこで、通信機能部４０は、受信したプログラム（制御プログラム，サービスプログラム）を対応するプログラムの記憶部に格納する。つまり、制御プログラムがダウンロードされてきた場合には、制御プログラム管理部２６ｂを介して制御プログラム記憶部２９ａに格納され、サービスプログラムがダウンロードされてきた場合には、サービスオブジェクト設定管理部２６ｃを介してサービスプログラム記憶部２９ｂに格納される。

なお、制御プログラム記憶部２９ａは、制御プログラムの実行モジュールを記憶するものである。そして、その記憶された制御プログラムは、コントローラ状態管理部２７で保持しているコントローラ（ＰＬＣ）の動作状態に応じて、制御プログラム実行エンジン４１を通じて停止・実行される。また、サービスプログラム記憶部２９ｂは、サービスプログラムの実行モジュールを記憶するものである。そして、その記憶されたサービスプログラムは、制御プログラムあるいは他のサービスプログラムからの呼び出しに応じて実行される。

一方、「ユーザアプリ実行コマンド」は、サービスオブジェクト参照段階において、ユーザが作成したプログラムをＰＬＣ２０上で実行するためのコマンドである。そこで、通信機能部４０は、指定されたプログラムを起動・実行させる。すなわち、通信処理部４０はコントローラ状態管理部２７に対し、受信したユーザアプリ実行コマンドを渡し、そのコントローラ状態管理部２７にて所定のプログラムの実行・停止を管理する。

コントローラ状態管理部２７は、コントローラ（ＰＬＣ）の実行状態を管理するものである。ツール１０から送信されるコマンド、またはコントローラが内部で持つ状態遷移の設定情報に応じて、ユーザアプリの停止・実行を制御する。そして、コントローラ（ＰＬＣ）は、以下に示すようなシステム初期状態，ユーザアプリ停止状態並びにユーザアプリ実行状態の３つの動作状態を持つ。

システム初期状態とは、外部（ツール１０等）からＰＬＣ２０に対するアクセスが可能となった状態である。この状態では、ツール１０からユーザアプリをダウンロードすることなどができる。また、ユーザアプリは、ＰＬＣ上に存在しない。

ユーザアプリ停止状態とは、ユーザアプリはＰＬＣ２０上に存在するが、当該ユーザアプリは実行していない状態である。この状態では、外部（ツール１０など）からＰＬＣ２０に対するアクセスが可能な状態である。

ユーザアプリ実行状態とは、ユーザアプリはＰＬＣ２０上に存在し、ユーザアプリが実行している状態である。外部（ツール１０など）からコントローラに対するアクセスが可能な状態である。

制御プログラム実行エンジン４１は、制御プログラム記憶部２９ａに記憶保持された制御プログラムを評価実行する。また、制御プログラムからサービスプログラムの呼び出しがある場合は、オブジェクト管理部２６へ該当するサービスプログラムが登録されているか参照を行う。

オブジェクト管理部２６は、ＰＬＣ２０上に配置されるプログラムの機能単位（例えば、「ＩＯユニットのＩＯデータを収集するプログラム」，「ＩＯユニットのＩＯデータを出力するプログラム等」）をオブジェクトとして保持し、管理するものである。オブジェクト管理部２６では、以下の（１）から（５）の構成要素の配列をオブジェクトの種類別に保持し、各オブジェクトの管理を行う。
（１）オブジェクトのクラス名
イベント、プログラム、デバイス、サービスなどの種類ごとに、個々に割り当てられるクラスの名称である。例えば、デバイスオブジェクトに対して、１６点ディジタル入力ユニット、３２点ディジタル入力ユニット、アナログ入力ユニット、などコントローラ上で取り扱えるＩ／Ｏユニットの機種ごとに与えられる名前を定義する。
（２）オブジェクトのクラスＩＤ
オブジェクトのクラスごとに定義されるＩＤである。
（３）オブジェクトのインスタンス名
オブジェクト生成時に、メモリ領域に割り当てられた各オブジェクトに対して与えられるインスタンス（実体）の名称。例えばデバイスオブジェクトにおいて、コントローラ上に２つの同じ１６点ディジタル入力ユニットが接続されている場合、アクセスするユニットを個別に識別できるようにそれぞれ名前を定義する。
（４）オブジェクトのインスタンスＩＤ
オブジェクトのインスタンスごとに定義されるＩＤである。
（５）オブジェクトのインスタンス
オブジェクトの実体である。

そして、本参考例に関係の深い制御プログラム管理部２６ｂは、制御プログラムをオブジェクトとして登録、管理する機能である。ツール１０から送信された制御プログラムが制御プログラム記憶部２９ａに保持されたデータに対して、管理対象として登録する。同様に、サービスオブジェクト設定管理部２６ｃは、サービスプログラムをオブジェクトとして登録、管理する機能である。ツール１０から送信されたプログラムにサービスオブジェクトが含まれる場合に、サービスプログラム記憶部２９ｂに保持されたデータを管理対象として登録する。

次に、各処理を行なう場合の処理フローを説明しつつ、各処理部（管理部，記憶部）の機能を説明する。図４は、主にサービスオブジェクトのダウンロード並びに初期化についての処理フローを示している。

まず、サービスオブジェクトは、ＰＬＣで動作する制御プログラムと合わせて、プロジェクトファイルとして、開発環境（ツール１０）からデータ送信される。そこで、通信処理部４０がツール１０から送られてきたプロジェクトファイルを受信すると、その受信したデータをオブジェクト管理部２６に渡す。

これに伴い、オブジェクト管理部２６では、オブジェクトを初期化する。すなわち、サービスオブジェクトを受信した後で、ＰＬＣの状態がシステム初期状態からユーザアプリ停止状態に遷移するときにオブジェクトが初期化される。そして、係る初期化時は、サービスオブジェクト設定管理部２６ｄは、サービスオブジェクトのコンフィグレーション情報をもとに、必要なサービスオブジェクトのパラメータを取得するとともに、サービスオブジェクトを生成し、サービスプログラム記憶部２９ｂにサービスプログラムを記憶する。同様に、制御プログラム管理部２６ｄは、制御プログラムのコンフィグレーション情報をもとに、必要な制御プログラムのパラメータを取得するとともに、オブジェクトを生成し、制御プログラム記憶部２９ａに制御部プログラムを記憶する。

上記のようにして各プログラムがそれぞれ所定の記憶部に格納されたならば、オブジェクト管理部２６は、サービスオブジェクト設定管理部２６ｃ，制御プログラム管理部２６ｂで生成されたオブジェクトを登録する。以後、コントローラ状態管理部２７がＰＬＣを停止状態に遷移させ、通信処理部４０がツール１０に向けてレスポンスデータ（ダウンロード完了）を返信し、これにより、一連の処理が完了する。

図５は、ユーザアプリケーションからサービスオブジェクトが参照された場合の処理フローを示している。まず、ユーザが作成した制御プログラムまたはサービスプログラムから、サービスの機能を利用する際に、サービスオブジェクト設定管理部２６ｃに該当するサービスが存在するか否かを判定する機能を実装した。この機能は、ユーザが作成したプログラムの中に、フレームワーク２５のオブジェクト管理部２６が持つオブジェクトの取得メソッドを記述することで実現している。そして、上記機能により、該当するサービスオブジェクトのインスタンスが得られた場合は、フレームワーク２５上にサービスが存在するものとして、サービスの利用が可能な状態となる。そして、サービスオブジェクトをユーザプログラム上で利用するための処理フローが図５に示す通りである。

すなわち、例えば、開発環境（ツール１０）からユーザアプリの実行コマンドが発行され、係るコマンドを通信処理部４０が受信すると、その通信処理部４０は、コントローラ状態管理部２７に係る実行コマンドを渡すとともに、ツール１０に対してレスポンスを返送する。

コントローラ状態管理部２７は、ＰＬＣをユーザアプリ実行状態に遷移させる。次いで、制御プログラム実行エンジン４１が、実行コマンドで指定された制御プログラムを実行する。具体的には、制御プログラム実行エンジン４１が、制御プログラム管理部２６ｂに対して所望の制御プログラムの実行要求をし、それを受けた制御プログラム管理部２６ｂが該当する制御プログラムを呼び出す。

そして、サービスオブジェクトが参照されたならば、制御プログラム管理部２６ｂが、参照対象のサービスオブジェクトの有無をオブジェクト管理部２６に問い合わせる。この問い合わせを受けたオブジェクト管理部２６は、サービスオブジェクトのインスタンスを取得し、サービスオブジェクト設定部２６ｃが、参照対象のサービスオブジェクトのインスタンスを制御プログラム設定部２６ｂに返す。なお、この返信するサービスオブジェクトのインスタンスは、対象となるサービスオブジェクトが存在している場合には、当該サービスオブジェクトのインスタンスのポインタとなり、存在しない場合にはＮＵＬＬをとする。これにより、具体的なポインタが返信されてきたか否（ＮＵＬＬ）かにより、制御プログラム設定部２６ｂはサービスオブジェクトが管理対象にあるか否かを判断する。

そして、サービスオブジェクトが存在する場合には、上記ポインタに基づき、サービスオブジェクト設定管理部２６ｃが、対応するサービスプログラムの処理を呼び出し、サービスプログラム記憶部２９ｂに格納されたサービスプログラムを実行する。係るサービスプログラムの実行後、或いは、サービスプログラムが存在しない場合にはそのまま、制御プログラム実行エンジンに４１による制御プログラムの実行に移行する。

また、上記した参考例では、制御プログラムの起動はツール１０からの実行コマンドに基づいて行われるようにしたが、本発明はこれに限ることはなく、例えば、ＰＬＣ２０の電源の投入に伴って起動されるなど、各種の手法がとれる。

図６は、本発明の第２実施例を示している。まず、この第２実施例は、ユーザアプリケーション（制御プログラム）の停止時にスレッドプログラムとしてサービスプログラムを利用（実行）する機能を実装したものである。係る機能により、ユーザプログラムにおいて、制御プログラムの制御周期に依存しないサービスプログラムを、ＰＬＣが制御プログラムを実行していない状態（停止状態）であっても、ＰＬＣ２０上で実行することができる。そして、本実施例で作成対象となるサービスプログラムは、ユーザが作成する制御プログラムの動作に影響しない、ファイル転送サーバ，Ｗｅｂサーバ，メールサーバ，通信ミドルウェアなどの常時実行が必要なプログラムがある。また、このスレッドプログラムは、システム初期状態からユーザアプリ停止時に遷移した時に実行を開始し、ユーザアプリ停止状態からシステム初期状態に遷移した時に実行を終了する。

そして、係る目的・作用効果を実現するための具体的な機能ブロック構成としては、図６に示すようになる。以下の説明では、各機能のうち、参考例と相違する点について説明する。まず、開発環境であるツール１０は、サービスオブジェクト設定機能１３は、ユーザが作成したサービスプログラムをコントローラのフレームワーク上でオブジェクトとして取り扱うために必要な項目を設定する機能であり、本実施例では、参考例にて設定する項目に加え、サービススレッド実行クラス名（実行スレッドが存在するプログラムファイル名）と、サービススレッド実行優先度がある。また、サービス取り扱いフラグとしては、ＰＬＣがシステム初期状態からユーザアプリ停止状態の遷移時点で実行し、逆の遷移時点で停止する、フレームワークが制御可能なスレッドプログラムとして取り扱うように設定される。ツール１０のその他の機能は、参考例と基本的に同じである。

ＰＬＣ２０は、ツールから制御プログラム，サービスプログラム，設定情報を受信し、各記憶部に格納する。そして、サービスプログラムの動作に着目すると、係るサービスプログラムはＰＬＣが初期状態からユーザアプリ停止状態に遷移した時に、そのサービスプログラムの記述に従って実行することができるようになっている。

そして、具体的な内部構成としては、参考例のものに加え、サービスプログラム実行エンジン４２を設けた。このサービスプログラム実行エンジン４２は、サービスプログラムがサービスオブジェクト設定管理部２６ｃに登録されている場合、サービスプログラム記憶部２９ｂに記憶保持されたサービスプログラムを評価実行する機能を有する。

そして、係るサービスプログラムの実行であるが、スレッド実行を含むサービスプログラムが定義された場合、サービスオブジェクト設定部２６ｃにおいて設定されたコンフィグレーション情報（登録情報）に応じて、スレッドプログラムを実行することが可能となり、その実行開始のタイミングはＰＬＣがシステム初期状態からユーザアプリ停止状態に遷移した時となる。そして、係るスレッド実行における具体的な処理フローは、図７に示すようになる。

すなわち、まず開発環境たるツール１０から、ユーザアプリ（制御プログラム）の停止コマンド（制御プログラムの停止状態にする旨の通知コマンド）を通信処理部４０が受信したならば、コントローラ状態管理部２７が現在のＰＬＣの状態を取得し、現在の状態がシステム初期状態か否かを判断する。そして、システム初期状態でない場合、つまり、制御プログラム停止状態（ユーザアプリ停止状態）か、或いは制御プログラム実行状態（ユーザアプリ実行状態）であるため、受信したコマンドにしたがい、コントローラ状態管理部２７は、ＰＬＣの状態を制御プログラム停止状態（ユーザアプリ停止状態）に遷移させる。そして係る遷移完了後には、通信処理部４０がツール１０に対してレスポンスデータ（停止状態に遷移したこと）を返信する。なお、停止状態，実行状態のいずれの状態においても、それより以前の段階で、初期状態から停止状態に遷移しているため、係る遷移の際に以下に説明する手順に従い、サービスプログラム実行エンジン４２によるサービスプログラムが実行されているため、その状態が継続する。

また、上記した停止コマンドの受信に伴いコントローラ状態管理部２７が確認した現在の状態がシステム初期状態の場合には、サービスプログラム実行エンジン４２がサービスプログラムの実行命令を出力する。これに伴い、まず、オブジェクト管理部２６が、サービスオブジェクトの登録情報（コンフィグレーション情報）を検索する。ついで、サービスオブジェクト設定管理部２６ｃが、登録件数に達したか否か、つまり、オブジェクト管理部２６が検索して抽出した全てのサービスオブジェクトに対する処理が完了したか否かを判断し、未処理のものがある場合には、サービスオブジェクト設定管理部２６ｃが、サービスオブジェクトの設定情報を取得し、本実施例のスレッド実行の定義がされているか否かを判断し、されていない場合には次の登録情報を検索する。また、スレッド実行の定義がされている場合には、実行対象のサービスプログラムを呼び出し、サービスプログラム記憶部２９ｂに格納されたサービスプログラムを実行する。その後、次の登録情報を検索する。

このようにして、スレッド実行の定義がされたサービスプログラムが全て実行されると、登録件数に達するので、コントローラ状態管理部２７がユーザアプリ停止状態に遷移させ、ツール１０に対して、レスポンスデータを返信する。

一方、上記のようにして起動・実行されたサービスプログラムを停止する場合には、以下のようになる。すなわち、スレッド実行を含むサービスプログラムが定義された場合、サービスオブジェクト設定において設定されたコンフィグレーション情報（登録情報）に応じて、スレッドプログラムを停止することが可能となる。実行停止のタイミングはＰＬＣ２０がユーザアプリ停止状態からシステム初期状態へ遷移した時となる。そして、係るスレッド停止における具体的な処理フローは、図８のようになる。

すなわち、開発環境であるツール１０から、コントローラ（ＰＬＣ）に対してリセット命令が発行され、通信処理部４０が係るリセット命令であるシステム初期化コマンドを受信したならば、コントローラ状態管理部２７が現在のＰＬＣの状態を取得し、現在の状態がユーザアプリ停止状態（制御プログラム停止状態）か否かを判断する。そして、ユーザアプリ停止状態の場合には、サービスプログラム実行エンジン４２がサービスプログラムの停止命令を出力する。これに伴い、まず、オブジェクト管理部２６が、サービスオブジェクトの登録情報（コンフィグレーション情報）を検索する。ついで、サービスオブジェクト設定管理部２６ｃが、登録件数に達したか否か、つまり、オブジェクト管理部２６が検索して抽出した全てのサービスオブジェクトに対する処理が完了したか否かを判断し、未処理のものがある場合には、サービスオブジェクト設定管理部２６ｃが、サービスオブジェクトの設定情報を取得し、本実施例のスレッド実行の定義がされているか否かを判断し、されていない場合には次の登録情報を検索する。また、スレッド実行の定義がされている場合には、実行対象のサービスプログラムを呼び出し、サービスプログラム記憶部２９ｂに格納されたサービスプログラムを停止する。その後、次の登録情報を検索する。

このようにして、スレッド実行の定義がされたサービスプログラムが全て停止されると、登録件数に達するので、コントローラ状態管理部２７がシステム初期状態に遷移させ、ツール１０に対して、レスポンスデータを返信する。

なお、本実施例では、ユーザアプリ停止状態からシステム初期状態に遷移する際にスレッド実行のサービスプログラムを停止するようにしたため、システム初期化コマンドを受信した際の状態がユーザアプリ停止状態でない場合には、サービスプログラムの停止処理は行わない。つまり、図８の処理フローには記載していないが、制御プログラム実行状態（ユーザアプリ実行状態）の場合には、一旦停止状態に移行させ、また、すでにシステム初期状態の場合には、その旨レスポンスデータを返信する。

なお、本実施例において、制御プログラムあるいは他のサービスプログラムから該当するサービスプログラムの関数呼び出しがある場合は、参考例の方式に従って、ライブラリの関数単位でプログラムを実行する（図５に示す処理フローを実行する）ことも可能である（図６中の点線表記の処理の流れ参照）。

図９，図１０は、本発明の第３実施例の要部を示している。すなわち、本実施例では、スレッドプログラムとしてのサービスプログラムの実行／停止タイミングが第２実施例と相違する。すなわち、ユーザアプリケーション（制御プログラム）実行時にスレッドプログラムとしてサービスプログラムを使用するようにしている。つまり、第２実施例では、制御プログラムの停止状態並びに実行状態のいずれの状態でもサービスプログラムが実行されるようにしたが、本実施例では、制御プログラムの稼働中のみサービスプログラムも実行するようにした。つまり、ユーザアプリ（制御プログラム）の停止状態から実行状態に遷移する際にサービスプログラムは実行開始し、実効状態から停止状態に遷移する際にサービスプログラムが停止するようにする。そして、本実施例で作成対象となるサービスプログラムは、上位アプリケーションとの通信サーバ機能などのユーザアプリ実行時に常時実行となるスレッドプログラムがある。

本実施例を利用することにより、ユーザ作成プログラムにおいて、制御プログラムの制御周期に依存しない、常時実行するサービスプログラムを、ＰＬＣが制御プログラムを実行している状態の時に、ＰＬＣ上で実行することが可能となる。

そして、係る目的・効果を達成するための本実施例における機能ブロック図は図６に示した第２実施例と同一であるが、所定の処理部の機能を異ならせた。そこで、第２実施例との相違点を中心に説明する。

まず、サービスオブジェクト設定機能部１３において設定する項目は第２実施例と同様であるが、定義したサービスプログラムをフレームワーク上でどのように取り扱うかを決めるフラグであるサービス取り扱いフラグが、ＰＬＣがユーザアプリ停止状態からユーザアプリ実行状態の遷移時点で実行し、逆の遷移時点で停止する、フレームワークが制御可能なスレッドプログラムとして取り扱うようにする。

また、ＰＬＣは、ツールから制御プログラム，サービスプログラム並びに設定情報を受信し、各記憶部に格納する点では同じであり、サービスプログラムはＰＬＣがユーザアプリ実行状態（制御プログラム実行状態）に遷移した時に、そのサービスプログラムの記述に従って実行する。そして、スレッド実行における処理フローとしては、図９に示すとおりとなる。

すなわち、まず開発環境たるツール１０から、ユーザアプリ（制御プログラム）の実行コマンド（制御プログラムを実行状態にする旨の通知コマンド）を通信処理部４０が受信したならば、コントローラ状態管理部２７が現在のＰＬＣの状態を取得し、現在の状態がユーザアプリ停止状態（制御プログラム停止状態）か否かを判断する。そして、上記した停止コマンドの受信に伴いコントローラ状態管理部２７が確認した現在の状態がユーザアプリ停止状態の場合には、サービスプログラム実行エンジン４２がサービスプログラムの実行命令を出力する。これに伴い、まず、オブジェクト管理部２６が、サービスオブジェクトの登録情報（コンフィグレーション情報）を検索する。ついで、サービスオブジェクト設定管理部２６ｃが、登録件数に達したか否か、つまり、オブジェクト管理部２６が検索して抽出した全てのサービスオブジェクトに対する処理が完了したか否かを判断し、未処理のものがある場合には、サービスオブジェクト設定管理部２６ｃが、サービスオブジェクトの設定情報を取得し、本実施例のスレッド実行の定義がされているか否かを判断し、されていない場合には次の登録情報を検索する。また、スレッド実行の定義がされている場合には、実行対象のサービスプログラムを呼び出し、サービスプログラム記憶部２９ｂに格納されたサービスプログラムを実行する。その後、次の登録情報を検索する。

このようにして、スレッド実行の定義がされたサービスプログラムが全て実行されると、登録件数に達するので、コントローラ状態管理部２７がユーザアプリ実行状態に遷移させ、ツール１０に対して、レスポンスデータを返信する。

なお、本実施例では、ユーザアプリ停止状態から実行状態に遷移する際にスレッド実行のサービスプログラムを実行するようにしたため、実行コマンドを受信した際の状態がユーザアプリ停止状態でない場合、つまり、すでに実行状態の場合にはそのまま処理を継続し、システム初期状態の場合には一旦ユーザプログラム停止状態に遷移させた後、上記の処理を実行する。そして、図１０の処理フローには記載していないが、その旨のレスポンスデータをツール１０に返信する。

なお、本実施例では、ユーザアプリ実行状態から停止状態に遷移する際にスレッド実行のサービスプログラムを停止するようにしたため、停止コマンドを受信した際の状態がユーザアプリ実行状態でない場合には、それ以前の段階でサービスプログラムが停止されているため、今回受信した停止コマンドに基づいて停止処理は行わない。つまり、図１０の処理フローには記載していないが、その旨レスポンスデータを返信する。

一方、上記のようにして起動・実行されたサービスプログラムを停止する場合には、以下のようになる。すなわち、スレッド実行を含むサービスプログラムが定義された場合、サービスオブジェクト設定において設定されたコンフィグレーション情報（登録情報）に応じて、スレッドプログラムを停止することが可能となる。実行停止のタイミングはＰＬＣ２０がユーザアプリ実行状態から停止状態へ遷移した時となる。そして、係るスレッド停止における具体的な処理フローは、図１０のようになる。

すなわち、開発環境であるツール１０から、コントローラ（ＰＬＣ）に対してユーザアプリの停止命令が発行され、通信処理部４０が係る停止命令である停止コマンドを受信したならば、コントローラ状態管理部２７が現在のＰＬＣの状態を取得し、現在の状態がユーザアプリ実行状態（制御プログラム実行状態）か否かを判断する。そして、ユーザアプリ実行状態の場合には、サービスプログラム実行エンジン４２がサービスプログラムの停止命令を出力する。これに伴い、まず、オブジェクト管理部２６が、サービスオブジェクトの登録情報（コンフィグレーション情報）を検索する。ついで、サービスオブジェクト設定管理部２６ｃが、登録件数に達したか否か、つまり、オブジェクト管理部２６が検索して抽出した全てのサービスオブジェクトに対する処理が完了したか否かを判断し、未処理のものがある場合には、サービスオブジェクト設定管理部２６ｃが、サービスオブジェクトの設定情報を取得し、本実施例のスレッド実行の定義がされているか否かを判断し、されていない場合には次の登録情報を検索する。また、スレッド実行の定義がされている場合には、実行対象のサービスプログラムを呼び出し、サービスプログラム記憶部２９ｂに格納されたサービスプログラムを停止する。その後、次の登録情報を検索する。

このようにして、スレッド実行の定義がされたサービスプログラムが全て停止されると、登録件数に達するので、コントローラ状態管理部２７がユーザアプリ停止状態に遷移させ、ツール１０に対して、レスポンスデータを返信する。

なお、本実施例では、ユーザアプリ実行状態から停止態に遷移する際にスレッド実行のサービスプログラムを停止するようにしたため、停止コマンドを受信した際の状態がユーザアプリ実行状態でない場合には、それ以前の段階でサービスプログラムが停止されているため、今回受信した停止コマンドに基づいて停止処理は行わない。つまり、図１０の処理フローには記載していないが、その旨レスポンスデータを返信する。

なお、本実施例において、制御プログラムあるいは他のサービスプログラムから該当するサービスプログラムの関数呼び出しがある場合は、参考例の方式に従って、ライブラリの関数単位でプログラムを実行する（図５に示す処理フローを実行する）ことも可能である（図６中の点線表記の処理の流れ参照）。

図１１は、本発明の第４実施例を示している。本実施例では、サービスプログラムの追加・削除・入替機能を組み込んでいる。すなわち、本発明では、制御プログラムとサービスプログラムを分離して作成し、記憶保持し、それぞれが独立して実行可能とした。そのため、ＰＬＣの稼動状態に依存せずに対象となるユーザ作成プログラムの追加・削除・入替が可能であるため、プログラム入替のためにＰＬＣを停止する（制御プログラムを停止する）必要がない。このことにより、ＰＬＣ２０の稼動率が向上する。さらに、制御プログラムに依存しないサービスプログラムの追加・削除・入替も可能であるため、サービス機能のバージョンアップや、使用環境に応じて必要な機能だけを搭載したＰＬＣの実装が容易になる。

そして、上記した目的・効果を実現するための構成としては、図１１に示すような内部構成をとることができる。もちろん、この図は、本実施例の特徴部分を示しており、第１から第３実施例に示すような制御プログラムを実行するための機能ももちろん備えている。以下、ブロック図内で示される各機能のうち、参考例や第２，第３実施例と差異がある項目について説明する。

ＰＬＣ２０は、ツールからサービスオブジェクトの追加，削除，入替のコマンドを受信し、そのタイミングに応じて、設定情報を受信する。そして、追加コマンドの場合は、サービスプログラムも合わせて受信し、記憶部に格納する。また、削除コマンドの場合は、サービスプログラム記憶部にある対象のプログラムを削除する。さらに、入替コマンドの場合は、サービスプログラムも合わせて受信し、入替後のプログラムを記憶部に格納し、入替前のプログラムを削除する。そして、サービスオブジェクト設定管理部が、各処理に応じて、オブジェクトの登録状態を変更後の状態に則して管理情報を更新する。なお、第２，第３実施例のように、サービスオブジェクトにスレッド実行指定がある場合は、現在のコントローラの動作状態に合わせて実行または停止状態に遷移する。

通信機能部４０は、各実施例と同様に開発環境であるツール１０からコマンドを受信し、各機能ブロックの処理への依頼や、記憶部へのデータ格納を行うものである。そして、本実施例で受信するコマンドとしては、以下の３つのコマンドがある。
（１）サービスオブジェクト追加コマンド
ユーザが作成したサービスプログラムをコントローラに追加登録するコマンドである。このコマンドを受信した場合には、対象となるサービスオブジェクトがスレッドプログラムとして実行するよう設定されている場合は、コントローラの動作状態に合わせて実行する。

（２）サービスオブジェクト削除コマンド
ユーザが作成したサービスプログラムをコントローラの登録対象から削除するコマンドである。このコマンドを受信した場合には、対象となるサービスオブジェクトがスレッドプログラムとして実行するよう設定されている場合は、スレッドプログラムを停止してから削除する。

（３）サービスオブジェクト入替コマンド
ユーザが作成したサービスプログラムを、既にコントローラ上に登録されているものと入れ替えるコマンドである。このコマンドを受信した場合には、対象となるサービスオブジェクトがスレッドプログラムとして実行するよう設定されている場合は、既に登録されているオブジェクトのスレッドを停止してから新たに入れ替えたスレッドを、コントローラの動作状態に合わせて実行する。

さらに本実施例では、上記した各実施例と相違して、オンラインエディット処理部４５を設けた。このオンラインエディット処理部４５は、ＰＬＣ２０上に配置される各オブジェクトに対して、オブジェクトごとの追加・削除・入替処理を行うものである。入替え時の古いオブジェクトのパラメータ継承や、親子関係を持つオブジェクトの関連づけの変更処理などをこの機能の中で実行する。そして、具体的には、図１２以降に示す処理フローを実施するようになっている。すなわち、サービスプログラムの追加処理は、図１２に示すシーケンス図の通り実行し、サービスプログラムの削除処理は、図１３に示すシーケンス図の通り実行し、サービスプログラムの置換処理は、図１４，図１５に示すシーケンス図の通り実行する。

まず、図１２に示すように、開発環境たるツール１０から、追加するサービスオブジェクトがダウンロードされてくると、通信処理部４０が設定ファイルと追加するプログラムファイルを受信するため、その受信したデータをオブジェクト管理部２６に渡す。

これに伴い、オブジェクト管理部２６では、オブジェクトを初期化する。係る初期化時は、サービスオブジェクト設定管理部２６ｄは、サービスオブジェクトのコンフィグレーション情報をもとに、必要なサービスオブジェクトのパラメータを取得するとともに、サービスオブジェクトを生成し、サービスプログラム記憶部２９ｂにサービスプログラムを記憶する。

次いで、オブジェクト管理部２６では、新規に追加するサービスオブジェクトについての追加登録し、オンラインエディット処理部４５では、オブジェクトに必要な追加処理を実行する。すなわち、すでに存在している他のサービスオブジェクト等と入子や親子関係になる場合には、係る関係情報を設定し、関連づけを行なう等の処理を行なう。

そして、サービスオブジェクト設定管理部は、サービスプログラムにスレッド実行の定義があるか否かを判断し、無い場合には、そのまま通信処理部４０がレスポンスデータを返信して追加処理を終了する。

また、スレッド実行の定義がある場合には、現在のコントローラ（ＰＬＣ）の状態（システム初期か状態／制御プログラム停止状態／制御プログラム実行状態）を確認し、現在の状態がスレッド実行の設定値と一致する場合には、実行対象のサービスプログラムを呼び出して、当該サービスプログラムを実行する。このスレッド実行については、第２，第３実施例と同様である。

また、図１３に示すように、サービスオブジェクトの削除は、開発環境たるツール１０から、サービスオブジェクトの削除コマンド（削除対象のサービスオブジェクトを指定）が送られてくるので、通信処理部４０が係る削除コマンドを受信すると、その受信した削除コマンドをオブジェクト管理部２６に渡す。

これに伴い、オブジェクト管理部２６では、削除対象のオブジェクトを検索し、検索したオブジェクトをオンラインエディット処理部４５に通知する。オンラインエディット処理部４５では、オブジェクトに必要な削除処理を実行する。すなわち、親子関係等の関連する他のサービスオブジェクトが存在するか否かを判断し、関係する他のオブジェクトが存在する場合には、その関係を解消する処理を行なう等の処理を行なう。

そして、サービスオブジェクト設定管理部は、サービスプログラムにスレッド実行の定義があるか否かを判断し、スレッド実行の定義がある場合には、実行対象のサービスプログラムを呼び出し、サービスプログラム設定部２６ｃが当該サービスプログラムを停止する。

そして、オブジェクト管理部２６では削除対象となっているオブジェクトを登録対象から削除し、次いで、サービスプログラム記憶部２９ｂに格納された該当するサービスプログラムを消去するとともに、サービスオブジェクト設定管理部２６ｃにて削除したサービスプログラムについてのオブジェクトを削除する。次いで、レスポンスデータを返信し、一連削除処理を終了する。

図１４，図１５に示すように、サービスプログラムの入れ替え処理は、まず、開発環境たるツール１０からの命令に基づき、上記した追加と同様の手順により、入替後の新たなサービスオブジェクトを生成するとともに、ダウンロードされてきた新たなサービスプログラムをサービスプログラム記憶部２９ｂに記憶し、オブジェクト管理部２６では入替後のオブジェクトを追加登録する。

その後、オンラインエディット処理部４５は、入替前のオブジェクトのパラメータを転送する。これにより、入替後のサービスプログラムは、転送された現在のパラメータに従って実行可能となる。

次いで、入替前のオブジェクトの削除工程を実行する。すなわち、上記した削除と同様に、入替前のオブジェクトについてスレッド実行の定義の有無を判断し、存在している場合には、該当する入替前のオブジェクトのサービスプログラムを停止する。そして、オブジェクト管理部２６は入替前のオブジェクトを登録対象から削除し、サービスプログラム記憶部２９ｂに格納された入替前のサービスプログラムを詳記し、サービスオブジェクト設定管理２６ｃが入替前のオブジェクトを削除する。

その後、入替後のサービスプログラムの実行、つまり、入替後のオブジェクトにスレッド実行の定義があるか否かを判断し、存在する場合には、コントローラ（ＰＬＣ）の状態を取得し、取得した現在の状態がスレッド実行の設定値に一致している場合には、その一致する入替後のサービスプログラムを呼び出し、入替後のサービスプログラムを実行する。

上記のようにサービスプログラムの実行後、或いは、スレッド実行の定義が無いか、仮にあったとしても現在の状態と設定値が一致しない場合には、プログラム実行をすることなく、処理完了のレスポンスデータをツール１０に向けて返信し、一連の入替処理を完了する。

以上を要するに、各実施例では、イベント（制御周期や割込み要因）駆動で動作する制御プログラムとは別に、呼び出し可能なライブラリや常時実行可能なプログラムとしてのサービスプログラムを定義するとともに、コントローラ上に配置されるプログラムの機能単位をオブジェクトとして保有し管理するオブジェクト管理機能を設けた。これらは、Ｊａｖａ（登録商標）を用いて実現できる。

これにより、制御アプリケーションからのサービスプログラム呼び出しを簡単に実行することができるようになった。さらに、入出力機器の制御を行う制御プログラムから、直接制御に関連しない汎用プログラムとして分離することにより、ユーザが作成するプログラムの再利用性が向上する。同じプログラム開発環境を利用する汎用プログラムに対して、汎用プログラムのソースコードの変更なく、コントローラで実行するための設定追加と、制御プログラムからの呼び出し機能追加を行うことで、利用することが可能となる。

そして、第２，第３実施例では、ＰＬＣの動作状態を取得し、常時実行可能なサービスプログラムの起動・停止を制御するサービスプログラム実行エンジンを設けた。これにより、上記した作用効果に加え、コントローラの実行・停止に合わせて、サービスプログラムを実行・停止することができ、また、コントローラが停止状態にあっても、サービスプログラムを常駐実行することができるようになった。

さらに、第４実施例では、オブジェクトごとにプログラムの追加・削除・入替処理を実行するオンラインエディット機能を設けた。これにより、コントローラの実行・停止状態に依存せず、サービスプログラムを追加、削除、変更することができるようになった。これにより、プログラム入替のためにコントローラを停止する必要がなくなり、コントローラの稼動率が向上する。そして、制御プログラムに依存しないサービスプログラムの追加・削除・入替も可能であるため、サービス機能のバージョンアップや、使用環境に応じて必要な機能だけを搭載したコントローラの実装が容易になる。

本発明が適用されるネットワーク構成の一例を示す図である。 本発明の好適な一実施の形態を示すソフトウェア構成図である。 参考例を示す機能ブロック図である。 機能（サービスオブジェクトのダウンロード＆初期化等）を説明する処理フローである。 機能（サービスオブジェクト参照）を説明する処理フローである。 本発明の第２実施例を示す機能ブロック図である。 第２実施例の機能（サービスオブジェクトのスレッド実行）を説明する処理フローである。 第２実施例の機能（サービスオブジェクトのスレッド停止）を説明する処理フローである。 第３実施例の機能（サービスオブジェクトのスレッド実行）を説明する処理フローである。 第３実施例の機能（サービスオブジェクトのスレッド停止）を説明する処理フローである。 本発明の第４実施例を示す機能ブロック図である。 第４実施例の機能（サービスオブジェクトの追加）を説明する処理フローである。 第４実施例の機能（サービスオブジェクトの削除）を説明する処理フローである。 第４実施例の機能（サービスオブジェクトの入替）を説明する処理フローである。 第４実施例の機能（サービスオブジェクトの入替）を説明する処理フローである。

符号の説明

１０ ツール
１１ プログラムエディタ
１２ 設定ツール
１３ サービスオブジェクト設定機能
２０ ＰＬＣ
２１ リアルタイムＯＳ
２２ ファイルシステム
２３ ネットワークドライバ
２４ Ｉ／Ｏユニットバスドライバ
２５ フレームワーク
２６ オブジェクト管理部
２６ａ イベント管理部
２６ｂ 制御プログラム管理部
２６ｃ サービスオブジェクト設定管理部
２６ｄ Ｉ／Ｏユニット管理部
２７ コントローラ状態管理部
２８ 保守・障害管理部
２９ ユーザメモリ
２９ａ 制御プログラム記憶部
２９ｂ サービスプログラム記憶部
３０ 上位コンピュータ
３１ ネットワーク
３２ 公衆回線網
３３ ネットワーク
３５ 携帯電話
３６ 機器
４０ 通信処理部
４１ 制御プログラム実行エンジン
４２ サービスプログラム実行エンジン
４５ オンラインエディット処理部

Claims (3)

1. 機器制御を行なうための制御プログラムを記憶する制御プログラム記憶手段と、
   前記機器制御に依存しないサービスプログラムを記憶するサービスプログラム記憶手段と、
   前記制御プログラム記憶手段に記憶保持された制御プログラムと、前記サービスプログラム記憶手段に記憶保持されたサービスプログラムを、それぞれ実行する手段を備え、
   前記サービスプログラムは、前記制御プログラムに依存しない独立して実行可能なプログラムとして記憶保持され、
   プログラマブルコントローラの動作状態に合わせて、実行，停止の制御が行なわれるようにしてなることを特徴とするプログラマブルコントローラ用機器。
2. 機器制御を行なうための制御プログラムを記憶する制御プログラム記憶手段と、
   前記機器制御に依存しないサービスプログラムを記憶するサービスプログラム記憶手段と、
   前記制御プログラム記憶手段に記憶保持された制御プログラムと、前記サービスプログラム記憶手段に記憶保持されたサービスプログラムを、それぞれ実行する手段を備え、
   前記サービスプログラムは、前記制御プログラムに依存しない独立して実行可能なプログラムとして記憶保持され、
   プログラマブルコントローラが停止状態でも、前記サービスプログラムを常駐実行できるようにしてなることを特徴とするプログラマブルコントローラ用機器。
3. 前記サービスプログラムは、プログラマブルコントローラの動作状況に依存せずに、追加，削除，変更の少なくとも１つを行う手段を備えたことを特徴とする請求項１または２に記載のプログラマブルコントローラ用機器。

Images