特表 2023-503370 制御デバイス及び複数の被制御デバイスを有するネットワーク化されたシステム、並びにシステムによって使用されるデバイス及び方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2023-01-27

(54)【発明の名称】制御デバイス及び複数の被制御デバイスを有するネットワーク化されたシステム、並びにシステムによって使用されるデバイス及び方法

(51)【国際特許分類】

   H05B 47/19 20200101AFI20230120BHJP

   H05B 47/105 20200101ALI20230120BHJP

   H04L 43/103 20220101ALI20230120BHJP

   H04Q 9/00 20060101ALI20230120BHJP

【ＦＩ】

H05B47/19

H05B47/105

H04L43/103

H04Q9/00 341A

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2022531358

(86)(22)【出願日】2020-11-23

(85)【翻訳文提出日】2022-07-26

(86)【国際出願番号】 EP2020083035

(87)【国際公開番号】W WO2021105050

(87)【国際公開日】2021-06-03

(31)【優先権主張番号】19212410.5

(32)【優先日】2019-11-29

(33)【優先権主張国・地域又は機関】EP

(81)【指定国・地域】

(71)【出願人】

【識別番号】516043960

【氏名又は名称】シグニファイ ホールディング ビー ヴィ

【氏名又は名称原語表記】ＳＩＧＮＩＦＹ ＨＯＬＤＩＮＧ Ｂ．Ｖ．

【住所又は居所原語表記】Ｈｉｇｈ Ｔｅｃｈ Ｃａｍｐｕｓ ４８，５６５６ ＡＥ Ｅｉｎｄｈｏｖｅｎ，Ｔｈｅ Ｎｅｔｈｅｒｌａｎｄｓ

(74)【代理人】

【識別番号】100163821

【弁理士】

【氏名又は名称】柴田 沙希子

(72)【発明者】

【氏名】ハーヴェルラーグ マルコ

(72)【発明者】

【氏名】ローゼンダール レーンダート テウニス

【テーマコード（参考）】

3K273

5K048

【Ｆターム（参考）】

3K273PA01

3K273PA03

3K273PA06

3K273PA07

3K273QA31

3K273TA03

3K273TA04

3K273TA15

3K273TA24

3K273TA27

3K273TA41

3K273TA54

3K273TA62

3K273UA17

5K048BA07

5K048DA02

5K048DC01

5K048EB02

5K048EB03

5K048EB13

5K048HA01

5K048HA02

(57)【要約】

ネットワーク化されたシステムは、１つ以上の他のデバイスにコマンドを送信する第１のデバイスを有する。これら他のデバイスは、コマンドに従うことができる場合、自身の状態の報告を抑制する。斯くして、状態レポートが、コマンドが従われることができなかったこと又は状態変更が第１のデバイスからのコマンドに応答せずになされたことを示さない限り、ネットワーク状態データはコマンドに基づいてメンテナンスされる。

【特許請求の範囲】

【請求項1】

制御機能を実行する第１のデバイスと、
状態監視デバイスと、
複数の被制御デバイスと、
を含む、ネットワーク化されたシステムであって、
前記第１のデバイスは、前記被制御デバイスに制御コマンドを送信するように構成され、前記被制御デバイスは、前記状態監視デバイスに状態報告メッセージを送信するように構成され、
各被制御デバイスは、制御コマンドを受信するための被制御デバイスレシーバと、被制御デバイストランスミッタと、被制御デバイスプロセッサとを含み、前記被制御デバイスプロセッサは、
デバイス状態を変更するための制御コマンドを前記第１のデバイスから又はコマンドの他のソースから受信する、
前記被制御デバイスが前記制御コマンドを順守することができる場合、前記制御コマンドに応答してデバイス状態を変更する、
前記制御コマンドが前記第１のデバイスから発信されたかどうかを判断する、
前記制御コマンドが前記第１のデバイスから発信されていて、順守された場合、前記状態監視デバイスへの状態報告メッセージの送信を抑制する、及び
前記制御コマンドが前記第１のデバイスから発信されていない場合、前記状態監視デバイスに状態報告メッセージを送信する、
ように構成される、システム。

【請求項2】

前記被制御デバイスプロセッサは、前記制御コマンドが前記第１のデバイスから発信されていて、順守されなかった場合、
状態報告メッセージを送信する、又は
前記制御コマンドは順守されなかったが、閾値を下回るマージンで順守されなかった場合にのみ、状態報告メッセージの送信を抑制し、それ以外の場合は状態報告メッセージを送信する、
ように構成される、請求項１に記載のシステム。

【請求項3】

前記第１のデバイスは、制御コマンドを送信するための第１のデバイストランスミッタと、前記第１のデバイストランスミッタを制御するための第１のデバイスプロセッサとを含み、前記状態監視デバイスは、状態報告メッセージを受信するための監視デバイスレシーバと、ネットワーク状態データを記憶するメモリと、前記制御コマンド及び前記受信した状態報告メッセージに基づいて前記ネットワーク状態データをメンテナンスするように構成される監視デバイスプロセッサとを含む、請求項１又は２に記載のシステム。

【請求項4】

前記監視デバイスプロセッサは、前記ネットワーク状態データに、静的値及び値の時間的遷移を示す過渡関数をポピュレートするように構成され、前記被制御デバイスプロセッサは、静的値及び任意選択的に過渡関数も示す状態報告メッセージを生成するように構成される、請求項３に記載のシステム。

【請求項5】

前記第１のデバイスプロセッサ又は前記状態監視デバイスは、状態チェックのために前記被制御デバイスを定期的にポーリングするように構成される、請求項１乃至４のいずれか一項に記載のシステム。

【請求項6】

当該システムは、ネットワーク化された照明システムを含み、前記被制御デバイスは、照明器具を含み、前記制御コマンドは、
オン／オフコマンド、
輝度レベルコマンド、
色温度コマンド、
色設定コマンド、
のうちの１つ以上を含む、請求項１乃至５のいずれか一項に記載のシステム。

【請求項7】

ネットワークで使用し、制御機能を実行する前記ネットワークの第１のデバイスによって制御するための被制御デバイスであって、当該被制御デバイスは、前記第１のデバイスから制御コマンドを受信するための被制御デバイスレシーバと、被制御デバイストランスミッタと、被制御デバイスプロセッサとを含み、前記被制御デバイスプロセッサは、
デバイス状態を変更するための制御コマンドを第１のデバイスから又は制御コマンドの他のソースから受信する、
当該被制御デバイスが前記制御コマンドを順守することができる場合、前記制御コマンドに応答してデバイス状態を変更する、
前記制御コマンドが前記第１のデバイスから発信されたかどうかを判断する、
前記制御コマンドが前記第１のデバイスから発信されていて、順守された場合、状態監視デバイスへの状態報告メッセージの送信を抑制する、及び
前記制御コマンドが前記第１のデバイスから発信されていない場合、前記状態監視デバイスに状態報告メッセージを送信する、
ように構成される、被制御デバイス。

【請求項8】

当該被制御デバイスプロセッサは、前記制御コマンドが前記第１のデバイスから発信されていて、順守されなかった場合、
状態報告メッセージを送信する、又は
前記第１のデバイスから発信された前記制御コマンドが順守されなかったが、閾値を下回るマージンで順守されなかった場合にのみ、状態報告メッセージの送信を抑制し、それ以外の場合は状態報告メッセージを送信する、
ように構成される、請求項７に記載の被制御デバイス。

【請求項9】

当該被制御デバイスは照明器具である、請求項７又は８に記載の被制御デバイス。

【請求項10】

