(57)【特許請求の範囲】
【請求項１】
ネットワークに接続取り外し可能なセンサであって、
受け取ったデータに対して、格納された処理プログラムに基づいてセンシング信号処理を行う信号処理部と、
前記信号処理部の処理結果を出力する手段と、
ネットワークを介した上位層からの指令で前記信号処理部をバイパスし、前記受け取ったデータをセンシング信号処理することなく出力する手段とを備えたことを特徴とするセンサ。
【請求項２】
前記信号処理部に格納された処理プログラムを、上位装置に向けて出力する機能を備えた請求項１に記載のセンサ。
【請求項３】
ネットワークを介して上位装置から処理プログラムを受け取るとともに、前記信号処理部にて、前記格納された処理プログラムに代えて、その受け取った処理プログラムを実行して受け取ったデータに対してセンシング信号処理を行うようにしたことを特徴とする請求項１または２に記載のセンサ。
【請求項４】
複数のセンサと、そのセンサの出力をネットワークを介して受信する上位装置とを備えたセンサシステムであって、
前記複数のセンサのそれぞれは、
生データに対して格納された処理プログラムに基づいてセンシング信号処理を行う信号処理部と、
前記信号処理部の処理結果を出力する手段と、
ネットワークを介した上位層からの指令で前記信号処理部をバイパスし、前記受け取ったデータをセンシング信号処理することなく出力する手段と、
前記信号処理部に格納された処理プログラムを上位装置に向けて出力する機能と、を備え、
前記上位装置は、
センサからネットワークを介して前記処理プログラムを受け取るとともに、その受け取った処理プログラムを実行し、前記ネットワークを介してセンサから送られる生データに対してセンシング信号処理を行う手段、を備えたことを特徴とするセンサシステム。
【請求項５】
前記上位装置は、
前記複数のセンサからネットワークを介して受取った処理プログラムをそれぞれ比較する手段と、
選択された１つの処理プログラムを前記複数のセンサに出力する手段と、を備え、
前記複数のセンサは、それぞれの信号処理部にて、格納された処理プログラムに代えて、その受け取った処理プログラムを実行して受け取ったデータに対してセンシング信号処理を行うようにすることを特徴とする請求項４に記載のセンサシステム。
【請求項６】
前記上位装置は、
前記センサが有する処理プログラムをネットワークを介してアップロードして受取る手段と、
前記ネットワークに接続されるデータベースから最新の処理プログラムに関する情報を取得し、前記アップロードした処理プログラムが最新のものか否かを判断し、最新のものでないと判断した場合には、前記最新の処理プログラムを前記センサにダウンロードする手段と、を備えたことを特徴とする請求項４または５に記載のセンサシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、センサ及びセンサシステムに関するものである。
【０００２】
【従来の技術】
従来、ＦＡシステム等において各種の制御をする場合、ＰＬＣにセンサ等を接続し、そのセンサで検出した情報をＰＬＣで解析し、その解析結果に基づいてＰＬＣの制御対象の機器に対して制御命令を送り、協調・同期制御等を行うようになっている。
【０００３】
そして、近年、センサに信号処理機能を付加したものが開発されている。すなわち、図１に示すように、センサ１をＰＬＣ２の下位に接続する。センサ１には、センサヘッド３を接続し、そのセンサヘッドで検出した信号をデジタル化するＡ／Ｄ変換器１ａと、受信したデータを信号処理し、センシング情報を生成する信号処理回路１ｂと、その信号処理回路１ｂで生成したセンシング情報を上位のＰＬＣ２へ送るためのインタフェース（Ｉ／Ｆ）１ｃを有し、さらに、上記の信号処理をするためのプログラムやパラメータ等を格納するＲＯＭ１ｄ並びに作業用メモリとしてのＲＡＭ１ｅなどを有している。そして、上記の信号処理は、例えば「入力信号がある条件に一致すればＯＮとする」等の処理である。
【０００４】
また、係るセンシング信号処理機能を備えたセンサが接続されるＰＬＣ２は、センサ１から接点のＯＮ／ＯＦＦ信号を、接点入出力インタフェース２ａを介してコントローラアプリケーション２ｂが受け取り、そのコントローラアプリケーション２ｂが、接点のＯＮ／ＯＦＦ信号に基づいてシーケンス制御やプロセス制御を行うようになる。さらに、このＰＬＣ２は、ネットワークインタフェース２ｃを介して、イーサネット等のネットワークに接続可能となっている。
【０００５】
【発明が解決しようとする課題】
しかしながら、上記した図１に示す従来のセンサでは、以下に示す問題を有している。すなわち、センサ１は、必要機能を実現するための信号処理回路１ｂの内容（機能）が固定されており、別な機能の追加や変更をするには、信号処理回路１ｂの交換や増設、或いはセンサ１そのものを交換する必要があった。従って、汎用性・柔軟性に欠けるという問題がある。
【０００６】
また、すべての機能をあらかじめ実装しておき、必要に応じて動作を切り替えるという方法も考えられる。つまり、各機能にあわせた信号処理回路を複数用意し、それらを並列的に配置する。そして、マルチプレクサなどの切り替え器を用い、いずれか必要な信号処理回路を動作可能にすることができる。しかし、係る構成をとった場合、多大なハードウェア資源を要するため必要以上にコストが増大するという新たな問題を生じる。さらに、あらかじめ予定していて実装した機能以外の新たな機能追加や変更には対応できないという点では、図１に示すものと同様の問題を有する。
【０００７】
さらに、上記した機能変更を行う場合には、センサの動作を停止した状態で行わなければならず、そのセンサを組み込んだネットワーク・システムが一時停止してしまい、システムの稼動率が低下するという問題がある。また、ＲＡＭ１ｅの容量も決まっているので、実際の処理に必要な作業エリアが足りなくなると、処理ができなくなる等の問題も有する。
【０００８】
さらにまた、ＰＬＣ等の上位装置に同種の複数のセンサが接続されているような場合、購入時期のずれなどから、個々のセンサに格納された処理プログラムのバージョンが異なることがある。このような場合、できれば同種のセンサのバージョンは揃えたいという要求があるが、バージョンを揃えるためには、例えば古いバージョンのセンサを廃棄し、新しいバージョンのセンサに交換することになり、コスト・資源の無駄となる。また、各センサのバージョンを調べる処理も煩雑となる。
【０００９】
本発明は、上記した背景に鑑みてなされたもので、その目的とするところは、上記した問題を解決し、例えばパソコンやＰＬＣ等の処理装置（上位ホスト，上位装置）と連携して信号処理の回路構成を再編し、センサのハードウェア資源を再利用することにより、少ないハードウェア資源で多様な処理機能を実現することのできるセンサ及びセンサシステムを提供することにある。さらに、機能の追加や変更に対して、現実的なコストで、システムの運転を停止することなく、容易に対応できるセンサシステムを提供する。
【００１０】
【課題を解決するための手段】
上記した目的を達成するために、本発明に係るセンサでは、ネットワークに接続取り外し可能なセンサであって、受け取ったデータに対して格納された処理プログラムに基づいてセンシング信号処理を行う信号処理部と、前記信号処理部の処理結果を出力する手段と、ネットワ−クを介した上位装置からの指令で、前記信号処理部をバイパスし、前記受け取ったデータをセンシング信号処理することなく出力する手段とを備えて構成した（請求項１）。
【００１１】
係る構成にすると、例えば通常はセンサに接続されたセンサヘッドから受け取ったデータに対してセンシング信号処理をし、処理済みのデータをＰＬＣ等に送るようにし、必要に応じてその経路を切り替えて信号処理部をバイパスさせ、センシング処理をせず、生データを上位装置に送り、その生データに対するセンシング信号処理を上位装置に委託でき、余裕のできたセンサのハードウェア資源を利用できる。係る処理を、動的（センサ稼働中に一時停止等することなく）に行なうことができる。
【００１２】
従って、例えばセンサがロギング機能を備えていて、ロギングに使用できる記憶領域が足りなくなった時に、ロギング領域を拡張したりロギングデータ回収を上位装置に指示して、ロギングデータを確実に保存／回収できる。また、稼働中に、システムの動作を停めることなく、センサのハードウェア資源を利用してパラメータチューニングや自己診断作業等を実行できる。もちろん、その他の利用形態も採り得る。
【００１３】
そして、本発明に係るセンサは、好ましくは前記信号処理部に格納された処理プログラムを、上位装置に向けて出力する機能を備えて構成することである（請求項２）。
【００１４】
このようにすると、センシング信号処理を上位装置に委託するに際し、センサが有する処理プログラムを上位装置に送ることで、上位装置側では、あらかじめセンサの種類やプログラムのバージョンに関するデータベースを持っていなくても、プログラムの同一性を確実に保証できる。つまり、センサで行うセンシング信号処理と同一の処理を上位装置で行うことができる。
【００１５】
このとき、少なくとも上位装置に送るプログラムは例えばＪａｖａのようなプラットフォーム非依存の高級言語で記述しておくとよい。つまり、センサが信号処理を実行するためのプログラムと、これとまったく同一機能で例えばＪａｖａのようなプラットフォーム非依存言語で記述されたプログラムを１セットとして記憶領域に格納しておくとよい。もちろん、センサ側でＪａｖａ等のプログラムを実行できる環境にあれば、上記のように言語の異なる２つのプログラムを用意する必要が無いのはもちろんである。
【００１６】
さらにまた、ネットワークを介して上位装置から処理プログラムを受け取るとともに、前記信号処理部にて、前記格納された処理プログラムに代えて、その受け取った処理プログラムを実行して受け取ったデータに対してセンシング信号処理を行うように構成しても良い（請求項３）。すなわち、処理プログラムの更新ができるようにしておけば、不具合を修正したり、新しいバージョンのものに書き替えることができる。よって、最新で最適なプログラムを用いてセンシング信号処理をすることができる。これは、図２０〜図２４に示す第３の実施の形態及びその変形例や、図２５〜図２８に示す第４の実施の形態並びに図２９に示す第５の実施の形態により実現されている。
【００１７】
すなわち、稼働中にシステムの動作を停めることなく、センサの信号処理プログラムのバージョンをチェックして最新版に更新したり（第３の実施の形態）、上位ホストにクロス開発環境を持たせて、稼働中にシステムの動作を停めることなく、センサの信号処理プログラムの修正や変更ができる（第４の実施の形態）。さらには、第５の実施の形態で説明したように、プログラムを分割し、一部をセンサで処理し、残りを上位装置で行うようにすることもできる（この場合に当該一部のプログラムをダウンロードする部分がこの請求項３に属する）。
【００２１】
さらに、本発明に係るセンサシステムでは、複数のセンサと、そのセンサの出力をネットワークを介して受信する上位装置とを備えたセンサシステムであって、前記複数のセンサのそれぞれは、生データに対して格納された処理プログラムに基づいてセンシング信号処理を行う信号処理部と、前記信号処理部の処理結果を出力する手段と、ネットワークを介した上位層からの指令で前記信号処理部をバイパスし、前記受け取ったデータをセンシング信号処理することなく出力する手段と、前記信号処理部に格納された処理プログラムを上位装置に向けて出力する機能と、を備え、前記上位装置は、センサからネットワークを介して前記処理プログラムを受け取るとともに、その受け取った処理プログラムを実行し、前記ネットワークを介してセンサから送られる生データに対してセンシング信号処理を行う手段、を備えて構成した。
【００２２】
本発明では、上位装置自体は、あらかじめセンシング信号処理するための処理プログラムを有していなくて良いので、簡易化できるばかりでなく、そこで実行するセンシング処理は、センサが行うのと等価のものとなる。
【００２３】
また、本発明に係るセンサシステムでは、前記上位装置は、前記複数のセンサからネットワークを介して受取った処理プログラムをそれぞれ比較する手段と、選択された１つの処理プログラムを前記複数のセンサに出力する手段と、を備え、前記複数のセンサは、それぞれの信号処理部にて、格納された処理プログラムに代えて、その受け取った処理プログラムを実行して受け取ったデータに対してセンシング信号処理を行うように構成した。この発明は、第３の実施の形態の変形例により実現されている。このようにすると、ネットワーク上に同種のセンサが複数存在する場合に、例えばその中の最新のバージョンのものに統一することができる。
【００２４】
また、前記上位装置は、前記センサが有する処理プログラムをネットワークを介してアップロードして受取る手段と、前記ネットワークに接続されるデータベースから最新の処理プログラムに関する情報を取得し、前記アップロードした処理プログラムが最新のものか否かを判断し、最新のものでないと判断した場合には、前記最新の処理プログラムを前記センサにダウンロードする手段と、を備えて構成しても良い。この発明は、第３の実施の形態により実現されている。
【００２５】
このようにすると、データベースを更新しておくだけで、例えば定期的にセンサに格納された処理プログラムのバージョンをチェックすることにより、センサの処理プログラムを最新のものに更新することができる。
【００２８】
＊用語の定義
本発明でいうところの「上位装置」は、ネットワークの接続形態における上位という概念にはとらわれず、センサの替わりにセンシング信号処理をする装置は全て上位装置となる。従って、ネットワーク上のあらゆる機器が上位装置に成り得る。
【００２９】
【発明の実施の形態】
図２は、本発明に係るセンサシステムの一実施の形態を示している。同図に示すように、ネットワークに接続して双方向に通信できるセンサ１０と、ネットワーク（デバイスネット）３０を通じてセンサ１０と通信できる上位装置としてのＰＬＣ２０とにより、センサシステムが構築されている。さらに本形態では、ＰＬＣ２０の上位に、そのＰＬＣ２０の動作を管理するパソコン３２が、やはりネットワーク（イーサネット）３３を介して接続されている。さらにまた、ＰＬＣ２０には、複数のセンサ１０が接続されており、それら複数のセンサ２０からの情報に基づいて所定の制御動作をするようになっている。
【００３０】
本形態におけるセンサ１０は、図２に示すように、下位にセンサヘッド１１が接続されており、このセンサヘッド１１から与えられる生データ（アナログ信号）は、一旦センサ１０内に取り込まれ、そのまま或いはセンシング信号処理して得られたデータをネットワーク３０を介してＰＬＣ２０に送るようになっている。そして、センサ１０の内部構造は、図３に示すようになっている。
【００３１】
すなわち、まず、センサヘッド１１からのアナログ信号を受信する信号入力部１２を有する。この信号入力部１２は、Ａ／Ｄ変換器１２ａを備え、アナログ信号をデジタル信号に変換する。またこのＡ／Ｄ変換器１２ａは、感度調整部１２ｂで設定された感度で変換する。
【００３２】
また、信号入力部１２（Ａ／Ｄ変換器１２ａ）の出力は、経路選択回路１３に送られる。経路選択回路１３は、信号処理部１４とマルチプレクサ（ＭＵＸ）１５の２経路を択一的に選択切替するもので、選択された一方へ信号入力部１２から受け取ったデータを送るようになっている。
【００３３】
信号処理部１４は、センサヘッド１１で検出され、信号入力部１２でデジタル化されたデータに対し、所定の信号処理（センシング信号処理）を行い、接点のＯＮ／ＯＦＦなどを決定する機能を有している。そして、係る処理は、信号処理回路１４ａが作業用記憶領域１４ｂ（ＲＡＭ）を使用しながら実行し、その実行するためのプログラムはプログラム格納領域１４ｃに格納されている。
【００３４】
この信号処理回路１４ａは用途に応じて例えば１６ビットマイコン等で構成することができる。そして、信号処理（プログラム）はセンシング対象に応じて異なるとともに、従来公知のものを用いることができるので、その詳細な説明を省略する。ここで本発明では、信号処理回路１４ａで実行する信号処理プログラムと、まったく同一機能のプログラムを、Ｊａｖａ等のプラットフォーム非依存言語で記述したものを作成し、プログラム格納領域１４ｃに格納している。
【００３５】
そして、この信号処理部１４の出力もマルチプレクサ１５に与えられる。このマルチプレクサ１５は、経路選択回路１３から直接送られる未処理入力データ（生データ）と、信号処理部１４から出力されたセンシング信号処理済みデータの一方を選択し、通信制御部１６のデータ送信回路１６ａに与えられ、ネットワーク３０を介して上位装置（ＰＬＣ２０）に送るようになっている。
【００３６】
そして、経路選択回路１３とマルチプレクサ１５は、構成管理部１７の構成変更制御回路１７ａから与えられる選択信号に基づいていずれか一方の経路をとるようになっている。つまり、通常のセンシング信号処理を行う場合には、経路選択回路１３の出力は信号処理部１４に接続し、マルチプレクサ１５は信号処理部１４からのデータを通信制御部１６に送るように切り替える。また、生データを送る場合には、経路選択回路１３の出力は直接マルチプレクサ１５に接続し、マルチプレクサ１５は経路選択回路１３からのデータを通信制御部１６に送るように切り替える。
【００３７】
さらに、通信制御部１６は、データ受信回路１６ｂを備え、ＰＬＣ２０から送られる各種情報を受信可能としている。また、構成管理部１７には、ロード制御回路１７ｂを有し、プログラム格納領域１４ｃに格納されたＪａｖａで記述された上記プログラムを上位装置（ＰＬＣ２０）に向けてアップロードしたり、上位装置（ＰＬＣ２０）から送られるプログラムをプログラム格納領域１４ｃにダウンロードする機能を有する。
【００３８】
一方、センサ１０の上位装置（上位ホスト）としてのＰＬＣ２０は、従来と同様センサ１０との間でデータの送受を行う通信制御部２１と、シーケンス制御やプロセス制御等を行うコントローラアプリケーション２３と、イーサネット３３に接続するためのネットワークインタフェース２４を備えている。なお、通信制御部２１は、センサ１０における通信制御部１６と同様に、データ送信回路とデータ受信回路を内蔵している。
【００３９】
そして、本発明では、センサ１０から生データが送られてくることが有るので、それに対応すべく生データに対してセンシング信号処理をする中央演算処理部２２を備え、その中央演算処理部２２で処理した演算結果をコントローラアプリケーション２３に送るようにしている。
【００４０】
さらに、センサ１０からは、センシング信号処理済みのデータ（接点ＯＮ／ＯＦＦ等）も送られてくるが、このときは中央演算処理部２２をスルーしてコントローラアプリケーション２３に処理済みのデータを与えるようにしている。これにより、コントローラアプリケーション２３は、従来と同様にセンシング信号処理されたデータが与えられるので、基本的に従来のアプリケーションをそのまま使用することができる。また、上記のスルーは、実際に中央演算処理部２２をスルーさせても良いし、センサ１０と同様に経路選択回路とマルチプレクサを実装し、中央演算処理部２２をバイパスするようにしてももちろん良い。
【００４１】
さらにまた、上記した中央演算処理部２２におけるセンシング信号処理は、プログラム格納領域２２ｃに格納されたセンシング信号処理プログラムに基づいて中央演算回路２２ａが作業用記憶領域２２ｂを適宜使用して実行するようになっている。そして、このようにセンシング信号処理したりスルーしたりするのは、構成管理部２５からの制御信号により実行される。なお、中央演算処理部２２はセンシング処理専用とはかぎらない。すなわち、例えば、コントローラアプリケーションは中央演算装置２２で実行する場合もあれば、専用ハ−ドウェア回路で実行することもある。
【００４２】
そして、プログラム格納領域２２ｃに格納されるセンシング信号処理プログラムは、センサ１０から送られたものをアップロードして格納するようにしている。そして、そのロードは、構成管理部２５により制御される。
【００４３】
また、上記したようにネットワーク（イーサネット）３３上にはパソコン３２が接続されており、パソコン３２にはＪａｖａＶＭ（Ｊａｖａ  ＶｉｒｔｕａｌＭａｃｈｉｎｅ）が実装されている。このＪａｖａＶＭ上ではプラットフォームに関係なくＪａｖａプログラムを実行できるという特徴がある。そして、本発明のＰＬＣ２０も、ＪａｖａＶＭを実装している。これにより上位ホスト（上位装置）になることができ、ハードウェアやＯＳ等のプラットフォームに制約を受けない。つまり、上記したセンサ１０からアップロードされたＪａｖａ言語で記述されたセンシング信号処理プログラムを実行することができ、そこで行う信号処理は、センサ１０で行うセンシング信号処理と等価のものとなる。
【００４４】
次に、上記したネットワーク３０を介して接続されるセンサ１０とＰＬＣ２０からなるセンサシステムについて説明する。まず、通常はセンサ１０側でセンシング信号処理をするようにしている。つまり、構成管理部１７からの選択信号に基づき、経路選択回路１３は信号処理部１４側を選択し、マルチプレクサ１５は信号処理部１４からの信号を選択する。これにより、センサヘッド１１から与えられるデータは、信号入力部１２でデジタル化された後、経路選択回路１３を介して信号処理部１４の信号処理回路１４ａに与えられ、そこにおいてセンシング信号処理される。そして、そのセンシング信号処理済みのデータは、マルチプレクサ１５，通信制御部１６，ネットワーク３０を経てＰＬＣ２０に与えられる。
【００４５】
ＰＬＣ２０では、通信制御部２１を介して係るセンシング信号処理済みデータを受け取るとともに、その受け取ったデータを中央演算処理部２２をスルーしてコントローラアプリケーション２３に与え、通常のＰＬＣ２０としてのシーケンス制御等を行う。そして、その結果をネットワークインタフェース２４からイーサネット３３に出力し、そのイーサネット３３を経由して制御対象の機器に対して制御信号を送る。
【００４６】
一方、センシング信号処理をＰＬＣ２０側で行うには、以下のように処理する。まず、センサ１０は、図４に示すようにプログラム格納領域１４ｃに格納されたＪａｖａで記述されたセンシング信号処理プログラムを、ＰＬＣ２０側に送り、ＰＬＣ２０のプログラム格納領域２２ｃに記憶（アップロード）する（図４中▲１▼）。
【００４７】
そして、このアップロードが完了したならば、経路選択回路１３，マルチプレクサ１５を切り替え、信号処理部１４をバイパスする経路に切り替える。これにより、センサ１０は、センサヘッド１１で検出した生データ（デジタル化はしている）を、ＰＬＣ２０に向けて出力するようになる（図４中▲２▼）。
【００４８】
また、ＰＬＣ２０側では、プログラム格納領域２２ｃに格納されたセンサ処理プログラムを読み出し、中央演算回路２２ａで受け取った生データに対してセンシング信号処理をする。このとき、アップロードされた処理プログラムは、Ｊａｖａで記述されているので、ＰＬＣ側でもそのまま使用することができ、しかも、センサ１０で使用していたセンサ処理プログラムを用いるので、中央演算回路２２ａで実行して得られるセンシング信号処理結果と、信号処理回路１４ａで実行して得られるセンシング信号処理結果は等価となる。よって、その中央演算回路２２ａの処理結果をコントローラアプリケーション２３に与えることにより、以降は通常の動作と同様の処理にしたがい、制御対象機器を制御する。
【００４９】
このように、Ｊａｖａプログラムを上位ホスト（ＰＬＣ２０）にアップロードして、出力データを切り替えることにより、信号処理の実行主体を上位ホスト（ＰＬＣ２０）に切り替えることができる。そして、図４に示すように直近上位のＰＬＣ２０を上位ホストとして信号処理を委託することにより、信号処理に要するセンサ１０の消費電力を抑えることができる。
【００５０】
また、センサ１０で行うべきセンシング信号処理を委託する上位ホストは、上記したようにＰＬＣ２０に限ることはなく、ネットワーク接続させたさらに上位の装置でも良い。一例としては、例えば図５に示すように、ＰＬＣ２０のさらに上位のパソコン３２に委託するようにしてもよい。つまり、Ｊａｖａで記述したセンシング信号処理プログラムをＰＬＣ２０を介してパソコン３２に与え（図５中▲３▼）、その後生データをＰＬＣ２０を介してパソコン３２に与える（図５中▲４▼）。そして、パソコン３２が、受け取った処理プログラムを実行し、センシング信号処理をする。
【００５１】
また、センサ１０は、図２，図３に示すような内部構成となっており、データ出力とは独立にプログラムを入れ替えたり実行したりできる。さらに、フラッシュＲＯＭで構成されるプログラム可能領域１４ｃ中の空いた領域やＲＡＭで構成される作業用記憶領域１４ｂと、センシング信号処理をせず暇になった信号処理回路１４ａを利用して、ロギングやチューニング、自己診断などのまったく別の処理を行うことができ、しかも、センシングと信号処理は上位ホスト（ＰＬＣ２０）と連携して実行しているので、システムの動作を停めなくても、様々な処理を実行できる。そして、それらの具体的な処理例を説明すると、以下のようになっている。
＊ロギング
センサ１０は、入力，出力，中間処理データなどのロギング機能を備え、ロギングデータ保存用記憶領域、つまり作業用記憶領域１４ｂの空状況を監視する機能を持つ。そして、作業用記憶領域１４ｂがフルになったならば、プロクラム格納領域１４ｃに格納された処理プログラムを上位ホスト（ＰＬＣ２０）にアップロードする（図６参照）。これにより、プログラム格納領域１４ｃに空領域をつくる。
【００５２】
次いで、空いたプログラム格納領域をロギングデータ保存用記憶領域に再配置する。つまり、作業用記憶領域を拡張する（図７参照）。そして、センシング信号処理は、センサ１０が信号処理部１３をバイパスさせて生データをセンシング信号処理プログラムをアップロードした上位ホスト（図示の例ではＰＬＣ２０）に送り、その上位ホストであるＰＬＣ２０がセンシング信号処理をする。
【００５３】
また、ロギングデータ保存用領域に空領域ができたならば、拡張した領域を開放して元のプログラム格納領域１４ｃを形成し、上位ホストからプログラムをダウンロードして元の状態に復帰させる機能も併せ持っている。
【００５４】
このように、緊急避難的にロギング領域を拡張してデータの喪失防止と、ログデータの回収指示という抜本的対策を、稼働中に本来の動作と並行して行えるので信頼度が高まる。
【００５５】
そして、上記した処理を行うためのセンサ１０の構成管理部１７の機能は、図８，図９に示すフローチャートを実現するようになっている。また、ＰＬＣ２０の構成管理部２５の機能は、図１０，図１１に示すようなフローチャートを実現するようになっている。そして、センサ１０とＰＬＣ２０間の状態遷移図は、図１２に示すようになっている。
【００５６】
まず、図１２に示すように本形態では、センサ１０がログ領域を監視し、ログ領域がフルになったり、逆にログ領域に空きが生じた場合に、それらの状態を上位ホスト（ＰＬＣ２０）に通知するようになっている。そして、ＰＬＣは、それら各通知を受けてセンサ１０に対して対応する指示、つまり「ログ領域拡大指示」や「ログ領域復帰指示」を与え、それら各指示を受けて、センサ１０の構成管理部１７が動作するようになっている。
【００５７】
すなわち、領域を拡大する場合には、センサ１０の構成管理部１７は、図８に示すように、「領域拡大指示」を受信したか否かを判断する（ＳＴ１）。そして、拡大指示を受信したならば、プログラム格納領域１４ｃに格納されているプログラムをＰＬＣ２０に対してアップロードする（ＳＴ２）。このアップロードが完了すると、上位ホスト（ＰＬＣ）より準備完了通知が来るので、係る完了通知が来たか否かを判断する（ＳＴ３）。そして、完了通知を受信したならば、経路選択回路１３並びにマルチプレクサ１５に対して選択信号を出力し、入力データ経路をバイパスに切り替える（ＳＴ４）。
【００５８】
その後、プログラム格納領域１４ｃを開放し（ＳＴ５）、ログ領域を拡大する（ＳＴ６）。つまり、当初の作業用記憶領域１４ｂのみから、プログラム格納領域１４ｃまで広げる。以後、送信データを切り替えて生データを送る。
【００５９】
また、上記のようにしてログ領域を拡大後、元の状態に復帰するには、図９に示すように、上位ホストであるＰＬＣ２０から「ログ領域復帰指示」を受信したか否かを判断する（ＳＴ１１）。そして、受信したならば、まずプログラム領域を確保する。つまり、図２，図３に示すように、プログラム格納領域１４ｃを形成する。
【００６０】
次いで、元のプログラム（ステップ２でアップロードしたもの）をダウンロードし、プログラム格納領域１４ｃに格納する（ＳＴ１３）。その後、経路選択回路１３並びにマルチプレクサ１５に対して選択信号を出力し、信号処理部１４を経由する経路に切り替える（ＳＴ１４）。これにより、以後は送信データが切り替わり、センシング信号処理したデータがセンサ１０から出力される。
【００６１】
一方、ＰＬＣ２０側の構成管理部２５の処理は、以下のようになる。まず、領域拡大は、図１０に示すように、「ログ領域フル」通知が来たか否かを判断する（ＳＴ２１）。そして、通知が来たならば、センサに対してログ領域拡大指示を送る（ＳＴ２２）。
【００６２】
その指示を受けたセンサから処理プログラムが送られてくるので、係るプログラムをアップロードし、プログラム格納領域２２ｃに格納する（ＳＴ２３）。そして、アップロードが完了したならば、センサ１０に対して実行準備完了通知を送る（ＳＴ２４）。
【００６３】
次いで、センサから生データに切り替わった送信データ（フラグなどによりわかるようにしておく）が送られてきたか否かを判断する（ＳＴ２５）。そして、係るデータが送られてきたならばデータ切り替えが完了したことがわかり、ログデータをアップロードするとともに、そのログデータを保存する（ＳＴ２６，２７）。
【００６４】
また、領域復帰時は、まずログ領域空き（Ｅｍｐｔｙ，Ｎｏｔ  Ｆｕｌｌ）通知の受信を待つ（ＳＴ３１）。そして、受信したならば、センサに対してログ領域復帰指示を送り、その後ステップ２３でアップロードしたプログラムをセンサにダウンロードさせる（ＳＴ３３）。
【００６５】
そして、データ切替が完了、つまり、センシング済みのデータが送られてくると、プログラム格納領域２２ｃに格納していたプログラムを破棄する。つまりメモリ開放する（ＳＴ３４，ＳＴ３５）。なお、その後ステップ２７で保存したログデータをセンサ側にダウンロードさせるようにしても良い。
【００６６】
なお、上記した例で「ログ領域フル」とは、完全にフル状態になった（あふれた）場合もあれば、あふれそうになった場合としてもよい。また、ステップ３５でプログラムを破棄することはせずに、保存しておいてもよい。また、プログラムのアップロードのタイミングは、上記したようにログ領域フルになった場合に限らず、最初に全てアップロードしデータ保存するようにしてもよい。その様に保存した場合、ログ領域があふれそうになった場合にアップロードの処理をすることなくすぐに経路切り替え・ログ領域拡大ができるので好ましい。
＊チューニング
図１３に示すように、センサ１０の信号処理部１４に、信号処理パラメータを調整して評価関数の変化を調べるチューニングプログラム１４ｄを持たせる。係る構成にすると、まず、センサ１０とＰＬＣ２０の各構成管理部１７，２５により、プログラム格納領域１４ｃに格納されたセンシング信号処理プログラムをＰＬＣ２０のプログラム格納領域２２ｃに送るとともに、経路を切り替えてセンサヘッド１１からの入力データをＰＬＣ２０に送り、そこにおいて受け取った生データに対してセンシングをする。
【００６７】
これと同時に、チューニングプログラムを作動して、パラメータのチューニング処理を実行する。すなわち、センサは調整できるパラメータに応じたチューニング用プログラムを持っているので、システム稼働のための信号処理を上位ホスト（ＰＬＣ２０）に任せている間に、パラメータを調整しながら評価関数の変化を調べ、最適なパラメータを決定する。
【００６８】
このとき、チューニングとセンシングを独立して並列処理ができるので、システム稼働中に、動作を停めることなく、オートチューニングができる。また、チューニング完了後、経路を元に戻し、センサヘッド１１からの信号を信号処理部１４を経由させることによりセンシング信号処理の実行をセンサに復帰させることができる。
【００６９】
そして、係る処理を行うための構成管理部１７，２５の機能は、図１４，図１５に示すフローチャートのようになっており、その場合の状態遷移図は図１６のようになっている。すなわち、センサ１０の構成管理部１７では、チューニングをするか否か、つまり上位ホスト（ＰＬＣ）から「チューニング指示」が来たか否かを判断する（ＳＴ４１）。そして、チューニング指示を受信すると、上位ホスト用のプログラム、つまり、Ｊａｖａで記述したセンシング信号処理を実行するプログラムをアップロードする（ＳＴ４２）。
【００７０】
次いで、準備完了したか否かを判断する（ＳＴ４３）。すなわち、後述するように、上位ホスト側でアップロードが完了すると、実行準備完了通知が送られてくるので、係る準備完了通知を受信したか否かにより、判断できる。
【００７１】
そして、準備完了したならば、入力データ経路の切替処理を行い、センサヘッド１１からの生データをそのままＰＬＣ２０へ送るようにする（ＳＴ４４）。次いで、プログラムの切り替えを行う（ＳＴ４５）。すなわち、通常の動作では、信号処理回路１４ａは、プログラム格納領域１４ｃに格納されたセンシング信号処理プログラムを実行するようになっているが、チューニングプログラムを読み込む。そして、新規プログラム（チューニングプログラム）を実行させ、チューニングを行う（ＳＴ４６）。
【００７２】
実行完了したならば（ＳＴ４７）、上位ホストに対して完了通知を発信し（ＳＴ４８）、その後元の状態に戻す。つまり、信号処理回路１４ａで実行するプログラムを、センシング処理プログラムに切り替え（ＳＴ４９）、その後、入力データを切り替えて、センサヘッド１１から送られるデータを信号処理回路１４ａを通過させ、そこにおいてセンシングするようにする（ＳＴ５０）。
【００７３】
一方、ＰＬＣ２０側の処理は、図１５に示すように、チューニング開始通知を発信する（ＳＴ５１）。次いで、センサ２０から送られてくるセンシング信号処理プログラムをアップロードし（ＳＴ５２）、アップロードが完了したならば、実行準備完了通知を発信する（ＳＴ５３）。
【００７４】
そして、センサからチューニング完了通知が送られるのを待ち（ＳＴ５４）、完了通知が来たならば、次に、データ切替が完了、つまり、センシング済みのデータが送られて来たのを確認し（ＳＴ５５）、プログラム格納領域２２ｃに格納していたプログラムを破棄する。つまり、メモリ開放する（ＳＴ５６）。なお、図１５のフローチャートには記載していないが、ステップ５３の完了通知を発した後、センサから生データが送られてきた場合には、アップロードしたセンシング信号処理プログラムを実行し、センシング信号処理をするのはもちろんである。
【００７５】
なお、上記した例では、チューニングプログラムはセンサ側に持たせていたが、図１７に示すように上位ホスト２０側にチューニングプログラムを持たせていても良い。つまり、センサヘッド１１からの入力データを信号処理回路１４ａで処理すると同時に、その処理結果の出力とは独立にバイパス経路を用いて生データを上位ホスト２０に送る。そして、上位ホスト２０側でチューニング処理を実行し、最適化されたパラメータやアルゴリズムをプログラムとしてセンサ１０にダウンロードする。このようにすると、システム稼働中に、動作を停めることなく、上位ホストの強力な演算資源を利用した高度なオートチューニングができる。
【００７６】
特に、チューニングに関しては、センサ装置は、チューニングプログラムのみ持ち、実行に必要なハードウエアリソースを持たないように構成し、チューニングプログラムを上位装置に送り、それに基づいてチューニングさせ結果だけをダウンロードするように構成することができる。すなわち、信号処理は比較的軽いがチューニングは複雑な処理が必要なことが多い。しかもチューニングは最初に行うだけである。そこで、チューニングに必要な構成をできるだけセンサ装置に組み込まないようにすることにより、センサの小型化が図れる。
【００７７】
なお、上記した各実施の形態では、いずれもセンサ１０とＰＬＣ２０とはデバイスネットワーク３０で接続し、ＰＬＣ２０をイーサネット３３に接続することにより、パソコン３２ともネットワークを組むようにした構成について説明した。つまり、センサとパソコン３２の間でデータの送受を行うには、ＰＬＣ２０を介して行うようにした。しかし、本発明はこれに限ることはなく、例えば図１８に示すように、イーサネット３３に対してセンサ１０とＰＬＣ２０並びにパソコン３２を接続するようにしたネットワークにおいても適用できる。
【００７８】
このようにすると、例えばセンサ１０の上位ホストをＰＬＣ２０とした場合には、同図中二点鎖線で示すように、イーサネット３３を介してセンシング信号処理プログラムのアップロード並びに生データの送信を行うようになる。また、上位ホストをパソコン３２とした場合には、同図中実線で示すように、イーサネット３３を介してセンシング信号処理プログラムのアップロード並びに生データの送信を行うようになる。共に、センサの出力が直接ネットワークを介して上位ホストに与えられるようになる。
【００７９】
そして、このようにネットワークの接続形態が上下関係になくても、本発明を適用できる。つまり、本発明における上位ホスト（上位装置）は、ネットワークの接続形態における上位ではなく、ネットワークに接続された全ての装置が上位装置に成り得る。しいていえば、センサヘッド１１にとってセンサ１０よりも上位と称することもできる。
【００８０】
また、信号の送受信は、上記した実施の形態及びその変形・使用例は、センサ１０との通信媒体はいずれも有線で示しているが、通信媒体として電波または赤外線等の光を利用した無線通信を用いても良い。このように無線通信とすると、センサと上位ホストは離れて設置されていても協調できる。
【００８１】
図１９は、本発明の第２の実施の形態を示している。本実施の形態では、センサ１０でセンシング信号処理をすることはなく、生データを上位ホスト２０に与えるようにしている。そして、本実施の形態の特徴は、そのセンサ１０用のセンシング信号処理プログラムをＪａｖａ等のプラットフォーム非依存プログラムで記述し、それをプログラム格納領域１８に格納しておく。
【００８２】
そして、起動時に上位ホスト２０に対して、プログラム格納領域１８に格納されたプロクラムをアップロードする。この処理は制御部１９からの制御信号に基づいて実行する。
【００８３】
また、センシング信号処理プログラムを受け取った上位ホスト２０は、まず受け取った処理プログラムをプログラム格納領域２２ｃに格納する。そして、中央演算回路２２ａは、センサ１０から送られてくる生データを、上記受け取ったプログラムを実行してセンシング信号処理をする。
【００８４】
つまり、上位ホスト２０は、センサ１０内部で実行されるはずだった処理内容については一切関知する必要がなく、センサ１０からアップロードされたプログラムを実行してセンサ１０から出力される生データをセンシング信号処理する。このようにすると、センサに信号処理部が不要となるので、センサのコストダウンを図れる。また、上位ホストはもともと演算能力に余力があり、複数のセンサから処理を任されても余力の範囲内であれば、余裕を持って処理できる。
【００８５】
係る構成をとると、センサ１０は起動時にプログラムを上位ホストにアップロードして信号実行を委託し、センサヘッド１１からの入力信号をデジタル化する機能のみ実行するので、センサを簡素化してコストを削減できる。
【００８６】
そして、各センサ１０には自己にあったセンシング信号処理プログラムを持たせることができ、上位ホストはアップロードされたプログラムに基づいてセンシング信号処理をすればよく、また、終了時には当該プログラムを破棄することができ、あらかじめ多数のセンシング信号処理プログラムを内蔵する必要はなく、しかも、そのセンサにあったプログラムを実行することができる。なお、その他の構成並びに作用効果は、上記した各例と同様であるので、関連する部分は同一符号を付し、その詳細な説明を省略する。
＊＊センシング信号処理プログラム更新（バージョンチェック）
図２０は、本発明の第３の実施の形態を示している。上記した各実施の形態では、センシング信号処理プログラムは固定であったが、本実施の形態ではプログラム格納領域１４ｃに格納するプログラムを更新可能としている。
【００８７】
すなわち、センサ１０と上位ホスト２０とがネットワーク３５を介して接続されている点では、上記した各実施の形態と同様である。そして、第１の実施の形態と同様に、センサ１０はセンサヘッド１１から受け取った入力データを信号処理部１４でセンシング信号処理した後上位ホストに与える機能と、信号処理部１４をバイパスして生データを上位ホストに送る機能を有している。
【００８８】
そして本形態では、センサ１０に格納するセンシング信号処理プログラムに、種別やバージョン情報を埋め込んでおく。また、ネットワーク３０に接続されるデータベース３６には、最新バージョンのリストを格納しておく。そして、上位ホスト２０では、センサ１０からアップロードされたセンシング信号処理プログラムのバージョンを抽出し、データベース３６に格納された最新バージョンであるか否かを判断する。そして、最新でない場合には、自動または手動によりデータベースから最新プログラムを収得するとともに、その最新プログラムをセンサ１０にダウンロードする。
【００８９】
係る構成をとると、新たな信号処理アルゴリズムの適用や、工程変更などに伴う処理内容やパラメータの入れ替えを、データベース３６で一元管理し、それを分散した上位ホストで同期をとって一斉に反映することができる。また、定期的にバージョンチェックをかけるだけてよいので、上位ホスト２０は膨大なデータベース３６を頻繁にアクセスしなくてもよい。そして、バージョンアップが必要になったときだけ、マスターデータベースから最新のプログラムをダウンロードすることになる。
【００９０】
そして、係る処理を行うためのセンサ１０の機能は、図２１に示すフローチャートを実現するようになり、上位ホスト２０の機能は、図２２に示すフローチャートを実現するようになる。そして、その時のシステムの状態遷移図は図２３のようになる。
【００９１】
まず、センサ１０側（構成管理部１７）の処理について説明する。本形態では、上位ホストからのバージョンチェック指示に基づいてチェックを行うようにしている。従って、バージョンチェックを行うか否かを判断する（ＳＴ６１）。この判断は、係るバージョンチェック指示があるか否かにより行う。
【００９２】
そして、指示があった場合には、プログラム格納領域１４ｃに格納されたプログラムをアップロードする（ＳＴ６２）。そして、後述するようにこのアップロードしたプログラムについて上位ホストがバージョンのチェックを行った後、その判定結果が送られてくるので、センサ１０側では、その判定結果が最新版であるか否かを判断する（ＳＴ６３）。
【００９３】
そして、最新版の場合には、更新する必要が無いので処理を終了する。一方、最新版でない場合には、プロクラムの更新処理に移行する。つまり、まず入力データ経路を切り替える（ＳＴ６４）。この切り替えにともない、信号処理部１４をバイパスし、生データを上位ホスト２０に送るようになる。そして、上位ホスト２０側ではすでにプログラムがアップロードされているので、上位ホスト２０にセンシング信号処理を委託することになる。
【００９４】
次いで、プログラム領域を開放し（ＳＴ６５）、新規（最新）プログラムをダウンロードする（ＳＴ６６）。これにより、プログラム格納領域には、最新のセンシング信号処理プログラムが格納される。その後、入力データ経路の切り替えを行い、信号処理部１４を経由するようにする（ＳＴ６７）。そして、以後、最新プログラムを用いてセンサ側でセンシング信号処理をするようになる（ＳＴ６８）。
【００９５】
一方、上位ホスト側では、まず「バージョンチェック指示」を通知し（ＳＴ７１）、その通知に基づいて行われるセンサに格納されていたプログラムをアップロードし、プログラム格納領域に格納する（ＳＴ７２）。この状態では、上位ホスト２０はセンシング信号処理は行わない（センサ側で行う）。
【００９６】
次に、データベース３６をアクセスし、アップロードしたプログラムのバージョンが最新のものか否かを判断する。そして、最新であった場合には更新は必要ないので、判定結果（最新版である）を通知後（ＳＴ７３）、ステップ７９に飛びアップロードしたプログラムを破棄（プログラム格納領域のメモリを開放）し、処理を終了する。
【００９７】
一方、最新でない場合には更新の必要があるので、ステップ７４に飛び、判定結果としてバージョンアップ開始通知を送る（ＳＴ７４）とともに、ステップ７２でアップロードしたプログラムを実行する（ＳＴ７５）。その後、センサ１０側でのデータの切り替えの完了を待ち、最新プログラムをセンサ１０にダウンロードする（ＳＴ７６，ＳＴ７７）。次に、データ切替が完了、つまり、ダウンロードが完了してセンシング済みのデータが送られて来たのを確認し（ＳＴ７８）、プログラム格納領域２２ｃに格納していたプログラムを破棄する。つまりメモリ開放する（ＳＴ７９）。
【００９８】
図２４は、別のバージョンチェックの方式である。すなわち、上記した実施の形態では、データベースとチェックをするようにしたが、この実施の形態では同一ネットワークに接続された同種のセンサに格納されたプログラム同士を比較することによりバージョンチェックを行うようにしている。
【００９９】
すなわち、センサ１０に格納するプログラムに種別やバージョン情報を埋め込むのは、上記した実施の形態と同様である。そして、センサ交換にともない上位ホスト２０は、新規追加センサのプログラムバージョンをチェックし、ネットワーク３５に接続されている同種のセンサプログラムのバージョンと比較して「要更新リスト」を作成する。そして、新規追加センサから最新プログラムをアップロードして既存センサにダウンロードするようにしている。
【０１００】
このようにすると、膨大なデータベースを持たなくても部品交換のタイミングクでセンサプログラムのバージョンアップができる。また、常にシステム内の最新センサにあわせてプログラムバージョンを統一できる。さらに、バイパス経路を使用し、上位ホストにセンシング信号処理を委託することにより、システム稼働中に、動作を停めることなく、センサプロクラムのバージョンアップができる。
【０１０１】
そして、この場合のセンサの処理は、図２１に示すものと等価となる。また、上位ホスト２０の機能も、処理フローとしては図２２に示すものと等価となる。但し、ステップ７３の更新の要否の判断が、データベースへのアクセスではなく、ネットワーク接続された各センサのプログラムのバージョンをチェックすることにより行うようにしている点で異なる。
＊＊最適処理プログラム更新
図２０に示したバージョンアップのシステム構成を用い、段取り替え時にセンサ装置に対して最適処理プログラムに更新することができる。すなわち、データベース３６に、ワークや環境の変化に対応するための最適処理プログラムを登録しておく。そして、上位ホスト２０は、ネットワーク３５を介してデータベース３６から最適処理プログラムに関する情報を取得し、その最適処理プログラムをセンサ装置１０にダウンロードする。このように段取替え時に、最適処理プログラムに入れ替えることにより、ワーク・環境変化等に対してパラメータ変更よりも、より最適な状態にシステムを設定することができる。
【０１０２】
＊＊センシング信号処理プログラム変更
図２５は、本発明の第４の実施の形態を示している。本実施の形態では、上位ホスト２０に、アップロードしたプラットフォーム非依存プログラム（Ｊａｖａプログラム）の編集機能２７を備えている。このように、センサ１０の信号処理回路１４に応じたクロスコンパイラを上位ホスト２０が備え、編集機能２７で編集したＪａｖａプログラムと、それをクロスコンパイルしたセンサの信号処理回路用プログラムをペアにして、センサ１０にダウンロードさせる構成をとっている。
【０１０３】
このようにすると、センサから上位ホストにプログラムをアップロードして信号処理を委託実行し、上位ホストにてプログラムを編集後、クロスコンパイルしたプログラムとペアにしてセンサにダウンロードして、信号処理の実行をセンサに復帰させることにより、システム稼働中に、動作を停めることなく、センサプログラムの修正や変更ができる。
【０１０４】
つまり、センサ１０と上位ホスト２０のＣＰＵにあわせて、片方はＣＰＵに最適化したバイナリ、片方はＪａｖａコードとし、これをセットで持つことにより、上位ホスト２０で扱うプログラムとセンサ１０で実行するプログラムの整合を保証できる。
【０１０５】
そして、係る処理を行うためのセンサ１０の機能は、図２６に示すフローチャートを実現するようになり、上位ホスト２０の機能は、図２７に示すフローチャートを実現するようになる。そして、その時のシステムの状態遷移図は図２８のようになる。
【０１０６】
まず、センサ１０側（構成管理部１７）の処理について説明する。本形態では、上位ホストからのエディット指示に基づいてチェックを行うようにしている。従って、エディット指示の通知を受けたか否かを判断する（ＳＴ８１）。そして、指示があった場合には、プログラム格納領域１４ｃに格納されたプログラムをアップロードする（ＳＴ８２）。次いで、入力データ経路を切り替える（ＳＴ８３）。この切り替えにともない、信号処理部１４をバイパスし、生データを上位ホスト２０に送るようになる。そして、上位ホスト２０側ではアップロードされたプログラムを用いてセンシング信号処理を実行することになる。
【０１０７】
次に、プログラムの変更があったか否かを判断する（ＳＴ８４）。つまり、上位ホストから「プログラム更新通知」を受信したか否かを判断する。そして、受信した場合には、プログラム領域を開放し（ＳＴ８５）、新規プログラムをダウンロードする（ＳＴ８６）。これにより、プログラム格納領域には、修正されたセンシング信号処理プログラムが格納される。その後、入力データ経路の切り替えを行い、信号処理部１４を経由するようにする（ＳＴ８７）。そして、以後修正された新規プログラムを用いてセンサ側でセンシング信号処理をするようになる（ＳＴ８８）。
【０１０８】
一方、上位ホスト２０側では、まず「エディット指示」を通知し（ＳＴ９１）、その通知に基づいて行われるセンサ１０に格納されていたプログラムをアップロードし、プログラム格納領域に格納する（ＳＴ９２）。次いで、編集機能２７を実行し、エディットしてプログラムの修正・変更を行う（ＳＴ９３）。
【０１０９】
そして、係る修正等の処理が完了したならば、プログラム更新通知を送る（ＳＴ９４）とともに、更新プログラムを実行する（ＳＴ９５）。その後、センサ１０側でのデータの切り替えの完了を待ち、更新プログラムをセンサ１０にダウンロードする（ＳＴ９６，９７）。次に、データ切替が完了、つまり、ダウンロードが完了してセンシング済みのデータが送られて来たのを確認し（ＳＴ９８）、プログラム格納領域２２ｃに格納していたプログラムを破棄する。つまりメモリ開放する（ＳＴ９９）。もちろん、センサにＪａｖａ実行環境をもたせてもよく、その場合、クロス開発環境やプログラム二重持ちは不要となる。
＊＊分散処理
図２９は、本発明の第５の実施の形態を示している。上記した実施の形態では、センシングプログラムをアップ／ダウンロードすることはあるが、ロード後の実施はセンサ側と上位ホスト側のいずれかが択一的に選択され、一方がセンシング信号処理するようになっている。これに対し、本形態では、両方で実施するようになっている。
【０１１０】
すなわち、上位ホスト２０側にプログラム解析処理部２８を備える。このプログラム解析処理部２８は、大きな演算能力を必要とする処理をプログラムから抽出して、以降の処理を上位ホスト２０で分担して実行できるように、センサ１０のプログラムを修正する。
【０１１１】
そして、そのプログラム解析部２８にて、上位ホスト２０にアップロードしたプログラムをシミュレーション等の方法による解析手段を備え、複雑な演算処理ループのように性能に影響する部分以降の処理を抜き出して上位ホスト２０で実行し、センサ１０には上記部分以前の処理を実行して結果を出力させるようプログラムを変更してダウンロードするようになっている。
【０１１２】
このようにすると、性能に影響する複雑な処理を演算能力の高い上位ホストが分担して実行できるので、センサシステム全体として信号処理性能が向上する。必要に応じて処理を分担することにより、システム要求性能の変化に対応できる。つまり、センサ１０と上位ホスト２０が協調して処理を分担することができる。システム構築後に上位ホストの演算能力の余力分までトータル性能を向上させることができる。
【０１１３】
【発明の効果】
以上のように、本発明では、例えばパソコンやＰＬＣ等の処理装置（上位ホスト，上位装置）と連携して信号処理の回路構成を再編し、センサのハードウェア資源を利用することにより、少ないハードウェア資源で多様な処理機能を実現することができる。さらに、本発明に係るセンサシステムでは、機能の追加や変更に対して、現実的なコストで、システムの運転を停止することなく、容易に対応することができる。
【０１１４】
つまり、請求項１のセンサでは、センシング信号処理を上位装置に委託することにより、余裕のできたハードウェア資源を利用することができ、チューニングや自己診断並びにロギング処理など多様な処理機能を実現することができる。つまり、従来手法ではセンサに実装できる信号処理部の容量はあまり大きくできず、高性能なものも実装しにくい。しかし、本発明によれは、データの経路を切り替えることにより、信号処理部をセンシング信号処理に用いたり、その他の処理を実行することができる。しかも、センシング信号処理を上位委託して継続したまま別の処理をすることができる。
【０１１５】
また、請求項２のセンサや請求項４のセンサシステムでは、上位装置で実行するセンシング信号処理のための処理プログラムは、センサが持っているものをアップロードして使用するので、上位装置側ではあらかじめ各種のセンサに対応するプログラムを用意しておく必要が無く、構成が簡易化できる。そして、実際に上位装置が委託を受けてセンシング処理をする場合には、センサで行うものと等価のものができる。
【０１１６】
そして、請求項２に記載のセンサでは、上記した請求項１の効果をさらに奏することができる。
【０１１７】
請求項５に記載のセンサシステムでは、ネットワークに接続された同種のセンサが複数存在する場合に、各センサの処理プログラムのバージョンを統一できる。つまり、常に全てのセンサをできるだけ新しいバージョンのものに統一することができる。
【０１１８】
また、請求項６に記載のセンサシステムでは、ネットワークに接続したデータベースに格納するプログラムを更新しておくだけで、そのネットワークに接続されたセンサの処理プログラムのバージョンが更新されるため、作業性が向上する。
【図面の簡単な説明】
【図１】従来例を示す図である。
【図２】本発明の第１の実施の形態を示す図である。
【図３】センサの内部構造を示す図である。
【図４】作用を説明する図である。
【図５】作用を説明する図である。
【図６】ロギングを用いた例を示す図である。
【図７】ロギングを用いた例を示す図である。
【図８】ロギングを実現するためのセンサの機能を示すフローチャートである。
【図９】ロギングを実現するためのセンサの機能を示すフローチャートである。
【図１０】ロギングを実現するための上位ホストの機能を示すフローチャートである。
【図１１】ロギングを実現するための上位ホストの機能を示すフローチャートである。
【図１２】ロギングを実施した際の状態遷移図である。
【図１３】チューニングを用いた例を示す図である。
【図１４】チューニングを実現するためのセンサの機能を示すフローチャートである。
【図１５】チューニングを実現するための上位ホストの機能を示すフローチャートである。
【図１６】チューニングを実施した際の状態遷移図である。
【図１７】チューニングを用いた他の例を示す図である。
【図１８】センサニング処理の上位委託の他の例を示す図である。
【図１９】本発明の第２の実施の形態を示す図である。
【図２０】本発明の第３の実施の形態を示す図である。
【図２１】第３の実施の形態におけるセンサの機能を示すフローチャートである。
【図２２】第３の実施の形態における上位ホストの機能を示すフローチャートである。
【図２３】第３の実施の形態を実施した際の状態遷移図である。
【図２４】第３の実施の形態の変形例を示す図である。
【図２５】本発明の第４の実施の形態を示す図である。
【図２６】第４の実施の形態におけるセンサの機能を示すフローチャートである。
【図２７】第４の実施の形態における上位ホストの機能を示すフローチャートである。
【図２８】第４の実施の形態を実施した際の状態遷移図である。
【図２９】本発明の第５の実施の形態を示す図である。
【符号の説明】
１０  センサ
１１  センサヘッド
１２  信号入力部
１３  経路選択回路
１４  信号処理部
１５  マルチプレクサ
１６  通信制御部
１７  構成管理部
２０  ＰＬＣ（上位ホスト）
２１  通信制御部
２２  中央演算処理部
２３  コントローラアプリケーション
２４  ネットワークインタフェース
２５  構成管理部
３０  ネットワーク
３２  パソコン（上位ホスト）
３３  イーサネット
３６  データベース
【図１】
0003791231.tif 000002
【図２】
0003791231.tif 000003
【図３】
0003791231.tif 000004
【図４】
0003791231.tif 000005
【図５】
0003791231.tif 000006
【図６】
0003791231.tif 000007
【図７】
0003791231.tif 000008
【図８】
0003791231.tif 000009
【図９】
0003791231.tif 000010
【図１０】
0003791231.tif 000011
【図１１】
0003791231.tif 000012
【図１２】
0003791231.tif 000013
【図１３】
0003791231.tif 000014
【図１４】
0003791231.tif 000015
【図１５】
0003791231.tif 000016
【図１６】
0003791231.tif 000017
【図１７】
0003791231.tif 000018
【図１８】
0003791231.tif 000019
【図１９】
0003791231.tif 000020
【図２０】
0003791231.tif 000021
【図２１】
0003791231.tif 000022
【図２２】
0003791231.tif 000023
【図２３】
0003791231.tif 000024
【図２４】
0003791231.tif 000025
【図２５】
0003791231.tif 000026
【図２６】
0003791231.tif 000027
【図２７】
0003791231.tif 000028
【図２８】
0003791231.tif 000029
【図２９】
0003791231.tif 000030