知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-04-04
(45)【発行日】2022-04-12
(54)【発明の名称】機器制御システム及びその方法
(51)【国際特許分類】
H04Q 9/00 20060101AFI20220405BHJP
【ＦＩ】
H04Q9/00 301C
【請求項の数】
12
(21)【出願番号】P 2018072961
(22)【出願日】2018-04-05
(65)【公開番号】P2019186667
(43)【公開日】2019-10-24
【審査請求日】2020-12-14
(73)【特許権者】
【識別番号】000233295
【氏名又は名称】株式会社日立情報通信エンジニアリング
(74)【代理人】
【識別番号】110001689
【氏名又は名称】青稜特許業務法人
(72)【発明者】
【氏名】淺原 彰規
(72)【発明者】
【氏名】佐藤 信夫
【審査官】安藤 一道
(56)【参考文献】
【文献】特開２０１１－０８９６８２（ＪＰ，Ａ）
【文献】特開２０１３－２３６５２０（ＪＰ，Ａ）
【文献】特開２０００－２２４６７０（ＪＰ，Ａ）
【文献】特開２０１７－０７６４３０（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｑ ９／００
(57)【特許請求の範囲】
【請求項1】
機器の制御を行う機器制御システムであって、利用者の操作に従って、移動物の位置と前記機器の制御を規定する制御要求を発行する制御要求発行部と、
前記制御要求発行部が発行する前記制御要求を基に、前記制御要求の前記移動物に関する条件が満たされるかの判定を行って、該制御要求の識別子を発する条件判定部を生成する判定計画生成部と、
前記判定計画生成部により生成される１又は複数の条件判定部と、
前記制御要求の前記識別子を受けて、該制御要求に規定された制御ルールに従って制御対象となる機器を特定し、該機器に対する制御手順に従う制御コマンドを機器へ転送する制御実行部を生成する実行計画生成部と、
前記実行計画生成部により生成される１又は複数の制御実行部と、
前記制御要求発行部から発行される前記制御要求を中継して、前記判定計画生成部及び前記実行計画生成部に転送する制御通信中継部を有し、
前記制御通信中継部は、通信トピックを一意に特定する識別子と、送付先となる前記判定計画生成部のアドレスと、を登録するサブスクライバ一覧を保持する
ことを特徴とする機器制御システム。
【請求項2】
前記制御要求発行部は、前記制御要求であることを示す所定のコードを含むトピック情報と、利用者によって指定される判定条件を含む条件記述と、前記機器の状態変更の内容を記述した結果記述とを有する前記制御要求を発行する請求項１に記載の機器制御システム。
【請求項3】
前記条件判定部は、複数の前記条件判定部を生成した場合、前記機器の制御を変更すべき条件を満たすと判定した前記条件判定部についてのみ、該条件判定部に関する情報を、前記制御通信中継部を介して前記制御実行部へ通知する請求項１に記載の機器制御システム。
【請求項4】
エリアを規定するエリア情報データと、前記機器の配置を規定する機器配置データを管理するレイアウトデータベースを有し、前記実行計画生成部は、前記制御要求により指定される制御データの記述に基づき、前記レイアウトデータベースを参照して、制御対象となる前記機器を特定し、
前記制御要求により指定される制御データの記述に基づき、前記機器ごとに特有の実行制御コマンドを生成する前記制御実行部を生成する
請求項２に記載の機器制御システム。
【請求項5】
機器の制御を行う機器制御システムであって、利用者の操作に従って、移動物の位置と前記機器の制御を規定する制御要求を発行する制御要求発行部と、
前記制御要求発行部が発行する前記制御要求を基に、前記制御要求の前記移動物に関する条件が満たされるかの判定を行って、該制御要求の識別子を発する条件判定部を生成する判定計画生成部と、
前記判定計画生成部により生成される１又は複数の条件判定部と、
前記制御要求の前記識別子を受けて、該制御要求に規定された制御ルールに従って制御対象となる機器を特定し、該機器に対する制御手順に従う制御コマンドを機器へ転送する制御実行部を生成する実行計画生成部と、
前記実行計画生成部により生成される１又は複数の制御実行部と、
エリアを規定するエリア情報データと、前記機器の配置を規定する機器配置データを管理するレイアウトデータベースと、
過去に取得された前記移動物の位置に関する計測結果を蓄積する計測結果データベースと、を有し、
前記条件判定部は、前記レイアウトデータベースを参照して前記判定を行い、
かつ該計測結果データベースを参照することで、前記移動物の位置の時間変化に関する制御要求に対応する条件を判定する、
ことを特徴とする機器制御システム。
【請求項6】
複数のセンサから得られる前記移動物に関する検知情報を受け取り、前記移動物の位置座標を推定する位置推定部と、前記位置推定部により特定された前記移動物の位置を記録する計測結果データベースと、を有し、
前記条件判定部は、前記計測結果データベースを参照して、前記移動物の位置に関する条件の判定を行う
請求項1に記載の機器制御システム。
【請求項7】
機器の制御を行う機器制御システムであって、利用者の操作に従って、移動物の位置と前記機器の制御を規定する制御要求を発行する制御要求発行部と、
前記制御要求発行部が発行する前記制御要求を基に、前記制御要求の前記移動物に関する条件が満たされるかの判定を行って、該制御要求の識別子を発する条件判定部を生成する判定計画生成部と、
前記判定計画生成部により生成される１又は複数の条件判定部と、
前記制御要求の前記識別子を受けて、該制御要求に規定された制御ルールに従って制御対象となる機器を特定し、該機器に対する制御手順に従う制御コマンドを機器へ転送する制御実行部を生成する実行計画生成部と、
前記実行計画生成部により生成される１又は複数の制御実行部と、
前記制御要求発行部からの制御要求を中継して、前記判定計画生成部及び前記実行計画生成部に転送する制御通信中継部を有し、
前記制御要求に応じて生成された、第１の条件判定部と第２の条件判定部とを有し、
前記制御要求に応じて生成された、第１の制御実行部と第２の制御実行部とを有し、
前記制御通信中継部は、前記移動物の位置データを前記第１の条件判定部と前記第２の条件判定部へ転送し、
前記第１の条件判定部と前記第２の条件判定部はそれぞれ、該位置データを用いて判定ルールに基づいて判定して、前記制御通信中継部を介して、対応する前記第１の制御実行部と前記第２の制御実行部へ判定結果を転送し、
前記第１の制御実行部と前記第２の制御実行部は、前記判定結果に応じて、前記制御コマンドおよび該制御コマンドの送付を特定する
ことを特徴とする機器制御システム。
【請求項8】
前記機器を統括する複数の制御統括部を有し、前記複数の制御統括部は、前記複数の制御実行部が発する複数の該制御コマンドの内容を確認して、前記機器への影響を調整する
請求項１に記載の機器制御システム。
【請求項9】
前記制御要求発行部は、前記制御要求ごとに、前記機器のレイアウトを示す図と、前記条件を入力する項目と、前記機器の制御の内容を入力する項目とを含む表示画面を表示し、前記表示画面からの入力に従って、前記制御要求を発行する
請求項２に記載の機器制御システム。
【請求項10】
機器の制御を行う機器制御システムであって、利用者の操作に従って、移動物の位置と前記機器の制御を規定する制御要求を発行する制御要求発行部と、
前記制御要求発行部が発行する前記制御要求を基に、前記制御要求の前記移動物に関する条件が満たされるかの判定を行って、該制御要求の識別子を発する条件判定部を生成する判定計画生成部と、
前記判定計画生成部により生成される１又は複数の条件判定部と、
前記制御要求の前記識別子を受けて、該制御要求に規定された制御ルールに従って制御対象となる機器を特定し、該機器に対する制御手順に従う制御コマンドを機器へ転送する制御実行部を生成する実行計画生成部と、
前記実行計画生成部により生成される１又は複数の制御実行部と、
前記機器の動作の良し悪しの評価の入力を受け付ける制御評価部を有し、
前記条件判定部または前記制御実行部が、前記制御ルールに現れる数値の一部ないし全部を所定の範囲でランダムに変更する手段と、
前記評価の対象となった前記の数値を特定する手段と、
前記評価の内容に応じて前記ランダムな変更の範囲を変更する手段と、を有する、
ことを特徴とする機器制御システム。
【請求項11】
機器の制御を行う機器制御方法であって、制御要求発行部が、利用者の操作に従って移動物の位置と前記機器の制御を規定する制御要求を発行する制御要求発行ステップと、
判定計画生成部が、前記制御要求発行ステップにより発行される前記制御要求を基に、該制御要求の識別子を持つ１又は複数の条件判定部を生成する判定計画生成ステップと、
前記判定計画生成ステップにより生成された前記１又は複数の条件判定部が、前記制御要求の前記移動物に関する条件が満たされるかの判定を行うステップと、
前記制御要求の前記識別子を受けて、該制御要求に規定された制御ルールに従って制御対象となる機器を特定した１又は複数の制御実行部を生成する実行計画生成ステップと、
前記実行計画生成ステップにより生成された前記１又は複数の制御実行部が、該機器に対する制御手順に従う制御コマンドを機器へ転送するステップと、
前記制御要求発行ステップから発行される前記制御要求を中継して、前記判定計画生成ステップ及び前記実行計画生成ステップに転送する制御通信中継ステップを有し、
前記制御通信中継ステップは、通信トピックを一意に特定する識別子と、送付先となる前記判定計画生成部のアドレスと、を登録するサブスクライバ一覧を保持する
ことを特徴とする機器制御方法。
【請求項12】
前記制御要求発行ステップは、前記制御要求であることを示す所定のコードを含むトピック情報と、利用者によって指定される判定条件を含む条件記述と、前記機器の状態変更の内容を記述した結果記述とを有する前記制御要求を発行する請求項１１に記載の機器制御方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、機器制御システム及びその方法に係り、特に移動物の検知情報を用いて機器を制御する機器制御システム及びその方法に関する。
【背景技術】
【0002】
センサによって人等の移動物を検知し、その検知情報（センサ情報）を用いて種々の機器を制御する技術が実用化されている。例えば、特許文献１には、制御ルールに基づいて電力消費機器を制御する、建物のフロア内における電気機器の制御シミュレートにおいて、消費電力削減のためにフロア内の人の位置を示すセンシング情報を用いる電力管理支援装置が開示されている。
【0003】
また、特許文献２には、精度の異なるセンサの計測結果に基づいて同一の移動物体の軌跡を精度よく判定する移動体計測システムにおいて、赤外レーザ光等を用いた装置で周囲をスキャンして周囲にある物体の位置を計測する装置を用いて人を検知する技術や、カメラの画像から顔の領域を抽出するなどして人を検知する技術が開示されている。
【先行技術文献】
【特許文献】
【0004】
【文献】特開２０１３－２３６５２０公報
【文献】特開２０１７－０４０５３０公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
特許文献１に開示された技術によれば、例えば人が密集してきた場合に自動的に冷房を稼動するなど、人にとって快適性の高い環境を維持することができる。しかし、人が密集した場合など、その精度が低い場合に誤作動を起こしてしまうことが想定される。特許文献２にて開示された技術では、レーザによる計測とカメラによる計測の結果を同時に用いて人の位置を推定できるため、より精度よく人の位置を計測できる。これを用いることで誤作動を低減することができる。
【0006】
しかし、実際に機器の動作は正確であっても、利用者の期待する動作と異なってしまうことがある。例えば、オフィスビル内の一角に新たな自動販売機が設置された結果その付近に以前よりも人が多く滞在するようになった場合、そこにいる人が検知されて、不要に冷房を稼動してしまう事態が考えられる。この例のように、設計時に想定された状況がその後変わってしまうことは頻繁にあり、それ以前のルールにしたがって制御を行うのが適切でないことが考えられる。
【0007】
そのような場合、制御ルールを変更することが考えられるが、機器に組み込まれた制御ルールを変更するには、機器に関する知識をもつ人員による、機器への設定変更の作業を要する。加えて、人を検知するセンサの動作と多数の機器の制御を連動させるとなると、制御ルールはきわめて複雑となり、設定変更には多大な時間を要する。
【0008】
更に、人の位置に関する設定には曖昧さがある。例えば、自動販売機の周囲２ｍ内に滞留している人を対象とすべきか、２．３ｍ内を対象とすべきか、或いは１．８ｍ内を対象とすべきか等々、その設定の妥当性は机上での判断が難しく、実際に機器を稼動するまでわからないことが多々ある。よって、たいていは仮の設定で機器を動作させてみて、その後問題がある場合には再度設定を行う、ということを繰り返さねばならない。
【0009】
このように、複雑な制御ルールを変更するには、実装作業に要する費用や時間の面で困難である。そのような状況下でのみ、単に機器の制御を停止するような運用をとることはできるが、そのような状況が頻繁に現れる用途では、人の検知と制御を複雑なルールで連動させることはその設定の不便さゆえ困難と考えられる。因みに、上記特許文献１及び２には、システムの運用開始後に機器制御の制御ルールを如何に変更するかについて具体的な言及はない。
【0010】
本発明目的は、システムの運用中でも機器の制御に関する設定変更を容易に行えるようにすることにある。
【課題を解決するための手段】
【0011】
本発明に係る機器制御システムの好ましい一側面は、
機器の制御を行う機器制御システムであって、
利用者の操作に従って、移動物の位置と前記機器の制御を規定する制御要求を発行する制御要求発行部と、
前記制御要求発行部が発行する前記制御要求を基に、前記制御要求の前記移動物に関する条件が満たされるかの判定を行って、該制御要求の識別子を発する条件判定部を生成する判定計画生成部と、
前記判定計画生成部により生成される１又は複数の条件判定部と、
前記制御要求の前記識別子を受けて、該制御要求に規定された制御ルールに従って制御対象となる機器を特定し、該機器に対する制御手順に従う制御コマンドを機器へ転送する制御実行部を生成する実行計画生成部と、
前実行計画生成部により生成される１又は複数の制御実行部と、を有する
ことを特徴とする機器制御システム、として構成される。
本発明はまた機器制御システムにおける機器制御方法として構成される。
機器の制御を行う機器制御システムであって、
利用者の操作に従って、移動物の位置と前記機器の制御を規定する制御要求を発行する制御要求発行部と、
前記制御要求発行部が発行する前記制御要求を基に、前記制御要求の前記移動物に関する条件が満たされるかの判定を行って、該制御要求の識別子を発する条件判定部を生成する判定計画生成部と、
前記判定計画生成部により生成される１又は複数の条件判定部と、
前記制御要求の前記識別子を受けて、該制御要求に規定された制御ルールに従って制御対象となる機器を特定し、該機器に対する制御手順に従う制御コマンドを機器へ転送する制御実行部を生成する実行計画生成部と、
前実行計画生成部により生成される１又は複数の制御実行部と、を有する
ことを特徴とする機器制御システム、として構成される。
本発明はまた機器制御システムにおける機器制御方法として構成される。
【発明の効果】
【0012】
本発明によれば、システムの運用中でも機器の制御に関する設定変更を容易に行うことができる。
【図面の簡単な説明】
【0013】
【図1】実施例１による機器制御システムの構成を示す図。
【図2】機器制御システムを構成する装置のハードウェア構成を示す図。
【図3】制御条件設定の流れを模式的に示す図。
【図4】機器制御の流れを模式的に示す図。
【図5】判定計画生成部104の制御条件設定のシーケンスを示す図。
【図6】判定計画生成部104の制御要求登録待受処理501のフローを示す図。
【図7】サブスクライブ登録メッセージ700のデータ構造を示す図。
【図8】サブスクライバ一覧800のデータ構造を示す図。
【図9】実行計画部105の制御要求登録待受処理502のフローを示す図。
【図10】制御要求発行処理503を示す図。
【図11】制御要求データ11のデータ構造を示す図。
【図12】レイアウトDB106のデータ構造を示す図。
【図13】制御要求発行処理503の例を概念的に示す図。
【図14】判定計画生成処理504および判定計画処理506のフローを示す図。
【図15】判定ルール1501の構造の例を示す図。
【図16】実行計画生成処理505および実行計画処理507を示す図。
【図17】実行制御コマンド1701のデータ構造を示す図。
【図18】機器制御のシーケンスを示す図。
【図19】位置推定処理1801のフローを示す図。
【図20】人の位置データ2001のデータ構造を示す図。
【図21】位置条件判定1802のフローを示す図。
【図22】過去位置データ2201のデータ項目を示す図。
【図23】位置判定結果データ2301のデータ構造を示す図。
【図24】制御実行1803のフローを示す図。
【図25】制御要求の発行のための画面表示を示す図。
【図26】実施例２による機器制御システムの構成を示す図。
【図27】実行計画生成処理の例を示す図。
【図28】制御評価シーケンスの例を示す図。
【図29】制御評価データのデータ構造の例を示す図。
【図30】実行計画評価処理の例を示す図。
【図31】制御条件を削除するシーケンスの例を示す図。
【発明を実施するための形態】
【0014】
以下、図面を参照して、本発明の実施形態について説明する。
【実施例1】
【0015】
図１は、一実施例による機器制御システムの構成を示す。
機器制御システム100は、端末測位システム112、カメラシステム113、レーザ計測システム114などのセンサシステムと、制御対象となる照明機器115や音響機器116が接続され、センサシステムから得られる検知情報を用いて、照明機器115や音響機器116を制御するシステムとして説明される。本実施例は、例えばオフィスやビルに適用されたセンサシステムが人などの移動物の存在を検知し、そのセンサ情報を用いて、オフィスの照明機器等を制御することを想定している。
機器制御システム100は、端末測位システム112、カメラシステム113、レーザ計測システム114などのセンサシステムと、制御対象となる照明機器115や音響機器116が接続され、センサシステムから得られる検知情報を用いて、照明機器115や音響機器116を制御するシステムとして説明される。本実施例は、例えばオフィスやビルに適用されたセンサシステムが人などの移動物の存在を検知し、そのセンサ情報を用いて、オフィスの照明機器等を制御することを想定している。
【0016】
端末測位システム112、カメラシステム113、レーザ計測システム114は、無線通信や可視光の画像、赤外線レーザの反射光の信号を公知の方法で処理して人の存在を検知する。なお、人を検知するセンサは他にも考えられるが、人とその位置を測定できるセンサであれば使用できる。（以下でこれらのシステム112,113,114を纏めて単にセンサということがある。）
照明機器115は照明の明るさや色を変更し、音響機器116は音を出力する、制御対象となる機器である。照明機器や音響機器以外にも、空調機器、自律移動する車両、液晶ディスプレイ、プロジェクタなど、人の位置に連動して制御する必然性のある機器であれば、制御対象とすることができる。
照明機器115は照明の明るさや色を変更し、音響機器116は音を出力する、制御対象となる機器である。照明機器や音響機器以外にも、空調機器、自律移動する車両、液晶ディスプレイ、プロジェクタなど、人の位置に連動して制御する必然性のある機器であれば、制御対象とすることができる。
【0017】
機器制御システム100は、機器の制御に関する制御要求等を含む種々の通信を中継する制御通信中継部101、人を検知するセンサからのデータを統合して人の位置を推定する位置推定部102、制御内容の設定及び変更に際して利用者（例えばシステム管理者）の操作を受け付けて制御要求を発行する制御要求発行部103、機器の状態変更の条件判定の計画を策定する判定計画生成部104、実際の制御の内容を策定する実行計画生成部105、オフィスや施設等の所定の領域内の壁や柱、及びそこに設置された机や機械等の静止物に関する位置の情報を保管するレイアウトデータベース（DBという）106、判定計画生成部104の指示によって生成され実際に条件の判定を行う条件判定部107、条件判定部107が条件判定用の情報を蓄積する計測結果DB108、実行計画生成部105の指示によって生成され実際に制御用のコマンド発行を行う制御実行部109、照明機器115へ制御コマンドを転送する照明制御統括部110、音響機器116へ制御コマンドを転送する音響制御統括部111、を有して構成される。なお、照明機器や音響機器以外にも制御対象の機器が在る場合には、その機器に対応する制御統括部を追加することができる。なお、本例では、制御通信中継部101は、実装の簡易化のためにPublisher-Subscriberアーキテクチャにもとづく通信、例えばMQTTプロトコルを用いているが、実装環境に合わせて適切な通信中継手段を用いることができる。
【0018】
図２は、機器制御システムを構成する各装置のハードウェア構成を示す。
レーザ計測システム 114は、レーザ光を発信するレーザ発振機201、レーザの反射光を読み取るレーザ受光器202、レーザの発振、受光にかかった時間等からレーザセンサ101の周囲の物体までの距離を求め点群データに変換する演算機（ＣＰＵ）203により構成される。
カメラシステム113は一般的なカメラを備えたシステムであり、イメージセンサ204によって可視光を画像として得て、演算装置（ＣＰＵ）203により画像の中から人を検知してその位置を推定することができる装置である。
レーザ計測システム 114は、レーザ光を発信するレーザ発振機201、レーザの反射光を読み取るレーザ受光器202、レーザの発振、受光にかかった時間等からレーザセンサ101の周囲の物体までの距離を求め点群データに変換する演算機（ＣＰＵ）203により構成される。
カメラシステム113は一般的なカメラを備えたシステムであり、イメージセンサ204によって可視光を画像として得て、演算装置（ＣＰＵ）203により画像の中から人を検知してその位置を推定することができる装置である。
【0019】
端末測位システム112は、演算処理を行うプロセッサ205、高速に読み書きが可能な揮発性一時記憶領域であるＤＲＡＭ206、ＨＤＤやフラッシュメモリなど永続的な記憶手段である記憶装置207、人の操作を受け付ける入力装置208、現在の端末の状況を提示するためのモニタ209、無線通信を行うためのネットワークインタフェースカードである無線通信ボード210、端末の位置を特定するためのGPS受信機211を備えており、記憶装置207に記憶されたプログラムをプロセッサ205が実行すると、GPS受信機211を用いて自己の位置を推定して無線通信ボード210を経由して配信する。
【0020】
機器制御システム100は、演算性能を持ったプロセッサ205、高速に読み書きが可能な揮発性一時記憶領域であるＤＲＡＭ206、ＨＤＤやフラッシュメモリなどを利用した永続的な記憶領域である記憶装置207、人の操作を受け付ける入力装置208、情報を提示するためのモニタ209、通信を行うためのネットワークインタフェースカード(NIC)212を備える。プロセッサ205は記憶領域209に記憶されたプログラムを実行することによって、図１の制御通信中継部101、位置推定部102、制御要求発行部103、判定計画生成部104、実行計画生成部105、条件判定部107、制御実行部109、照明制御統括部110、音響制御統括部111の各機能を実現する。入力装置208及びモニタ209は制御要求発行部103を実現する。レイアウトDB106、計測結果DB108は記憶装置207に記憶して形成される。
【0021】
本実施例の特徴の一つは、利用者301の操作による制御要求発行部103からの要求に応じて、判定計画生成部104及び実行計画生成部105がそれぞれ、機器の制御を変更するための条件判定部107および制御実行部109を生成して、生成された条件判定部107および制御実行部109が、他の条件判定部107および制御実行部109とは独立的に動作して機器を制御することにある。これによって、機器制御システムの運用開始後（即ち運用中）でも自由かつ容易に位置と制御ルールを追加や削除等の変更ができ、機器が設置された現場の状況変化に適時に対応できる。
【0022】
次に、図３及び図４を参照して、位置と制御ルールの変更の設定、及び機器制御について説明する。図３は機器制御システムに制御要求を追加する制御条件設定の流れを示す。図４は実際に制御するための機器制御を実行するときの流れを示す。
【0023】
利用者301が制御の内容を変更したいとき、制御要求発行部103を用いて、「位置がどのような状況のときに」、「機器がどうなるようにするか」を指定して入力することができる。制御要求発行部103は、入力された制御要求をメッセージとして、制御通信中継部101を経由して判定計画生成部104および実行計画生成部105へ転送する。判定計画生成部104および実行計画生成部105はこの要求を解釈して具体的な動作コードを生成して、それを実行する条件判定部107、制御実行部109を生成して動作させる。
【0024】
この機器制御システムは、運用開始後でも利用者301の求めに応じて制御ルールを変更することができる。制御条件設定は利用者301の求めに応じて幾度も実行され得る。条件判定部107や制御実行部109は複数生成されてもよいように、スレッド処理を用いてそれぞれが独立した形で動作する。なお、スレッドの代わりに複数のコンピュータに分散して実行することで処理を高速化することもできる。
【0025】
図４は、制御条件設定で生成された条件判定部107、制御実行部109が実際に機器制御を実行するときの流れを示す。
機器制御では、端末測位システム112、カメラシステム113、レーザ計測システム114が送信した位置検知に関する情報が制御通信中継部101を経由して位置推定部102で受信されると、位置推定部102はそれらを組み合わせて人の位置を推定する。その結果は制御通信中継部101を経由して制御条件設定で生成された条件判定部107に配信される。
機器制御では、端末測位システム112、カメラシステム113、レーザ計測システム114が送信した位置検知に関する情報が制御通信中継部101を経由して位置推定部102で受信されると、位置推定部102はそれらを組み合わせて人の位置を推定する。その結果は制御通信中継部101を経由して制御条件設定で生成された条件判定部107に配信される。
【0026】
条件判定部107は、制御条件設定が複数回実行された時には複数生成される。そのうち制御を変更するべき条件を満たすと判断されたものを、制御通信中継部101を経由して対応する制御実行部109にその情報を通知する。制御実行部109は事前に生成済みの制御コマンドを照明制御統括部110と音響制御統括部111へ転送して、照明機器115、音響機器116を適切に動作させる。なお、本実施例ではそれぞれ制御連携中継部101を経由して各部の通信が行われているが、これは実装を容易にするためのものであり、通信回数を低減する目的で各部が直接通信するなどの形態としてもよい。
【0027】
【0028】
まず、制御条件設定の処理について説明する。
図５は制御条件設定のシーケンスを示す。制御条件設定では、例えば電源投入時などの動作開始時に、判定計画生成部104が制御要求登録待受設定処理501を実行し、実行計画生成部105が制御要求登録待受設定処理502を実行する。
図５は制御条件設定のシーケンスを示す。制御条件設定では、例えば電源投入時などの動作開始時に、判定計画生成部104が制御要求登録待受設定処理501を実行し、実行計画生成部105が制御要求登録待受設定処理502を実行する。
【0029】
ここで、図６～図９を参照して、制御要求登録待受設定処理501、502の詳細及びそれらの処理に使用されるメッセージ等のデータ構成について説明する。
図６は判定計画生成部104が実行する制御要求登録待受設定処理501の詳細を示す。制御要求登録待受設定処理501では、サブスクライブ登録メッセージ700に所定の制御要求のトピックID（例えば’operation_req’という文字列）、サブトピックIDにはワイルドカード（全てのサブトピックに適合することを示す記号）を設定し、制御通信中継部101へ転送する（601)。
図６は判定計画生成部104が実行する制御要求登録待受設定処理501の詳細を示す。制御要求登録待受設定処理501では、サブスクライブ登録メッセージ700に所定の制御要求のトピックID（例えば’operation_req’という文字列）、サブトピックIDにはワイルドカード（全てのサブトピックに適合することを示す記号）を設定し、制御通信中継部101へ転送する（601)。
【0030】
図７にサブスクライブ登録メッセージ700のデータ構造を示す。
制御通信中継部101は、Publisher-Subscriberアーキテクチャにもとづく動作をしており、サブスクライブ登録メッセージ700を受け取ると、受信トピックID702、受信サブトピックID703を参照して、登録者(この場合は判定計画生成部104)のIPアドレスを示す通信アドレス701を制御通信中継部101内で管理するサブスクライバ一覧800に登録する(602)。
制御通信中継部101は、Publisher-Subscriberアーキテクチャにもとづく動作をしており、サブスクライブ登録メッセージ700を受け取ると、受信トピックID702、受信サブトピックID703を参照して、登録者(この場合は判定計画生成部104)のIPアドレスを示す通信アドレス701を制御通信中継部101内で管理するサブスクライバ一覧800に登録する(602)。
【0031】
図８にサブスクライバ一覧800の構造を示す。
サブスクライバ一覧800は、トピックID802と、サブトピックID803に対応付けられて送付先となるアドレスの集合である送付先アドレス一覧804を登録して管理する。制御通信中継部101が、トピックIDが設定された配信メッセージを受け取ると、このサブスクライバ一覧800からトピックID802とサブトピックID803が一致するもの、およびトピックID802が一致してサブトピックID803にワイルドカードが指定されているものを選定し、一致したそれらのIDに対応する送付先アドレス一覧804に記載されている機器へその配信メッセージを転送する。制御要求登録待受設定処理501ではサブトピックIDにワイルドカードを指定しているので、判定計画生成部104は所定の制御要求のトピックIDが付与された配信メッセージを全て受け取ることができる。
サブスクライバ一覧800は、トピックID802と、サブトピックID803に対応付けられて送付先となるアドレスの集合である送付先アドレス一覧804を登録して管理する。制御通信中継部101が、トピックIDが設定された配信メッセージを受け取ると、このサブスクライバ一覧800からトピックID802とサブトピックID803が一致するもの、およびトピックID802が一致してサブトピックID803にワイルドカードが指定されているものを選定し、一致したそれらのIDに対応する送付先アドレス一覧804に記載されている機器へその配信メッセージを転送する。制御要求登録待受設定処理501ではサブトピックIDにワイルドカードを指定しているので、判定計画生成部104は所定の制御要求のトピックIDが付与された配信メッセージを全て受け取ることができる。
【0032】
同様にして、実行計画生成部105も制御要求登録待受設定処理502（図９参照）として、サブスクライブ登録メッセージ700に同じ制御要求のトピックIDとワイルとカードのサブトピックIDを設定して、制御通信中継部101へ転送する(901)。制御通信中継部101は同様にして制御要求サブスクライブ登録メッセージ700をサブスクライバ一覧800に登録する(902)。これにより実行計画生成部105も制御要求のトピックIDが付与された配信メッセージを受け取ることができるようになる。
【0033】
図５に戻り説明を続ける。制御要求登録待受設定処理501、502の後、利用者が制御内容を変更したいときには、制御要求発行部103を操作して制御要求発行処理503を実行する。
【0034】
図１０に制御要求発行処理503の詳細を示す。制御要求発行部103が、利用者による入力1001を受け取ると、その入力に応じた制御要求データ1101を生成する。
【0035】
ここで、図１１に示す、制御要求データ1101の構造を説明する。制御要求データ1101には、トピック情報1102と、制御を変更する位置に関する条件を記述した条件記述1103と、どのような状況を目指して制御すべきかを示す結果記述1104が含まれる。
トピック情報1102には、前述の制御要求であることを示すトピックID1105(’operation_req’)と、制御要求データを一意に識別できる要求IDであるサブトピックID1106が含まれる。ここで、要求IDは制御要求発行処理503が実行される度に連番で発行するなどの一意性を保つことが必要である。
条件記述1103には、利用者が指定した制御を変更する条件として、判定条件1107と、データ選択条件1108が含まれる。判定条件1107にはデータ選択条件1108で指定された範囲の位置に関する真偽の判定が可能な条件が記載されており、真のときに本要求の制御が実行される。この判定条件1107で「部屋内の人数が2人以上」などの空間情報に関連した条件も記述でき、その際にはレイアウトDB106を用いることができる。
トピック情報1102には、前述の制御要求であることを示すトピックID1105(’operation_req’)と、制御要求データを一意に識別できる要求IDであるサブトピックID1106が含まれる。ここで、要求IDは制御要求発行処理503が実行される度に連番で発行するなどの一意性を保つことが必要である。
条件記述1103には、利用者が指定した制御を変更する条件として、判定条件1107と、データ選択条件1108が含まれる。判定条件1107にはデータ選択条件1108で指定された範囲の位置に関する真偽の判定が可能な条件が記載されており、真のときに本要求の制御が実行される。この判定条件1107で「部屋内の人数が2人以上」などの空間情報に関連した条件も記述でき、その際にはレイアウトDB106を用いることができる。
【0036】
図１２にレイアウトDB106のエリア情報データ1201の構造の例を示す。
（Ａ）に示すエリア情報データ1201には、エリアを一意に識別するエリアID1202と、エリアの種類を示すエリア種別1203と、そして座標点列でエリアの形状を示すポリゴンを格納したエリア形状1204のデータが含まれる。これらのデータは条件の記述に利用される。
位置のデータがRDBMS(関係データベースシステム)に格納されていることを想定すると、条件記述1103の情報はSQL文を構築できる情報に相当し、select文の返り値が判定条件1107、from句とwhere句がデータ選択条件1108に対応する。
（Ａ）に示すエリア情報データ1201には、エリアを一意に識別するエリアID1202と、エリアの種類を示すエリア種別1203と、そして座標点列でエリアの形状を示すポリゴンを格納したエリア形状1204のデータが含まれる。これらのデータは条件の記述に利用される。
位置のデータがRDBMS(関係データベースシステム)に格納されていることを想定すると、条件記述1103の情報はSQL文を構築できる情報に相当し、select文の返り値が判定条件1107、from句とwhere句がデータ選択条件1108に対応する。
【0037】
例えば、
”select count(distinct pedestrian.id>2 from pedestrians, area where is inside (pedestrian. location, area. shape and area.id=2”
というSQL文を想定すると、” count(distinct pedestrian.id>2”は「pedestrian.idが2種類以上」つまり「2人以上」を表す判定条件1107であり、” from pedestrians, area where is inside (pedestrian. location, area. Shape) and area.id=2”は「位置の情報を格納した表pedestriansとエリア情報データを格納したareaを用いて、エリアIDを示すarea.idが２のエリアの形状area. shapeの内部に人の位置pedestrian. locationにあるもの」つまり「エリアID２のエリア内の人」というデータ選択条件1108に対応する。この例ではエリアID2のエリア内の人数が２人を越えたら、結果記述1104にあるように制御を変えることになる。
”select count(distinct pedestrian.id>2 from pedestrians, area where is inside (pedestrian. location, area. shape and area.id=2”
というSQL文を想定すると、” count(distinct pedestrian.id>2”は「pedestrian.idが2種類以上」つまり「2人以上」を表す判定条件1107であり、” from pedestrians, area where is inside (pedestrian. location, area. Shape) and area.id=2”は「位置の情報を格納した表pedestriansとエリア情報データを格納したareaを用いて、エリアIDを示すarea.idが２のエリアの形状area. shapeの内部に人の位置pedestrian. locationにあるもの」つまり「エリアID２のエリア内の人」というデータ選択条件1108に対応する。この例ではエリアID2のエリア内の人数が２人を越えたら、結果記述1104にあるように制御を変えることになる。
【0038】
結果記述1104には、どのように制御を変えるべきかを示す情報として、対象領域1109と、状態変更の種別1110と、状態の変更内容1111が含まれる。対象領域1109はエリア情報データ1201のエリアID1202を格納していて、そのエリアを対象にした制御が行われる。状態変更種別1110には、状態変更ないし割り込みの種別が記載される。ここに状態変更が指定された場合には、状態変更内容1111に記載の状態を維持するように制御が行われる。割り込みが指定された場合には、状態変更内容1111に記載の状態にした後、元の状態を維持するように制御される。例えば、照明に関して、状態変更種別1110に状態変更を指定し状態変更内容1111を「照度を最大の５０％」とすると、エリアID内の照度が最大の５０％程度になるように制御が行われる。一方、照明がついていないときに、状態変更種別1110に割り込みを指定し状態変更内容1111を「照度を最大の５０％」とすると、エリアID内の照度を一度最大の５０％程度になるようにして点灯した後、再び照明を消す処理が行われる。
【0039】
ここで図１０の説明に戻る。制御要求発行部103により生成された制御要求データ1101は、一度制御通信中継部101へ転送する(1003)。制御通信中継部1101は、制御要求データ1101のトピックID1105、サブトピックID1106を参照して、サブスクライバ一覧800に登録されているアドレス、すなわち判定計画生成部104と実行計画生成部105のアドレスを取得して(1004)、それぞれのアドレスへ送信する（1005）。これにより判定計画生成部104と実行計画生成部105は制御要求を受け取ることができる。
【0040】
ここで図１３を参照して、制御要求発行処理503の例について説明する。
図示の例では、対象領域は図示の矩形1301で表現されており、対象領域には棚1302がいくつか配置されている。これは倉庫内の棚を意味しており、倉庫内では棚間の通路を台車が移動する。移動の経路は棚の間にあり、図の左から右の方向1303と下から上の方向13041305がある。この経路の交差する領域で衝突事故がおきやすいと予想されるので、黒円1306で示された位置に設置された、衝突を警告する警告灯（照明機器の例）を点灯させることを考える。
図示の例では、対象領域は図示の矩形1301で表現されており、対象領域には棚1302がいくつか配置されている。これは倉庫内の棚を意味しており、倉庫内では棚間の通路を台車が移動する。移動の経路は棚の間にあり、図の左から右の方向1303と下から上の方向13041305がある。この経路の交差する領域で衝突事故がおきやすいと予想されるので、黒円1306で示された位置に設置された、衝突を警告する警告灯（照明機器の例）を点灯させることを考える。
【0041】
このとき、２つ交差点の領域1307、1308に人が進入したとき、これら領域1307,1308内にある警告灯を点灯するように制御するとする。そこで、領域1307と1308の情報をエリア情報データ1201に格納しておき、制御要求発行部103は、条件記述1103に「領域1307内の人の数が増えたか」、結果記述1104に「領域1307の警告灯を割り込みで点灯する」旨の記述をした制御要求データ1101を発行する。
【0042】
しかし、実際の施設の運用では、ある日に限り通路内の領域1309を占有する特殊作業が行われるようなことは十分想定される。このとき、上記のままの条件で運用した場合、特殊作業に従事する人が交差点の領域1307に何度も接触してしまい、警告灯が幾度も点灯してしまうことが想定される。このとき、左の通路を下から進行する経路1304は塞がれており台車が通過することは少ないが、右の通路の経路1305は通行できる。この場合、領域1307に関する条件は設定せずに、領域1308の条件のみ残して警告灯の制御を行うことが望ましいと考えられる。あるいは、領域の形状を変更し、もしくは特殊作業のために別のルールでの警告灯操作を行いたいことも想定される。本実施例では、このような場合でも利用者が現場で任意に制御ルールを追加できるという点が特徴の一つであり、利用者はセンサや機器の仕様を知ることなく、要求のみを逐次投入すれば、自在に複雑なルールでの機器の制御が行えるのである。
【0043】
この処理のためには、図１２（Ｂ）に示される、レイアウトDB106の機器配置データ1205が用いられる。機器配置データ1205は、機器ID1206、機器位置1207、機器影響範囲1208、機器種別1209、機器型番1210、機器アドレス1211を含んで構成される。前述のエリアID内の照度が最大の５０％程度になるような制御のためには、機器位置1207ないし機器影響範囲1208が参照され、当該エリアIDに対応するエリア形状1204と接触する機器が選定されて制御対象となる。
【0044】
図５に戻り、説明を続ける。制御要求発行部103で発行された制御要求データ1101が実行計画生成部105及び判定計画生成部104へ転送されると、判定計画生成部104は判定計画生成処理504および判定計画処理506を実行し、実行計画生成部105は実行計画生成処理505および実行計画処理507を実行する。
【0045】
ここで図１４を参照して、判定計画生成処理504と判定計画処理506について説明する。制御要求データ1101を受信した判定計画生成部104は、条件判定部107を生成し1401、制御要求データ1101を渡す。条件判定部107は独立したスレッドやプロセスとして動作するように実装されており、受け取った制御要求データ1101の条件記述1103を元に、条件を満たしたか否かを判定するルーチンである判定ルール1501を生成する。図１５に判定ルール1501のデータ構造を示す。判定ルール1501は、原則的に条件記述1103を実行しやすい形、例えば前述のSQL文の形に変換し、要求ID1502と対応づけて保持する。この際、条件記述1103の解釈にレイアウトの情報が必要であれば、レイアウトDB106を参照することもできる。判定ルール1501が準備できたら、条件判定部104は位置データの更新に関する所定のトピックID（例えば、’pedestrian_ location’を指定したサブスクライブ登録メッセージ700を生成して(1604)、制御通信中継部101へ転送して、サブスクライブ登録メッセージ700をサブスクライバ一覧に登録する(1605)。以降、人が検知されるたびに、制御実行部109にはそれを通知するメッセージが配信されることになる。
【0046】
図１６に実行計画生成部105の実行計画生成処理505及び実行計画処理507の手順を示す。制御要求データ1101を受信した実行計画生成部105は、制御実行部108を生成し(1601)、制御要求データ1101を渡す。制御実行部108は条件判定部107と同様に独立に動作するようになっており、制御要求データ1101の結果記述1104を元に、制御の具体的な内容を決定し、機器ごとに特有の実行制御コマンド1701に変換する。
【0047】
図１７に実行制御コマンド1701のデータ構造を示す。実行制御コマンド1701は、実行すべき制御に対応する制御コマンド列1702を送付対象1703と対応づけて保持する。この際、レイアウトDB106の機器配置データ1205にある機器位置1207および機器影響範囲1208と、エリア情報データ1201のエリア形状1204を照合して、制御の対象となる機器を特定し、その機器の種別や型番が特定され、それに適合した制御コマンド列1702と送付対象1703が生成される。この制御コマンド列1702と送付対象1703の組は複数含まれており、制御実行部108が複数の機器の制御を受け持つことになる。なお、一つの制御実行部108が一つの機器を受け持つようにしてもよく、処理の負荷は増大するが、制御実行部108が単純な仕組みになるため、実装に伴う不具合等を低減できるという利点がある。
【0048】
実行制御コマンド1701の準備ができたら、制御実行部109は制御要求の条件判定の結果を意味する所定のトピックID（例えば、’result_ location’）をトピックID702に、要求ID1701をサブトピックID(703に指定したサブスクライブ登録メッセージ700を生成して(1604)、制御通信中継部101へ転送して、サブスクライバ一覧に登録させる(1605)。以降、条件判定部107の判定が真であったときにそれに対応するメッセージが発行されると、制御実行部108に配信されることになる。
【0049】
次に、図１８～図２４を参照して、図４に示した機器制御の詳細について説明する。
図１８は機器制御のシーケンスを示す。機器制御は、レーザ計測システム114等のセンサシステムが定期的に検知した人の情報を送付することが起点になる。当該人の検知情報は制御通信中継部101を経由して位置推定部102へ転送され、それをもとに位置推定処理1801が実行される。
図１８は機器制御のシーケンスを示す。機器制御は、レーザ計測システム114等のセンサシステムが定期的に検知した人の情報を送付することが起点になる。当該人の検知情報は制御通信中継部101を経由して位置推定部102へ転送され、それをもとに位置推定処理1801が実行される。
【0050】
図１９は位置推定処理1801のフローを示す。
位置推定部102が、レーザ計測システム114またはカメラシステム113または端末測位システム112（以下、代表的にレーザ計測システム114等ということにする）から人の検知データを受信すると(1901)、位置推定部102は検知データを組み合わせて人の位置座標を推定する。
位置推定部102が、レーザ計測システム114またはカメラシステム113または端末測位システム112（以下、代表的にレーザ計測システム114等ということにする）から人の検知データを受信すると(1901)、位置推定部102は検知データを組み合わせて人の位置座標を推定する。
【0051】
ここで複数のセンサシステムからのデータがある場合は、それらの検知データを統合処理する。例えば、一人の人をレーザ計測システム114とカメラシステム113とが独立に検出すると、同一人を二重にカウントして、誤った条件判定をすることが考えられる。そこで、一人の人に関する検知データを複数のセンサシステムで別々に得られる場合でも、単一の人として同定することが求められる。その同定方法としては、人の位置に関する多数の仮説を生成し、受信したデータと最も矛盾しないものを推定結果とする方法などの公知の方法を用いて、同一の人を一意に特定することができる。
【0052】
次に、位置推定部102は推定結果から位置データ2001を作成して制御通信中継部101へ転送する(1903)。
ここで、図２０に人の位置データ2001のデータ構造を示す。位置データ2001は、判定計画処理505で設定したのと同じ、位置の更新を意味するトピックID2002に対して、現在の人の位置のリストを含むデータである。各人ごとに、人ID2003、計測時刻2004、座標2005を対応付けて組を構成し、その組が人数分並んだ構造となっている。この位置データはセンサシステムのデータを統合して人の位置を特定する処理(1902)で作成される情報であり、それがそのまま、あるいは適切な座標やサンプリングレートの変換した後、付与される。
ここで、図２０に人の位置データ2001のデータ構造を示す。位置データ2001は、判定計画処理505で設定したのと同じ、位置の更新を意味するトピックID2002に対して、現在の人の位置のリストを含むデータである。各人ごとに、人ID2003、計測時刻2004、座標2005を対応付けて組を構成し、その組が人数分並んだ構造となっている。この位置データはセンサシステムのデータを統合して人の位置を特定する処理(1902)で作成される情報であり、それがそのまま、あるいは適切な座標やサンプリングレートの変換した後、付与される。
【0053】
制御通信中継部101は位置データ2001を受け取ると、サブスクライバ一覧から、制御要求データと対応するトピックIDに対応付けられた送付先アドレス一覧804を取得する(1904)。送付先アドレス一覧804には、制御条件設定において生成された条件判定部107のアドレスが格納されており、位置データ2001を送付先アドレス一覧のそれぞれのアドレスへ転送する(1905)。
【0054】
図１８に戻って説明を続ける。上述の通り、位置推定処理1801が終わると、制御条件設定において生成された条件判定部107全てに位置データ2001が配信される（この例では、条件判定部Ａと条件判定部Ｂの２つがある）。それらの条件判定部107はそれぞれ個別に位置条件判定1802を実行する。
【0055】
図２１に位置条件判定1802の流れを示す。位置条件判定1802では、受け取った位置データ2001を用いて計測結果DB109の過去位置データ2201を更新する(2101)。条件判定部107は、過去位置データ2201を用いて判定ルール1501に基づいて判定する(2102)。過去位置データ2201には、過去の位置データの情報も蓄積してあるため、例えば「滞留時間が10秒を超えたら警告する」など、時間的な変化に依存する条件にも対応できるようになる。
【0056】
図２２に、過去の位置データ2200のデータ項目の一覧を示す。位置データ2200は計測結果DB108に記憶されるものであり、それには要求ID2201により識別可能な形式で、人ID2202、計測時刻2203、座標2204が含まれる。位置データ2200は条件判定部107ごとにこれまでに受け取った位置データ2200が格納され、人ID2202は人ID2003から、計測時刻2203は計測時刻2004から、座標2204は座標2005から、それぞれ複製されたものである。
【0057】
位置データ2200の更新(2101)に際して、位置データ2001に格納されている複数の人のデータのうち、判定条件1503に寄与するもの、すなわちデータ選択条件1504の条件を満たすものだけを格納することができる。これによりデータ数を削減でき、高速な判定ができる。また、データ選択条件1504に登場しないほど過去のデータ（計測時刻2203により判定可能）に関しては適宜削除することで、過去位置データ2201が大きくなり過ぎて判定が遅くなることを避けることができる。
【0058】
また、複数の条件判定部107が動作することに鑑み、計測結果DB109の実体として複数のHDD等の記憶装置に分けて格納することで、読み書きが同時に行われることによる速度低下を抑えることもできる。
【0059】
条件判定部107における判定ルール1501に基づく判定を実行して(2102)、その結果が偽ならば位置条件判定1802は終了する。一方、判定結果が真ならば、制御通信中継部101に位置判定結果データ2301を発行する(2103)。
【0060】
ここで、図２３に位置判定結果データ2301を示す。位置判定結果データ2301は、トピックID2302、サブトピックID2303、判定結果2304が含まれる。トピックID2302については、実行計画処理507で指定されたのと同じ、位置判定結果データであることを示す所定の値(例えば‘result_location’)が格納される。また、判定結果2304もその結果が真であったことを示す所定のデータ(たとえば、文字列”True”)が格納される。サブトピックID2303については、判定ルール1501の要求ID1502が格納される。これは条件判定部107の生成時、つまり判定計画処理505で受け取った制御要求データのサブトピックID1106の値であり、この位置判定結果データ2301がどの制御要求データに対応するかを示している。
【0061】
図２４に制御実行1803の処理フローを示す。
制御実行部108が位置判定結果データ2301を受信すると(2401)、実行制御コマンド1701を参照して、実行すべき制御コマンド列1702および送付対象1703を特定する(2402)。その後、制御コマンド列1702を照明制御統括部110や音響制御統括部111に配信する(2403)。照明制御統括部110や音響制御統括部111は受信した制御コマンドの内容を確認して、機器への影響を評価して調整する(2404)。例えば、複数の制御実行部108が照明の点灯、消灯を次々要求して来るようなことがあり得る。その場合、照明を過剰に点滅させると故障を誘発することになる。そこで、調整処理2404を設けて、複数の制御実行部108が異なる制御要求を発するときに発生する可能性のある問題について検証する。例えば照明の点滅頻度を減らすなどの調整を加えることで故障の発生を検証する。最後に、照明機器115や音響機器116に対して、調整済みの制御コマンドを発行することにより制御を実行する(2405)。
以上のように、システム稼働中でも人の位置情報を利用して機器の制御を適確、自在に設定することができる。
制御実行部108が位置判定結果データ2301を受信すると(2401)、実行制御コマンド1701を参照して、実行すべき制御コマンド列1702および送付対象1703を特定する(2402)。その後、制御コマンド列1702を照明制御統括部110や音響制御統括部111に配信する(2403)。照明制御統括部110や音響制御統括部111は受信した制御コマンドの内容を確認して、機器への影響を評価して調整する(2404)。例えば、複数の制御実行部108が照明の点灯、消灯を次々要求して来るようなことがあり得る。その場合、照明を過剰に点滅させると故障を誘発することになる。そこで、調整処理2404を設けて、複数の制御実行部108が異なる制御要求を発するときに発生する可能性のある問題について検証する。例えば照明の点滅頻度を減らすなどの調整を加えることで故障の発生を検証する。最後に、照明機器115や音響機器116に対して、調整済みの制御コマンドを発行することにより制御を実行する(2405)。
以上のように、システム稼働中でも人の位置情報を利用して機器の制御を適確、自在に設定することができる。
【0062】
図２５は、制御要求発行部103が制御要求を発行するための表示画面の例を示す。表示画面250はセンサ連携制御のための画面であり、制御要求発行部103によって生成されて、モニタ209に表示される。表示画面250を入力操作することで、制御要求発行処理503が実行できる。
【0063】
表示画面250はタブ2501を備えており、このタブ2501を操作することで、新たな制御要求を逐次発行することができる。図示の例では、２つの制御要求の画面2502が表示される。画面2502には、事前に設定された機器等の静止物のレイアウト図2503と、その図中に制御の条件となるエリア25031と、制御条件2504を入力する項目が含まれる。エリア25031についてはレイアウトDB106のエリア情報データ1201に追記され、その他の入力とともに、制御要求データ1101の判定条件1107、データ選択条件1108に用いられる。さらに、制御の内容2505を入力する項目がある。この内容2505が結果記述1104に用いられる。項目全てに入力された後、発行ボタン2506が操作されると、制御要求発行処理503が実行され、このルールが制御に反映されて制御ルールとなる。
このように、実施例１によれば、人の位置に関する条件による制御ルールを自由に設定できるので、現場の人の状況に応じて機器の制御を変更することができるようになる。
このように、実施例１によれば、人の位置に関する条件による制御ルールを自由に設定できるので、現場の人の状況に応じて機器の制御を変更することができるようになる。
【実施例2】
【0064】
図２６は実施例２による機器制御システム100の構成を示す。
実施例２が、実施例1の機器制御システム100と異なる点は、利用者から制御のパラメータ（すなわち制御条件2504や制御内容2505）の妥当性評価を得るための制御評価部2601を追加したことにある。さらに、判定計画生成部104および実行計画生成部105は、制御評価部2601の入力を受けて条件判定部107や制御実行部109のパラメータを自動調節する機能を持ち、制御実行部109は制御要求間の機器割り当て最適化を行う機能も持つ。
実施例２が、実施例1の機器制御システム100と異なる点は、利用者から制御のパラメータ（すなわち制御条件2504や制御内容2505）の妥当性評価を得るための制御評価部2601を追加したことにある。さらに、判定計画生成部104および実行計画生成部105は、制御評価部2601の入力を受けて条件判定部107や制御実行部109のパラメータを自動調節する機能を持ち、制御実行部109は制御要求間の機器割り当て最適化を行う機能も持つ。
【0065】
現場ではシステムの運用中に制御のパラメータを変更することがある。実施例1では、制御要求発行部103で制御要求を追加することができるので、一度、システムを再起動した後、新たな制御要求を含む形で全ての制御要求を発行することで対応できる。しかし、パラメータの細かな調整には実際の動作を観察することを求められるため、変更の結果が妥当かを確認し、適切でなければパラメータを変更して再起動、という手続を繰り返すことになってしまうため、パラメータの細かな調整をあまり頻繁に行えない。
このような事情に鑑み、実施例２ではシステムを再起動しなくても制御要求の変更や自動的なパラメータ調整ができる機能を実現する。
このような事情に鑑み、実施例２ではシステムを再起動しなくても制御要求の変更や自動的なパラメータ調整ができる機能を実現する。
【0066】
図２７は実施例２における実行計画生成部105の実行計画生成処理505を示す。実行計画生成処理505では、制御要求データ1101に乱数揺動のパラメータを付与する。これにより、図１１の制御要求データ1101の状態変更内容1111のパラメータに乱数のふり幅が与えられる。具体的には「エリアID2内の人数が(2～10)人以下のとき」のように、人数や照度等の数値が、乱数のふり幅を記載した形に変更される。同様に、判定計画生成部104の判定計画生成処理504でも判定条件1107のパラメータに乱数を加える。条件判定部107および制御実行部109は例えば１分おきなど適当なタイミングで乱数値を更新しながら、判定や制御を行う。乱数のふり幅は、初期状態では所定の値で固定されるが、制御評価部2601から入力を受けると変更される。
【0067】
図２８は制御評価部2601から入力を受ける際のシーケンス図を示す。
制御評価部2601は、利用者から制御の良し悪しの評価を受付けて、その結果あらわす制御評価データ3001を生成し、判定計画生成部104および実行計画生成部105に配信する(2802)。なお、繰り返しになるため説明は省略するが、この配信は他の手順と同様に、制御通信中継部101にしかるべきトピックIDを与えたメッセージを送付することによって実現できる。図２９に制御評価データ2901のデータ構造の例を示す。制御評価データ2901は評価を受けた時刻を意味する評価時刻2902、およびその良し悪しを意味する評価内容2903を含むデータである。
制御評価部2601は、利用者から制御の良し悪しの評価を受付けて、その結果あらわす制御評価データ3001を生成し、判定計画生成部104および実行計画生成部105に配信する(2802)。なお、繰り返しになるため説明は省略するが、この配信は他の手順と同様に、制御通信中継部101にしかるべきトピックIDを与えたメッセージを送付することによって実現できる。図２９に制御評価データ2901のデータ構造の例を示す。制御評価データ2901は評価を受けた時刻を意味する評価時刻2902、およびその良し悪しを意味する評価内容2903を含むデータである。
【0068】
判定計画生成部104および実行計画生成部105は、それぞれ判定計画評価処理2803と実行計画評価処理2804として、制御評価データ3001をもとにした制御のパラメータの乱数揺動の範囲を変更する指令を、条件判定部107および制御実行部109へ配信する。
【0069】
図３０は実行計画評価処理2804を示す。実行計画生成部105は、制御評価データ2901を受け取ると、その評価時刻2902を参照し、その時刻の乱数の値を特定する(3001)。それを元にパラメータの調整を行う(3002)。例えば、評価内容2903が「よい」となっており、そのときの乱数値が現在の設定範囲の平均より大きい場合、現在の設定範囲をそれぞれ少しずつ大きくする。これにより、評価内容2903が「よい」となった周囲の値がよりとりやすくなり、より「よい」状況が発生しやすくなる。この方法は一例であり、「よい」の状態がより頻繁に発生する、または「わるい」の状態が発生しにくくなるような調整法であれば、任意の方法で調整することができる。
【0070】
また、この際に複数の制御実行部108の間で重複する制御がある場合にそれを省略するようにするなどの最適化をすることもできる。
その結果を受けて、実行計画生成部105は制御実行部108に対してパラメータの更新を指示する。制御実行部108はパラメータの更新指示を受けて、実効制御コマンド列を更新する。
同様の処理は判定計画生成部104でも行われ、判定のパラメータに関しての調整が行われる。この手順により、「よい」パラメータに近づいていくようにできる。
その結果を受けて、実行計画生成部105は制御実行部108に対してパラメータの更新を指示する。制御実行部108はパラメータの更新指示を受けて、実効制御コマンド列を更新する。
同様の処理は判定計画生成部104でも行われ、判定のパラメータに関しての調整が行われる。この手順により、「よい」パラメータに近づいていくようにできる。
【0071】
実施例２では要求削除の機能も実現できる。それには、まず判定計画生成部104および実行計画生成部105は、制御要求登録待受処理501および制御要求登録待受処理502においてサブスクライブ登録メッセージを発送する際、制御要求の削除を意味する所定値（例えば”delete_req”）をトピックIDに、サブトピックIDをワイルドカードにしたメッセージも同時に配信し登録しておく。その上で要求削除の手順を実行して要求登録を解除する。
【0072】
図３１に要求削除のシーケンス図を示す。
要求削除の手順は次の通りである。まず、利用者が制御要求発行部103を操作して制御要求の解除を指示すると、上述の制御要求の削除の意味する所定値をトピックIDに、当該解除対象の要求IDをサブトピックID1106にしたメッセージが、制御通信中継部101へ転送される。すると、判定計画生成部104および実行計画生成部105に配信される。判定計画生成部104および実行計画生成部105はそれぞれサブトピックID1106に該当する条件判定部107および制御実行部109を削除する。この際も、複数の条件判定部107および制御実行部108の間で重複がある場合にそれを省略するようにするなど最適化をしてもよい。同時に、制御通信中継部101のサブスクライバ一覧800からも削除される。
上記のように、実施例２では制御ルールの変更が「よい」「わるい」の指示により行えるので、現場でのパラメータ調整がさらに容易になる。
要求削除の手順は次の通りである。まず、利用者が制御要求発行部103を操作して制御要求の解除を指示すると、上述の制御要求の削除の意味する所定値をトピックIDに、当該解除対象の要求IDをサブトピックID1106にしたメッセージが、制御通信中継部101へ転送される。すると、判定計画生成部104および実行計画生成部105に配信される。判定計画生成部104および実行計画生成部105はそれぞれサブトピックID1106に該当する条件判定部107および制御実行部109を削除する。この際も、複数の条件判定部107および制御実行部108の間で重複がある場合にそれを省略するようにするなど最適化をしてもよい。同時に、制御通信中継部101のサブスクライバ一覧800からも削除される。
上記のように、実施例２では制御ルールの変更が「よい」「わるい」の指示により行えるので、現場でのパラメータ調整がさらに容易になる。
【0073】
以上、実施形態について説明したが、本発明は上記実施形態に限定されずに種々変形、応用して実施し得る。
例えば、上記実施形態による機器制御システムでは、人の存在を検知してそのセンサ情報を機器制御に適用するものである。応用例によれば、人に限らず、移動物を検知してそのセンサ情報を用いて機器を制御する機器制御システムにも適用可能である。例えば、赤外線センサや画像センサで鳥獣を検知してそのセンサ情報を用いて、音波発生器を制御して特定の音波を発生させて鳥獣を追い払う音波制御システム等の機器制御システムにも適用可能である。更に他の例として、移動物に限らず、画像センサを用いて車両等の移動体の位置や動きを検知して、そのセンサ情報を用いて信号機を制御する信号機制御システムにも適用可能である。
例えば、上記実施形態による機器制御システムでは、人の存在を検知してそのセンサ情報を機器制御に適用するものである。応用例によれば、人に限らず、移動物を検知してそのセンサ情報を用いて機器を制御する機器制御システムにも適用可能である。例えば、赤外線センサや画像センサで鳥獣を検知してそのセンサ情報を用いて、音波発生器を制御して特定の音波を発生させて鳥獣を追い払う音波制御システム等の機器制御システムにも適用可能である。更に他の例として、移動物に限らず、画像センサを用いて車両等の移動体の位置や動きを検知して、そのセンサ情報を用いて信号機を制御する信号機制御システムにも適用可能である。
【0074】
また、上記実施例では、機器制御システム100が照明制御統括部110や音響制御統括部111等の機器制御統括部を有しているが、これらの機器制御統括部は別の装置として構成して、機器制御システム100とは物理的に離れた例えば機器115,116に近い場所に設置してもよい。この場合、機器制御システム100を構成するサーバと別構成の機器制御統括部を有する装置とはネットワークで接続すればよい。この場合、機器制御システム100は制御実行部109の出力である制御情報を提供する機器制御情報提供システム或いは機器制御情報生成システムとして把握することができる。
【符号の説明】
【0075】
100：機器制御システム
101：制御通信中継部
102：位置推定部
103：制御要求発行部
104：判定計画生成部
105：実行計画生成部
106：レイアウトDB
107：条件判定部
108：計測結果DB
109：制御実行部
110：照明制御統括部
111：音響制御統括部
112：端末測位システム
113：カメラシステム
114：レーザ計測システム
115：照明機器
116：音響機器
101：制御通信中継部
102：位置推定部
103：制御要求発行部
104：判定計画生成部
105：実行計画生成部
106：レイアウトDB
107：条件判定部
108：計測結果DB
109：制御実行部
110：照明制御統括部
111：音響制御統括部
112：端末測位システム
113：カメラシステム
114：レーザ計測システム
115：照明機器
116：音響機器
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】