ネットワーク化されたシステムの制御及び監視デバイスであって、当該制御及び監視デバイスは、
制御機能を実行するネットワーク化されたシステムの第１のデバイスであって、前記第１のデバイスは、ネットワークの被制御デバイスに制御コマンドを送信するための第１のデバイストランスミッタを含む、第１のデバイスと、
ネットワーク化されたシステムの被制御デバイスの状態変更を監視するための、前記第１のデバイスとコロケートされる、ネットワーク化されたシステムの状態監視デバイスと、
を含み、前記状態監視デバイスは、
状態報告メッセージを受信するための監視デバイスレシーバと、
監視デバイスプロセッサと、
ネットワーク状態データを記憶するメモリと、
を含み、
前記監視デバイスレシーバは、被制御デバイスから、
前記被制御デバイスが、前記第１のデバイスによって送信されていない制御コマンドに応答して状態を変更した、又は
前記被制御デバイスが、前記第１のデバイスによって送信された制御コマンドを順守しなかった、
ことを示す状態報告メッセージを受信するように構成され、
前記監視デバイスプロセッサは、
制御コマンドが前記第１のデバイスによって被制御デバイスに送信される場合、前記被制御デバイスによる順守を仮定して、前記被制御デバイスに送信された制御コマンドに基づいて前記被制御デバイスのネットワーク状態データを適応させる、
状態報告メッセージが、前記第１のデバイスによって被制御デバイスに送信された制御コマンドが前記被制御デバイスによって順守されることができなかったことを示す場合、受信した状態報告メッセージに従って前記被制御デバイスのネットワーク状態データを適応させる、及び
状態報告メッセージが、被制御デバイスが前記第１のデバイスによって送信されていない制御コマンドに応答して状態を変更したことを示す場合、受信した状態報告メッセージに従って前記被制御デバイスのネットワーク状態データを適応させる、
ことによりネットワーク状態データをメンテナンスするように構成される、制御及び監視デバイス。

【請求項11】

当該制御及び監視デバイスは、照明システムコントローラである、請求項１０に記載の制御及び監視デバイス。

【請求項12】

制御機能を実行する第１のデバイスと、状態監視デバイスと、複数の被制御デバイスとを含むネットワーク化されたシステムで使用するための、被制御デバイスのためのネットワーク制御方法であって、前記第１のデバイスは、前記被制御デバイスに制御コマンドを送信するように構成され、前記被制御デバイスは、前記状態監視デバイスに状態報告メッセージを送信するように構成され、当該方法は、前記被制御デバイスにおいて、
デバイス状態を変更するための制御コマンドを受信することと、
前記被制御デバイスが前記制御コマンドを順守することができる場合、前記制御コマンドに応答してデバイス状態を変更することと、
前記制御コマンドが前記第１のデバイスから発信されたかどうかを判断することと、
前記制御コマンドが前記第１のデバイスから発信されていて、順守された場合、前記状態監視デバイスへの状態報告メッセージの送信を抑制することと、
前記制御コマンドが前記第１のデバイスから発信されていない場合、前記状態監視デバイスに状態報告メッセージを送信することと、
を含む、方法。

【請求項13】

ネットワーク化されたシステムで使用するための、制御及び監視デバイスのためのネットワーク制御方法であって、照明システムコントローラは、ネットワークの被制御デバイスに制御コマンドを送信する第１のデバイスと、前記第１のデバイスとコロケートされる状態監視デバイスとを含み、当該方法は、
前記第１のデバイスが、
前記ネットワークの被制御デバイスに制御コマンドを送信することと、
前記状態監視デバイスが、
ネットワーク状態データを記憶することと、
被制御デバイスに送信された制御コマンドを受信することと、
前記制御コマンドに基づいてネットワーク状態データをメンテナンスすることと、
ネットワーク状態報告メッセージを受信することと、
前記受信したネットワーク状態報告メッセージに基づいてネットワーク状態データを更新することと、
を含み、
前記メンテナンスすることは、
制御コマンドが前記第１のデバイスによって被制御デバイスに送信される場合、前記被制御デバイスによる順守を仮定して、前記被制御デバイスに送信された制御コマンドに基づいて前記被制御デバイスのネットワーク状態データを適応させること、
を含み、
前記更新することは、
状態報告メッセージが、前記第１のデバイスによって送信された制御コマンドが被制御デバイスによって順守されることができなかったことを示す場合、受信した状態報告メッセージに従って前記被制御デバイスのネットワーク状態データを適応させることと、
状態報告メッセージが、前記被制御デバイスが前記第１のデバイスによって送信されていない制御コマンドに応答して状態を変更したことを示す場合、受信した状態報告メッセージに従って前記被制御デバイスのネットワーク状態データを適応させることと、
を含む、方法。

【請求項14】

コンピュータプログラムコード手段を含むコンピュータプログラムであって、前記コンピュータプログラムコード手段は、当該コンピュータプログラムがコンピュータで実行された場合、請求項１２又は１３に記載の方法を実施するように構成される、コンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、制御デバイス及び複数の被制御デバイスを有する、ネットワーク化されたシステムに関する。本発明はまた、システムによって使用されるデバイス及び方法に関する。

【背景技術】

【0002】

本発明は、デバイスのネットワークに一般的に関心があるが、とりわけ、ネットワーク化された照明システムへの特定のアプリケーションを有する。

【0003】

業務用照明市場(professional lighting market)では、あらゆる種類の新しい機能が実装されることを可能にする、コネクテッドライティングシステム(connected lighting system)への移行が進んでいる。これらの新しい特徴には、例えば、リモートスケジューリング、エネルギモニタリング、センサベースの照明制御、アセットマネジメント等がある。

【0004】

設置における配線量を抑えるために、ローカルエリアワイヤレス通信が、各ノードに照明コマンドを送信する及び各照明器具の状態を評価する手段として急速に普及している。

【0005】

現在広く使用されているこのようなワイヤレスネットワークプロトコルの例としては、ＩＥＥＥ ８０２．１５．４、８０２．１５．１又は８０２．１１＊規格の上に構築された様々な独自のネットワーク実装、及びＺｉｇＢｅｅ（登録商標）、Ｔｈｒｅａｄ、ＢＬＥメッシュ、Ｗｉ－Ｆｉ（登録商標）等のオープン規格がある。

【0006】

場合によっては、これらのシステムは、多くのワイヤレスノードから成ることができ、慎重なネットワーク設計が、ネットワークパッケージ同士の衝突に起因してメッセージが失われるのを避けるために必要である。

【0007】

パケットの衝突は完全には避けられないので、これらのネットワークプロトコルのほとんどは、パケットが宛先に到達しなかった（及び／又は受信確認応答がコマンド発行元(issuer)に戻らなかった）場合のためにリトライメカニズムを有する。

【0008】

多くの場合、ネットワークは、中央コントローラからすべてのノードに直接到達できないように（距離的に）非常に大きく、それゆえ、いくつかのネットワークプロトコルは、他のノードを経由してメッセージを送信するメカニズムを実装している。このようにして、リモートノードは、１つ又は複数の「ホップ」を経由して到達されることもできる。

【0009】

多くのホップを必要とするメッセージは、宛先ノードに到達するためにネットワークパケットが何度も再送される必要があるため、ネットワーク上のエクストラトラフィック(extra traffic)をもたらす。

【0010】

これは、中央コントローラから多くのノードにコマンドを送信する（又は中央コントローラによって多くのノードから情報を受信する）ことが、パケットの衝突を避ける賢い方法を必要とする状況をもたらす。

【0011】

ＵＳ２０１８／００２７６３１ Ａ１は、（ｉ）占有センサ、又はオン／オフスイッチによって報告されるイベント等、状態変更イベント、（ｉｉ）イベントを検出したメンバ照明制御デバイスの識別子、及び（ｉｉｉ）モニタ照明制御デバイス及び照明制御デバイスのメンバを含む照明制御グループの制御グループ識別子を含む状態変更イベントメッセージを受信するモニタ照明制御デバイスに関する。モニタ照明制御デバイスは、メンバ照明制御デバイスに確認応答を送信し、その後、状態変更イベントを含むマルチキャストメッセージを照明制御グループに送信する。複数の同時グループ／ゾーン状態変更要求を処理するために、モニタ照明制御デバイスは、新しい状態変更を受けると、変更が進行中であるかどうかをチェックし、そうである場合、当該状態変更をキャンセルし、新しい状態変更を実行する。

【0012】

ＵＳ２０１９／００８０２４ Ａ１は、アクセス機器と照明器具とをペアリングする方法に関し、この目的のために、アクセス機器は、第１のコマンドをブロードキャストし、これに応答して照明器具は、自身の照明器具識別子と電波強度とを含む第１の情報をアクセス機器に送信する。アクセス機器は、自身の識別子と第１の情報の部分を照明コントローラに転送する。所定の照明器具が１つのアクセス機器のみに第１の情報を送信したと判断した場合に、照明コントローラは、所定の照明器具と上記１つのアクセス機器とをペアリングする。所定の照明器具が複数のアクセス機器に第１の情報を送信したと判断した場合に、照明コントローラは、複数のアクセス機器のうち電波強度が最も強いアクセス機器と所定の照明器具とをペアリングするように決定する。

