JP4240695B2 - 機器間協調制御方法及びシステム - Google Patents
機器間協調制御方法及びシステム Download PDFInfo
- Publication number
- JP4240695B2 JP4240695B2 JP32211599A JP32211599A JP4240695B2 JP 4240695 B2 JP4240695 B2 JP 4240695B2 JP 32211599 A JP32211599 A JP 32211599A JP 32211599 A JP32211599 A JP 32211599A JP 4240695 B2 JP4240695 B2 JP 4240695B2
- Authority
- JP
- Japan
- Prior art keywords
- processing
- information
- status
- peripheral device
- devices
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B15/00—Systems controlled by a computer
- G05B15/02—Systems controlled by a computer electric
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/2803—Home automation networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/2803—Home automation networks
- H04L12/2807—Exchanging configuration information on appliance services in a home automation network
Landscapes
- Engineering & Computer Science (AREA)
- Automation & Control Theory (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Control By Computers (AREA)
- Selective Calling Equipment (AREA)
- Computer And Data Communications (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、制御機械または物に組み込まれたプロセッサを相互に連携させて動作させる分散システムに関する。その中でも特に、制御機械または物の移動や制御対象などの周辺環境の状態変化が継続的に発生する環境において、制御機械や物に接続されるかまたは制御機械や物に含まれ、相互にデータの送受信を行う機能と任意の実行する（例えば、プログラムを実行する機能とを持った）機器が、自身の置かれた物理的環境に関する情報を用いて相互に連携する場合や、該機器が現在どのような働きをしているかなどの動作に関する情報である状況に応じて局所的に連携するものに関する。
【０００２】
そして、本発明は、ビル・ホームオートメーションシステム、プラント制御や製造、物流などの社会システム、交通システムなどの制御システムに好適に適合しうる。
【０００３】
【従来の技術】
半導体の高性能高密度化に伴うダウンサイジングの進行に合わせ、計算能力を持つプロセッサは、もはや専用の計算機にのみ存在するのではなくなり、あらゆる機器に組み込まれつつある。さらにインターネットに代表されるように、これらの機器を介して計算機システムと通信を行う手段も整いつつある。このような通信機能を持った機器、または機器で利用する通信機能には、例えば「PHSで楽しむモバイルコンピューティング」(ISBN4-87188-532-1)にあるようなPHSがある。これは、端末間で音声通信を行うものである。端末間は、明示的に通信先端末のアドレスとなる番号をダイヤルすることで通信を確立する。また、ＰＨＳでは通信の切断は端末への切断命令により行われる。
【０００４】
また、ユーザの設定を省きつつ機器間で対応する処理プログラム間を連携させる技術として、例えば日経コンピュータ（1998年12月7日）P.P.86 - 101「Jiniのベールを剥ぐ」に示すような方法がある。本技術によると、各機器はネットワークに接続されると同時に自機器のIPアドレスをブロードキャストし、存在を知らせる。Lookupサーバがこれに応答し、機器よりLookupサーバに対して機器の仕様、ドライバが登録される。逆に機器側からはLookupサーバに登録されている機器を検索し、他の機器と処理を連携させることができる。本技術においては、Lookupサーバがネットワークに接続された機器の情報を一元管理しており、機器間の連携にはLookupサーバが必須となっている。連携先の機器を変更する場合は、Lookupサーバへ問い合わせ、他の連携相手を探索する必要がある。また、連携する機器の選択には機器の仕様が用いられており、Lookupサーバに登録されている情報が共有され、各機器より参照される。連携のために必要なドライバ・ソフトウェアなどもLookupサーバを介して取得される。
【０００５】
同様に複数の機器から連携する相手を検索し、連携する技術として、例えばIEEE Transaction Computer, Vol.C-29, No.12,pp.1104 - 1113「The Contract Net Protocol:High-level Communication and Control in a Distributed Problem Solver」に示すような方法がある。
【０００６】
【発明が解決しようとする課題】
上記のIEEEによる方法によると、連携先を探す側の機器が要求を出し、該要求を受信した機器は該要求を処理できるか否かを表す指標を返信する。該要求を送信した機器は、返信した指標を判断し、どの機器と連携するかを判断する。本技術においては、機器には要求に対する指標を見積もる能力が必要である。また、連携した後の機器の稼動状態変化や判断の指標の動的な変化については考慮されていない。プロセッサの小型化、高性能化により、専用の計算機のみでなく、従来計算機能を持たなかった機械や物にもプロセッサが埋め込まれつつある。一方、これらの機械や物は、その存在する環境においてそれぞれ制御対象や役割を持っており、制御対象や役割の変化に応じて移動されたり、買い替えによって入れ替えられたり、組み立てや分解によって構成を変化させたりする。また、処理内容を変えたり、ある目的を果たすために相互に連携することも必要となる。
【０００７】
上記従来技術は、計算機側での管理を主眼としており、機器間の構成を管理するためのサーバとなる機器か、連携する相手を検索するための共有伝送媒体を必要としていた。このため機器が連携するためには、相手となる機能を持つ機器をサーバを介して探す必要があるとともに、機器の移動や入れ替えに依存しないサーバを設置する必要があり、柔軟性の点で問題があった。機器またはその組み込まれた機械が連続稼動する環境においては、サーバ自身を入れ替えることも困難であり、技術進歩に追従してサーバ機を入れ替えたり、サーバ機のメンテナンスを行うことが困難であることも問題であった。また、機器が連携する範囲はサーバの管理する範囲に限られるため、サーバの管理領域を跨った範囲において機器間を連携させるために、サーバ間の連携機構または複数のサーバを統括する機構が必要であり、計算機システム側の機構が大規模化、複雑化してしまうという問題があった。こうした機構を設けない場合は、サーバ機の管理範囲を運用上の管理範囲に一致させておく必要があり、運用を見通して事前に設計することが大変困難であるといった問題があった。
【０００８】
連携する機器間の関係を構築するという観点では、上記従来技術は、地上局のようなサーバ機能を持ったサーバのうち近いサーバと通信するか、サーバより取得した相手機器の仕様を元にして連携相手を決定する。このため、連携するか否かの判断や、同種の機器の中から連携する機器を選択するといった判断は、機器の仕様といった静的情報に限られていた。機器の接続された制御対象や物においては、その置かれた場所や他の機器との相対的関係によって制御方法や役割、重要性が異なってくる。しかし、連携する機器間の関係を構築する際に考慮されておらず、運用上不便な位置関係にある機器を連携させたり、役に立たない機械を稼動させ続けたりするなどといった問題があった。これを回避するには人手による作業や定期的メンテナンスを必要としてしまい、目的とする利用者の手間削減を達成できないといった問題があった。
【０００９】
さらに、システムを構成する機器の構成や稼動状況、または環境の変化によって、システムの状況は時間と共に変化していくため、事前にどの範囲の機器を連携させて動作させればよいか予測できない場合も多い。このような不明瞭な状況については従来技術では考慮されておらず、利便性が達成できないといった問題もあった。
【００１０】
また、機器間での連携を保守するという観点では、上記従来技術は、サーバが機器の構成を管理しており、新たに連携可能となった機器はサーバに登録される。このため、ある機器と連携した後に、より条件のよい機器が連携可能となった場合でも、機器側で該更新を検出できないといった問題があった。更新を検出するためには、サーバ上の情報が更新されるのを待つとともに、サーバに定期的に問い合わせなければ該更新を検出することができないため、機器の数が多くなるとサーバに負荷が集中するといった問題があった。さらに、各機器の接続された制御対象や物の置かれた場所や状況の変化に応じて、その都度よりよい相手と連携するといったことは考慮されておらず、利便性の点で問題があった。
【００１１】
【課題を解決するための手段】
本発明は、上記問題点を鑑みてなされたもので、利用者に対する柔軟かつ木目細かな制御・サービスを提供するために、機器が、置かれた物理環境や周辺機器との関係を認識し、これを用いて相互に連携する相手を選択したり、自機器の稼動状態を変更できるようにすることを目的とする。また、自機器の置かれた環境や、他機器の置かれた環境及び状況を継続的に認識することで、各時点でよりよい機器と連携したり、稼動状態を変更したり、連携する相手を事前に決めることが困難な場合でも適切な相手機器と連携できるようにすることを目的とする。さらに、システムを構成する機器を管理するサーバに依存せず、各機器が各々局所的に、自機器及び相手機器の認識と、連携相手の判断を行えるようにすることを目的とする。
【００１２】
従来の技術として記載したＰＨＳは、新たに増えた端末や、システムから離脱した端末は、ユーザがシステム外で管理する必要があると本発明者が認識した。ここで、ＰＨＳの特徴として端末が現在置かれた位置が解る点があるが、地上局の制御に用いられるものである。また、通信先の制御は前述したような明示的ダイヤルによるため、端末の物理的な位置は用いられていない。この物理的な位置を用いることが本発明の特徴の1つである。
【００１３】
本発明の機器間協調制御システム及び装置は、上記目的を達成するために、各機器が、
機器の置かれた物理的位置などの環境に関する情報と、
機器の行う動作、働きに関する情報である状況と、
を用いて、連携する相手機器や自機器の動作状態である稼動状態を変更するようにするものである。
【００１４】
ここで、状況としては、機器が最終的に行うべきまたは行われるべき働きのうち、どこまで終了しているか、機器が行うべきまたは行われるべき働きと実際の動作についての相違点がないか、ある場合相違点の内容自身などが含まれる。
【００１５】
また、稼動状態としては、機器の処理プログラムの動作状態や処理プログラム以外による動作状態も含む。
【００１６】
また、環境や状況の変化に適応して各機器が連携できるようにするために、各機器が、
自機器の置かれた環境や状況に関する情報を検出して他の機器に通知することで、継続的に自機器又は他機器の置かれた環境や状況を認識するか、
連携動作の要求に対して実際に動作してみることで、各時点で連携可能かを自ら判断するようにして、連携する相手機器や自機器の稼動状態を変更できるようにしたものである。
【００１７】
さらに、このような適応を、システム構成を管理するサーバや伝送媒体に依存せず行えるようするために、各機器が局所的に認識及び判断するようにしたものである。
【００１８】
【発明の実施の形態】
以下に、本発明の実施の形態を説明する。特に、環境情報として機器の置かれた物理的位置や機器間の相対位置または部屋の壁など境界となるものを用いて、周辺機器を認識・判定する方法について以下の例を用いて説明する。
【００１９】
（１）機器が機器間の相対位置を測定することにより連携する周辺機器を認識・判定する方法
（２）認識した周辺機器情報を共有することにより周辺機器を認識・判定する方法
次に、機器のもつ処理プログラム構成やインタフェースなどの機能に関する情報や、機器の状況に関する情報を用いて、連携する周辺機器を選択する方法について、以下の例を用いて説明する。
【００２０】
（３）各機器が各々持つ該機器自身の機能に関する情報と、状況として該機器が処理を行えるか否かや負荷状態、または該機器の処理プログラムの処理結果や応答時間を用いて、連携する機器を選択する方法
（４）機器が各々持つ該機器自身の機能に関する情報と、環境情報である相対位置情報、及び該機器の状況に関する情報を用いて、連携する機器を判断する方法また、連携する機器を事前に決定せず、連携する機器間の関係を形成する方法について以下の例で説明する。
【００２１】
（５）連携可能な機器を連携させ、結果をフィードバックすることで状況に応じて連携する機器を選別する方法
（６）連携できるものから順次連携させていく方法
図１は、本発明を適用した機器の構成例である。機器101内の処理は、環境を認識し周辺に存在する機器を判断する環境認識処理111と、他の機器との間でのデータ送受信を行う通信処理112、各機器内の処理間での連携を判断及び制御する連携制御処理113、及び機器の制御を行う処理プログラム114から構成される。環境認識処理111は、センサ131を介して該機器の存在する環境情報を取得し、取得した環境情報に基づいて、該機器と周辺機器の位置関係を認識して連携制御処理113に渡す。ここで、センサ131は環境から情報を取得するのみでなく、周囲に情報発信して応答を受信するなどアクティブな情報取得が可能なものを用いることもできる。また、環境側の地図情報121を用いて自機器と周辺機器の関係を認識し、周辺機器を判断することもできる。本実施の形態では、環境認識において、センサ131から取得した情報のみを用いる場合や、通信処理112から取得した他の機器情報を用いる場合の実施の形態について説明しているが、他の方法で環境情報を取得し、認識してもよい。
【００２２】
認識した周辺機器情報は、環境管理テーブル123に格納される。連携制御処理113では、プロファイル122と、通信処理112より取得した他機器のプロファイルを照合し、ポリシー124に従って連携する相手となる機器及び処理を判断する。プロファイル122には、自機器の名称や種別といった自機器に関するデータ、及び自機器に存在する処理プログラムに関する情報が含まれており、各機器に存在する処理間で連携するかしないか、入出力データの関係により連携できるか否かなどを判断する元となる。実際に連携している相手機器や処理プログラムの情報は、動的連携管理テーブル125に格納される。処理プログラム114は、外部入出力部132を介して情報の入出力や機器の制御を行う。ここで、外部入出力装置とは、液晶パネルやキーボード、タッチパネル等のマンマシンインタフェ−スを介して機器上で実行される処理プログラム114の制御や出力値参照を行ったりする機能を有している。ただしこれは必須ではなく、外部入出力部を持たない機器もある。
【００２３】
図１７は、本発明を適用した住居システム構成の例を示す図である。住居内の機器システムの例を示している。住居の内の各機器は、映像・メディア用ネットワーク1711や、電灯線ネットワーク1712などの通信媒体をそれぞれ用いて相互に接続されている。各機器には、本発明を適用した機器1721が組み込まれ、または接続されており、計算機の管理範囲を越えて互いに連携する。連携する範囲は、住居全体（1701）、２階全体といったフロア毎（1702）、または特定の部屋毎（1703）のように物理的な境界に基づいて決めることができる。または、電力制御や映像音響制御といった目的毎に範囲を決めてもよい。また、連携する範囲を物理的な境界と目的別の両方の組合せで決めてもよい。例えば、特定の部屋の電力制御、としてもよい。このシステムにおいて、例えば冷蔵庫1731は、買い替えやメンテナンスのために冷蔵庫1732と入れ替えられる。
【００２４】
また、携帯電話1733は、利用者の移動に伴って移動する。このような環境への参入・離脱によって、住居やフロア、部屋といった範囲を構成する機器は動的に変化する。
【００２５】
図２５は、本発明を適用した制御システム構成の例を示す図である。部材1772を搬送車1771が搬送し、処理機械1773で処理するシステムの例である。各設備には本発明を適用した機器1721が組み込まれ、または接続されている。各設備は、ローカル・エリア・ネットワーク（1761）や、無線セル（1762）を管理する地上局を介して相互に接続されている。連携する範囲は、この例では工場全体（1751）、在庫領域（1752）、処理ライン１領域（1753）、処理ライン２領域（1754）といった、物理的かつ機能的な境界に基づいて形成されている。このシステムにおいて、例えば部材1772は、搬送により在庫領域1752への参入・離脱を行い、搬送車1771は、搬送に伴い在庫領域1752や処理ライン１、処理ライン２へ参入・離脱を繰り返す。また、ラインの改造などが発生すると処理ラインの位置や構成も変化する。このように、システムを構成する設備は動的に変化する。
【００２６】
（実施例１）
図２は、本発明の第１の実施例におけるシステム構成例を示す図である。部屋201内に機器211〜213が配置されている。ここで、機器212は赤外線などの光通信を用いて周囲の機器に対して存在確認信号を送信し（221）、本信号を受信した機器211及び機器213がこれに応答することで、周辺機器及びその配置を認識する。部屋201の壁は、機器間で送信、応答されるこれらの信号を遮断するため、部屋内の機器が周囲の機器として認識される。赤外線でなく例えば無線通信を用いた場合でも、電波遮断効果のある壁を用いることで、本実施例と同様の方法で部屋内の機器を周囲の機器として認識することができる。
【００２７】
図３は、本実施例における環境情報管理テーブルの構成例を示す図である。各レコードは、機器名311、機器種別312、相対位置313、及び更新時刻314で構成される。機器名311は認識された周辺機器の名称を格納するフィールドである。相対位置313は、自機器と周辺機器の相対位置関係を格納するフィールドである。更新時刻314には、該レコードの示す周辺機器を認識した最新時刻が格納される。
【００２８】
図４は、本実施例において、各機器が自ら周辺をスキャンして周辺機器を検出する場合の環境認識処理の流れを示す図である。本実施例における環境認識処理は、センサ131を介して周辺機器が存在するか問い合わせ（ステップ411）、返信を待つ（ステップ412）。ステップ412では、他の機器からの返信があるか、または事前に設定した時間内に返信が無い場合に次ステップへ移る。次ステップでは返信があったかどうかを判定し（ステップ413）、返信があった場合は、返信された機器の情報を環境管理テーブル123へ格納する（ステップ414）。ここで、相手機器が該機器の情報を返信する機能が無くセンサへの反応信号を返すのみで、問い合わせ元の機器からは何らかの機器が存在することしか検出できない場合でも、重複しない機器名称を割り当て機器名311に格納し、相対位置313に該機器からの方位及び信号強度から求めた相対距離を格納する。ステップ413において返信が無かった場合は、ステップ415へ移行する。
【００２９】
その後、周辺機器を検出するセンサの信号強度を変換し（ステップ415）、ステップ411〜ステップ415を繰り返す。信号強度が最大になるまで繰り返した後、信号強度を最小にリセットし（ステップ416）、方位を変更し（ステップ417）、ステップ411から本処理を繰り返す。なお、本実施例ではセンサの方位を変更しながら周辺機器を検出する例を示したが、全方位型のセンサを用いる場合はステップ417の方位変更は必ずしもなくともよい。この場合の相対位置には、該機器からの距離が格納される。
【００３０】
図３５は、本実施例における環境認識処理の、自機器情報返信処理の流れを示す図である。図４にて説明した処理へ応答する処理の流れを示している。本処理においては、センサからの反応を待ち（ステップ3511）、他の機器からの問い合わせ信号を受信すると自機器のプロファイル122より自機器の名称や種別を取得し（ステップ3512）、問い合わせ元の機器へ返信する（ステップ3513）。
【００３１】
図２６は、本実施例において各機器が自機器情報を自発的に発信する場合の、環境認識処理の流れを示す図である。本処理においては、センサからの反応を待ち（ステップ421）、受信した信号より送信元機器の情報を抽出し、環境管理テーブルへ格納する。その後、ステップ421へ戻る。
【００３２】
本実施例によれば、グローバルに機器の位置や相対距離を検出する手段がない中でも、各機器が機器同士の相対的位置関係を認識することが可能である。この相対位置を用いて、通信信号の強度や方向を制御してアドレスに変換することで、例えば信号が届く範囲である部屋のような範囲や、信号強度に対応して自機器から一定の距離にあるもの、一定の距離内または距離外にあるものなどのような限定した範囲の周辺機器を検出することが容易であり、システム全体で一意のアドレスを設定せずとも、連携する機器を判断することができる。また、専用のサーバ機を設置せずとも、機器同士で認識することが可能である。
【００３３】
（実施例２）
本発明の第２の実施例においては、認識した周辺機器情報を共有することにより、連携する相手を認識する場合の実施例について説明する。
【００３４】
図５は、本発明の第２の実施例におけるシステム構成を表す図である。搬送機械531は、搬送路541上を移動し、搬送物532を運搬する。搬送機械531には、本発明の実施例である搬送機械制御機器511が搭載されている。また搬送機械制御機器511では、環境情報を取得するセンサ131として、搬送路上での位置を測定するトラッキング装置521を用いている。また、搬送物532には、本発明の実施例である搬送物識別機器512が付けられており、さらにこれは環境情報を取得するセンサ131としてIDタグを用いている。ここで、IDタグ522にはセンシング機能は無く情報の格納のみが可能であるが、搬送機械によって置かれた際、搬送機械が現在位置情報を書き込むことで擬似的に位置センサの役割を果たすことができる。搬送機械制御機器511は無線による通信機能を持ち、一定距離内にある搬送物のIDタグ情報の読み書きを行うことができ、一定距離内の他搬送機械533に搭載された搬送機械制御機器513と通信する無線機能を有する。これらの無線通信は、障害物やノイズによって一時的に通信ができなくなる場合がある。
【００３５】
図６は、搬送機械制御機器511で保持している地図情報121の構成例を示す図である。各レコードは、ルート番号611、ポイント(From)612、絶対位置(From)613、ポイント(To)614、絶対位置(To)615で構成される。各レコードは搬送機械が通行可能な搬送路上に置かれたポイントと向きを表しており、ルート番号で識別される。ポイント(From)は出発点となる搬送路上のポイントで、絶対位置(From)はポイント(From)の絶対位置を格納する。ポイント(To)は到着点となる搬送路上のポイントで、絶対位置(To)はポイント(To)の絶対位置を格納する。
【００３６】
図２７は、搬送物識別機器512及び搬送機械制御機器511で保持している現在位置情報の構成例を示す図である。現在位置情報には、搬送機械または搬送物が現在存在する区間を示すルート番号635、該区間の近傍ポイントであるポイント(From)631、及びポイント(To)632、該区間において現在位置のポイント(From)からのオフセット633、及び絶対位置が格納されている。現在位置情報は、搬送機械制御機器511ではトラッキング装置521より、搬送物識別機器512では搬送した搬送機械より取得して格納される。
【００３７】
図７は、本実施例における環境認識処理の、周辺機器を検出する処理の流れを示す図である。本実施例における環境認識処理は、通信処理112より他機器から送信された該機器の情報及び位置情報を受信し（ステップ711）、自機器に保持している地図情報121を用いて照合する（ステップ712）。ステップ712においては、受信した機器の存在する位置及び自機器の位置を地図上で認識し、該機器が自機器の近傍に存在するか否かを判断する（ステップ713）。ここで、近傍に存在するとは、例えば本実施例における搬送機械側では、搬送機械の現在位置と同一のルート番号を持つ区間に存在するか否かで判断する。あるいは、IDタグのように送受信範囲が制限されるものを用いる場合は、受信した機器情報の送信元機器を近傍であると判断してもよい。ステップ713において近傍に存在した場合、該機器の情報及び位置情報を環境管理テーブルへ格納する（ステップ714）。なお環境管理テーブルは、例えば格納されたレコードの更新時刻314を周期的にチェックし、一定時間経過して更新されていない機器情報を削除することで、自機器の移動によって周辺機器でなくなった機器情報を更新することができる。
【００３８】
図２８は、本実施例における環境認識処理の、自機器情報及び位置情報配信処理の流れを示す図である。本処理においては、自機器の機器名311や機器種別312をプロファイルより取得し、センサ131より取得した位置情報と共に、通信処理を介して配信する（ステップ721）。その後指定時間待機し（ステップ722）、再度ステップ721の処理より繰り返す。または、単体のIDタグのように電源を持たず能動的に送信することが出来ない場合は、IDタグの読み書き装置よりチャージ波を送られたイベントに連動して送信を行ってもよい。
【００３９】
図２９は、本実施例における環境認識処理の、周辺機器情報共有処理の流れを示す図である。各機器のもつ環境管理テーブルは、周期的または環境管理テーブルが更新されたタイミングで通信媒体へブロードキャストすることで、他の機器へ通知される。本処理は受信した機器の処理の流れを示しており、他機器より送信された該機器の周辺機器情報を格納した環境管理テーブルを通信処理より取得し（ステップ731）、自機器の環境管理テーブルと照合して、更新する（ステップ732）。
【００４０】
本実施例においては、搬送機械の搬送路を地図情報として用いたが、GPS(Global Positioning System)のような位置検出機構を用いてもよい。また、カー・ナビゲーションシステムのような装置を用いて地図上での位置を検出してもよい。
【００４１】
本実施例によれば、機器が自律的に位置情報を発信し、各機器において該位置情報を用いて相対位置を判定することで、専用のサーバ機を設置せずとも、機器同士の相対的位置関係を認識し、連携する機器を認識することが可能である。また、連携する機器が互いに移動したり、連携する相手が事前に決まっていない場合でも、柔軟に連携相手を認識し判断することができる。
【００４２】
さらに、自機器の認識した周辺機器情報を、自機器より通信可能な媒体を通じて他機器へも通知することで、該周辺機器情報を受信した機器では、自律的に位置情報を発信する機能を有しない機器の情報も含めて、通信障害により検出できなかった周辺機器情報を補正したり、移動によって変化した周辺機器の情報を検出・更新することができる。
【００４３】
（実施例３）
本発明の第３の実施例においては、各機器の持つ機能に関する情報と状況に関する情報を用いて、機器間の連携を動的に制御する例について説明する。
【００４４】
図８（a）は、プロファイル122のうち自機器情報格納テーブルの構成例を示す図である。自機器情報格納テーブルは、機器名811、機器種別812、及び仕様813から構成される。機器名811は機器を一意に識別する名称を格納し、通信処理において宛先アドレスとして用いられる。機器種別812は、例えば搬送機械やテレビといった機器の種類を格納する補助的情報である。仕様813は、機器の型式や性能といった仕様を格納する。
【００４５】
図８（b）は、プロファイル122のうち、他機器の処理と連携可能な自機器内の処理構成格納テーブルの構成例を示す図である。各レコードは、処理名821、入力インタフェース822、出力インタフェース823、仕様824、ステータス825で構成される。処理名821は機器内の各処理を識別する名称を格納するフィールドである。該処理の外部インタフェースが、入力インタフェース822、及び出力インタフェース823に格納される。入力インタフェース822は、他の処理から該処理に対してコマンドまたはデータを渡すインタフェースである。
【００４６】
出力インタフェース823は、該処理より他処理に対して発行するコマンドまたはデータを渡すインタフェースである。これらのインタフェースは、例えば「Inside CORBA−CORBAとそのシステム開発への応用」(ISBN4-7561-2015-6)にあるようにIDL(Interface Definition Language)を用いて記述することで、インタフェース名や引数データを定義し、識別することが可能である。仕様824には、各処理の仕様が記述される。これには、例えば「XML入門」(ISBN4-532-14610-0)にあるようなXML(eXtensible Markup Language)などを用いて、複合的情報を構造化して格納することができる。ステータス825は各処理の状態を格納するフィールドで、異常や、該処理の制御対象機器の障害、高負荷といった状態の他、接続中の他機器、処理、接続中かまたは接続が切断された状態かといった接続状態などの情報が格納される。連携制御処理113は、この情報も用いて処理を連携させるか否か判断する。
【００４７】
以下、本実施例における処理間のおおまかなデータフローを説明する。
【００４８】
図１４は、本実施例においてシステムへの参入機器を検出する場合の、処理間のデータフローの例を示す図である。機器1402が参入し、機器1401がこれを検出する場合の例を示している。機器1402は、通信処理112を介して、周期的かつ自発的にHeartbeatメッセージを送信し（*1）、機器1401の通信処理112ではこれを受信し、既にHeartbeatメッセージを受信した機器か否かを判断し、新たに参入した機器であることを検出する（*2）。Heartbeatメッセージには、機器1402を特定する識別子や、送信周期が格納されている。新たに検出した機器である場合は、連携制御処理113において自機器のポリシーとのマッチングを行い（*3）、連携してもよい機器である場合はアプリケーションプロファイルとの照合処理へ移る。
【００４９】
図３０は、本実施例においてシステムからの離脱機器を検出する場合の、処理間のデータフローの例を示す図である。機器1402が離脱したことを、機器1401が検出する場合の例を示している。機器1402は、離脱する場合にShutdownメッセージを送信し（*1）、機器1401の通信処理はこれを受信して機器1402が離脱することを検出する。または、機器1401より周期的に送信されるHeartbeatメッセージが、該Heartbeatメッセージの送信周期に比例する一定期間受信できない場合に、タイムアウト処理により機器1402の離脱を検出する（*2）。機器1402の離脱を検出した後、連携制御処理113において、離脱した機器1402の処理プログラムと既に連携している処理プログラム114が存在する場合は、切断処理を行う（*3）。
【００５０】
図１５は、本実施例において各機器の持つ処理プログラム間を連携させる場合の、処理間のデータフローの例を示す図である。機器1402を認識した機器1401が、自機器内の処理プログラムと機器1402内の処理プログラムを連携させる場合に、機器1402内の処理プログラムの構成を取得し、機器1401内の処理の構成と照合して、相手となる処理を選択する（*1）。または機器1401内の処理の構成を機器1402へ送り、連携できる処理があるか照合させる。相手となりうる機器が複数ある場合は、同様に機器1403、機器1404との間でも同様の処理を行う。その後、連携する相手との間で接続を確立し、処理プログラム間を連携させる（*2）。
【００５１】
図３１は、本実施例において各機器の持つ処理プログラム間の連携を更新する場合の、処理間のデータフローの例を示す図である。機器の状態に変化が発生した場合は、機器1402は状態変化通知を送信し（*1）、機器1401はこれを受信して処理プログラム間の連携を更新するか判断する（*1）。ここで、状態変化とは処理プログラムの異常や、応答性などのような、連携する際に照合した条件が変化した場合などである。また、機器1402は、機器の負荷や、現在実行可能な処理プログラムや実行不可能な処理プログラムがあることを示す機器の状況などをポリシーとして保持しており、これに変化が生じた場合も通知する。機器1403、機器1404でも、機器1401の処理プログラムと連携している処理プログラムがある場合は同様である。その後、別の処理プログラムと連携する場合は、図１５において説明したような処理を行い、新たな相手と連携する。既存の連携を継続する場合も、連携する条件を更新する（*2）。さらに、これを自機器の処理プログラムに通知し、条件更新や接続の切断・再接続といった処理を行う（*3）。
【００５２】
図１６は、本実施例において位置情報を取得する場合のデータフローの例を示す図である。環境認識処理111を介して、センサ131として、GPSセンサ1611を用いた場合は、本発明の第２の実施例で説明したように、絶対位置情報や地図上での位置情報を取得する。
【００５３】
また、カードリーダ1612を用いた場合は、読み込んだカードの情報を用いて、読み込んだ時点での該カードとの相対位置情報を取得することができる。また通信媒体としてPHSのような位置情報の解かるものを用いた場合は、センサを設けずとも位置情報を得ることができる（*3）。このようにして得た自機器の情報や他機器の位置情報を元に、システム内での位置付けを常時更新する（*4）。
【００５４】
図９は、本実施例における連携制御処理113の、マッチング処理の流れを示す図である。本処理においては、自機器内処理又は他機器の状態変化イベントを待ち（ステップ911）、イベント受信時にいかなる種別の状態変化が発生したかを判定する（ステップ912）。本実施例においては、状態変化として他機器状態変化と自機器内状態変化の2種類の場合の処理の流れについて説明する。他機器状態変化とは、環境認識処理111において新たな周辺機器を検出した場合や、既に検出している機器の状態変化を意味する。自機器内状態変化とは、自機器内の処理の構成変化や状態変化であり、処理プログラム114からの障害通知を受け取ることや、オペレーティングシステムからの通知を監視することで検出できる。本実施例においては以上のような状態変化が発生した場合の例について説明するが、これ以外にも利用者からの明示的な指示などのような様々なイベントに対応してマッチング処理を行うことが可能である。
【００５５】
ステップ912において他機器の状態変化を検出した場合は、該機器よりポリシーを取得し、自機器のポリシーと照合し、連携するか、または連携を継続するかを判断する（ステップ914）。連携しない場合はステップ911へ戻り、イベント待ち状態となる。連携する場合は、該状態変化の発生した機器より受信した該機器のプロファイルを取得する（ステップ915）。なお、ステップ913において用いる該機器のポリシーや、ステップ915において取得する該機器のプロファイルは、問い合わせて取得してもよいし、各機器より周期的に発信させ、取得してもよい。または、例えば特願平８−２４９６１１にあるような方法を用いて、変更が発生したときのみ配信して複製してもよい。
【００５６】
ステップ912において自機器内状態変化を検出した場合は、プロファイル情報を更新する（ステップ916）。これらのステップにより新たに取得した最新の自機器、または他機器のプロファイルを照合し（ステップ917）、連携できるものがあるかどうか判断する（ステップ918）。連携できるものは、本実施例では一方の処理の出力インタフェースと、他方の処理の入力インタフェースが一致し、プロファイルのステータス情報825が両方の処理とも実行可能であるか否かで判断するものとする。連携できる処理がある場合は、動的連携管理テーブルに連携する処理の組み合わせを格納し、該処理間でデータ送受信できるよう処理間の連携処理を行う（ステップ919）。処理間連携処理には、例えば「Inside CORBA−CORBAとそのシステム開発への応用」(ISBN4-7561-2015-6)にあるように、データ受信側のオブジェクト・リファレンスをデータ送信側が取得するなどといった方法を用いて処理間をバインドする。どちらかの処理に異常がある場合は、処理間の接続を切り離す。
【００５７】
図３２は、本実施例における連携制御処理113の、連携状態監視処理の流れを示す図である。プロファイル情報は各機器より周期的に送信されており、このプロファイル情報を受信し（ステップ931）、自機器と連携している処理のステータスを確認する（ステップ932）。自機器内の処理と連携している処理に状況変化があるか判定し（ステップ933）、状況変化がある場合は図９にて説明したマッチング処理へ通知する（ステップ934）。ここで、状況変化には処理に異常が発生した場合の他、実施例４において示すように複数の機器または複数の処理から連携相手を選定する場合に、現在連携している相手より良い相手が検出された場合などである。
【００５８】
図１９は、本実施例における動的連携管理テーブル125の構成例を示す図である。各レコードは、目的識別子1911、連携先1912、自機器処理名・インタフェース名1913、連携状態1914で構成される。目的識別子1911は処理プログラム間を連携させる目的の識別子を格納し、本実施例においてはレコード番号が格納される。連携先1912は、連携している他機器の機器名、連携先処理名、及び該処理のインタフェース名が格納され、自機器処理名・インタフェース名1913に、連携している自機器の処理名、及びインタフェース名が格納される。連携状態1914は該レコードの示す処理プログラム間の連携状態を格納するもので、「連携中」「連携解除中」などといった接続状態と、処理応答時間などの性能値などが格納される。
【００５９】
図２１は、本実施例における連携制御処理の、連携先選択処理の流れを示す図である。処理プログラムからの要求を受け取り（ステップ2111）、動的連携管理テーブルより要求送信元の処理プログラムの該当するレコードを検索して、該要求を実行させる連携先相手を選択する（ステップ2112）。連携先相手は、環境管理テーブルより取得した相手機器との相対距離を用いて自機器に近いものを選択してもよいし、相手を特定せず全ての機器を選択し、処理させてもよい。また、この結果を次回以降の要求時に用いて、早く処理を終えるものを選択してもよい。例えば、通信状態や相手機器の負荷によって処理の応答性能は変化するため、このように複数の連携先を持ち、実行時に相手を選択することで、柔軟に他の機器と連携することができる。相手機器や自機器が移動する場合は、処理実行時に最も近い機器を選択して連携することもできる。その後処理要求を送信し（ステップ2113）、相手機器からの処理結果を取得する（ステップ2114）。評価結果を次回以降の相手選択に用いる場合は、これを動的連携管理テーブルに格納する。受け取った結果は処理プログラムへ返し（ステップ2115）、処理プログラムからの要求待ち状態に戻る。
【００６０】
実施例の方法によれば、各機器の置かれた環境情報と、各機器がローカルに管理する処理情報を用いて、各機器が局所的に照合することで、専用のサーバ機を設置せずとも、機器間での連携が可能である。また、各機器の処理状態に関する情報を用いて連携するか、あるいは連携を継続するか否かを、継続的に判断することで、連携する機器に状態変化が発生した場合でも、柔軟に他機器との間の連携を制御することができる。さらに、複数の連携先を持ち、実行時に相手を選択する、または複数の相手を実行させた処理結果を選択することで、より柔軟な連携を行うことができる。
【００６１】
（実施例４）
本発明の第４の実施例においては、環境情報である相対位置情報や自機器の状況に応じて連携する周辺機器及び処理を判断する方法の例として、機器間の相対位置と、サービスの締め切り時間を元に連携機器を判断する場合の例について説明する。
【００６２】
図１０は、本実施例におけるシステム構成の例を示す図である。本発明の機器は、搬送機械1011,1012、搬送物1021〜1023、及び処理機械1013に組み込みまたは接続されている。搬送機械1011,1012は、搬送路1031を通って、搬送物1021〜1023を置き場1041へ運搬するとともに、置き場1041より処理機械1013へ運搬する。また、搬送機械は同時に１つの搬送物しか運搬できない。ここで、搬送物1021〜1023は、置き場1041へ置かれてから処理機械1013で処理されるまでに時間の制限がある。
【００６３】
図１１（a）は、本実施例におけるポリシー124の自機器状況格納テーブルの構成例を示す図である。自機器現在状況1111には、処理プログラム114の処理結果に応じて、自機器の現在の状況が格納される。ここで、自機器状況とは、搬送機械側では、搬送中、空、予約中といった搬送機械の作業状況であり、搬送物側では搬送中、置き場中では処理期限までの余裕時間、処理中などといった状況のことである。
【００６４】
図１１（b）は、本実施例におけるポリシー124の認証機器テーブルの構成例を示す図である。各レコードは、連携機器名1121、及び連携機器種別1122で構成される。連携機器名1121には連携してもよい機器名が格納され、連携機器種別1122には連携してもよい機器種別が格納される。機器種別とは、本実施例においては搬送機械や搬送物、処理機械といった単位での識別子である。ここで連携機器名1121が空欄で連携機器種別1122に値が格納されているレコードは、当該種別の機器全てと連携してもよいことを意味する。本テーブルは、本発明の第３の実施例で説明した連携制御処理113の、ポリシー取得・照合処理913で用いられる。
【００６５】
図１１（c）は、本実施例におけるポリシー124のマッチングテーブルの構成例を示す図である。各レコードはマッチングの条件を示しており、自機器状況1131、優先度1132、連携機器名・種別1133、連携機器状況1134、及び連携機器選択条件1135で構成される。自機器状況1131は、自機器現在状況1111と照合して、本レコードを用いてマッチングを行うか否か判断するための条件となる。連携機器名・種別1133には、連携する相手の機器名または機器種別が格納され、連携機器状況1134には連携する相手の機器状況が格納される。優先度1132は、同一の自機器状況1131に対して複数のレコードが存在する場合に、どのレコードのマッチング条件を優先するかを判断するための番号である。連携機器選択条件1135は、連携先機器が複数ある場合に、連携する機器の数や、どの機器を選択するかに関する条件を格納する。
【００６６】
数に関しては、例えば１つ、最大2つなどである。どの機器を選択するかについては、例えば先に連携できたものを優先する、相対距離の近いものを優先するなどである。
【００６７】
図１２は、本実施例における連携制御処理113のマッチング処理の流れを示す図である。処理921は第３の実施例と同様の流れであり、イベント検出し、自機器または他機器のいずれに関するイベントの判定を行い、他機器に関するイベントの場合はポリシー照合処理を行う。本実施例における他機器の状態変化には、図１１（a）にて説明した各機器の現在状況が変化したことに関するイベントも含む。他機器に関するイベントである場合はプロファイルを取得し、照合する（ステップ911〜917）。照合の結果、連携できるものがある場合は（ステップ918）、ポリシー124より自機器現在状況を取得し（ステップ1211）、イベントの発生した他機器の状況を、図１１（c）にて説明したポリシーのマッチングテーブルを用いて照合する（ステップ1212）。マッチング条件を満たした場合は、既に連携している機器と比較し、連携先を変更するか否かを判断する（ステップ1213）。ここで、連携先の比較には、ポリシーのマッチングテーブルに格納された連携機器選択条件1135を用いる。
【００６８】
連携機器選択条件に基づき、連携先機器を追加するか、変更するかを判断する。この判断に基づき、機器の処理を新たにバインドしたり、変更する場合は既存の接続を解除し、選択した処理との間で新たに接続を確立する。
【００６９】
なお、本実施例においては自機器または他機器に関するイベントで駆動される処理の例を示したが、自機器または他機器に関するイベントを格納しておき、周期的に処理を行ってもよい。また、本実施例では、他機器に変化が検出される度に連携を変更するか判断しているが、複数の機器に関するイベントを複数待った後に判断してもよい。
【００７０】
図３３は、本実施例における連携制御処理113の、ポリシー受信処理の流れを示す図である。ポリシー情報は各機器より周期的、または状況変化時に送信されており、これを受信し、該機器の自機器現在状況を取得する（ステップ1221）。図１２にて説明したマッチング処理へ通知する（ステップ1222）。
【００７１】
図１３は、本実施例における各機器の状況変化のタイムチャート例を示す図である。タイムチャート1311〜1315は、それぞれ搬送機械１、搬送物１〜３、及び搬送機械２の状況の遷移を表しており、上から下へいくにつれ時間が経過していることを示している。搬送物1は、搬送機械で空いている搬送機械１を使う予定であり予約する（ステップ1321）。予約は、搬送物１と連携した搬送機械１の処理プログラム114が、ポリシー124の自機器現在状況を更新することで「予約中」状態とする。その後、搬送機械２が処理装置への搬送を終えて「空」状態となり（ステップ1322）、搬送物１〜３では該ポリシーの変化を検出し、搬送機械２においても搬送物１〜３の状況を受信し、図１２及び図３３にて説明したマッチング処理を行う（ステップ1323）。
【００７２】
ここで、搬送物１〜３では、連携機器選択条件1135として相対距離を用い、より近い搬送機械２と連携する。一方搬送機械２では、本実施例のマッチング処理では先に状況を受信できたものからマッチング処理を行って連携するが、連携機器選択条件1135として処理期限を用い、期限の短い搬送物１が最終的に選択され、搬送機械２の状況が「予約中」となる（ステップ1324）。これにより搬送物１と搬送機械１の連携は切断され、搬送機械１の状況が、搬送機械１内の処理プログラムによって「空」に変更される（ステップ1325）。この後は、ステップ1323〜ステップ1324と同様の処理の流れによって、搬送物２と搬送機械１との間で連携し、搬送機械１の状況が「予約中」となる（ステップ1326）。
【００７３】
本実施例の方法によれば、手動設定や、また専用のサーバ機の設置がなくとも、機器間での連携が可能である。さらに、各機器の状況や環境に関する情報を用いて継続的に判断することで、システム全体としての状況や構成が、機器の移動や稼動状態変化により時間とともに変化する環境においても、各時点で、柔軟によりよい他機器との間の連携を制御することができる。
【００７４】
また、本実施例では搬送物の処理装置への運搬という例を示したが、搬送物の回収といった目的及び期限の異なる処理も含めて連携して行う場合でも、本実施例の方法を用いることで、機器毎に各時点で柔軟に連携することができる。例えば、タイマ録画/録音機能を持つAV機器のタイマ機能に障害が発生した場合に、同一住居内にあるコンピュータや電話機のような他の機器のタイマ機能と連携させて動作させるといった再構成を行うことができる。
【００７５】
（実施例５）
本発明の第５の実施例では、機器が連携する相手を事前に決められない場合に、各機器が実際に動作し、動作結果をフィードバックすることで機器間の連携関係を形成する場合の例について説明する。
【００７６】
図１８は、本実施例におけるシステム構成の概念を示す図である。複数の機器が存在し（1813）、ユーザの要求1811に基づいて処理プログラム間を連携させ（1812）、動作する。本実施例においては、これらの機器はユーザ1851にとっての目的である「省エネルギー運転(Less Energy)」1821、及び「娯楽(Enjoy)」1822に基づいて、連携する範囲であるBalancingグループ1831、及びCoordinatingグループ1832を形成し、互いに連携して動作する。グループに属する単位は、機器毎の処理プログラムの他、Sound Ctl(1833)に示すように、複数の機器が纏まって動作する場合はこの単位で連携動作することもできる。各機器は、相互に自分の状況を発信して（1841）動作する。また、試行的に動作することで（1824）、該グループに影響の小さい機器との関係を切断し、影響の大きい機器だけでグループを形成したりする。
【００７７】
本実施例における動的連携管理テーブル125の構成例を説明する。目的識別子1911には処理プログラム間を連携させる目的の識別子を格納し、本実施例においては「省エネルギー運転(Less Energy)」や「娯楽(Enjoy)」といった識別子が格納される。連携先1912には、該目的のために連携している他機器の機器名、連携先処理名、及び該処理のインタフェース名が格納され、自機器処理名・インタフェース名1913に、連携している自機器の処理名、及びインタフェース名が格納される。連携状態1914には該レコードの示す処理プログラム間の連携状態を格納し、「連携中」「連携解除中」などといった状態が格納される。
【００７８】
図２０は、本実施例における連携制御処理113の、要求判断処理の流れを示す図である。本処理は、他の機器やユーザから送信された動作要求イベントを待ち（ステップ2011）、自機器内の処理プログラムで受信した要求に対応して動作できるものがあるか判定する（ステップ2012）。本実施例においては、要求は処理プログラムのインタフェースの形で受信するものとする。例えば「省エネルギー運転」といった目的には「省エネルギーモード設定」などのインタフェースで要求される。無論、該要求を受信した機器側で、受信した要求を解釈してインタフェースに変換するフィルタを設けて処理してもよい。例えば、照明機器の処理プログラムに「省エネルギーモード設定」というインタフェースが無いが、「電灯の半数を消す」というインタフェースがある場合に、これらをマッピングするフィルタなどである。
【００７９】
次に、ステップ2012の結果を判定し（ステップ2013）、自機器に動作可能な処理プログラムがある場合は、該処理プログラムを実行し（ステップ2014）、要求及び要求元機器名、処理プログラム名及びインタフェース名、自機器処理名及びインタフェース名を図１９にて説明した動的連携管理テーブルに格納する（ステップ2015）。
【００８０】
このような機構を用いて、連携動作させる機器が事前に解らない場合でも、本実施例の方法を用いて各機器を試行的に動作させることで、動的に連携相手を探索することができる。動作の結果が不十分または目標を超過した場合は、当該部分を微調整することで目的を達成できる。例えば図１８の例では、「娯楽」という目的に対して動作した機器のうち、不要な掃除機を停止させる、などといった調整である。
【００８１】
図３４は、本実施例における連携制御処理113の、連携更新処理の流れを示す図である。本処理は、処理プログラムを試行した後起動され、処理プログラムの試行結果を取得する（ステップ2021）。ここで結果情報は、通信処理を介して要求を送信した機器より、またはセンサを介して直接取得するものとする。次に試行した自機器内処理の寄与率を判定し（ステップ2022）、該連携を継続するか否か判定する（ステップ2023）。ここで寄与率とは、目的に対する自機器内処理の影響度合いのことであり、例えば「省エネルギー運転」という目標に対しては、自機器内処理の試行により削減された消費電力量の、全体消費電力量に対する割合がこれにあたる。寄与率が解からない場合は、連携を継続する。継続の判定には、例えば「10％以下は寄与しない」といった定数値との比較や、目標量を達成するための閾値を動的に計算するなど、種々のアルゴリズムを用いることができる。
【００８２】
ステップ2023において継続すると判定した場合は連携したままにする、または無効化された連携を有効にし（ステップ2024）、継続しないと判定した場合は連携を無効化し、処理の試行を停止する（ステップ2025）。その後、本処理を繰り返す。
【００８３】
本実施例に示したようなフィードバック処理を含めることで、図２０で説明した連携関係を、環境の状況変化に適応させてメンテナンスすることができる。例えば住居システムにおいては、食事の準備時か、昼間の人が少ないときか、夜の家族の団欒時か、などのように時間によって稼動する機器が変化するため、「省エネルギー運転」も時間によって稼動させるべき機器が変化する。また、照明機器も朝、昼、夜と周囲の環境変化に連動して稼動すべきか否かが変化する。省エネルギー運転の要求があった場合、動作中の機器で連携を取り、または各機器が要求を解釈して、最も消費電力の大きなものをＯＦＦにする制御をしてもよい。また、運転に対する優先度に基づいて、優先度の小さいものからＯＦＦにする制御を行ってもよい。例えば、予約録画で録画中のビデオの優先度は高く、人間のいない部屋での電灯の点灯の優先度は低くする、としてもよい。なお、省エネルギー運転では、OFFにする制御でなく、機器の消費電力を抑える制御としてもよい。例えば、テレビやラジオの音量を下げる、電灯の明るさを下げるなどの制御でもよい。
【００８４】
また、本発明の構成では、照度センサと照明が互いにデータを交換してフィードバック制御を行える。照度センサで測定した照度が、その部屋に人がいないのにも関わらず高い場合は、照度を下げる、などの制御が可能になる。また、動作開始の要求があった場合、例えば帰宅した際に、玄関に設置された動作開始のボタンを押すと、センサと連動して帰宅者が移動している廊下、部屋の電灯を点灯するよう制御してもよい。また、通過した後は消灯してもよい。本実施例で示した処理を継続的に用いることで、このような環境変化に適応しながら機器を連携動作させることが可能となる。
【００８５】
（実施例６）
本発明の第６の実施例では、機器が連携する相手を事前に決められない場合に、連携できる機器から順次連携していくことで、機器間の連携関係を形成する場合の例について説明する。
【００８６】
図２２は、本発明の第６の実施におけるシステム構成例を表す図である。住宅内のシステム構成例を示しており、部屋2201〜2203から構成されている。部屋2201には、無線2221で相互に通信できるチューナー2231、ビデオ2232、テレビ2233と、Universal Serial Bus(USB)2223で相互に接続されたパソコン2239、スピーカー2240，2341、外部記憶装置2242が存在している。部屋2202には冷蔵庫2234、電子レンジ2235、照明2236などが電灯線2222で接続され、部屋2203にはエアコン2237、照明2238などが同様に電灯線2222で接続されている。テレビ2223は無線2221と電灯線2222のゲートウェイとなっており、同様にパソコン2239は電灯線2222とUSB2223のゲートウェイとなっている。部屋2201のAV機器2231〜2233はユーザ2211が使用しており、部屋2202の機器2234〜2236はユーザ2212が制御している。住宅内にはこのように多数の機器が各種の伝送媒体を用いて接続されている。
【００８７】
本実施例では、このような多数の機器を含むシステム構成を、ユーザが詳細に知らずとも制御する方法の例について説明する。例えば、第５の実施例で説明した「省エネルギー運転」のようにどの機器が要求時点で縮退運転できるか解からない場合や、「AV機器のリモコンからのパソコンに接続したスピーカー制御」を行う場合のように、システム構成が複雑な場合などである。
【００８８】
図２３は、本実施例における要求メッセージのフォーマットを表す図である。メッセージは、通信ヘッダ2311、相手範囲2312、目的識別子2313、目標パラメータ2314と目標値2315及び現在実力2316の組み合わせである目標2321で構成される。通信ヘッダ2311は通信処理で用いるヘッダで、送信元機器のアドレスや宛先機器アドレス情報、ブロードキャストアドレスなどの情報が格納される。相手範囲2312は該要求を受け取ってほしい相手機器の範囲を示す識別子が格納される。
【００８９】
例えばネットワーク上の同一セグメントであったり、同一の部屋、建物といった識別子である。目的識別子2313はリレーされる要求を表す識別子で、本発明の第５の実施例で説明したものと同様に機器内の処理のインタフェースにマッピングされるものである。目標2321に格納される目標パラメータ2314は該要求の目標とするパラメータの識別子で、例えば「電力」、目標値2315は該パラメータの目標値で、例えば「100W」、現在実力2316は該要求リレー時に達成された目標量で、例えば「30W」が格納される。スピーカー制御のようなオン・オフ制御の場合は、目標パラメータ2314には「スピーカ台数」、目標値2315には「２台」、現在実力2316には例えば「0台」が格納される。
【００９０】
図２４は、本実施例における連携制御処理113の、要求判断処理の流れを示す図である。本処理は、他の機器やユーザから送信された動作要求イベントを待ち（ステップ2411）、自機器内の処理プログラムで受信した要求に対応して動作できるものがあるか判定する（ステップ2412）。ここで動作できるものがあるかどうかの判断には、インタフェースの合うものがあるかの判断の他に、機器の負荷や、他により優先度の高い処理が稼動していないかなどを含めて統合的に判断する。同種の機器の数が非常に多い場合は、各機器が意図的に、かつランダムにダミープログラムを実行させて処理負荷を上げることで敢えて動作しないようにし、多数の機器間での負荷を分散して、将来の不測の事態に対応できるようシステムに余裕を持たせておくこともできる。
【００９１】
次に、ステップ2412の結果を判定し（ステップ2413）、自機器に動作可能な処理プログラムがない場合はステップ2416へ移る。ある場合は、該処理プログラムを実行し（ステップ2414）、要求及び要求元機器名、処理プログラム名及びインタフェース名、自機器処理名及びインタフェース名を図１９にて説明した動的連携管理テーブルに格納する（ステップ2415）。
【００９２】
その後、処理プログラムを実行した結果を、受信した要求メッセージの対応する目標パラメータの現在実力に反映する（ステップ2416）。反映する値は、USBのように機器へ順番にメッセージが伝送される媒体から受信した要求メッセージの場合は、自機器の処理結果を反映し、無線のようにブロードキャストにより受信した要求メッセージの場合は、該媒体における機器の処理結果を統合して反映する。反映する値は、各機器単独の結果である場合は積算して反映し、総合した結果である場合は該値を上書きすることで反映する。例えば、「省エネルギー運転」という要求に対する目標パラメータ「電力」の現在実力の場合は、各機器の動作を変更することにより節約された電力を積算していき、「スピーカ制御」という要求に対する目標パラメータ「スピーカ台数」の現在実力の場合は、処理できるか否かを判断する。
【００９３】
現在実力を反映した後、要求メッセージの目標値を満たしたか判断し（ステップ2417）、満たした場合はイベント待ちに戻る。満たしていない場合、要求メッセージを転送するか否かを判断し（ステップ2418）、転送する場合は、ステップ2416において更新した要求メッセージを転送する（ステップ2419）。ここで、転送するか否かの判断は、USBのようにシリアルに通信を行う場合は次の相手が居るか否かで判断する。無線のように並列型の伝送媒体を用いている場合は、自機器が要求メッセージを受信した伝送媒体と別の伝送媒体に接続されているかで判断する。上記の判断に加え、要求メッセージに指定された相手範囲が転送先でも有効か否かを判断することで、要求メッセージを転送するか決定する。
【００９４】
本実施例によれば、連携動作させる機器が事前に決定できない場合でも、各機器が自機器の機能や能力、状況を局所的に判断し、連携できるものから順次動作することで、動的に状況にあった連携を行うことができる。各機器の持つ機能や状況をシステム全体として共有せずとも、局所的な動作によって目的を達成することができる。また機器の数が多い場合でも、特定の機器を指定して制御せずとも、１回の要求で適当な機器を動作させることが可能である。
【００９５】
【発明の効果】
本発明によれば、各機器が、自機器の置かれた環境や状況に応じて、連携する他の機器や自機器の稼動状態を判断し変更することができるため、柔軟かつ木目細かな制御・サービスを行うことができる。
【００９６】
また、各機器が自機器の置かれた環境情報や自機器の状況を自ら通知し、継続的に判断を行うことで、各時点でよりよい機器と連携したり、稼動状態を変更したり、連携する相手を事前に決めることが困難な場合でも適切な相手機器と連携できるという効果がある。連携する相手が不明な場合でも、各機器が動作してみることで結果をフィードバックしたり、結果に応じて動作要求を継続して行うことで、適切な相手機器と連携することができる。
【００９７】
さらに、このような判断を局所的に行うことで、システム構成を管理するサーバに依存せず行えるという効果がある。
【図面の簡単な説明】
【図１】本発明を適用した機器の構成例である。
【図２】本発明の第１の実施例におけるシステム構成例を示す図である。
【図３】本発明の第１の実施例における環境情報管理テーブルの構成例を示す図である。
【図４】本発明の第１の実施例における環境認識処理の周辺機器検出処理の流れを示す図である。
【図５】本発明の第２の実施例におけるシステム構成を表す図である。
【図６】本発明の第２の実施例における地図情報の構成例を示す図である。
【図７】本発明の第２の実施例における環境認識処理の、周辺機器検出処理の流れを示す図である。
【図８】本発明の第３の実施例におけるプロファイルの、自機器情報格納テーブルおよび他機器の処理と連携可能な自機器内の処理構成格納テーブルの構成例を示す図である。
【図９】本発明の第３の実施例における連携制御処理の、マッチング処理の流れを示す図である。
【図１０】本発明の第４の実施例におけるシステム構成の例を示す図である。
【図１１】本発明の第４の実施例におけるポリシーの自機器状況格納テーブル、認証機器テーブルおよびマッチングテーブルの構成例を示す図である。
【図１２】本発明の第４の実施例における連携制御処理のマッチング処理の流れを示す図である。
【図１３】本発明の第４の実施例における各機器の状況変化のタイムチャート例を示す図である。
【図１４】本発明の第３の実施例においてシステムへの参入機器を検出する場合の、処理間のデータフローの例を示す図である。
【図１５】本発明の第３の実施例において各機器の持つ処理プログラム間を連携させる場合の、処理間のデータフローの例を示す図である。
【図１６】本発明の第３の実施例において位置情報を取得する場合のデータフローの例を示す図である。
【図１７】本発明を適用した住居システム構成の例を示す図である。
【図１８】本発明の第５の実施例におけるシステム構成の概念を示す図である。
【図１９】本発明の第３の実施例における動的連携管理テーブルの構成例を示す図である。
【図２０】本発明の第５の実施例における連携制御処理の、要求判断処理の流れを示す図である。
【図２１】本発明の第３の実施例における連携制御処理の、連携先選択処理の流れを示す図である。
【図２２】本発明の第６の実施例におけるシステム構成例を示す図である。
【図２３】本発明の第６の実施例における要求メッセージのフォーマットを示す図である。
【図２４】本発明の第６の実施例における連携制御処理の、要求判断処理の流れを示す図である。
【図２５】本発明を適用した制御システム構成の例を示す図である。
【図２６】本発明の第１の実施例において各機器が自機器情報を自発的に発信する場合の、環境認識処理の流れを示す図である。
【図２７】本発明の第２の実施例における現在位置情報の構成例を示す図である。
【図２８】本発明の第２の実施例における環境認識処理の、自機器情報及び位置情報配信処理の流れを示す図である。
【図２９】本発明の第２の実施例における環境認識処理の、周辺機器情報共有処理の流れを示す図である。
【図３０】本発明の第３の実施例においてシステムからの離脱機器を検出する場合の、処理間のデータフローの例を示す図である。
【図３１】本発明の第３の実施例において各機器の持つ処理プログラム間の連携を更新する場合の、処理間のデータフローの例を示す図である。
【図３２】本発明の第３の実施例における連携制御処理の、連携状態監視処理の流れを示す図である。
【図３３】本発明の第４の実施例における連携制御処理のポリシー受信処理の流れを示す図である。
【図３４】本発明の第５の実施例における連携制御処理の、連携更新処理の流れを示す図である。
【図３５】本発明の第１の実施例における環境認識処理の自機器情報返信処理の流れを示す図である。
【符号の説明】
101：機器、111：環境認識処理、112：通信処理、113：連携制御処理、114：処理プログラム、121：地図情報、122：プロファイル、123：環境管理テーブル、124：ポリシー、125：動的連携管理テーブル、131：センサ、132：外部入出力部
【発明の属する技術分野】
本発明は、制御機械または物に組み込まれたプロセッサを相互に連携させて動作させる分散システムに関する。その中でも特に、制御機械または物の移動や制御対象などの周辺環境の状態変化が継続的に発生する環境において、制御機械や物に接続されるかまたは制御機械や物に含まれ、相互にデータの送受信を行う機能と任意の実行する（例えば、プログラムを実行する機能とを持った）機器が、自身の置かれた物理的環境に関する情報を用いて相互に連携する場合や、該機器が現在どのような働きをしているかなどの動作に関する情報である状況に応じて局所的に連携するものに関する。
【０００２】
そして、本発明は、ビル・ホームオートメーションシステム、プラント制御や製造、物流などの社会システム、交通システムなどの制御システムに好適に適合しうる。
【０００３】
【従来の技術】
半導体の高性能高密度化に伴うダウンサイジングの進行に合わせ、計算能力を持つプロセッサは、もはや専用の計算機にのみ存在するのではなくなり、あらゆる機器に組み込まれつつある。さらにインターネットに代表されるように、これらの機器を介して計算機システムと通信を行う手段も整いつつある。このような通信機能を持った機器、または機器で利用する通信機能には、例えば「PHSで楽しむモバイルコンピューティング」(ISBN4-87188-532-1)にあるようなPHSがある。これは、端末間で音声通信を行うものである。端末間は、明示的に通信先端末のアドレスとなる番号をダイヤルすることで通信を確立する。また、ＰＨＳでは通信の切断は端末への切断命令により行われる。
【０００４】
また、ユーザの設定を省きつつ機器間で対応する処理プログラム間を連携させる技術として、例えば日経コンピュータ（1998年12月7日）P.P.86 - 101「Jiniのベールを剥ぐ」に示すような方法がある。本技術によると、各機器はネットワークに接続されると同時に自機器のIPアドレスをブロードキャストし、存在を知らせる。Lookupサーバがこれに応答し、機器よりLookupサーバに対して機器の仕様、ドライバが登録される。逆に機器側からはLookupサーバに登録されている機器を検索し、他の機器と処理を連携させることができる。本技術においては、Lookupサーバがネットワークに接続された機器の情報を一元管理しており、機器間の連携にはLookupサーバが必須となっている。連携先の機器を変更する場合は、Lookupサーバへ問い合わせ、他の連携相手を探索する必要がある。また、連携する機器の選択には機器の仕様が用いられており、Lookupサーバに登録されている情報が共有され、各機器より参照される。連携のために必要なドライバ・ソフトウェアなどもLookupサーバを介して取得される。
【０００５】
同様に複数の機器から連携する相手を検索し、連携する技術として、例えばIEEE Transaction Computer, Vol.C-29, No.12,pp.1104 - 1113「The Contract Net Protocol:High-level Communication and Control in a Distributed Problem Solver」に示すような方法がある。
【０００６】
【発明が解決しようとする課題】
上記のIEEEによる方法によると、連携先を探す側の機器が要求を出し、該要求を受信した機器は該要求を処理できるか否かを表す指標を返信する。該要求を送信した機器は、返信した指標を判断し、どの機器と連携するかを判断する。本技術においては、機器には要求に対する指標を見積もる能力が必要である。また、連携した後の機器の稼動状態変化や判断の指標の動的な変化については考慮されていない。プロセッサの小型化、高性能化により、専用の計算機のみでなく、従来計算機能を持たなかった機械や物にもプロセッサが埋め込まれつつある。一方、これらの機械や物は、その存在する環境においてそれぞれ制御対象や役割を持っており、制御対象や役割の変化に応じて移動されたり、買い替えによって入れ替えられたり、組み立てや分解によって構成を変化させたりする。また、処理内容を変えたり、ある目的を果たすために相互に連携することも必要となる。
【０００７】
上記従来技術は、計算機側での管理を主眼としており、機器間の構成を管理するためのサーバとなる機器か、連携する相手を検索するための共有伝送媒体を必要としていた。このため機器が連携するためには、相手となる機能を持つ機器をサーバを介して探す必要があるとともに、機器の移動や入れ替えに依存しないサーバを設置する必要があり、柔軟性の点で問題があった。機器またはその組み込まれた機械が連続稼動する環境においては、サーバ自身を入れ替えることも困難であり、技術進歩に追従してサーバ機を入れ替えたり、サーバ機のメンテナンスを行うことが困難であることも問題であった。また、機器が連携する範囲はサーバの管理する範囲に限られるため、サーバの管理領域を跨った範囲において機器間を連携させるために、サーバ間の連携機構または複数のサーバを統括する機構が必要であり、計算機システム側の機構が大規模化、複雑化してしまうという問題があった。こうした機構を設けない場合は、サーバ機の管理範囲を運用上の管理範囲に一致させておく必要があり、運用を見通して事前に設計することが大変困難であるといった問題があった。
【０００８】
連携する機器間の関係を構築するという観点では、上記従来技術は、地上局のようなサーバ機能を持ったサーバのうち近いサーバと通信するか、サーバより取得した相手機器の仕様を元にして連携相手を決定する。このため、連携するか否かの判断や、同種の機器の中から連携する機器を選択するといった判断は、機器の仕様といった静的情報に限られていた。機器の接続された制御対象や物においては、その置かれた場所や他の機器との相対的関係によって制御方法や役割、重要性が異なってくる。しかし、連携する機器間の関係を構築する際に考慮されておらず、運用上不便な位置関係にある機器を連携させたり、役に立たない機械を稼動させ続けたりするなどといった問題があった。これを回避するには人手による作業や定期的メンテナンスを必要としてしまい、目的とする利用者の手間削減を達成できないといった問題があった。
【０００９】
さらに、システムを構成する機器の構成や稼動状況、または環境の変化によって、システムの状況は時間と共に変化していくため、事前にどの範囲の機器を連携させて動作させればよいか予測できない場合も多い。このような不明瞭な状況については従来技術では考慮されておらず、利便性が達成できないといった問題もあった。
【００１０】
また、機器間での連携を保守するという観点では、上記従来技術は、サーバが機器の構成を管理しており、新たに連携可能となった機器はサーバに登録される。このため、ある機器と連携した後に、より条件のよい機器が連携可能となった場合でも、機器側で該更新を検出できないといった問題があった。更新を検出するためには、サーバ上の情報が更新されるのを待つとともに、サーバに定期的に問い合わせなければ該更新を検出することができないため、機器の数が多くなるとサーバに負荷が集中するといった問題があった。さらに、各機器の接続された制御対象や物の置かれた場所や状況の変化に応じて、その都度よりよい相手と連携するといったことは考慮されておらず、利便性の点で問題があった。
【００１１】
【課題を解決するための手段】
本発明は、上記問題点を鑑みてなされたもので、利用者に対する柔軟かつ木目細かな制御・サービスを提供するために、機器が、置かれた物理環境や周辺機器との関係を認識し、これを用いて相互に連携する相手を選択したり、自機器の稼動状態を変更できるようにすることを目的とする。また、自機器の置かれた環境や、他機器の置かれた環境及び状況を継続的に認識することで、各時点でよりよい機器と連携したり、稼動状態を変更したり、連携する相手を事前に決めることが困難な場合でも適切な相手機器と連携できるようにすることを目的とする。さらに、システムを構成する機器を管理するサーバに依存せず、各機器が各々局所的に、自機器及び相手機器の認識と、連携相手の判断を行えるようにすることを目的とする。
【００１２】
従来の技術として記載したＰＨＳは、新たに増えた端末や、システムから離脱した端末は、ユーザがシステム外で管理する必要があると本発明者が認識した。ここで、ＰＨＳの特徴として端末が現在置かれた位置が解る点があるが、地上局の制御に用いられるものである。また、通信先の制御は前述したような明示的ダイヤルによるため、端末の物理的な位置は用いられていない。この物理的な位置を用いることが本発明の特徴の1つである。
【００１３】
本発明の機器間協調制御システム及び装置は、上記目的を達成するために、各機器が、
機器の置かれた物理的位置などの環境に関する情報と、
機器の行う動作、働きに関する情報である状況と、
を用いて、連携する相手機器や自機器の動作状態である稼動状態を変更するようにするものである。
【００１４】
ここで、状況としては、機器が最終的に行うべきまたは行われるべき働きのうち、どこまで終了しているか、機器が行うべきまたは行われるべき働きと実際の動作についての相違点がないか、ある場合相違点の内容自身などが含まれる。
【００１５】
また、稼動状態としては、機器の処理プログラムの動作状態や処理プログラム以外による動作状態も含む。
【００１６】
また、環境や状況の変化に適応して各機器が連携できるようにするために、各機器が、
自機器の置かれた環境や状況に関する情報を検出して他の機器に通知することで、継続的に自機器又は他機器の置かれた環境や状況を認識するか、
連携動作の要求に対して実際に動作してみることで、各時点で連携可能かを自ら判断するようにして、連携する相手機器や自機器の稼動状態を変更できるようにしたものである。
【００１７】
さらに、このような適応を、システム構成を管理するサーバや伝送媒体に依存せず行えるようするために、各機器が局所的に認識及び判断するようにしたものである。
【００１８】
【発明の実施の形態】
以下に、本発明の実施の形態を説明する。特に、環境情報として機器の置かれた物理的位置や機器間の相対位置または部屋の壁など境界となるものを用いて、周辺機器を認識・判定する方法について以下の例を用いて説明する。
【００１９】
（１）機器が機器間の相対位置を測定することにより連携する周辺機器を認識・判定する方法
（２）認識した周辺機器情報を共有することにより周辺機器を認識・判定する方法
次に、機器のもつ処理プログラム構成やインタフェースなどの機能に関する情報や、機器の状況に関する情報を用いて、連携する周辺機器を選択する方法について、以下の例を用いて説明する。
【００２０】
（３）各機器が各々持つ該機器自身の機能に関する情報と、状況として該機器が処理を行えるか否かや負荷状態、または該機器の処理プログラムの処理結果や応答時間を用いて、連携する機器を選択する方法
（４）機器が各々持つ該機器自身の機能に関する情報と、環境情報である相対位置情報、及び該機器の状況に関する情報を用いて、連携する機器を判断する方法また、連携する機器を事前に決定せず、連携する機器間の関係を形成する方法について以下の例で説明する。
【００２１】
（５）連携可能な機器を連携させ、結果をフィードバックすることで状況に応じて連携する機器を選別する方法
（６）連携できるものから順次連携させていく方法
図１は、本発明を適用した機器の構成例である。機器101内の処理は、環境を認識し周辺に存在する機器を判断する環境認識処理111と、他の機器との間でのデータ送受信を行う通信処理112、各機器内の処理間での連携を判断及び制御する連携制御処理113、及び機器の制御を行う処理プログラム114から構成される。環境認識処理111は、センサ131を介して該機器の存在する環境情報を取得し、取得した環境情報に基づいて、該機器と周辺機器の位置関係を認識して連携制御処理113に渡す。ここで、センサ131は環境から情報を取得するのみでなく、周囲に情報発信して応答を受信するなどアクティブな情報取得が可能なものを用いることもできる。また、環境側の地図情報121を用いて自機器と周辺機器の関係を認識し、周辺機器を判断することもできる。本実施の形態では、環境認識において、センサ131から取得した情報のみを用いる場合や、通信処理112から取得した他の機器情報を用いる場合の実施の形態について説明しているが、他の方法で環境情報を取得し、認識してもよい。
【００２２】
認識した周辺機器情報は、環境管理テーブル123に格納される。連携制御処理113では、プロファイル122と、通信処理112より取得した他機器のプロファイルを照合し、ポリシー124に従って連携する相手となる機器及び処理を判断する。プロファイル122には、自機器の名称や種別といった自機器に関するデータ、及び自機器に存在する処理プログラムに関する情報が含まれており、各機器に存在する処理間で連携するかしないか、入出力データの関係により連携できるか否かなどを判断する元となる。実際に連携している相手機器や処理プログラムの情報は、動的連携管理テーブル125に格納される。処理プログラム114は、外部入出力部132を介して情報の入出力や機器の制御を行う。ここで、外部入出力装置とは、液晶パネルやキーボード、タッチパネル等のマンマシンインタフェ−スを介して機器上で実行される処理プログラム114の制御や出力値参照を行ったりする機能を有している。ただしこれは必須ではなく、外部入出力部を持たない機器もある。
【００２３】
図１７は、本発明を適用した住居システム構成の例を示す図である。住居内の機器システムの例を示している。住居の内の各機器は、映像・メディア用ネットワーク1711や、電灯線ネットワーク1712などの通信媒体をそれぞれ用いて相互に接続されている。各機器には、本発明を適用した機器1721が組み込まれ、または接続されており、計算機の管理範囲を越えて互いに連携する。連携する範囲は、住居全体（1701）、２階全体といったフロア毎（1702）、または特定の部屋毎（1703）のように物理的な境界に基づいて決めることができる。または、電力制御や映像音響制御といった目的毎に範囲を決めてもよい。また、連携する範囲を物理的な境界と目的別の両方の組合せで決めてもよい。例えば、特定の部屋の電力制御、としてもよい。このシステムにおいて、例えば冷蔵庫1731は、買い替えやメンテナンスのために冷蔵庫1732と入れ替えられる。
【００２４】
また、携帯電話1733は、利用者の移動に伴って移動する。このような環境への参入・離脱によって、住居やフロア、部屋といった範囲を構成する機器は動的に変化する。
【００２５】
図２５は、本発明を適用した制御システム構成の例を示す図である。部材1772を搬送車1771が搬送し、処理機械1773で処理するシステムの例である。各設備には本発明を適用した機器1721が組み込まれ、または接続されている。各設備は、ローカル・エリア・ネットワーク（1761）や、無線セル（1762）を管理する地上局を介して相互に接続されている。連携する範囲は、この例では工場全体（1751）、在庫領域（1752）、処理ライン１領域（1753）、処理ライン２領域（1754）といった、物理的かつ機能的な境界に基づいて形成されている。このシステムにおいて、例えば部材1772は、搬送により在庫領域1752への参入・離脱を行い、搬送車1771は、搬送に伴い在庫領域1752や処理ライン１、処理ライン２へ参入・離脱を繰り返す。また、ラインの改造などが発生すると処理ラインの位置や構成も変化する。このように、システムを構成する設備は動的に変化する。
【００２６】
（実施例１）
図２は、本発明の第１の実施例におけるシステム構成例を示す図である。部屋201内に機器211〜213が配置されている。ここで、機器212は赤外線などの光通信を用いて周囲の機器に対して存在確認信号を送信し（221）、本信号を受信した機器211及び機器213がこれに応答することで、周辺機器及びその配置を認識する。部屋201の壁は、機器間で送信、応答されるこれらの信号を遮断するため、部屋内の機器が周囲の機器として認識される。赤外線でなく例えば無線通信を用いた場合でも、電波遮断効果のある壁を用いることで、本実施例と同様の方法で部屋内の機器を周囲の機器として認識することができる。
【００２７】
図３は、本実施例における環境情報管理テーブルの構成例を示す図である。各レコードは、機器名311、機器種別312、相対位置313、及び更新時刻314で構成される。機器名311は認識された周辺機器の名称を格納するフィールドである。相対位置313は、自機器と周辺機器の相対位置関係を格納するフィールドである。更新時刻314には、該レコードの示す周辺機器を認識した最新時刻が格納される。
【００２８】
図４は、本実施例において、各機器が自ら周辺をスキャンして周辺機器を検出する場合の環境認識処理の流れを示す図である。本実施例における環境認識処理は、センサ131を介して周辺機器が存在するか問い合わせ（ステップ411）、返信を待つ（ステップ412）。ステップ412では、他の機器からの返信があるか、または事前に設定した時間内に返信が無い場合に次ステップへ移る。次ステップでは返信があったかどうかを判定し（ステップ413）、返信があった場合は、返信された機器の情報を環境管理テーブル123へ格納する（ステップ414）。ここで、相手機器が該機器の情報を返信する機能が無くセンサへの反応信号を返すのみで、問い合わせ元の機器からは何らかの機器が存在することしか検出できない場合でも、重複しない機器名称を割り当て機器名311に格納し、相対位置313に該機器からの方位及び信号強度から求めた相対距離を格納する。ステップ413において返信が無かった場合は、ステップ415へ移行する。
【００２９】
その後、周辺機器を検出するセンサの信号強度を変換し（ステップ415）、ステップ411〜ステップ415を繰り返す。信号強度が最大になるまで繰り返した後、信号強度を最小にリセットし（ステップ416）、方位を変更し（ステップ417）、ステップ411から本処理を繰り返す。なお、本実施例ではセンサの方位を変更しながら周辺機器を検出する例を示したが、全方位型のセンサを用いる場合はステップ417の方位変更は必ずしもなくともよい。この場合の相対位置には、該機器からの距離が格納される。
【００３０】
図３５は、本実施例における環境認識処理の、自機器情報返信処理の流れを示す図である。図４にて説明した処理へ応答する処理の流れを示している。本処理においては、センサからの反応を待ち（ステップ3511）、他の機器からの問い合わせ信号を受信すると自機器のプロファイル122より自機器の名称や種別を取得し（ステップ3512）、問い合わせ元の機器へ返信する（ステップ3513）。
【００３１】
図２６は、本実施例において各機器が自機器情報を自発的に発信する場合の、環境認識処理の流れを示す図である。本処理においては、センサからの反応を待ち（ステップ421）、受信した信号より送信元機器の情報を抽出し、環境管理テーブルへ格納する。その後、ステップ421へ戻る。
【００３２】
本実施例によれば、グローバルに機器の位置や相対距離を検出する手段がない中でも、各機器が機器同士の相対的位置関係を認識することが可能である。この相対位置を用いて、通信信号の強度や方向を制御してアドレスに変換することで、例えば信号が届く範囲である部屋のような範囲や、信号強度に対応して自機器から一定の距離にあるもの、一定の距離内または距離外にあるものなどのような限定した範囲の周辺機器を検出することが容易であり、システム全体で一意のアドレスを設定せずとも、連携する機器を判断することができる。また、専用のサーバ機を設置せずとも、機器同士で認識することが可能である。
【００３３】
（実施例２）
本発明の第２の実施例においては、認識した周辺機器情報を共有することにより、連携する相手を認識する場合の実施例について説明する。
【００３４】
図５は、本発明の第２の実施例におけるシステム構成を表す図である。搬送機械531は、搬送路541上を移動し、搬送物532を運搬する。搬送機械531には、本発明の実施例である搬送機械制御機器511が搭載されている。また搬送機械制御機器511では、環境情報を取得するセンサ131として、搬送路上での位置を測定するトラッキング装置521を用いている。また、搬送物532には、本発明の実施例である搬送物識別機器512が付けられており、さらにこれは環境情報を取得するセンサ131としてIDタグを用いている。ここで、IDタグ522にはセンシング機能は無く情報の格納のみが可能であるが、搬送機械によって置かれた際、搬送機械が現在位置情報を書き込むことで擬似的に位置センサの役割を果たすことができる。搬送機械制御機器511は無線による通信機能を持ち、一定距離内にある搬送物のIDタグ情報の読み書きを行うことができ、一定距離内の他搬送機械533に搭載された搬送機械制御機器513と通信する無線機能を有する。これらの無線通信は、障害物やノイズによって一時的に通信ができなくなる場合がある。
【００３５】
図６は、搬送機械制御機器511で保持している地図情報121の構成例を示す図である。各レコードは、ルート番号611、ポイント(From)612、絶対位置(From)613、ポイント(To)614、絶対位置(To)615で構成される。各レコードは搬送機械が通行可能な搬送路上に置かれたポイントと向きを表しており、ルート番号で識別される。ポイント(From)は出発点となる搬送路上のポイントで、絶対位置(From)はポイント(From)の絶対位置を格納する。ポイント(To)は到着点となる搬送路上のポイントで、絶対位置(To)はポイント(To)の絶対位置を格納する。
【００３６】
図２７は、搬送物識別機器512及び搬送機械制御機器511で保持している現在位置情報の構成例を示す図である。現在位置情報には、搬送機械または搬送物が現在存在する区間を示すルート番号635、該区間の近傍ポイントであるポイント(From)631、及びポイント(To)632、該区間において現在位置のポイント(From)からのオフセット633、及び絶対位置が格納されている。現在位置情報は、搬送機械制御機器511ではトラッキング装置521より、搬送物識別機器512では搬送した搬送機械より取得して格納される。
【００３７】
図７は、本実施例における環境認識処理の、周辺機器を検出する処理の流れを示す図である。本実施例における環境認識処理は、通信処理112より他機器から送信された該機器の情報及び位置情報を受信し（ステップ711）、自機器に保持している地図情報121を用いて照合する（ステップ712）。ステップ712においては、受信した機器の存在する位置及び自機器の位置を地図上で認識し、該機器が自機器の近傍に存在するか否かを判断する（ステップ713）。ここで、近傍に存在するとは、例えば本実施例における搬送機械側では、搬送機械の現在位置と同一のルート番号を持つ区間に存在するか否かで判断する。あるいは、IDタグのように送受信範囲が制限されるものを用いる場合は、受信した機器情報の送信元機器を近傍であると判断してもよい。ステップ713において近傍に存在した場合、該機器の情報及び位置情報を環境管理テーブルへ格納する（ステップ714）。なお環境管理テーブルは、例えば格納されたレコードの更新時刻314を周期的にチェックし、一定時間経過して更新されていない機器情報を削除することで、自機器の移動によって周辺機器でなくなった機器情報を更新することができる。
【００３８】
図２８は、本実施例における環境認識処理の、自機器情報及び位置情報配信処理の流れを示す図である。本処理においては、自機器の機器名311や機器種別312をプロファイルより取得し、センサ131より取得した位置情報と共に、通信処理を介して配信する（ステップ721）。その後指定時間待機し（ステップ722）、再度ステップ721の処理より繰り返す。または、単体のIDタグのように電源を持たず能動的に送信することが出来ない場合は、IDタグの読み書き装置よりチャージ波を送られたイベントに連動して送信を行ってもよい。
【００３９】
図２９は、本実施例における環境認識処理の、周辺機器情報共有処理の流れを示す図である。各機器のもつ環境管理テーブルは、周期的または環境管理テーブルが更新されたタイミングで通信媒体へブロードキャストすることで、他の機器へ通知される。本処理は受信した機器の処理の流れを示しており、他機器より送信された該機器の周辺機器情報を格納した環境管理テーブルを通信処理より取得し（ステップ731）、自機器の環境管理テーブルと照合して、更新する（ステップ732）。
【００４０】
本実施例においては、搬送機械の搬送路を地図情報として用いたが、GPS(Global Positioning System)のような位置検出機構を用いてもよい。また、カー・ナビゲーションシステムのような装置を用いて地図上での位置を検出してもよい。
【００４１】
本実施例によれば、機器が自律的に位置情報を発信し、各機器において該位置情報を用いて相対位置を判定することで、専用のサーバ機を設置せずとも、機器同士の相対的位置関係を認識し、連携する機器を認識することが可能である。また、連携する機器が互いに移動したり、連携する相手が事前に決まっていない場合でも、柔軟に連携相手を認識し判断することができる。
【００４２】
さらに、自機器の認識した周辺機器情報を、自機器より通信可能な媒体を通じて他機器へも通知することで、該周辺機器情報を受信した機器では、自律的に位置情報を発信する機能を有しない機器の情報も含めて、通信障害により検出できなかった周辺機器情報を補正したり、移動によって変化した周辺機器の情報を検出・更新することができる。
【００４３】
（実施例３）
本発明の第３の実施例においては、各機器の持つ機能に関する情報と状況に関する情報を用いて、機器間の連携を動的に制御する例について説明する。
【００４４】
図８（a）は、プロファイル122のうち自機器情報格納テーブルの構成例を示す図である。自機器情報格納テーブルは、機器名811、機器種別812、及び仕様813から構成される。機器名811は機器を一意に識別する名称を格納し、通信処理において宛先アドレスとして用いられる。機器種別812は、例えば搬送機械やテレビといった機器の種類を格納する補助的情報である。仕様813は、機器の型式や性能といった仕様を格納する。
【００４５】
図８（b）は、プロファイル122のうち、他機器の処理と連携可能な自機器内の処理構成格納テーブルの構成例を示す図である。各レコードは、処理名821、入力インタフェース822、出力インタフェース823、仕様824、ステータス825で構成される。処理名821は機器内の各処理を識別する名称を格納するフィールドである。該処理の外部インタフェースが、入力インタフェース822、及び出力インタフェース823に格納される。入力インタフェース822は、他の処理から該処理に対してコマンドまたはデータを渡すインタフェースである。
【００４６】
出力インタフェース823は、該処理より他処理に対して発行するコマンドまたはデータを渡すインタフェースである。これらのインタフェースは、例えば「Inside CORBA−CORBAとそのシステム開発への応用」(ISBN4-7561-2015-6)にあるようにIDL(Interface Definition Language)を用いて記述することで、インタフェース名や引数データを定義し、識別することが可能である。仕様824には、各処理の仕様が記述される。これには、例えば「XML入門」(ISBN4-532-14610-0)にあるようなXML(eXtensible Markup Language)などを用いて、複合的情報を構造化して格納することができる。ステータス825は各処理の状態を格納するフィールドで、異常や、該処理の制御対象機器の障害、高負荷といった状態の他、接続中の他機器、処理、接続中かまたは接続が切断された状態かといった接続状態などの情報が格納される。連携制御処理113は、この情報も用いて処理を連携させるか否か判断する。
【００４７】
以下、本実施例における処理間のおおまかなデータフローを説明する。
【００４８】
図１４は、本実施例においてシステムへの参入機器を検出する場合の、処理間のデータフローの例を示す図である。機器1402が参入し、機器1401がこれを検出する場合の例を示している。機器1402は、通信処理112を介して、周期的かつ自発的にHeartbeatメッセージを送信し（*1）、機器1401の通信処理112ではこれを受信し、既にHeartbeatメッセージを受信した機器か否かを判断し、新たに参入した機器であることを検出する（*2）。Heartbeatメッセージには、機器1402を特定する識別子や、送信周期が格納されている。新たに検出した機器である場合は、連携制御処理113において自機器のポリシーとのマッチングを行い（*3）、連携してもよい機器である場合はアプリケーションプロファイルとの照合処理へ移る。
【００４９】
図３０は、本実施例においてシステムからの離脱機器を検出する場合の、処理間のデータフローの例を示す図である。機器1402が離脱したことを、機器1401が検出する場合の例を示している。機器1402は、離脱する場合にShutdownメッセージを送信し（*1）、機器1401の通信処理はこれを受信して機器1402が離脱することを検出する。または、機器1401より周期的に送信されるHeartbeatメッセージが、該Heartbeatメッセージの送信周期に比例する一定期間受信できない場合に、タイムアウト処理により機器1402の離脱を検出する（*2）。機器1402の離脱を検出した後、連携制御処理113において、離脱した機器1402の処理プログラムと既に連携している処理プログラム114が存在する場合は、切断処理を行う（*3）。
【００５０】
図１５は、本実施例において各機器の持つ処理プログラム間を連携させる場合の、処理間のデータフローの例を示す図である。機器1402を認識した機器1401が、自機器内の処理プログラムと機器1402内の処理プログラムを連携させる場合に、機器1402内の処理プログラムの構成を取得し、機器1401内の処理の構成と照合して、相手となる処理を選択する（*1）。または機器1401内の処理の構成を機器1402へ送り、連携できる処理があるか照合させる。相手となりうる機器が複数ある場合は、同様に機器1403、機器1404との間でも同様の処理を行う。その後、連携する相手との間で接続を確立し、処理プログラム間を連携させる（*2）。
【００５１】
図３１は、本実施例において各機器の持つ処理プログラム間の連携を更新する場合の、処理間のデータフローの例を示す図である。機器の状態に変化が発生した場合は、機器1402は状態変化通知を送信し（*1）、機器1401はこれを受信して処理プログラム間の連携を更新するか判断する（*1）。ここで、状態変化とは処理プログラムの異常や、応答性などのような、連携する際に照合した条件が変化した場合などである。また、機器1402は、機器の負荷や、現在実行可能な処理プログラムや実行不可能な処理プログラムがあることを示す機器の状況などをポリシーとして保持しており、これに変化が生じた場合も通知する。機器1403、機器1404でも、機器1401の処理プログラムと連携している処理プログラムがある場合は同様である。その後、別の処理プログラムと連携する場合は、図１５において説明したような処理を行い、新たな相手と連携する。既存の連携を継続する場合も、連携する条件を更新する（*2）。さらに、これを自機器の処理プログラムに通知し、条件更新や接続の切断・再接続といった処理を行う（*3）。
【００５２】
図１６は、本実施例において位置情報を取得する場合のデータフローの例を示す図である。環境認識処理111を介して、センサ131として、GPSセンサ1611を用いた場合は、本発明の第２の実施例で説明したように、絶対位置情報や地図上での位置情報を取得する。
【００５３】
また、カードリーダ1612を用いた場合は、読み込んだカードの情報を用いて、読み込んだ時点での該カードとの相対位置情報を取得することができる。また通信媒体としてPHSのような位置情報の解かるものを用いた場合は、センサを設けずとも位置情報を得ることができる（*3）。このようにして得た自機器の情報や他機器の位置情報を元に、システム内での位置付けを常時更新する（*4）。
【００５４】
図９は、本実施例における連携制御処理113の、マッチング処理の流れを示す図である。本処理においては、自機器内処理又は他機器の状態変化イベントを待ち（ステップ911）、イベント受信時にいかなる種別の状態変化が発生したかを判定する（ステップ912）。本実施例においては、状態変化として他機器状態変化と自機器内状態変化の2種類の場合の処理の流れについて説明する。他機器状態変化とは、環境認識処理111において新たな周辺機器を検出した場合や、既に検出している機器の状態変化を意味する。自機器内状態変化とは、自機器内の処理の構成変化や状態変化であり、処理プログラム114からの障害通知を受け取ることや、オペレーティングシステムからの通知を監視することで検出できる。本実施例においては以上のような状態変化が発生した場合の例について説明するが、これ以外にも利用者からの明示的な指示などのような様々なイベントに対応してマッチング処理を行うことが可能である。
【００５５】
ステップ912において他機器の状態変化を検出した場合は、該機器よりポリシーを取得し、自機器のポリシーと照合し、連携するか、または連携を継続するかを判断する（ステップ914）。連携しない場合はステップ911へ戻り、イベント待ち状態となる。連携する場合は、該状態変化の発生した機器より受信した該機器のプロファイルを取得する（ステップ915）。なお、ステップ913において用いる該機器のポリシーや、ステップ915において取得する該機器のプロファイルは、問い合わせて取得してもよいし、各機器より周期的に発信させ、取得してもよい。または、例えば特願平８−２４９６１１にあるような方法を用いて、変更が発生したときのみ配信して複製してもよい。
【００５６】
ステップ912において自機器内状態変化を検出した場合は、プロファイル情報を更新する（ステップ916）。これらのステップにより新たに取得した最新の自機器、または他機器のプロファイルを照合し（ステップ917）、連携できるものがあるかどうか判断する（ステップ918）。連携できるものは、本実施例では一方の処理の出力インタフェースと、他方の処理の入力インタフェースが一致し、プロファイルのステータス情報825が両方の処理とも実行可能であるか否かで判断するものとする。連携できる処理がある場合は、動的連携管理テーブルに連携する処理の組み合わせを格納し、該処理間でデータ送受信できるよう処理間の連携処理を行う（ステップ919）。処理間連携処理には、例えば「Inside CORBA−CORBAとそのシステム開発への応用」(ISBN4-7561-2015-6)にあるように、データ受信側のオブジェクト・リファレンスをデータ送信側が取得するなどといった方法を用いて処理間をバインドする。どちらかの処理に異常がある場合は、処理間の接続を切り離す。
【００５７】
図３２は、本実施例における連携制御処理113の、連携状態監視処理の流れを示す図である。プロファイル情報は各機器より周期的に送信されており、このプロファイル情報を受信し（ステップ931）、自機器と連携している処理のステータスを確認する（ステップ932）。自機器内の処理と連携している処理に状況変化があるか判定し（ステップ933）、状況変化がある場合は図９にて説明したマッチング処理へ通知する（ステップ934）。ここで、状況変化には処理に異常が発生した場合の他、実施例４において示すように複数の機器または複数の処理から連携相手を選定する場合に、現在連携している相手より良い相手が検出された場合などである。
【００５８】
図１９は、本実施例における動的連携管理テーブル125の構成例を示す図である。各レコードは、目的識別子1911、連携先1912、自機器処理名・インタフェース名1913、連携状態1914で構成される。目的識別子1911は処理プログラム間を連携させる目的の識別子を格納し、本実施例においてはレコード番号が格納される。連携先1912は、連携している他機器の機器名、連携先処理名、及び該処理のインタフェース名が格納され、自機器処理名・インタフェース名1913に、連携している自機器の処理名、及びインタフェース名が格納される。連携状態1914は該レコードの示す処理プログラム間の連携状態を格納するもので、「連携中」「連携解除中」などといった接続状態と、処理応答時間などの性能値などが格納される。
【００５９】
図２１は、本実施例における連携制御処理の、連携先選択処理の流れを示す図である。処理プログラムからの要求を受け取り（ステップ2111）、動的連携管理テーブルより要求送信元の処理プログラムの該当するレコードを検索して、該要求を実行させる連携先相手を選択する（ステップ2112）。連携先相手は、環境管理テーブルより取得した相手機器との相対距離を用いて自機器に近いものを選択してもよいし、相手を特定せず全ての機器を選択し、処理させてもよい。また、この結果を次回以降の要求時に用いて、早く処理を終えるものを選択してもよい。例えば、通信状態や相手機器の負荷によって処理の応答性能は変化するため、このように複数の連携先を持ち、実行時に相手を選択することで、柔軟に他の機器と連携することができる。相手機器や自機器が移動する場合は、処理実行時に最も近い機器を選択して連携することもできる。その後処理要求を送信し（ステップ2113）、相手機器からの処理結果を取得する（ステップ2114）。評価結果を次回以降の相手選択に用いる場合は、これを動的連携管理テーブルに格納する。受け取った結果は処理プログラムへ返し（ステップ2115）、処理プログラムからの要求待ち状態に戻る。
【００６０】
実施例の方法によれば、各機器の置かれた環境情報と、各機器がローカルに管理する処理情報を用いて、各機器が局所的に照合することで、専用のサーバ機を設置せずとも、機器間での連携が可能である。また、各機器の処理状態に関する情報を用いて連携するか、あるいは連携を継続するか否かを、継続的に判断することで、連携する機器に状態変化が発生した場合でも、柔軟に他機器との間の連携を制御することができる。さらに、複数の連携先を持ち、実行時に相手を選択する、または複数の相手を実行させた処理結果を選択することで、より柔軟な連携を行うことができる。
【００６１】
（実施例４）
本発明の第４の実施例においては、環境情報である相対位置情報や自機器の状況に応じて連携する周辺機器及び処理を判断する方法の例として、機器間の相対位置と、サービスの締め切り時間を元に連携機器を判断する場合の例について説明する。
【００６２】
図１０は、本実施例におけるシステム構成の例を示す図である。本発明の機器は、搬送機械1011,1012、搬送物1021〜1023、及び処理機械1013に組み込みまたは接続されている。搬送機械1011,1012は、搬送路1031を通って、搬送物1021〜1023を置き場1041へ運搬するとともに、置き場1041より処理機械1013へ運搬する。また、搬送機械は同時に１つの搬送物しか運搬できない。ここで、搬送物1021〜1023は、置き場1041へ置かれてから処理機械1013で処理されるまでに時間の制限がある。
【００６３】
図１１（a）は、本実施例におけるポリシー124の自機器状況格納テーブルの構成例を示す図である。自機器現在状況1111には、処理プログラム114の処理結果に応じて、自機器の現在の状況が格納される。ここで、自機器状況とは、搬送機械側では、搬送中、空、予約中といった搬送機械の作業状況であり、搬送物側では搬送中、置き場中では処理期限までの余裕時間、処理中などといった状況のことである。
【００６４】
図１１（b）は、本実施例におけるポリシー124の認証機器テーブルの構成例を示す図である。各レコードは、連携機器名1121、及び連携機器種別1122で構成される。連携機器名1121には連携してもよい機器名が格納され、連携機器種別1122には連携してもよい機器種別が格納される。機器種別とは、本実施例においては搬送機械や搬送物、処理機械といった単位での識別子である。ここで連携機器名1121が空欄で連携機器種別1122に値が格納されているレコードは、当該種別の機器全てと連携してもよいことを意味する。本テーブルは、本発明の第３の実施例で説明した連携制御処理113の、ポリシー取得・照合処理913で用いられる。
【００６５】
図１１（c）は、本実施例におけるポリシー124のマッチングテーブルの構成例を示す図である。各レコードはマッチングの条件を示しており、自機器状況1131、優先度1132、連携機器名・種別1133、連携機器状況1134、及び連携機器選択条件1135で構成される。自機器状況1131は、自機器現在状況1111と照合して、本レコードを用いてマッチングを行うか否か判断するための条件となる。連携機器名・種別1133には、連携する相手の機器名または機器種別が格納され、連携機器状況1134には連携する相手の機器状況が格納される。優先度1132は、同一の自機器状況1131に対して複数のレコードが存在する場合に、どのレコードのマッチング条件を優先するかを判断するための番号である。連携機器選択条件1135は、連携先機器が複数ある場合に、連携する機器の数や、どの機器を選択するかに関する条件を格納する。
【００６６】
数に関しては、例えば１つ、最大2つなどである。どの機器を選択するかについては、例えば先に連携できたものを優先する、相対距離の近いものを優先するなどである。
【００６７】
図１２は、本実施例における連携制御処理113のマッチング処理の流れを示す図である。処理921は第３の実施例と同様の流れであり、イベント検出し、自機器または他機器のいずれに関するイベントの判定を行い、他機器に関するイベントの場合はポリシー照合処理を行う。本実施例における他機器の状態変化には、図１１（a）にて説明した各機器の現在状況が変化したことに関するイベントも含む。他機器に関するイベントである場合はプロファイルを取得し、照合する（ステップ911〜917）。照合の結果、連携できるものがある場合は（ステップ918）、ポリシー124より自機器現在状況を取得し（ステップ1211）、イベントの発生した他機器の状況を、図１１（c）にて説明したポリシーのマッチングテーブルを用いて照合する（ステップ1212）。マッチング条件を満たした場合は、既に連携している機器と比較し、連携先を変更するか否かを判断する（ステップ1213）。ここで、連携先の比較には、ポリシーのマッチングテーブルに格納された連携機器選択条件1135を用いる。
【００６８】
連携機器選択条件に基づき、連携先機器を追加するか、変更するかを判断する。この判断に基づき、機器の処理を新たにバインドしたり、変更する場合は既存の接続を解除し、選択した処理との間で新たに接続を確立する。
【００６９】
なお、本実施例においては自機器または他機器に関するイベントで駆動される処理の例を示したが、自機器または他機器に関するイベントを格納しておき、周期的に処理を行ってもよい。また、本実施例では、他機器に変化が検出される度に連携を変更するか判断しているが、複数の機器に関するイベントを複数待った後に判断してもよい。
【００７０】
図３３は、本実施例における連携制御処理113の、ポリシー受信処理の流れを示す図である。ポリシー情報は各機器より周期的、または状況変化時に送信されており、これを受信し、該機器の自機器現在状況を取得する（ステップ1221）。図１２にて説明したマッチング処理へ通知する（ステップ1222）。
【００７１】
図１３は、本実施例における各機器の状況変化のタイムチャート例を示す図である。タイムチャート1311〜1315は、それぞれ搬送機械１、搬送物１〜３、及び搬送機械２の状況の遷移を表しており、上から下へいくにつれ時間が経過していることを示している。搬送物1は、搬送機械で空いている搬送機械１を使う予定であり予約する（ステップ1321）。予約は、搬送物１と連携した搬送機械１の処理プログラム114が、ポリシー124の自機器現在状況を更新することで「予約中」状態とする。その後、搬送機械２が処理装置への搬送を終えて「空」状態となり（ステップ1322）、搬送物１〜３では該ポリシーの変化を検出し、搬送機械２においても搬送物１〜３の状況を受信し、図１２及び図３３にて説明したマッチング処理を行う（ステップ1323）。
【００７２】
ここで、搬送物１〜３では、連携機器選択条件1135として相対距離を用い、より近い搬送機械２と連携する。一方搬送機械２では、本実施例のマッチング処理では先に状況を受信できたものからマッチング処理を行って連携するが、連携機器選択条件1135として処理期限を用い、期限の短い搬送物１が最終的に選択され、搬送機械２の状況が「予約中」となる（ステップ1324）。これにより搬送物１と搬送機械１の連携は切断され、搬送機械１の状況が、搬送機械１内の処理プログラムによって「空」に変更される（ステップ1325）。この後は、ステップ1323〜ステップ1324と同様の処理の流れによって、搬送物２と搬送機械１との間で連携し、搬送機械１の状況が「予約中」となる（ステップ1326）。
【００７３】
本実施例の方法によれば、手動設定や、また専用のサーバ機の設置がなくとも、機器間での連携が可能である。さらに、各機器の状況や環境に関する情報を用いて継続的に判断することで、システム全体としての状況や構成が、機器の移動や稼動状態変化により時間とともに変化する環境においても、各時点で、柔軟によりよい他機器との間の連携を制御することができる。
【００７４】
また、本実施例では搬送物の処理装置への運搬という例を示したが、搬送物の回収といった目的及び期限の異なる処理も含めて連携して行う場合でも、本実施例の方法を用いることで、機器毎に各時点で柔軟に連携することができる。例えば、タイマ録画/録音機能を持つAV機器のタイマ機能に障害が発生した場合に、同一住居内にあるコンピュータや電話機のような他の機器のタイマ機能と連携させて動作させるといった再構成を行うことができる。
【００７５】
（実施例５）
本発明の第５の実施例では、機器が連携する相手を事前に決められない場合に、各機器が実際に動作し、動作結果をフィードバックすることで機器間の連携関係を形成する場合の例について説明する。
【００７６】
図１８は、本実施例におけるシステム構成の概念を示す図である。複数の機器が存在し（1813）、ユーザの要求1811に基づいて処理プログラム間を連携させ（1812）、動作する。本実施例においては、これらの機器はユーザ1851にとっての目的である「省エネルギー運転(Less Energy)」1821、及び「娯楽(Enjoy)」1822に基づいて、連携する範囲であるBalancingグループ1831、及びCoordinatingグループ1832を形成し、互いに連携して動作する。グループに属する単位は、機器毎の処理プログラムの他、Sound Ctl(1833)に示すように、複数の機器が纏まって動作する場合はこの単位で連携動作することもできる。各機器は、相互に自分の状況を発信して（1841）動作する。また、試行的に動作することで（1824）、該グループに影響の小さい機器との関係を切断し、影響の大きい機器だけでグループを形成したりする。
【００７７】
本実施例における動的連携管理テーブル125の構成例を説明する。目的識別子1911には処理プログラム間を連携させる目的の識別子を格納し、本実施例においては「省エネルギー運転(Less Energy)」や「娯楽(Enjoy)」といった識別子が格納される。連携先1912には、該目的のために連携している他機器の機器名、連携先処理名、及び該処理のインタフェース名が格納され、自機器処理名・インタフェース名1913に、連携している自機器の処理名、及びインタフェース名が格納される。連携状態1914には該レコードの示す処理プログラム間の連携状態を格納し、「連携中」「連携解除中」などといった状態が格納される。
【００７８】
図２０は、本実施例における連携制御処理113の、要求判断処理の流れを示す図である。本処理は、他の機器やユーザから送信された動作要求イベントを待ち（ステップ2011）、自機器内の処理プログラムで受信した要求に対応して動作できるものがあるか判定する（ステップ2012）。本実施例においては、要求は処理プログラムのインタフェースの形で受信するものとする。例えば「省エネルギー運転」といった目的には「省エネルギーモード設定」などのインタフェースで要求される。無論、該要求を受信した機器側で、受信した要求を解釈してインタフェースに変換するフィルタを設けて処理してもよい。例えば、照明機器の処理プログラムに「省エネルギーモード設定」というインタフェースが無いが、「電灯の半数を消す」というインタフェースがある場合に、これらをマッピングするフィルタなどである。
【００７９】
次に、ステップ2012の結果を判定し（ステップ2013）、自機器に動作可能な処理プログラムがある場合は、該処理プログラムを実行し（ステップ2014）、要求及び要求元機器名、処理プログラム名及びインタフェース名、自機器処理名及びインタフェース名を図１９にて説明した動的連携管理テーブルに格納する（ステップ2015）。
【００８０】
このような機構を用いて、連携動作させる機器が事前に解らない場合でも、本実施例の方法を用いて各機器を試行的に動作させることで、動的に連携相手を探索することができる。動作の結果が不十分または目標を超過した場合は、当該部分を微調整することで目的を達成できる。例えば図１８の例では、「娯楽」という目的に対して動作した機器のうち、不要な掃除機を停止させる、などといった調整である。
【００８１】
図３４は、本実施例における連携制御処理113の、連携更新処理の流れを示す図である。本処理は、処理プログラムを試行した後起動され、処理プログラムの試行結果を取得する（ステップ2021）。ここで結果情報は、通信処理を介して要求を送信した機器より、またはセンサを介して直接取得するものとする。次に試行した自機器内処理の寄与率を判定し（ステップ2022）、該連携を継続するか否か判定する（ステップ2023）。ここで寄与率とは、目的に対する自機器内処理の影響度合いのことであり、例えば「省エネルギー運転」という目標に対しては、自機器内処理の試行により削減された消費電力量の、全体消費電力量に対する割合がこれにあたる。寄与率が解からない場合は、連携を継続する。継続の判定には、例えば「10％以下は寄与しない」といった定数値との比較や、目標量を達成するための閾値を動的に計算するなど、種々のアルゴリズムを用いることができる。
【００８２】
ステップ2023において継続すると判定した場合は連携したままにする、または無効化された連携を有効にし（ステップ2024）、継続しないと判定した場合は連携を無効化し、処理の試行を停止する（ステップ2025）。その後、本処理を繰り返す。
【００８３】
本実施例に示したようなフィードバック処理を含めることで、図２０で説明した連携関係を、環境の状況変化に適応させてメンテナンスすることができる。例えば住居システムにおいては、食事の準備時か、昼間の人が少ないときか、夜の家族の団欒時か、などのように時間によって稼動する機器が変化するため、「省エネルギー運転」も時間によって稼動させるべき機器が変化する。また、照明機器も朝、昼、夜と周囲の環境変化に連動して稼動すべきか否かが変化する。省エネルギー運転の要求があった場合、動作中の機器で連携を取り、または各機器が要求を解釈して、最も消費電力の大きなものをＯＦＦにする制御をしてもよい。また、運転に対する優先度に基づいて、優先度の小さいものからＯＦＦにする制御を行ってもよい。例えば、予約録画で録画中のビデオの優先度は高く、人間のいない部屋での電灯の点灯の優先度は低くする、としてもよい。なお、省エネルギー運転では、OFFにする制御でなく、機器の消費電力を抑える制御としてもよい。例えば、テレビやラジオの音量を下げる、電灯の明るさを下げるなどの制御でもよい。
【００８４】
また、本発明の構成では、照度センサと照明が互いにデータを交換してフィードバック制御を行える。照度センサで測定した照度が、その部屋に人がいないのにも関わらず高い場合は、照度を下げる、などの制御が可能になる。また、動作開始の要求があった場合、例えば帰宅した際に、玄関に設置された動作開始のボタンを押すと、センサと連動して帰宅者が移動している廊下、部屋の電灯を点灯するよう制御してもよい。また、通過した後は消灯してもよい。本実施例で示した処理を継続的に用いることで、このような環境変化に適応しながら機器を連携動作させることが可能となる。
【００８５】
（実施例６）
本発明の第６の実施例では、機器が連携する相手を事前に決められない場合に、連携できる機器から順次連携していくことで、機器間の連携関係を形成する場合の例について説明する。
【００８６】
図２２は、本発明の第６の実施におけるシステム構成例を表す図である。住宅内のシステム構成例を示しており、部屋2201〜2203から構成されている。部屋2201には、無線2221で相互に通信できるチューナー2231、ビデオ2232、テレビ2233と、Universal Serial Bus(USB)2223で相互に接続されたパソコン2239、スピーカー2240，2341、外部記憶装置2242が存在している。部屋2202には冷蔵庫2234、電子レンジ2235、照明2236などが電灯線2222で接続され、部屋2203にはエアコン2237、照明2238などが同様に電灯線2222で接続されている。テレビ2223は無線2221と電灯線2222のゲートウェイとなっており、同様にパソコン2239は電灯線2222とUSB2223のゲートウェイとなっている。部屋2201のAV機器2231〜2233はユーザ2211が使用しており、部屋2202の機器2234〜2236はユーザ2212が制御している。住宅内にはこのように多数の機器が各種の伝送媒体を用いて接続されている。
【００８７】
本実施例では、このような多数の機器を含むシステム構成を、ユーザが詳細に知らずとも制御する方法の例について説明する。例えば、第５の実施例で説明した「省エネルギー運転」のようにどの機器が要求時点で縮退運転できるか解からない場合や、「AV機器のリモコンからのパソコンに接続したスピーカー制御」を行う場合のように、システム構成が複雑な場合などである。
【００８８】
図２３は、本実施例における要求メッセージのフォーマットを表す図である。メッセージは、通信ヘッダ2311、相手範囲2312、目的識別子2313、目標パラメータ2314と目標値2315及び現在実力2316の組み合わせである目標2321で構成される。通信ヘッダ2311は通信処理で用いるヘッダで、送信元機器のアドレスや宛先機器アドレス情報、ブロードキャストアドレスなどの情報が格納される。相手範囲2312は該要求を受け取ってほしい相手機器の範囲を示す識別子が格納される。
【００８９】
例えばネットワーク上の同一セグメントであったり、同一の部屋、建物といった識別子である。目的識別子2313はリレーされる要求を表す識別子で、本発明の第５の実施例で説明したものと同様に機器内の処理のインタフェースにマッピングされるものである。目標2321に格納される目標パラメータ2314は該要求の目標とするパラメータの識別子で、例えば「電力」、目標値2315は該パラメータの目標値で、例えば「100W」、現在実力2316は該要求リレー時に達成された目標量で、例えば「30W」が格納される。スピーカー制御のようなオン・オフ制御の場合は、目標パラメータ2314には「スピーカ台数」、目標値2315には「２台」、現在実力2316には例えば「0台」が格納される。
【００９０】
図２４は、本実施例における連携制御処理113の、要求判断処理の流れを示す図である。本処理は、他の機器やユーザから送信された動作要求イベントを待ち（ステップ2411）、自機器内の処理プログラムで受信した要求に対応して動作できるものがあるか判定する（ステップ2412）。ここで動作できるものがあるかどうかの判断には、インタフェースの合うものがあるかの判断の他に、機器の負荷や、他により優先度の高い処理が稼動していないかなどを含めて統合的に判断する。同種の機器の数が非常に多い場合は、各機器が意図的に、かつランダムにダミープログラムを実行させて処理負荷を上げることで敢えて動作しないようにし、多数の機器間での負荷を分散して、将来の不測の事態に対応できるようシステムに余裕を持たせておくこともできる。
【００９１】
次に、ステップ2412の結果を判定し（ステップ2413）、自機器に動作可能な処理プログラムがない場合はステップ2416へ移る。ある場合は、該処理プログラムを実行し（ステップ2414）、要求及び要求元機器名、処理プログラム名及びインタフェース名、自機器処理名及びインタフェース名を図１９にて説明した動的連携管理テーブルに格納する（ステップ2415）。
【００９２】
その後、処理プログラムを実行した結果を、受信した要求メッセージの対応する目標パラメータの現在実力に反映する（ステップ2416）。反映する値は、USBのように機器へ順番にメッセージが伝送される媒体から受信した要求メッセージの場合は、自機器の処理結果を反映し、無線のようにブロードキャストにより受信した要求メッセージの場合は、該媒体における機器の処理結果を統合して反映する。反映する値は、各機器単独の結果である場合は積算して反映し、総合した結果である場合は該値を上書きすることで反映する。例えば、「省エネルギー運転」という要求に対する目標パラメータ「電力」の現在実力の場合は、各機器の動作を変更することにより節約された電力を積算していき、「スピーカ制御」という要求に対する目標パラメータ「スピーカ台数」の現在実力の場合は、処理できるか否かを判断する。
【００９３】
現在実力を反映した後、要求メッセージの目標値を満たしたか判断し（ステップ2417）、満たした場合はイベント待ちに戻る。満たしていない場合、要求メッセージを転送するか否かを判断し（ステップ2418）、転送する場合は、ステップ2416において更新した要求メッセージを転送する（ステップ2419）。ここで、転送するか否かの判断は、USBのようにシリアルに通信を行う場合は次の相手が居るか否かで判断する。無線のように並列型の伝送媒体を用いている場合は、自機器が要求メッセージを受信した伝送媒体と別の伝送媒体に接続されているかで判断する。上記の判断に加え、要求メッセージに指定された相手範囲が転送先でも有効か否かを判断することで、要求メッセージを転送するか決定する。
【００９４】
本実施例によれば、連携動作させる機器が事前に決定できない場合でも、各機器が自機器の機能や能力、状況を局所的に判断し、連携できるものから順次動作することで、動的に状況にあった連携を行うことができる。各機器の持つ機能や状況をシステム全体として共有せずとも、局所的な動作によって目的を達成することができる。また機器の数が多い場合でも、特定の機器を指定して制御せずとも、１回の要求で適当な機器を動作させることが可能である。
【００９５】
【発明の効果】
本発明によれば、各機器が、自機器の置かれた環境や状況に応じて、連携する他の機器や自機器の稼動状態を判断し変更することができるため、柔軟かつ木目細かな制御・サービスを行うことができる。
【００９６】
また、各機器が自機器の置かれた環境情報や自機器の状況を自ら通知し、継続的に判断を行うことで、各時点でよりよい機器と連携したり、稼動状態を変更したり、連携する相手を事前に決めることが困難な場合でも適切な相手機器と連携できるという効果がある。連携する相手が不明な場合でも、各機器が動作してみることで結果をフィードバックしたり、結果に応じて動作要求を継続して行うことで、適切な相手機器と連携することができる。
【００９７】
さらに、このような判断を局所的に行うことで、システム構成を管理するサーバに依存せず行えるという効果がある。
【図面の簡単な説明】
【図１】本発明を適用した機器の構成例である。
【図２】本発明の第１の実施例におけるシステム構成例を示す図である。
【図３】本発明の第１の実施例における環境情報管理テーブルの構成例を示す図である。
【図４】本発明の第１の実施例における環境認識処理の周辺機器検出処理の流れを示す図である。
【図５】本発明の第２の実施例におけるシステム構成を表す図である。
【図６】本発明の第２の実施例における地図情報の構成例を示す図である。
【図７】本発明の第２の実施例における環境認識処理の、周辺機器検出処理の流れを示す図である。
【図８】本発明の第３の実施例におけるプロファイルの、自機器情報格納テーブルおよび他機器の処理と連携可能な自機器内の処理構成格納テーブルの構成例を示す図である。
【図９】本発明の第３の実施例における連携制御処理の、マッチング処理の流れを示す図である。
【図１０】本発明の第４の実施例におけるシステム構成の例を示す図である。
【図１１】本発明の第４の実施例におけるポリシーの自機器状況格納テーブル、認証機器テーブルおよびマッチングテーブルの構成例を示す図である。
【図１２】本発明の第４の実施例における連携制御処理のマッチング処理の流れを示す図である。
【図１３】本発明の第４の実施例における各機器の状況変化のタイムチャート例を示す図である。
【図１４】本発明の第３の実施例においてシステムへの参入機器を検出する場合の、処理間のデータフローの例を示す図である。
【図１５】本発明の第３の実施例において各機器の持つ処理プログラム間を連携させる場合の、処理間のデータフローの例を示す図である。
【図１６】本発明の第３の実施例において位置情報を取得する場合のデータフローの例を示す図である。
【図１７】本発明を適用した住居システム構成の例を示す図である。
【図１８】本発明の第５の実施例におけるシステム構成の概念を示す図である。
【図１９】本発明の第３の実施例における動的連携管理テーブルの構成例を示す図である。
【図２０】本発明の第５の実施例における連携制御処理の、要求判断処理の流れを示す図である。
【図２１】本発明の第３の実施例における連携制御処理の、連携先選択処理の流れを示す図である。
【図２２】本発明の第６の実施例におけるシステム構成例を示す図である。
【図２３】本発明の第６の実施例における要求メッセージのフォーマットを示す図である。
【図２４】本発明の第６の実施例における連携制御処理の、要求判断処理の流れを示す図である。
【図２５】本発明を適用した制御システム構成の例を示す図である。
【図２６】本発明の第１の実施例において各機器が自機器情報を自発的に発信する場合の、環境認識処理の流れを示す図である。
【図２７】本発明の第２の実施例における現在位置情報の構成例を示す図である。
【図２８】本発明の第２の実施例における環境認識処理の、自機器情報及び位置情報配信処理の流れを示す図である。
【図２９】本発明の第２の実施例における環境認識処理の、周辺機器情報共有処理の流れを示す図である。
【図３０】本発明の第３の実施例においてシステムからの離脱機器を検出する場合の、処理間のデータフローの例を示す図である。
【図３１】本発明の第３の実施例において各機器の持つ処理プログラム間の連携を更新する場合の、処理間のデータフローの例を示す図である。
【図３２】本発明の第３の実施例における連携制御処理の、連携状態監視処理の流れを示す図である。
【図３３】本発明の第４の実施例における連携制御処理のポリシー受信処理の流れを示す図である。
【図３４】本発明の第５の実施例における連携制御処理の、連携更新処理の流れを示す図である。
【図３５】本発明の第１の実施例における環境認識処理の自機器情報返信処理の流れを示す図である。
【符号の説明】
101：機器、111：環境認識処理、112：通信処理、113：連携制御処理、114：処理プログラム、121：地図情報、122：プロファイル、123：環境管理テーブル、124：ポリシー、125：動的連携管理テーブル、131：センサ、132：外部入出力部
Claims (8)
- 通信機能を有する複数の機器それぞれが、他の機器との通信を行って周辺機器を選択し処理を行う機器間協調制御方法において、
前記複数の機器それぞれが、前記周辺機器への処理を実行中であるか、前記周辺機器への処理を予約中であるか、いずれでもないかを示す自機器状況に関する情報、および前記周辺機器が被処理中であるか否かを示す周辺機器状況に関する情報を有し、
前記複数の機器それぞれが、周期的におよび前記自機器状況が変化した場合に他の機器に対して前記自機器状況に関する情報を送信し、
前記周辺機器への処理を実行中でない機器が、他の機器より前記他の機器の自機器状況に関する情報を受信した場合に、自機器の前記自機器状況に関する情報、受信した前記他の機器の自機器状況に関する情報、および前記周辺機器状況に関する情報に基づいて、前記周辺機器を処理対象として選択するか否かを決定し、
前記周辺機器への処理を実行中でない機器が、前記周辺機器を処理対象として選択する場合は、前記自機器状況に関する情報を前記周辺機器への処理を予約中であるとし、
前記周辺機器への処理を実行中でない機器が、自機器が処理を予約中であった前記周辺機器を前記他の機器が処理対象として選択した場合は、前記自機器状況に関する情報を前記周辺機器への処理の予約を解消とすることを特徴とする機器間協調制御方法。 - 請求項１に記載の機器間協調制御方法において、
前記周辺機器は、処理を施される期限を有し、
前記周辺機器状況に関する情報は、前記処理を施される期限に関する情報を含み、
前記複数の機器それぞれは、処理を施される期限が短い順に前記周辺機器を処理対象として選択することを特徴とする機器間協調制御方法。 - 請求項１または２記載の機器間協調制御方法において、
前記自機器状況に関する情報は、自機器の位置情報を含み、
前記周辺機器状況に関する情報は、前記周辺機器の位置情報を含み、
前記周辺機器への処理を実行中でない機器が、前記他の機器の自機器状況を受信した際、自機器と前記周辺機器との距離が前記他の機器と前記周辺機器との距離より小さい場合に前記周辺機器を処理対象として選択することを特徴とする機器間協調制御方法。 - 請求項１乃至３のいずれか１つに記載の機器間協調制御方法において、
前記周辺機器への処理とは、前記周辺機器の運搬であることを特徴とする機器間協調制御方法。 - 通信機能を有する複数の機器から構成され、前記複数の機器それぞれが、他の機器との通信を行って周辺機器を選択し処理を行う機器間協調制御システムにおいて、
前記複数の機器それぞれが、前記周辺機器への処理を実行中であるか、前記周辺機器への処理を予約中であるか、いずれでもないかを示す自機器状況に関する情報、および前記周辺機器が被処理中であるか否かを示す周辺機器状況に関する情報を有し、
前記複数の機器それぞれが、周期的におよび前記自機器状況が変化した場合に他の機器に対して前記自機器状況に関する情報を送信する手段を有し、
前記周辺機器への処理を実行中でない機器が、他の機器より前記他の機器の自機器状況に関する情報を受信した場合に、自機器の前記自機器状況に関する情報、受信した前記他の機器の自機器状況に関する情報、および前記周辺機器状況に関する情報に基づいて、前記周辺機器を処理対象として選択するか否かを決定する手段と、前記周辺機器を処理対象として選択する場合は、前記自機器状況に関する情報を前記周辺機器への処理を予約中であるとする手段と、自機器が処理を予約中であった前記周辺機器を前記他の機器が処理対象として選択した場合は、前記自機器状況に関する情報を前記周辺機器への処理の予約を 解消とする手段とを有することを特徴とする機器間協調制御システム。 - 請求項５に記載の機器間協調制御システムにおいて、
前記周辺機器は、処理を施される期限を有し、
前記周辺機器状況は、前記処理を施される期限に関する情報を含み、
前記複数の機器それぞれは、処理を施される期限が短い順に前記周辺機器を処理対象として選択することを特徴とする機器間協調制御システム。 - 請求項５または６記載の機器間協調制御システムにおいて、
前記自機器状況は、自機器の位置情報を含み、
前記周辺機器状況は、前記周辺機器の位置情報を含み、
前記周辺機器への処理を実行中でない機器が、前記他の機器の自機器状況を受信した際、自機器と前記周辺機器との距離が前記他の機器と前記周辺機器との距離より近い場合に前記周辺機器を処理対象とする機器として選択することを特徴とする機器間協調制御システム。 - 請求項５乃至７のいずれか１つに記載の機器間協調制御システムにおいて、
前記周辺機器への処理とは、前記周辺機器の運搬であることを特徴とする機器間協調制御システム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP32211599A JP4240695B2 (ja) | 1999-11-12 | 1999-11-12 | 機器間協調制御方法及びシステム |
| US09/650,138 US6983306B1 (en) | 1999-11-12 | 2000-08-29 | Inter-device cooperative control method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP32211599A JP4240695B2 (ja) | 1999-11-12 | 1999-11-12 | 機器間協調制御方法及びシステム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001145174A JP2001145174A (ja) | 2001-05-25 |
| JP4240695B2 true JP4240695B2 (ja) | 2009-03-18 |
Family
ID=18140097
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP32211599A Expired - Fee Related JP4240695B2 (ja) | 1999-11-12 | 1999-11-12 | 機器間協調制御方法及びシステム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6983306B1 (ja) |
| JP (1) | JP4240695B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8780391B2 (en) | 2010-09-09 | 2014-07-15 | Ricoh Company, Ltd. | Image processing apparatus and image processing system with processability determining unit |
Families Citing this family (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1435752A4 (en) * | 2001-10-11 | 2007-10-17 | Fujitsu Ltd | DEVICE FOR USE IN A SERVICE DELIVERY SYSTEM WITH INTEGRATED COMPONENTS IN AN AD HOC NETWORK |
| US20030217135A1 (en) * | 2002-05-17 | 2003-11-20 | Masayuki Chatani | Dynamic player management |
| US7603412B2 (en) * | 2002-06-17 | 2009-10-13 | Siemens Communications, Inc. | System and method for collaborating using instant messaging in multimedia telephony-over-LAN conferences |
| JP4123838B2 (ja) * | 2002-06-20 | 2008-07-23 | ダイキン工業株式会社 | 機器制御システム |
| JP2004192077A (ja) * | 2002-12-09 | 2004-07-08 | Hitachi Ltd | 分散システムおよびコンテキスト対応ブローカリング方法 |
| US7956766B2 (en) | 2003-01-06 | 2011-06-07 | Panasonic Corporation | Apparatus operating system |
| TWI277317B (en) | 2003-07-07 | 2007-03-21 | Hsiang-Tsung Kung | Methods and systems for operating a logical sensor network |
| JP4465598B2 (ja) | 2004-07-05 | 2010-05-19 | ソニー株式会社 | 集積回路およびその処理制御方法、並びに、プログラム |
| JP2006039685A (ja) * | 2004-07-22 | 2006-02-09 | Advanced Institute Of Information Technology Inc | 情報管理システム |
| KR100587563B1 (ko) | 2004-07-26 | 2006-06-08 | 삼성전자주식회사 | 상황인지 서비스를 제공하는 장치 및 방법 |
| US7984068B2 (en) * | 2007-05-25 | 2011-07-19 | Google Inc. | Providing profile information to partner content providers |
| JP5114123B2 (ja) | 2007-07-24 | 2013-01-09 | トヨタ自動車株式会社 | 車載装置制御システム |
| JP2009303014A (ja) * | 2008-06-16 | 2009-12-24 | Nippon Telegr & Teleph Corp <Ntt> | 制御装置、制御方法、制御プログラムおよび制御プログラムを記録した記録媒体 |
| US9516696B2 (en) * | 2011-11-29 | 2016-12-06 | Lenovo (Singapore) Pte. Ltd. | Context aware device disconnection |
| US9946273B2 (en) | 2012-11-15 | 2018-04-17 | Panasonic Intellectual Property Corporation Of America | Information providing method and information providing apparatus |
| CN103533706A (zh) * | 2013-09-25 | 2014-01-22 | 浙江生辉照明有限公司 | 无线led照明装置、无线照明控制系统及控制方法 |
| JP6180627B2 (ja) | 2014-05-19 | 2017-08-16 | 三菱電機株式会社 | 動作制御装置、動作制御方法、及び再生装置 |
| WO2016006138A1 (ja) | 2014-07-08 | 2016-01-14 | 三菱電機株式会社 | 前照灯モジュール及び前照灯装置 |
| CN105353729B (zh) * | 2014-08-21 | 2018-12-04 | 丰唐物联技术（深圳）有限公司 | 一种信息处理方法与控制设备 |
| JP6090511B1 (ja) * | 2016-05-06 | 2017-03-08 | 富士ゼロックス株式会社 | 端末装置及びプログラム |
| JP2018107487A (ja) * | 2016-12-22 | 2018-07-05 | ソニーセミコンダクタソリューションズ株式会社 | 情報送信装置、情報送信方法、および情報送信システム |
| CN108630131A (zh) * | 2017-12-05 | 2018-10-09 | 南京天朝机网络科技有限公司 | 一种机械设备标识装置 |
| CN112291290B (zh) * | 2019-07-25 | 2024-06-11 | 京东方科技集团股份有限公司 | 一种设备关联建立方法、装置及电子设备 |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6029188A (en) * | 1993-01-18 | 2000-02-22 | Institute For Personalized Information Environment | Information processing system for an architecture model capable of interfacing with humans and capable of being modified |
| US5906657A (en) * | 1996-07-01 | 1999-05-25 | Sun Microsystems, Inc. | System using position detector to determine location and orientation between computers to select information to be transferred via wireless medium |
| US6073176A (en) * | 1996-07-29 | 2000-06-06 | Cisco Technology, Inc. | Dynamic bidding protocol for conducting multilink sessions through different physical termination points |
| US6683538B1 (en) * | 1998-08-29 | 2004-01-27 | Robert D Wilkes, Jr. | Position dependent messaging system |
| US6414955B1 (en) * | 1999-03-23 | 2002-07-02 | Innovative Technology Licensing, Llc | Distributed topology learning method and apparatus for wireless networks |
| US6300904B1 (en) * | 1999-06-09 | 2001-10-09 | Honeywell International Inc. | Narrowband based navigation scheme |
-
1999
- 1999-11-12 JP JP32211599A patent/JP4240695B2/ja not_active Expired - Fee Related
-
2000
- 2000-08-29 US US09/650,138 patent/US6983306B1/en not_active Expired - Fee Related
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8780391B2 (en) | 2010-09-09 | 2014-07-15 | Ricoh Company, Ltd. | Image processing apparatus and image processing system with processability determining unit |
Also Published As
| Publication number | Publication date |
|---|---|
| JP2001145174A (ja) | 2001-05-25 |
| US6983306B1 (en) | 2006-01-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4240695B2 (ja) | 機器間協調制御方法及びシステム | |
| US20220239622A1 (en) | Efficient Network Stack for Wireless Application Protocols | |
| CN112340557B (zh) | 呼梯信息的处理方法、控制板和存储介质 | |
| KR102252258B1 (ko) | 홈 네트워크 시스템에서 홈 디바이스들의 그룹 제어 방법 및 장치 | |
| US20060190538A1 (en) | Method and apparatus for recognizing location of a home device using RFID | |
| US11849310B2 (en) | Synchronized reception in mesh networks | |
| JP6263303B1 (ja) | デバイス、装置、情報処理方法、情報処理システム及びプログラム | |
| CN110255306B (zh) | 呼梯方法、系统、装置、服务器和存储介质 | |
| US20180376336A1 (en) | Rf client for implementing a hyper distribution communications protocol and maintaining a decentralized, distributed database among radio nodes | |
| KR102650059B1 (ko) | 로봇 친화형 건물, 로봇 및 건물을 주행하는 멀티-로봇 제어 시스템 | |
| US20230015053A1 (en) | Linking system and linking control method | |
| US11343774B2 (en) | Enhanced frame pending | |
| KR20220097735A (ko) | 배송로봇을 이용한 무인 배송 시스템 | |
| US20220275555A1 (en) | Automatic laundry dispensing device in contact-free laundry service | |
| US11595226B1 (en) | Method and system for collecting sensor data in buildings | |
| JP3826735B2 (ja) | 分散システムによるサービス提供方法及び分散システムを構成する機器 | |
| Bello | Societal adoption problems of internet of things (IOT)-a study | |
| JP2005354247A (ja) | Ｃａｔｖネットワークを利用した無線タグ情報収集システム | |
| KR20120049453A (ko) | 유비쿼터스 지능형 공간에서 자율적 서비스 제공 장치 및 방법 | |
| US12114386B2 (en) | Building environmental sensor method and system for collecting data from same | |
| CN111314411A (zh) | 由地面处理设备和信号发送装置组成的系统及其运行方法 | |
| KR20140139986A (ko) | 게이트웨이 및 그 제어방법 | |
| KR102901803B1 (ko) | 대기 전력 절약 방법 및 이를 지원하는 전자 장치 | |
| Shavali et al. | Home Automation & Its Detection for Performing and Operation for Reducing Power | |
| CN115542751A (zh) | 友邻互助方法、服务器及计算机可读存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060309 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20060417 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20080404 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080408 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080606 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20081209 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20081222 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120109 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120109 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130109 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140109 Year of fee payment: 5 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313111 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| LAPS | Cancellation because of no payment of annual fees |