【0013】

照明制御コマンドを送信する場合、ブロードキャスティングは、多数のノードに制御メッセージを送信する効率的なやり方である。ブロードキャストメッセージは多くのノードによって同時に受信されることができ、各ノードがメッセージを数回繰り返す場合、コマンドを見逃す可能性は、許容できる程度に十分低くなる。ネットワークのサイズ及び密度に依存して、ブロードキャスト中に発生する「ネットワークストーム」を抑制するために、繰り返しの回数は（一部のネットワークにおいて）構成されることができる。このような抑制がない場合、各ノードは典型的にはメッセージを１回再送信し、これは、２００ノードのネットワークにおける１つのブロードキャストメッセージが、このような抑制が適用されない場合に２００のＲＦ送信をもたらし得ることを意味する。

【0014】

それゆえ、中央コントローラから照明器具制御ノードへのコマンドの伝達は、多数のノードから成るネットワークでも、容易に可能である。しかしながら、その逆の場合は、困難が生じる。例えば、各ネットワークデバイス、例えば、照明器具の状態（オン／オフ状態、調光状態、カラーポイント、エネルギ使用、エラー状態）を確認したい場合、ユニキャストメッセージが中央コントローラから各ノードに送信されなければならず、要求されたデータを含む応答がコントローラに向けて返送されなければならない。ノードがコントローラからの直接通信範囲外にある場合、この結果、多数のネットワークメッセージが上り下りすることになる。ネットワークサイズが（距離的に）大きい場合、これは、各ノードの状態を問い合わせることが、大きな間隔でしか行われることができないことを意味し、目下のアプリケーションにとって十分でない可能性がある。

【発明の概要】

【発明が解決しようとする課題】

【0015】

本発明は、とりわけ、（中央コントローラであってもよく、又は、単に当該時点で制御役割を果たすデバイスであってもよい）制御デバイスを有する大きなネットワークがある場合に生じ、ノードの状態の変更に応じたノードの状態報告に関するトラフィックを最小限にすることが望まれる問題に向けられる。

【課題を解決するための手段】

【0016】

本発明は、特許請求の範囲によって規定される。

【0017】

本発明の一態様による例によれば、
制御機能を実行する第１のデバイスと、
状態監視デバイス(status monitoring device)と、
複数の被制御デバイス(controlled device)と、
を含む、ネットワーク化されたシステム(networked system)であって、
第１のデバイスは、被制御デバイスに制御コマンドを送信するように構成され、被制御デバイスは、状態監視デバイスに状態報告メッセージ(status report message)を送信するように構成され、
各被制御デバイスは、制御コマンドを受信するための被制御デバイスレシーバと、被制御デバイストランスミッタと、被制御デバイスプロセッサとを含み、被制御デバイスプロセッサは、
デバイス状態を変更するための制御コマンドを第１のデバイスから又はコマンドの他のソースから受信する、
被制御デバイスが制御コマンドを順守する(adhere)ことができる場合、制御コマンドに応答してデバイス状態を変更する、
制御コマンドが第１のデバイスから発信されたかどうかを判断する、
制御コマンドが第１のデバイスから発信されていて、順守された場合、状態監視デバイスへの状態報告メッセージの送信を抑制する、及び
制御コマンドが第１のデバイスから発信されていない場合、状態監視デバイスに状態報告メッセージを送信する、
ように構成される、被制御デバイスが提供される。

【0018】

第１のデバイスは、集中型ユニット(centralized unit)において状態監視デバイスとコロケートされ(co-located)てもよい、すなわち、集中型ユニットは、制御コマンドを発行すると共に、ネットワークのデバイスの状態を監視してもよいことに留意されたい。集中型ユニットは、例えば、ネットワークコントローラであってもよい。

【0019】

このネットワーク化されたシステムの被制御デバイスは、受信したコマンド又は主電源及び／若しくはローカル制御ユニットをスイッチオンする等の他のイベントに応答して状態を変更した場合に状態報告メッセージを送信する。これは、属性レポーティング(attribute reporting)として知られている。しかしながら、被制御デバイスが第１のデバイスからのコマンドに応答して正しく状態を変更した場合、状態更新は与えられない。これは、状態レポーティングの量を減らし、これによりデータトラフィックは低減される。

【0020】

被制御デバイスプロセッサはさらに、制御コマンドが第１のデバイスから発信されていて、順守されなかった場合、
状態報告メッセージを送信する、又は
制御コマンドは順守されなかったが、閾値を下回るマージンで(by a margin)順守されなかった場合にのみ、状態報告メッセージの送信を抑制し、それ以外の場合は状態報告メッセージを送信する、
ように構成されてもよい。

【0021】

たとえコマンドが第１のデバイスから発信されているとしても、コマンドが順守されることができなかった場合、状態報告メッセージは送信される。例えば、被制御デバイスは、制御コマンドを（一部又は全部）順守するケイパビリティを有していない可能性がある。斯くして、状態レポートは、コマンドが（一部又は全部）従われなかったことに状態監視デバイスが気付くことを保証するために送信される。コマンドは順守されなかったが、些細な不一致(trivial discrepancy)（例えば、丸め誤差又は量子化誤差又は所定の閾値等）である場合、状態レポートは抑制されてもよい。

【0022】

例えば、第１のデバイスは、制御コマンドを送信するための第１のデバイストランスミッタと、第１のデバイストランスミッタを制御するための第１のデバイスプロセッサとを含み、状態監視デバイスは、状態報告メッセージを受信するための監視デバイスレシーバと、ネットワーク状態データを記憶するメモリと、制御コマンド及び受信した状態報告メッセージに基づいてネットワーク状態データをメンテナンスする(maintain)ように構成される監視デバイスプロセッサとを含む。

【0023】

第１の（制御）デバイス及び状態監視デバイスが１つのユニットにおいてコロケートされない場合、状態監視デバイスは、被制御デバイスに送信されるコマンド（例えば、Ｚｉｇｂｅｅ）をスニッフィングする、又は制御コマンドを（Ｚｉｇｂｅｅ又は帯域外を介して）受信することにより、何の制御コマンドが送信されているかを知る必要がある。斯くして、状態監視デバイスは、レポーティングが被制御デバイスから受信されない場合でもネットワーク状態データを更新することができる。この知識は、すべて制御コマンドに基づいている。

【0024】

状態監視デバイスは、（第１のデバイスからの）コマンドは順守されたと仮定し、ゆえに、状態監視デバイスは、状態報告メッセージがそうでないことを示すまで、ネットワーク状態データ、例えば、テーブルを更新する。状態報告メッセージは、仮定された値をオーバーライドする。これにより、さもなければ関連する遅延を伴うポーリングを必要としていた、状態報告データの更新を迅速にすることができる。

【0025】

監視デバイスプロセッサは、ネットワーク状態データに、静的値及び値の時間的遷移を示す過渡関数をポピュレートする(populate)ように構成され、被制御デバイスプロセッサは、静的値及び任意選択的に過渡関数も示す状態報告メッセージを生成するように構成されてもよい。

【0026】

この措置は、時間の経過に伴う既知の展開(evolution)（「デッドレコニング」）に従っている状態変更の度重なるレポーティングの必要性を回避する。状態レポートは、例えば、（コマンドが第１のデバイスから発信されていない場合）時間的遷移の終りに提供されてもよい。代替例又は追加例は、現在値だけでなく、遷移終了値及び（残りの）遷移時間も示すレポートでもってレポーティングメカニズムを拡張することである。

【0027】

状態レポートは、例えば、関数が状態監視デバイスにまだ知られていない（例えば、状態監視デバイスによって設定されていない）場合、過渡関数(transient function)の識別(identification)を含んでもよい。例えば、被制御デバイスプロセッサが、状態監視デバイスに知られている調光カーブを実施している場合、被制御デバイスプロセッサは現在の状態を報告することで十分であり得、これにより、監視デバイスプロセッサは、追従される関数を決定することができるであろう。

【0028】

第１のデバイスプロセッサ又は状態監視デバイスは、状態チェックのために被制御デバイスを定期的にポーリングする(poll)ように構成されてもよい。（たとえ第１のデバイスから送信されているとしても）ポーリングの結果は、状態監視デバイスに送信される必要があるであろう。

【0029】

斯くして、被制御デバイスは、状態変更に応答して即座にレポーティングを行うだけでなく、定期的なポーリングに基づいて定期的にレポーティングを行うこともできる。ポーリングは、例えば、報告メッセージの見逃しに対するセーフティネットを提供する。

【0030】

例えば、実際の状態と管理された状態との間のミスマッチを避けるために、代わりに従来の属性レポーティングが使用され得るように、オーバールールビット又はフラグ(overrule bit or flag)が、本発明のアプローチを有効及び無効にするために使用されてもよい。

【0031】

システムは、ネットワーク化された照明システムを含み、被制御デバイスは、照明器具を含み、制御コマンドは、
オン／オフコマンド、
輝度レベルコマンド、
色温度コマンド、
色設定コマンド、
のうちの１つ以上を含んでもよい。

【0032】

これは、ネットワーク化されたシステムの１つの好ましいアプリケーションである。暖房、換気及び空調システム（ＨＶＡＣ）、交通照明システム、センサノードのネットワークを含むシステム等の他のアプリケーションもある。

【0033】

本発明はまた、ネットワークで使用し、制御機能を実行するネットワークの第１のデバイスによって制御するための被制御デバイスであって、被制御デバイスは、第１のデバイスから制御コマンドを受信するための被制御デバイスレシーバと、被制御デバイストランスミッタと、被制御デバイスプロセッサとを含み、被制御デバイスプロセッサは、
デバイス状態を変更するための制御コマンドを第１のデバイスから又は制御コマンドの他のソースから受信する、
被制御デバイスが制御コマンドを順守することができる場合、制御コマンドに応答してデバイス状態を変更する、
制御コマンドが第１のデバイスから発信されたかどうかを判断する、
制御コマンドが第１のデバイスから発信されていて、順守された場合、状態監視デバイスへの状態報告メッセージの送信を抑制する、及び
制御コマンドが第１のデバイスから発信されていない場合、状態監視デバイスに状態報告メッセージを送信する、
ように構成される、被制御デバイスを提供する。

【0034】

この被制御デバイスは、状態報告メッセージが必要とされない場合、状態報告メッセージを抑制する。なぜなら、状態は、状態報告メッセージが送信されるであろうデバイスによって既に知られている（例えば、指示されている）からである。制御デバイスが、例えば中央ユニットにおいて、状態監視デバイスとコロケートされる場合、中央ユニットの状態監視機能は、何らかの内部インタフェースによって中央ユニットの制御機能による制御コマンドを知る。そうでない場合、状態監視デバイスは、制御コマンドを知る必要がある。

【0035】

例えば、被制御デバイスプロセッサはさらに、制御コマンドが第１のデバイスから発信されていて、順守されなかった場合、
状態報告メッセージを送信する、又は
第１のデバイスから発信された制御コマンドが順守されなかったが、閾値を下回るマージンで順守されなかった場合にのみ、状態報告メッセージの送信を抑制し、それ以外の場合は状態報告メッセージを送信する、
ように構成される。

【0036】

斯くして、状態報告メッセージは、状態が第１のデバイスによって期待される状態に十分に近い場合にも抑制されてもよい。

【0037】

本発明はまた、ネットワーク化されたシステムの制御及び監視デバイスであって、制御及び監視デバイスは、制御機能を実行するネットワーク化されたシステムの第１のデバイスであって、第１のデバイスは、ネットワークの被制御デバイスに制御コマンドを送信するための第１のデバイストランスミッタを含む、第１のデバイスと、ネットワーク化されたシステムの被制御デバイスの状態変更を監視するための、第１のデバイスとコロケートされる、ネットワーク化されたシステムの状態監視デバイスとを含み、状態監視デバイスは、状態報告メッセージを受信するための監視デバイスレシーバと、監視デバイスプロセッサと、ネットワーク状態データを記憶するメモリとを含み、監視デバイスレシーバは、被制御デバイスから、被制御デバイスが、第１のデバイスによって送信されていない制御コマンドに応答して状態を変更した、又は、被制御デバイスが、第１のデバイスによって送信された制御コマンドを順守しなかったことを示す状態報告メッセージを受信するように構成され、監視デバイスプロセッサは、制御コマンドが第１のデバイスによって被制御デバイスに送信される場合、被制御デバイスによる順守を仮定して、被制御デバイスに送信された制御コマンドに基づいて被制御デバイスのネットワーク状態データを適応させる、状態報告メッセージが、第１のデバイスによって被制御デバイスに送信された制御コマンドが被制御デバイスによって順守されることができなかったことを示す場合、受信した状態報告メッセージに従って被制御デバイスのネットワーク状態データを適応させる、及び、状態報告メッセージが、被制御デバイスが第１のデバイスによって送信されていない制御コマンドに応答して状態を変更したことを示す場合、受信した状態報告メッセージに従って被制御デバイスのネットワーク状態データを適応させることによりネットワーク状態データをメンテナンスするように構成される、制御及び監視デバイスを提供する。

【0038】

制御及び監視デバイスは、例えば、照明システムコントローラである。

【0039】

本発明はまた、制御機能を実行する第１のデバイスと、状態監視デバイスと、複数の被制御デバイスとを含むネットワーク化されたシステムで使用するための、被制御デバイスのためのネットワーク制御方法であって、第１のデバイスは、被制御デバイスに制御コマンドを送信するように構成され、被制御デバイスは、状態監視デバイスに状態報告メッセージを送信するように構成され、方法は、被制御デバイスにおいて、
デバイス状態を変更するための制御コマンドを受信することと、
被制御デバイスが制御コマンドを順守することができる場合、制御コマンドに応答してデバイス状態を変更することと、
制御コマンドが第１のデバイスから発信されたかどうかを判断することと、
制御コマンドが第１のデバイスから発信されていて、順守された場合、状態監視デバイスへの状態報告メッセージの送信を抑制することと、
制御コマンドが第１のデバイスから発信されていない場合、状態監視デバイスに状態報告メッセージを送信することと、
を含む、方法を提供する。

【0040】

これは、データトラフィック量を低減させるために状態報告メッセージが抑制される、被制御デバイスによって実施される方法を規定する。

【0041】

本発明はまた、ネットワーク化されたシステムで使用するための、制御及び監視デバイスのためのネットワーク制御方法であって、照明システムコントローラは、ネットワークの被制御デバイスに制御コマンドを送信する第１のデバイスと、第１のデバイスとコロケートされる状態監視デバイスとを含み、方法は、第１のデバイスが、ネットワークの被制御デバイスに制御コマンドを送信することと、状態監視デバイスが、ネットワーク状態データを記憶することと、被制御デバイスに送信された制御コマンドを受信することと、制御コマンドに基づいてネットワーク状態データをメンテナンスすることと、ネットワーク状態報告メッセージを受信することと、受信したネットワーク状態報告メッセージに基づいてネットワーク状態データを更新することとを含み、メンテナンスすることは、制御コマンドが第１のデバイスによって被制御デバイスに送信される場合、被制御デバイスによる順守を仮定して、被制御デバイスに送信された制御コマンドに基づいて被制御デバイスのネットワーク状態データを適応させることを含み、更新することは、状態報告メッセージが、第１のデバイスによって送信された制御コマンドが被制御デバイスによって順守されることができなかったことを示す場合、受信した状態報告メッセージに従って被制御デバイスのネットワーク状態データを適応させることと、状態報告メッセージが、被制御デバイスが第１のデバイスによって送信されていない制御コマンドに応答して状態を変更したことを示す場合、受信した状態報告メッセージに従って被制御デバイスのネットワーク状態データを適応させることとを含む、方法を提供する。

【0042】

これは、データトラフィック量を低減させるために、ある状況においてのみ状態報告メッセージが送信される、したがって、受信される、制御及び監視デバイスによって実施される方法を規定する。ネットワーク状態データは、デフォルトで制御コマンドに従って更新され、ネットワーク状態が更新される場合、状態報告メッセージが受信される。更新は、制御コマンド、及びその後到来する状態報告メッセージの両方に対して行われる。斯くして、ネットワーク状態データは、状態報告メッセージを受信されるか否かにかかわらず、制御コマンドに基づいてメンテナンスされ、もし状態報告メッセージが受信される場合、ネットワーク状態データは（さらに）更新されてもよい。

【0043】

これらの方法においても、ネットワーク化されたシステムは、照明システムであり、被制御デバイスは、照明器具であり、制御コマンドは、
オン／オフコマンド、
輝度レベルコマンド、
色温度コマンド、
色設定コマンド、
のうちの１つ以上を含んでもよい。

【0044】

これらの方法において、第１の（コマンディング(commanding)）デバイスは、ネットワークコントローラ等、単一のユニット又はデバイスにおいて状態監視デバイスとコロケートされ、斯くして、制御及び監視デバイスを表す。

【0045】

本発明はまた、コンピュータプログラムコード手段を含むコンピュータプログラムであって、コンピュータプログラムコード手段は、コンピュータプログラムがコンピュータで実行された場合、上記の方法を実施するように構成される、コンピュータプログラムを提供する。

【0046】

本発明はまた、コンピュータプログラムを担持するデータキャリアを提供する。

【0047】

本発明のこれらの及び他の態様は、以下に述べられる実施形態を参照して明らかになり、解明されるであろう。

【図面の簡単な説明】

【0048】

本発明のより良好な理解のために、及び、どのようにして本発明が実施され得るかをより明らかに示すために、例としてのみ、添付の図面が参照される。

【図1】デバイスのネットワークを示す。

【図2】被制御デバイスで実施される方法を示す。

【図3】制御コマンドを送信するデバイスであってもよい、状態監視デバイスで実施される方法を示す。

【発明を実施するための形態】

【0049】

本発明が、図を参照して述べられる。

【0050】

詳細な説明及び特定の例示は、装置、システム及び方法の例示的な実施形態を示すものであるが、説明のみを目的としたものであり、本発明の範囲を限定することを意図したものではないことが理解されるべきである。本発明の装置、システム及び方法のこれら及び他の特徴、態様及び有利な点は、以下の説明、添付の特許請求の範囲、及び添付の図面からよりよく理解されることになるであろう。図面は単に概略的なものであり、縮尺通りに描かれていないことを理解されたい。同じ参照番号は、図面全体にわたって同じ又は類似の部分を示すために用いられることも理解されたい。

【0051】

本発明は、１つ以上の他のデバイスにコマンドを送信する第１のデバイスを有するネットワーク化されたシステムを提供する。これら他のデバイスは、コマンドに従うことができる場合、自身の状態の報告を抑制する。斯くして、状態レポートが、コマンドが従われることができなかったこと又は状態変更が第１のデバイスからのコマンドに応答せずになされたことを示さない限り、ネットワーク状態データはコマンドに基づいてメンテナンスされる。

【0052】

本発明は、従来の属性レポーティングスキームに対する修正を提供する。Ｚｉｇｂｅｅ（登録商標）は、デバイスが属性の変更を報告するように構成される、属性レポーティングを定義している。これは、例えば、設定された量を超える変更がある場合又は周期的（例えば、５分ごと）に最後の測定値を報告するように光レベルセンサが指示される、センサで使用される。値が急速に変化する場合のネットワーク過負荷を防止するために、制限がレポーティング頻度に設けられてもよく、例えば、５秒に１回以下であってもよい。

【0053】

照明の場合、関連する属性は、同様のパラメータのセットで構成されるであろう、オン／オフ状態、明るさ、色等であってもよい。

【0054】

ネットワークコントローラがこれらのパラメータの１つ以上を設定するコマンド（例えば、「スイッチオン」、「明るさを７５％に増加」等）を送信し、照明器具が従来の属性レポーティングを備えて構成される場合、照明器具はすべてネットワークコントローラに応答して、実際にこの変更を実行したことを報告する。

【0055】

これは、コントローラが、各デバイスが実際にコマンドを受信（及び処理）したことを確認するのに有効であるが、大量のネットワークメッセージをもたらす。また、すべての照明器具が同時にこのような報告メッセージを送信しようとすることは、通信アルゴリズム（ＣＳＭＡ－ＣＤ）のストレスをもたらす。斯くして、多くの照明器具が関与する場合、すべてのレポートが実際に配信されないことが起こり得る。この場合、コントローラは、実際には一部の照明器具が制御メッセージを受信したが、それらのレポートが届かなっただけにもかかわらず、誤って、これらの照明器具は制御メッセージを受信しなかったと見なす可能性がある。スケジューリングメカニズムが、この問題を解決するために使用されてもよい。

【0056】

既存の照明システムでは、代わりに、ネットワークコントローラが、照明器具の状態を判断するために定期的に照明器具をポーリングすることが知られている。主な目的は、ネットワーク内のすべての照明器具のデータベースにおいて状態に関するビューを維持することである。これは、ライトの現在の状態を表すためにレポーティングアプリによって使用されてもよく、コントローラ自体によって使用されてもよい（例えば、特定のユーザーコマンド及び特定の照明器具設定がある場合にのみトリガするルール）。このポーリングは、ラウンドロビンフェーズで実行される（例えば、２秒ごとに１つの照明器具をポーリング）。斯くして、大規模なシステム（例えば６０個の照明器具）では、これは、フルサイクルに１２０秒かかり、照明器具の変更からデータベースに反映されるまでの遅延は平均６０秒となる。

【0057】

この遅延の一部は、特定のコマンドの結果（例えば、シーンリコールを送信する場合）を直接データベースに記憶し、照明器具はこれに従って動作するであろうと仮定することによって対処される。この場合、ポーリングの主な目的は、ネットワークコントローラ自身によってトリガされない光遷移、例えば、主電源のオン／オフ、Ｂｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙ又は業務用照明ネットワークに使用されるプロキシアプローチによる制御、ネットワークコントローラが認識しない照明器具コマンドを送信することができる他のＺｉｇｂｅｅ（登録商標）コントローラ、センサ、スイッチ、（例えば、日没時又はその近くにライトをオンする）スケジュールされたコマンドを送信するデバイスによる制御等を追跡することになる。プロキシアプローチの場合、スマートフォン等のデバイスが、Ｂｌｕｅｔｈｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙ（登録商標）、ＢＬＥを介して（プロキシである）ライトのうちの１つに接続し得、制御コマンドは、プロキシからＺｉｇｂｅｅ（登録商標）を介して他のライト（被制御デバイス）に伝わる。

【0058】

そのほか、一過性の性質に起因してデータベースに反映されなネットワークコントローラによって送信される照明制御コマンドもある。これの典型的な例は、ネットワークコントローラが、光の強さ及び／又は色を変化させるコマンドを、多数の照明器具に高速で（例えば、１秒間に１０回）繰り返し送信する「エンターテイメント」（ストリーミング）機能である。このような変更をデータベースで更新することは重要ではない。なぜなら、これらは、その後すぐに（送信される次のコマンドで）無効にされるからである。

【0059】

これらすべての照明変更のソースについて、ポーリングサイクルに起因するレイテンシは解決されない。

【0060】

ポーリングの代わりに（又はポーリングに加えて）属性レポーティングを使用することは、これらの問題のいくつかに対処することができる。例えば、属性レポーティングの場合、すべての照明器具は、すべての変更を直ちにネットワークコントローラに送信する。斯くして、データベースは直ちに更新されることができる。一般に、ネットワークは、メッセージ送信が非常に信頼性が高いように設計される。したがって、すべてのライト状態変更のレポーティングは、ネットワークコントローラが照明器具が状態を変更することをすでに知っている（なぜなら、ネットワークコントローラが、照明器具にそうするように指示したからである）メッセージについて貴重なリソース（ネットワーク帯域幅）の浪費と考えられることができる。これは、ネットワーク化された照明システムにおける照明器具の状態変更の大部分に当てはまる（ほとんどの変更は、ネットワークコントローラによって指示される）。

【0061】

斯くして、本発明は、属性レポーティングへの適応を提供すると考えられてもよい。

【0062】

図１は、制御機能を実行する第１のデバイス１２を含む、ネットワーク化されたシステム１０を示している。これは、中央ネットワークコントローラであってもよいが、等しくネットワークのすべてのデバイスが同じであり、１つが特定の瞬時に指示機能(instructing function)を実行してもよい。

【0063】

複数の被制御デバイス１４、１６、１８がある。

【0064】

第１のデバイス１２は被制御デバイスに制御コマンドを送信し、被制御デバイスは第１のデバイスに状態報告メッセージを返送する。

【0065】

この例は、説明をよりシンプルにするために、コマンドを送信するデバイスが状態レポートを受信するデバイスと同じであることに基づいている。しかしながら、状態報告メッセージを受信する別個の状態監視デバイスがあってもよい。斯くして、（コマンドを送信することができる）別個の第１のデバイスと、（ネットワーク状態を監視する）別個の状態監視デバイスとがあってもよい。また、状態監視デバイスは、送信された制御コマンドを知るように制御コマンドを受信するであろう。何らかのシステム適応が、これらのメッセージがフィルタリングされないように必要とされてもよい。例えば、システムは、照明器具の状態を推測するために聞く(hear)ことができるすべてのネットワークトラフィックを解釈するように構成されてもよい。Ｚｉｇｂｅｅのブロードキャスト／マルチキャスト／グループキャストの場合、メッセージは常に（物理レベルで）受信される。ユニキャストの場合、メッセージは、物理レベルで受信されるとは限らない。

【0066】

制御機能と監視機能との間の通信は、帯域外（例えば、建物内のＥｔｈｅｒｎｅｔ（登録商標）又はＷｉ－Ｆｉ（登録商標）ネットワーク）であってもよく、クラウド接続を介してもよい。このような帯域外通信が使用される場合、そのレイテンシが大きいと、制御コマンドは、被制御デバイスからの状態報告メッセージが到着した後に（短い時間間隔で）状態監視デバイスに到着する可能性がある。この場合、被制御デバイスからの状態報告メッセージが状態をより良く表している可能性が高いので、帯域外制御コマンドを無視した方が良い可能性がある。

【0067】

この例では、第１のデバイス及び状態監視デバイスは同じデバイスである。とりわけ、両者は、ネットワークコントローラの一体部分である。

【0068】

各被制御デバイスは、制御コマンドを受信するための被制御デバイスレシーバ及び被制御デバイストランスミッタを有する被制御デバイストランシーバ２０と、被制御デバイスプロセッサ２２とを含む。

【0069】

被制御デバイスは、照明ユニット等の機能ユニットを有する。この場合、各被制御デバイスは、照明器具のネットワークにおける照明器具であり、第１のデバイスは、（場合によっては、例えばＰｈｉｌｉｐｓ（登録商標）Ｈｕｅ（登録商標）照明システムにおいて、ブリッジとして知られる）照明システムコントローラである。

【0070】

斯くして、この例は、ネットワーク化された照明システムに基づく。この場合、制御コマンドは、
オン／オフコマンド、
輝度レベルコマンド、
色温度コマンド、
色設定コマンド、
のうちの１つ以上を含む。

【0071】

これは、ネットワーク化されたシステムの１つの好ましいアプリケーションである。ホームオートメーション、暖房、換気及び空調システム（ＨＶＡＣ）、交通照明システム、センサノードのネットワークを含むシステム等の他のアプリケーションもある。

【0072】

システムの詳細な動作が、照明の例を参照して述べられる。

【0073】

各被制御デバイスプロセッサ２２は、デバイス状態を変更するための制御コマンドを第１のデバイス１２から又はコマンドの他のソースから受信する、この他のソースは、デバイスのうちの別の１つ、コマンドの外部ソース、ましてはデバイスとの直接ユーザインタラクションであってもよい。

【0074】

被制御デバイスプロセッサは、被制御デバイスがコマンドを順守することができる場合、制御コマンドに応答してデバイス状態を変更する（例えば、明るさ、色、又は他の出力特性を変更する）。

【0075】

被制御デバイスプロセッサは、制御コマンドが第１のデバイス１２から発信されたかどうかを判断する。制御機能及び監視機能が分かれている状況では、無論、監視デバイスではなく制御デバイスから来たと判断される。

【0076】

制御コマンドが第１のデバイスから発信されていて、順守された場合、第１のデバイス（又は別個のデバイスである場合には状態監視デバイス）への状態報告メッセージの送信が抑制される。これは、従来の属性レポーティングアプローチに対する修正である。

【0077】

制御コマンドが第１のデバイスから発信されていない場合、状態報告メッセージが、第１のデバイス（又は別個のデバイスである場合には状態監視デバイス）へ送信される。

【0078】

斯くして、被制御デバイスは、第１のデバイスから来ていない受信したコマンド、又は主電源及び／若しくはローカル制御ユニットをスイッチオンする等の他のイベントに応答して状態を変更した場合に状態報告メッセージを送信する。被制御デバイスが第１のデバイスからのコマンドに応答して正しく状態を変更した場合、状態更新は与えられない。これは、状態レポーティングの量を減らし、これによりデータトラフィックは低減される。

【0079】

被制御デバイスプロセッサ２２はさらに、制御コマンドが第１のデバイスから発信されていて、順守されなかった場合、状態報告メッセージを送信するように構成されてもよい。しかしながら、制御コマンドが閾値を下回るマージンだけ順守されなかった場合、状態報告メッセージの送信は抑制され、一方、被制御デバイスの状態の正確なオーバービューは依然維持される。

【0080】

この場合、コマンドが第１のデバイスから発信されている場合、以下のオプションがある。
－ 制御コマンドが順守された：状態報告メッセージは抑制される、
－ 制御コマンドはほぼ(nearly)順守された、すなわち、状態は制御コマンドの閾値マージン内で変更された：状態報告メッセージは抑制される、
－ 制御コマンドが概ねさえ順守されなかった、すなわち、状態は変更されなかった又は状態は制御コマンドの閾値マージンを超えて変更された：状態報告メッセージが送信される。

【0081】

コマンドが第１のデバイスから発信されていない場合、状態報告メッセージが送信される。

【0082】

制御コマンドが第１のデバイスから発信されていない場合、状態報告メッセージが送信される。

【0083】

斯くして、たとえコマンドが第１のデバイスから発信されているとしても、コマンドが順守されることができなかった場合、状態報告メッセージは送信される。例えば、被制御デバイスは、制御コマンドを（一部又は全部）順守するケイパビリティを有していない可能性がある。斯くして、状態レポートは、コマンドが（一部又は全部）従われなかったことに第１のデバイス（又は状態監視デバイス）が気付くことを保証するために送信される。例えば、コマンドは、サポートされていない色温度（例えば、５０００Ｋ）を設定するためのものである可能性がある。この場合、最も近い利用可能な色温度（例えば、４０００Ｋ）が設定され、設定値が報告される。コマンドは順守されなかったが、些細な不一致（例えば、丸め誤差又は量子化誤差等）である場合、状態レポートは抑制されてもよい。

【0084】

被制御デバイスは、制御コマンドの発信元のネットワークアドレスと、第１のデバイスでもある場合、属性報告メッセージの宛先のネットワークアドレスとを比較することにより、（例えば、光を変更するための）制御コマンドが第１のデバイスから発信されているかどうかを判断することができる。

【0085】

上述したように、いくつかのネットワーク構成では、レポートコレクタがコマンドの送信元とは異なるデバイスであるため、これは当てはまらない可能性がある。コマンドの１つ以上の送信元は、状態監視デバイスが帯域内又は帯域外の更新を受ける（すなわち、送信された又は送信されるであろう制御コマンドを認識する）ことができるように、状態監視デバイスに関連付けられてもよい。このオプションは、属性レポーティングの構成に１つ以上の追加パラメータを有することによって実施されてもよい。代替的に、被制御デバイスは、１つ以上のアドレスからの制御コマンドを受ける場合、属性レポートを送信しないように（例えば、何らかの製造者特有コマンドによって）指示されてもよい。制御コマンドがすべて監視機能に「知られる」、複数のコントローラが存在してもよく、この場合、複数のアドレスが使用されてもよい。

【0086】

斯くして、基本的なオプションの１つは、コマンドが、レポーティングメッセージの宛先でもあるネットワークデバイスから来る場合に報告しないことである。他のオプションは、コマンドが、特定のネットワークアドレスにマッチするネットワークデバイスから来る場合に報告しないことである。

【0087】

第１のデバイス１２は、（制御コマンドを送信するための第１のデバイストランスミッタ及び状態報告メッセージを受信するための第１のデバイスレシーバを有する）第１のデバイスコントローラトランシーバ２６と、ネットワーク状態データを記憶するメモリ２８とを有する。第１のデバイスプロセッサ３０は、トランスミッタを制御するために使用される。第１のデバイスプロセッサは、制御コマンド及び受信した状態報告メッセージに基づいてネットワーク状態メッセージをメンテナンスする。

【0088】

第１のデバイスが状態監視デバイスでもある例では、第１のデバイスは自身のコマンドが順守されたと仮定し、状態報告メッセージがそうでないことを示すまで、ネットワーク状態データ（例えば、テーブル）を更新する。斯くして、状態報告メッセージは、仮定された値をオーバーライドする。これにより、さもなければ関連する遅延を伴うポーリングを必要としていた、状態報告データの更新を迅速にすることができる。

【0089】

ネットワーク状態データは、ネットワーク状態を記憶するための任意のデータ構造又はデータベースであってよく、単一のテーブル、複数のテーブル、リスト、リンクリスト等の形態をとってもよい。

【0090】

第１のデバイス（コマンドの発信元）及び状態監視デバイス（レポーティングコレクタ）が同じデバイスであっても、属性レポーティングが依然として有用である状況があり得る。例えば、第１のデバイスが、照明器具を２０００Ｋの色温度に設定するためのコマンドを送信する可能性がある。しかしながら、デバイスは、デバイスに設けられたＬＥＤのケイパビリティに起因して２２００～５０００Ｋしかサポートしていない。この場合、これは、最も近い可能な値（２２００Ｋ）に処理されることになり、この場合、実際の値（２２００Ｋ）を報告することが必要であり、有用である。なぜなら、さもなければ、状態監視デバイスは、照明器具が実際に２０００Ｋに動いたと思い込むからである。

【0091】

指示された値からのこの「偏差(deviation)」を送信するかどうかの判断のために、既存のＺｉｇｂｅｅ（登録商標）閾値パラメータが、報告される前に値はどの程度変わるべきかを示すために使用されてもよい。この場合、偏差は、実際の値が最後に報告された値からどれだけ異なるかを示す。無論、代わりに、追加の（専用）パラメータが、属性レポーティングの構成に追加されてもよい。これは、例えば、照明器具が３００４Ｋの色温度になるように指示され、内部量子化に起因して、２９９２Ｋ、３００１Ｋ、３０１０Ｋ等の値にしかなれない場合等、非常に小さな変更のレポーティングを防止する。この場合、最も近い可能な値である３００１Ｋを使用することになるが、このわずかな偏差のレポートを送信することはほとんど意味がない。この場合、３Ｋの差は閾値を下回るので、レポートは送信されない。

【0092】

デバイスがコマンドを完全に順守できない（例えば、上記の２０００／２２００Ｋの例を参照）第１のデバイスによって送信されるコマンドの場合、データベースは、コマンドを送信する場合にまず状態監視デバイスによって（２０００Ｋに）更新されてもよい。照明器具が最も近い可能な値（２２００Ｋ）を採用し、新しい値を報告した後、データベースは、実際の値である２２００Ｋに更新される。

【0093】

照明器具が主電源スイッチ、Ｂｌｕｔｅｔｏｏｔｈ（登録商標）又は他のＺｉｇｂｅｅ（登録商標）コントローラ等の外部手段によって制御される場合、変更のソースが制御デバイスにリンクされていない又は状態監視デバイスに知られていないため、照明器具は、データベースを最新に保つために状態監視デバイスに報告する。

【0094】

主電源がオフされる場合、被制御デバイスは、電力が低下し始めたことを検出した場合にいわゆるラストブレスメッセージを送信し、状態監視デバイスに、デバイスが（ａ）オフになり（ｂ）もはや到達できなくなることを知らせてもよい。

【0095】

照明器具がストリーミングを介して制御される場合、属性レポーティングは送信されないであろう。状態監視デバイス（又は第１のデバイス）は、関与するアプリにデバイスの現在の設定を報告してもよく、又は、明るさ若しくは色の値の代わりに「変化している(varying)」という値を示してもよい。

【0096】

いくつかのコマンドは、ゆっくりとした遷移を伴う可能性がある。例えば、第１のデバイスが照明器具に「明るさ＝１％でオン(switch on with brightness=1%)」コマンド、続いて「３０分の遷移時間で明るさ＝７５％まで行く(go to brightness=75% with 30 minutes transition time)」コマンドを送信する、「ウェイクアップ」機能が実装される可能性がある。

【0097】

通常の属性レポーティングの場合、この結果、Ｘ秒ごとに照明器具からメッセージが生じ、データベース内の値はＸ秒に一度しか更新されないのに、照明器具は明るさを増加し続けるため、データベース内の値は実際の値より遅れることになる。

【0098】

これは、データベースに遷移が進行中であることを反映させ（例えば、「タイムスタンプＴＡで明るさ＝ＡからタイムスタンプＴＢで明るさ＝Ｂに移動(moving from brightness=A at timestamp TA to brightness=B at timestamp TB)」）、デバイス又はアプリが知る必要がある場合に、実際の状態が常に計算されることができるようにすることにより改善されることができる。このようにして、照明器具からの属性レポートは、このような遷移が進行中であることも反映する。この場合、状態報告メッセージは、「タイムスタンプＴＡで明るさ＝ＡからタイムスタンプＴＢで明るさ＝Ｂに移動(moving from brightness=A at timestamp TA to brightness=B at timestamp TB)」という形態であってもよい。

【0099】

無論、この状態報告メッセージは、コマンドが、状態監視デバイスから、又は状態監視デバイスが制御デバイスによって送信されたコマンドを認識する、該他の制御デバイスから発信される場合、送信される必要はないであろう。

【0100】

エンドポイントに到達した場合、又は他のコマンドによって遷移が中断される場合、属性報告メッセージが送信されてもよい。

【0101】

エンターテイメント及びストリーミングの場合、光の状態の何らかのインディケーションを有する要望があれば、Ｘ分ごとに送出されるメッセージが、過去Ｘ分間の平均の明るさ若しくは色、又は過去Ｘ分間の最小若しくは最大の明るさ若しくは色（座標空間ｘ、ｙ）を示してもよい。これは、照明器具が生成している効果の何らかのインディケーションを有するためにアプリによって使用されてもよい。

【0102】

追加的に、第１のデバイスプロセッサは、状態チェックのために被制御デバイスを定期的にポーリングしてもよい。斯くして、被制御デバイスは、状態変更に応答して即座にレポーティングを行うだけでなく、定期的なポーリングに基づいてよりゆっくりとしたレポーティングを行ってもよい。ポーリングは、例えば、報告メッセージの見逃しに対するセーフティネットを提供する。オーバールールビット又はフラグが、第１のデバイスが即時状態チェックを強制することを可能にするために使用されてもよい。

【0103】

図２は、被制御デバイスのうちの１つのためのネットワーク制御方法を示している。第１のデバイスは、被制御デバイスに制御コマンドを送信する。

【0104】

ステップ３０において、一つのこのような制御コマンドが受信される。

【0105】

ステップ３２において、被制御デバイスは、コマンドを順守できるかどうかを判断する。できる場合、ステップ３４において、被制御デバイスは、制御コマンドに応答して状態を変更する。

【0106】

ステップ３６において、被制御デバイスは、制御コマンドが第１のデバイスから発信されたかどうかを判断する。

【0107】

制御コマンドが第１のデバイスから発信されていて、順守された場合、ステップ３８において、状態報告メッセージの送信は抑制される、すなわち、（上述したように、第１のデバイス又は他の監視デバイスであってもよい）状態監視デバイスに送信されるメッセージはない。

【0108】

制御コマンドが第１のデバイスから発信されていない場合、ステップ４０において、状態報告メッセージが状態監視デバイスに送信される。

【0109】

被制御デバイスが（上述した光色温度の例における等）部分的に順守することができる場合、ステップ４２において、コマンドからの偏差が評価される。閾値を超える場合、状態報告メッセージが、再びステップ４０において送信される。

【0110】

差が閾値より小さい場合、方法はステップ３６に進む。斯くして、再び、制御コマンドが第１のデバイスから来ているか否かのチェックがある。そうではなかった場合、ステップ４０において状態報告メッセージが送信され、そうであった場合、ステップ３８において状態報告メッセージの送信は抑制される。

【0111】

遷移関数の実装は示されていないが、方法は上述したように拡張されてもよいことに留意されたい。

【0112】

図２に示されるネットワーク制御方法は、ステップ３２に関して３つのオプション、すなわち、「順守される」、「順守されない」、「部分的に順守される」を示しているが、「部分的に順守される」は必ずしも必要ではない。「部分的に順守される」が意味をなさないシンプルな例は、状態変更が二値状態変更である場合であり、ここでは、「部分的に順守される」は意味をなさない。しかしながら、光の調光が可能であるシステムにおける等、状態変更が二値ではない実施形態を考える場合であっても、厳守(strict compliance)が必要とされてもよく、この場合、「順守される」及び「順守されない」のみを使用することが設計上の判断があってもよい。しかしながら、このような判断は状態レポートの増加を代償とし、斯くして、より高いネットワーク負荷を招く可能性がある。

【0113】

図３は、状態監視デバイスのためのネットワーク制御方法を示している。

【0114】

ステップ５０において、ネットワーク状態データが初期化される。

【0115】

ステップ５２において、被制御デバイスに送信された制御コマンドが受信される場合、ステップ５４において、制御コマンドに基づいてネットワーク状態データがメンテナンスされる。

【0116】

ステップ５６において、（例えば、制御コマンドによって促された）ネットワーク状態報告メッセージが受信される場合、ステップ５８において、受信したネットワーク状態報告メッセージに基づいてネットワーク状態データが更新される。

【0117】

これら２つのブランチは並行して動作する。例えば、コマンドが先ず受信されてもよく、その後、ステップ５４における更新をオーバーライドすることになる、状態レポートが受信されてもよい。代替的に、状態レポートは、制御コマンドを受信することなく受信されてもよい。

【0118】

状態監視デバイスは、ネットワーク状態データを記憶する。とりわけ、状態監視デバイスは、送信された制御コマンドに基づく状態及び到来するレポートからの状態の両方を記憶する。状態は、既知の制御コマンドに応答して更新され、その後、状態報告メッセージが受信される場合にさらに更新される。

【0119】

本発明は、屋外照明ネットワーク（例えば、集中型コントローラがすべての街灯の状態のミラーを維持する、街灯）、又は代替的に、ビル制御システム若しくはコンシューマシステムにおける屋内照明ネットワークにとりわけ関心がある。

【0120】

第１のデバイスは、コマンドにおいて、属性レポーティングを必要とするか否かを指示してもよい。例えば、本発明の方法は、複数の可能な動作モードのうちオプションの動作モードとして設定されてもよい。

【0121】

上記の例は、中央コントローラと、中央コントローラ又は専用の監視デバイスに報告するデバイスのセットに基づいている。他の構成も可能である。例えば、状態に関心がある複数のパーティがあってもよい。中央コントローラ及び／又は状態監視デバイスは、被制御デバイスに属性レポーティングをセットアップすることができ、これは、レポーティングが送信される必要がある複数のエントリをもたらす可能性がある。

【0122】

ネットワークデバイス（例えば、携帯電話）はレポーティングが有効であるのに対し、中央コントローラはレポーティングが有効でなくてもよい。

【0123】

上述のように、Ｚｉｇｂｅｅ（登録商標）で定義される属性レポーティングは、最後に報告された値から有意な変更がある場合にレポートを送信する、及び、（このような有意な変更がない場合）依然としてＮ分ごとに報告メッセージを送信するように構成されることができる。このＮ分ごとのレポートは、報告メッセージを見逃した場合に関連し、最終的に、関心のある受信デバイスの「状態キャッシュ」が正しくなる。このＮ分ごとのレポートは、デバイスがまだ到達可能であるかどうかを判断するために使用されることもできる（デバイスは、電源が落とされている、又は接続不良に見舞われている可能性がある）。タイムアウトＮは、観察された挙動(observed behavior)に依存するようにされてもよい。例えば、デバイスが（レポートがＮ分ごとに来る、及び報告された値が「キャッシュ」とマッチすることを意味する）信頼できることが判明する場合、タイムアウトＮは増加されることができる。これは、トラフィック量を低減させる。デバイスが（レポートがＮ分ごとに来ない、又は報告された値が「キャッシュ」から外れ、他の制御ソースを示唆することを意味する）信頼できないことが判明する場合、当該デバイスについてタイムアウトＮは減少されることができる。

【0124】

デバイスが、ユーザによってある期間主電源が落とされることを示す、ある期間到達不能である場合、タイムアウトＮは、パワーダウンがより早く検出されるように減らされてもよい（「到達不能(non reachable)」の検出は、従来典型的には、Ｍ＊Ｎ分間メッセージが受信されなかった場合である（Ｍは、デバイスが到達不能であるとみなされるまでに必要とされるメッセージの欠落数を示す係数である））。

【0125】

システム内の一部のデバイスが上記の方法をサポートし、一部のデバイスはサポートしない状況では、第１のデバイス（中央コントローラ）は、措置の組み合わせを適用してもよい。例えば、上記の属性レポーティングは、これをサポートするデバイスに使用されてもよく、他のデバイスには通常の属性レポーティングが使用されてもよい。代替的に、上記の属性レポーティングは、これをサポートするデバイスに使用されてもよく、他のデバイスにはポーリングが使用されてもよい。

【0126】

また、属性レポーティングがポーリングと組み合わされる状況もあり得る。（別個の場合は状態監視デバイスと協働する）第１のデバイスは、通常、属性レポーティングに依存してもよい。しかしながら、特定の状況において、例えば、デバイスが（属性報告メッセージが失われたことを意味する）定期的に到達不能になる場合、追加的にデバイスをポーリングしてもよく、又はポーリングが「キャッシュ」と異なる値を示す場合、ポーリングレートを増加してもよい。しばらくして、ポーリングが再び一貫した値を示す場合、ポーリングレートは減少されることができる。

【0127】

ポーリングは、オン／オフ状態及び輝度レベル等の属性の現在の値をデバイスに問い合わせることを伴う。デバイスは、典型的には、これらのリクエストに答えることが義務付けられる。

【0128】

さらなる拡張は、被制御デバイスがある状況において不従順(disobedient)になり、変更がない場合には応答しないことを許容することである。現在、中央コントローラは、この場合、被制御デバイスは到達不能であるとみなすことになる。しかしながら、中央コントローラ及び被制御デバイスの両方がこのようなアプローチに適応される場合、メッセージの量が低減されることができる。

【0129】

例えば、第１のデバイスは、（システムが安定状態にある場合）回答がないように、可能であれば単一のコマンドにまとめて、多くのポーリングメッセージを各デバイスに定期的に送信してもよい。

【0130】

図面、本開示、及び添付の請求項の検討によって、開示される実施形態に対する変形形態が、当業者により理解されることができ、また、特許請求される発明を実施する際に実行されることができる。請求項では、単語「含む」は、他の構成要素又はステップを排除するものではなく、不定冠詞「１つの（a）」又は「１つの（an）」は、複数を排除するものではない。単一のプロセッサ又は他のユニットが、請求項において列挙される、いくつかの項目の機能を果たしてもよい。特定の手段が、互いに異なる従属請求項内に列挙されているという単なる事実は、これらの手段の組み合わせが、有利に使用され得ないことを示すものではない。コンピュータプログラムが上述されている場合、コンピュータプログラムは、他のハードウェアと共に、又は他のハードウェアの一部として供給される、光学記憶媒体又は固体媒体等の、好適な媒体において記憶／頒布されてもよいが、インターネット、又は他の有線若しくは無線の電気通信システム等を介して、他の形態で頒布されてもよい。「に適合される」という用語が特許請求の範囲又は明細書において使用される場合、「に適合される」という用語は、「に構成される」という用語と同等であることが意図されていることに留意されたい。請求項中のいかなる参照符号も、範囲を限定するものとして解釈されるべきではない。

【図1】

【図2】

【図3】

【国際調査報告】