(57)【特許請求の範囲】
【請求項１】
複数のネットワーク要素を含むネットワークを管理するための方法であって、
前記ネットワーク要素の属性を識別するステップと、
識別された属性の対応するものを少なくとも１つの属性グループへとグループ化するステップと、
前記少なくとも１つの属性グループのそれぞれの中の前記ネットワーク要素の選択されたものから属性データを集めるステップと、
前記選択されたものから集められた属性データに基づき、前記少なくとも１つの属性グループ内のネットワーク要素の各属性の状態を求めるステップと
を含む、方法。
【請求項２】
識別された属性が、ネットワーク要素に関連する静的な属性のグループから選択される、請求項１に記載の方法。
【請求項３】
前記静的な属性が、装置の種類、名前、位置、型式、モデル、及び製造から成るグループから選択される、請求項２に記載の方法。
【請求項４】
前記グループ化するステップが、
属性グループ内の属性間の相関を検証するステップ
を更に含む、請求項１に記載の方法。
【請求項５】
前記属性グループ内の前記属性間の相関を欠く属性を除去するステップ
を更に含む、請求項４に記載の方法。
【請求項６】
属性データを集めるステップが、
ネットワーク要素に関連する動的な属性データを集めるステップ
を更に含む、請求項１に記載の方法。
【請求項７】
前記動的な属性データが、調光レベル、負荷電流、負荷電圧、及び温度から成るグループから選択される、請求項６に記載の方法。
【請求項８】
前記ネットワーク要素の選択されたものからデータを集めるステップが、
比率Ｍ／Ｎを定めるステップであって、Ｎは対応する属性グループ内の要素の数であり、ＭはＮ未満である、ステップと、
対応する属性グループ内の要素ごとに
０から１の範囲内にある乱数Ｒを生成するステップと、
Ｒ＜Ｍ／Ｎが成立する場合、前記要素に関連する対応する属性値を伝送するステップと
を含む、請求項１に記載の方法。
【請求項９】
前記ネットワーク要素の選択されたものからデータを集める前記ステップが、既知の期間Ｐで行われる、請求項８に記載の方法。
【請求項１０】
前記複数のネットワーク要素の中の２つのネットワーク要素がそれぞれのベンダを持ち、対応する属性の前記求められた状態が閾値を上回る場合、作業工程を生成するステップと、
前記作業工程を満たすように２つ以上の前記ベンダ間で作業工程を調節するステップと、
を更に含む、請求項１に記載の方法。
【請求項１１】
複数のネットワーク要素を含むネットワークを管理するためのシステムであって、
属性情報を受け取る受信システムと、
メモリと通信するプロセッサと
を含み、前記メモリは、前記プロセッサによってアクセスされるとき、
前記ネットワーク要素の属性を識別すること、
識別された属性の対応するものを少なくとも１つの属性グループへとグループ化すること、
前記少なくとも１つの属性グループのそれぞれの中の前記ネットワーク要素の選択されたものから属性データを集めること、
前記選択されたものから集められた属性データに基づき、前記少なくとも１つの属性グループ内のネットワーク要素の各属性の状態を求めること
を前記プロセッサに行わせるコードを含む、システム。
【請求項１２】
前記グループ化することが、
属性グループ内の属性間の相関を検証すること
を更に含む、請求項１１に記載のシステム。
【請求項１３】
前記属性グループ内の前記属性間の相関を欠く属性を除去すること
を更に含む、請求項１２に記載のシステム。
【請求項１４】
前記ネットワーク要素の選択されたものからデータを集めることが、
比率Ｍ／Ｎを定めることであって、Ｎは対応する属性グループ内の要素の数であり、ＭはＮ未満である、定めること、
対応する属性グループ内の要素ごとに
０から１の範囲内にある乱数Ｒを生成すること、
Ｒ＜Ｍ／Ｎが成立する場合、前記要素に関連する対応する属性値を伝送すること
を含む、請求項１１に記載のシステム。
【請求項１５】
前記複数のネットワーク要素の中の２つのネットワーク要素がそれぞれのベンダを持ち、
前記プロセッサは、
対応する属性の前記求められた状態が閾値を上回る場合、作業工程を生成すること、及び
前記作業工程を満たすように２つ以上の前記ベンダ間で作業工程を調節すること
を更に行う、請求項１１に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、照明ネットワークシステムの分野に関し、より詳細には、屋外照明システム向けの適応測定及び調整された保守を行うためのシステムに関する。
【背景技術】
【０００２】
ＭＥＭＳ、計算、及び通信技術の進歩により、屋外照明を遠隔的且つインテリジェントに管理できるようにするために屋外照明ネットワーク（ＯＬＮ：Ｏｕｔｄｏｏｒ  Ｌｉｇｈｔｉｎｇ  Ｎｅｔｗｏｒｋ）が幾つかの企業によって導入されている。図１に示されている従来の屋外照明管理システム１００は、２層アーキテクチャを有し得る。下位層では、照明地点が区間へとグループ化される。各区間は屋外照明ネットワーク（ＯＬＮ）１１０、１２０、１３０を形成し、それらは送電線や無線周波（ＲＦ）等の異なる通信技術に基づき得る。上位層では、中央管理システム（ＣＭＳ：Ｃｅｎｔｒａｌ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ）１５０がＩＰネットワーク１４０を介して区間コントローラ（ＳＣ：Ｓｅｇｍｅｎｔ  Ｃｏｎｔｒｏｌｌｅｒ）に接続し、それらのＳＣを介して照明地点を管理する。実際には、（対応するネットワークの）ＳＣ１１０．１、１２０．１、１３０．１が屋外の遠隔地に導入されるので、ＣＭＳとＳＣとを接続するネットワークは有線、無線、及び／又はセルラネットワークであり得る。各照明地点（即ちネットワーク要素）がセルラネットワークを介して到達可能な場合、ＣＭＳ１５０は各照明地点を直接管理することもできる。
【０００３】
遠隔モニタリングは、故障を検出し又は予測するための屋外照明管理の１つの不可欠な部分である。この遠隔モニタリングは、離れたＯＬＮから状態の測定値を取得することに依拠する。例えば、点灯時間、電流、電圧、及び他の属性がモニタリング機能によって取得され得る。その一方で、交通モニタリングや汚染モニタリング等、何らかのスマートシティアプリケーションを支援するために、照明地点に取り付けられたセンサから他の感覚データが集められても良い。従って、ＳＣ１１０．１、１２０．１、１３０．１、又は照明地点から、ＣＭＳ１５０に測定値を中継する（有線、無線、及び／又はセルラ）ネットワークが通信のボトルネックとなり、運営費の大部分を構成する。例えば、１０００箇所の照明地点がある小都市で、ＣＭＳ１５０が１５分ごとに８０バイトの測定サンプルを各照明地点から１つ集めると仮定すると、総トラフィックは１カ月当たり２３０．４ＭＢである。実際には、メッセージングのオーバーヘッドがあるのでこの値は通常はるかに大きい。この場合、小都市でのＯＬＮの測定単独での年間費用は、（例えばセルラ）ネットワークプロバイダによって課される料金にもよるが約＄５，０００にもなり得る。
【０００４】
更に、保守は、都市の屋外照明に関する最も一般的で重要な作業の１つである。実際には、保守サービスは顧客（即ち都市）又はベンダによって提供され得る。保守サービスは、顧客とベンダとの両方によって共同で提供されても良い。例えば、顧客が装置を清掃してランプを付け直す責任を負う場合がある一方で、ベンダはネットワーク接続を維持することができる。しかしながら、これらの保守モデルの何れの場合も、ＯＬＮシステムの統合及び情報共有の難しさが原因で保守エンティティ（顧客、ベンダ）は連携を欠く。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
従って、ＯＬＮを効率的に管理してネットワークのオーバーヘッド及び維持費を減らすために、効率的な通信を提供する方法及びシステムが当業界で求められている。
【課題を解決するための手段】
【０００６】
本発明の一態様では、複数のネットワーク要素を含む屋外照明ネットワークを管理するための方法が開示されている。この方法は、ネットワーク要素の属性を識別するステップと、前述の識別された属性の対応するものを少なくとも１つの属性グループへとグループ化するステップと、少なくとも１つの属性グループのそれぞれの中のネットワーク要素の選択されたものから属性データを集めるステップと、集められた属性データに基づき、少なくとも１つの属性グループ内のネットワーク要素の各属性の状態を求めるステップとを含む。
【０００７】
本発明の一態様では、比率Ｍ／Ｎを定めることにより、前述のネットワーク要素の選択されたものからデータを集めることによってグループ内の要素間で集められるデータ量が制限され、ここでＮは対応する属性グループ内の要素の数であり、ＭはＮ未満であり、対応する属性グループ内の要素ごとに乱数Ｒを生成し、Ｒは０から１の範囲内にあり、Ｒ＜Ｍ／Ｎが成立する場合、その要素に関連する対応する属性値を伝送する。
【０００８】
本発明の別の態様では、複数のネットワーク要素を含む照明ネットワークを管理するためのシステムが開示されており、このシステムは、属性情報を受け取る受信システムと、メモリと通信するプロセッサとを含み、メモリは、プロセッサによってアクセスされるとき、ネットワーク要素の属性を識別すること、前述の識別された属性の対応するものを少なくとも１つの属性グループへとグループ化すること、少なくとも１つの属性グループのそれぞれの中のネットワーク要素の選択されたものから属性データを集めること、及び集められた属性データに基づき、少なくとも１つの属性グループ内のネットワーク要素の各属性の状態を求めることをプロセッサに行わせるコードを含む。
【０００９】
本発明の更に別の態様では、複数のベンダを含むシステムが開示されており、各ベンダは複数のネットワーク要素のネットワークを管理し、このシステムは、ベンダのそれぞれから状態情報を受け取ることであって、その情報は対応するネットワーク内の要素に関連する少なくとも選択された属性を含む、受け取ること、ネットワークのそれぞれの間で属性情報をモニタすること、対応する属性の状態が閾値を上回る場合に少なくとも１つの作業工程を生成すること、及び前述の作業工程を満たすように、少なくとも１つの作業工程をベンダ間で調節することを行う受信システムを含む。
【００１０】
添付図面に関連して詳細に説明される例示的実施形態を検討するとき、本発明の利点、性質、及び様々な更なる特徴がより完全に明らかになり、添付図面では、同様の要素を識別するために同様の参照番号が図面全体を通して使用される。
【図面の簡単な説明】
【００１１】
【図１】従来のコマンド管理システム（ＣＭＳ）を示す。
【図２】本発明の原理による一例示的プロセスを示す。
【図３】本発明の原理による一例示的プロセスの流れ図を示す。
【図４】本発明の原理による一例示的メッセージ形式を示す。
【図５】様々なオペレータが対応するネットワークを個々に管理する一例示的ネットワーク構成を示す。
【図６】様々なネットワーク及びオペレータ間の効率的調整を行うための一例示的実装形態を示す。
【図７】本発明の原理による一例示的保守作業の流れのプロセスを示す。
【図８】本発明の原理による一例示的保守調整プロセスを示す。
【発明を実施するための形態】
【００１２】
本発明を明確に理解することに関連する要素を示すために、本明細書に記載される本発明の図面及び説明は、明瞭にする目的で他の多くの要素を省きながら単純化されていることを理解すべきである。但し、それらの要素は当技術分野で良く知られており、本発明をより十分に理解する助けにはならないので、かかる要素の説明は本明細書では行われない。本明細書の開示は、当業者に知られる改変形態及び修正形態も対象とする。
【００１３】
本発明の一態様では、不要な測定サンプルをなくすことで照明地点からＣＭＳまでのトラフィック量を減らすことにより、オーバーヘッド及び関連費用の低減が実現され得る。例えば、２つの照明地点が短期間のうちに設置される同じ照明器具を有する場合、それらの照明器具が同じ調光レベルで動作するのであれば２つの照明地点の負荷電流は同じであり得る。この相関関係を使用することにより、２つの照明地点の片方の電流のサンプルだけが取られても良く、２つの照明地点に単一のサンプルが使用され得る。２つの照明器具のサンプルの何れかに関する選択は、２つの照明器具のうちの決まった片方を選択することに基づいて、ラウンドロビン式に（即ち次の照明器具を選択すること）、又は無作為に行われ得る。
【００１４】
屋外照明測定における適応サンプリングが、管理システムが既に利用可能な照明の属性に基づく測定において相関を示したので、本明細書に記載の適応サンプリング方法は有利である。
【００１５】
本明細書に記載の適応サンプリングに加え、照明地点からＣＭＳまでのトラフィック量を減らすために、データ圧縮及び／又はデータ集約が使用されても良い。これらの方法は本明細書に記載の本発明の方法と無関係であり、従って一緒に用いて測定費用を更に節約することができる。
【００１６】
提案される方法は他のＯＬＮ装置（例えば温度センサや周辺光センサ）の測定値を集めるために応用され得るが、センサ測定値の相関の精度は、予測及び定量化が困難な屋外環境に依存する。従って、本発明は、照明に関係する測定値の相関を発見することに重点を置く。
【００１７】
図２は、本発明の原理による一例示的プロセス２００を示す。この例示的プロセスでは、ブロック２１０で、ＯＬＮ装置又はネットワーク要素の属性が集められ、ＣＭＳ内に記憶される。ブロック２２０で、モニタされる属性のうちの所望の属性を有する装置が、対応する相関グループにまとめられる。ブロック２３０で、グループ内の装置間の相関関係が実際にあるかどうかの判定（即ち検証）が行われる。相関関係が有効でない、又はない場合、ブロック２４０でその相関グループが破棄される。しかしながら、相関グループが有効だと判定される場合、ブロック２５０で、相関グループ内の要素をサンプルするために本明細書に記載の適応的方法が使用される。
【００１８】
図３は、本発明の原理による一例示的プロセスの流れ図３００を示す。この例示的プロセスでは、ＯＬＮ装置が導入された後、ブロック３１０でその静的特徴が集められる。この収集は、設置エンジニアによって手動で、又は自らの特徴（属性）を登録するためにＣＭＳへの接続を開始するＯＬＮ装置によって動的に行われ得る。集められる静的特徴は、装置の種類、装置を識別し、その装置と通信するためにＣＭＳによって使用される装置のアドレス、設置日、装置名、製造業者、モデル番号、シリアル番号等、並びに装置の位置を含み得る。これらの静的特徴（即ち属性）は、装置が導入された後は静的である。これらの静的特徴は、交換又は修理が行われる場合にのみ更新される。
【００１９】
ブロック３２０で、ＯＬＮ装置が静的特徴に基づいてグループに取り込まれ、又は複数の装置の静的特徴に基づいて装置のグループが形成され得る。例えばグループは、装置の種類及び設置日に基づいて形成され得る。例えば製造業者に基づき、他の相関グループが形成されても良い。
【００２０】
ブロック３３０で、グループ内の要素又は装置の動的特徴が集められる。動的特徴又は属性の値は、負荷電流、負荷電圧、出力輝度、装置温度、環境温度等の値であり得る。
【００２１】
ブロック３４０で、グループのＯＬＮ装置又は要素間の相関の検証が行われる。各相関グループ内のＯＬＮ装置は、グループを形成する属性の値の強い相関関係を有するものとする。例えば、負荷電流の相関グループは、照明器具のモデル及び調光レベルに基づいて構築され得る一方で、負荷電圧の相関グループは、装置が接続される電力網の区間に基づいて構築され得る。
【００２２】
相関が強くないと判定された装置は、グループから除去される。その後、これらの除去された装置が、ブロック３５０で他の同様の装置とグループ化される。このグループ化のプロセスは、ネットワーク内の装置が少なくとも１つのグループ内に含まれるまで繰り返される。
【００２３】
ブロック３６０で、相関グループ内のＯＬＮ装置又は要素がサンプルされる。サンプリングは、複数の方法のうちの１つ又は複数を使用して行われ得る。例えばサンプリングは、サンプルする１つ又は複数の装置をグループから無作為に選択することができ、又はサンプルは、１つ又は複数の装置からラウンドロビン式に選択されても良い。従って、グループの特性を定める限られた数のサンプルがＣＭＳに与えられる。更に、限られた数のサンプルは、グループ内の要素間の強い相関関係を更に検証するために使用されても良い。
【００２４】
本発明の別の例示的態様では、スケジュールを使用してサンプリングが設定されても良く、Ｎ台の装置のグループを所与として、Ｍ台の装置のサブセットが期間又は周期Ｐごとにサンプルされても良い。この場合、ＣＭＳは（Ｍ，Ｎ）に関する情報をグループ内の装置に送ることができる。Ｐの各期間内に、グループ内の各装置が無作為の数Ｒを生成する。例えば、装置は（０，１）内の一様分布を実現することができる。
【００２５】
次いで装置は、Ｒ＜Ｍ／Ｎか、Ｒ＞Ｍ／Ｎかを判定することができる。装置がＲ＜Ｍ／Ｎであると判定する場合、装置は対応する属性をＣＭＳに報告する。さもなければ、装置は属性を報告しない。このようにして、確率に従い、グループ内のＮ台の装置のうちＭ台の装置が自らの属性をＣＭＳに報告する。従って、モニタされる動的属性ごとに、ＯＬＮ装置はＣＭＳからのメッセージによって構成される３つのパラメータＭ、Ｎ、及びＰを保持する。
【００２６】
その結果、Ｎ台の装置のグループのうちＭ台の装置しか属性データを提供しないので、グループの属性をサンプリングする際のオーバーヘッドが大幅に低減される。対応する属性をどの装置が報告するのかを決定する確率論的方法を使用することは、報告を提供する要素の更なる分散ももたらす。例えば３つの属性が報告される場合、選択された数の装置が自らの３つの属性を報告するのではなく、Ｍ台の装置のそれぞれがグループに関連する属性を報告する。これにより、著しく多くのものから属性の組み合わせられた数を受け取ることができる。
【００２７】
図４は、ＣＭＳからグループ内のＯＬＮ装置にサンプリング情報を伝えるための一例示的メッセージ形式を示す。この事例では、ブロック４１０において要求識別情報が提供される。送信者及び受信者に関するアドレス情報が、ブロック４２０及びブロック４３０のそれぞれにおいて提供される。ブロック４４０において構成メッセージ形式が提供され、ブロック４５０において所望の属性が提供される。ブロック４６０においてサンプリングのパラメータ（Ｍ，Ｎ，Ｐ）が提供される。
【００２８】
理解されるように、異なる属性が異なる期間又は周期（Ｐ）で、Ｎ台の装置のグループ内の異なる数の装置（Ｍ）を使用して提供され得る。従って、例えば２つの属性に基づいて形成されるグループでは、各属性が異なるレートで異なる装置（Ｍ）からＣＭＳに提供され得る。
【００２９】
従って、本発明のこの例示的態様によれば、ＯＬＮ装置の属性のサンプリングは、所望の期間の開始時に集められる（即ち問合せ）のではなく、所望の期間中に間隔を空けることができる。
【００３０】
ＯＬＮ管理の別の重要な側面においては、本明細書に記載のＯＬＮ装置とＣＭＳとの間の通信を減らすための方法は、ＯＬＮの保守にも適用可能である。多くの保守モデルにおいて、ＯＬＮシステムの統合及び情報共有の難しさが原因で保守エンティティは連携を欠く。
【００３１】
図５は、異なるオペレータ（ＣＭＳ  Ａ、ＣＭＳ  Ｂ、ＣＭＳ  Ｃ）が対応するネットワークＯＬＮ  Ａ、ＯＬＮ  Ｂ、及びＯＬＮ  Ｃを個々に管理する一例示的ネットワーク構成を示す。それぞれのＣＭＳオペレータによって、点灯時間、電流負荷、電圧負荷等の特徴に関して先に論じられたように、これらのネットワークのそれぞれの属性が集められ得る。
【００３２】
しかしながら、ネットワーク間でＯＬＮ装置の保守が重複する場合、効率的な保守に必要な情報が異なるオペレータの間で適切に相関されない。
【００３３】
図６は、異なるネットワーク及びオペレータ間の効率的調整を行うための一例示的実装形態を示す。
【００３４】
この例示的構成では、ＣＭＳ６１０が、対応するベンダ管理システムＶＭＳ  Ａ６２０、ＶＭＳ−Ｂ６３０、ＶＭＳ−Ｃ６４０によって管理されるネットワークＯＬＮ  Ａ、ＯＬＮ  Ｂ、ＯＬＮ  Ｃのそれぞれの要素のうちの選択されたものと更に通信する。先に論じられたように、ＣＭＳ６１０（及びＶＭＳ）は対応するＯＬＮ内の装置をグループ化し、対応するＯＬＮ内の装置からサンプルデータを受け取る。次いでＣＭＳ６１０は、ネットワークを担当する対応するネットワークオペレータ（ＶＭＳ）と装置の保守を調整することができる。更に、各ＶＭＳ６２０、６３０、６４０は、通信オーバーヘッドを減らしながらＯＬＮの状態をモニタし、ＯＬＮ装置を保守する必要性を判定するために、本明細書に記載のグループ化及びサンプリング方法を利用しても良い。
【００３５】
従って、ＣＭＳ６１０及び各ＶＭＳ６２０、６３０、６４０の両方が、装置を保守する必要があるかどうかを判定するために、又は保守が何時必要であり得るのかを予測するために、対応するネットワーク内のグループ中の所望の数の装置からサンプル情報を受け取ることができる。
【００３６】
ＯＬＮの保守を調整する利点は明白である。例えば近くにある２つの照明が故障した場合、１つの保守チームが、交通費を節約するようにその両方の照明を修理するために派遣され得る。２つの照明が２つのエンティティ（例えば２つのベンダ）によって保守される場合、その２つのエンティティは保守情報を共有し、保守作業を調整しようとする可能性がある。ＯＬＮ保守調整の問題は、ＯＬＮが異なるエンティティによってモニタ及び保守される場合に起こる。実際に、都市が様々な製造業者／ベンダの製品を選択し、更に様々な領域／区間（例えば道路や公園）が異なるエンティティによって管理されるので、この問題は現実に発生する。
【００３７】
従って本発明の原理によれば、先に説明されたように、各ＶＭＳが、対応するネットワーク内でＣＭＳ６１０にさらされるＯＬＮ装置（例えば区間コントローラ、照明地点、照明器具、及びセンサ）の属性を動的に構成する。従って、ＣＭＳ６１０は先に説明されたようにＯＬＮ装置の属性を発見することができ、対応するＶＭＳによって指定されたグループ内のＯＬＮ装置は、提供されるスケジュールによって指示される通りに報告する状態をＣＭＳ６１０から受け取ることができる。同様に、ＶＭＳ６２０、６３０、６４０は、対応するネットワーク内のＯＬＮ装置に関する状態をＣＭＳに報告することができる。
【００３８】
例えば、ＶＭＳ６２０、６３０、６４０は、対応するネットワーク内のより多数の装置からのより速い報告速度に備え得り、ＣＭＳ６１０は、ネットワーク間のより少数の装置からのより遅い報告速度に備え得る。ＶＭＳ６２０、６３０、６４０、及びＣＭＳ６１０は、様々な予測（projection）モデルを使用して潜在的な故障及び／又は保守を行う必要性を予測することができる。
【００３９】
ＯＬＮ内の装置の異常（例えば劣化、故障）を検出し又は予測するために、区間コントローラ、照明地点、照明器具、センサ等のＯＬＮ装置から属性値を集めることが必要とされる。先に論じられたように、表１は、集められる照明地点の属性の一例を示す。これらの値は、装置の静的な値及び動的な値の両方を表し、集められ得る属性の全範囲を表すものではない。
【００４０】
【表１】
0006422862.tif 000002
【００４１】
本発明の一態様では、ＯＬＮ装置の属性情報を集めるために、ＣＭＳ６１０がＯＬＮ装置への直接接続を確立することができる。しかしながら、ＣＭＳ６１０は属性の一部にしかアクセスできない一方、他の属性はＶＭＳ６２０、６３０、６４０しか確認することができない可能性がある。例えば、負荷電流及び負荷電圧が顧客（例えばＣＭＳ）に開示され得る一方で、コントローラの電流及び電圧はベンダ（ＶＭＳ）によって保護されても良い。
【００４２】
別の実施形態では、ＣＭＳが対応するＶＭＳ６２０、６３０、６４０を介してのみＯＬＮ装置と通信することができ、この実施形態ではＶＭＳ自体がＯＬＮ装置のように機能する。この場合もやはり、ＶＭＳは関連するＯＬＮ装置の属性の一部だけをＣＭＳ６１０に開示することができる。これらの実施形態の何れの場合も、ＶＭＳ６２０、６３０、６４０は装置の属性の可視性を構成する必要がある。図１に示されている本発明の別の実施形態では、全ての属性がベンダによって集められ、この可視性の構成が不要であることに留意されたい。
【００４３】
属性の可視性は、工場から事前に構成されても良い。属性の可視性は、コミッション段階又は動作段階中に構成されても良い。コミッショニング中、設置作業員によって使用されるコミッショニングツールにより、装置は自らの属性の一覧をＶＭＳ６２０、６３０、６４０の何れかに送ることができる。次いで、ＶＭＳ６２０、６３０、６４０又はコミッショニングツールが、ＣＭＳ６１０に公開することを許可された属性の一覧を用いて装置に応答する。動作段階中、ＶＭＳは、有効化メッセージ又は無効化メッセージを装置に送ることにより、装置の属性の可視性を動的に変更することができる。
【００４４】
装置がＣＭＳ６１０の情報、並びにＣＭＳ６１０にとって確認可能な属性の一覧を明らかにした後、その装置は、自らを公開属性に登録するためにＣＭＳ６１０への接続を開始することができる。更に、装置は、ＣＭＳ６１０に情報をアップロードするコミッショニングエンジニアによって手動で登録されても良い。その後、ＣＭＳ６１０は装置への接続を開始して属性の一覧を確認する。
【００４５】
動作中に属性の可視性が変えられる場合、ＯＬＮ装置がＣＭＳ６１０に通知を送る。新たな属性が確認可能になる場合（例えば新たな種類が測定可能）、ＯＬＮ装置がＣＭＳ６１０に知らせる。ＣＭＳ６１０が、不可視であると決定されている或る属性を現在測定している場合、装置はエラーメッセージを更に生成する。
【００４６】
先に説明されたように、ＣＭＳ及びＶＳＭはどちらも、ＯＬＮ装置に対して自らの属性の状態を報告するように要求することができる。ＣＭＳ及びＶＭＳの両方によって測定が要求される場合、装置は測定をＶＭＳ６２０、６３０、６４０にだけ送信し、その測定がＶＭＳによってＣＭＳに転送されなければならないことをメッセージ内で指示することができる。ＣＭＳ６１０及びＶＭＳ６２０、６３０、６４０は典型的には共にインターネット上のサーバなので、この方法は装置からサーバへのボトルネックになっているアップリンクを省く。
【００４７】
装置の属性値は故障を検出するためだけでなく、故障を予測するためにも使用され得る。ＣＭＳ６１０及びＶＭＳ６２０、６３０、６４０はどちらも、自らが集めた情報に基づいて故障を検出及び予測し、具体的な優先順位及び必要とされる作業員の専門分野を示す作業工程を生成するための独自のモデルを有することができる。
【００４８】
例えば、規定された照明の寿命及び集められた点灯時間の情報を用いて、ＣＭＳ６１０は、点灯時間に応じて徐々に減少する照明の残留寿命を予測することができる。即ち、例えばＣＭＳ６１０又はＶＭＳ６２０は、集められた情報に基づいて或る傾向を求め、その傾向がいつ閾値を上回るのかを断定することができる。閾値は、故障又は故障に近い状態を示し得る。
【００４９】
従って、付近の照明のグループが比較的同じ残留寿命を有する場合、それらの照明が一緒に保守されても良い。その一方で、ＶＭＳ６２０、６３０、６４０は更なる情報、例えばランプの温度にアクセスできても良い。ＶＭＳ６２０、６３０、６４０はこの情報を使用して照明の出力性能を予測し、その出力が閾値を下回る場合にランプを交換することに決めることができる。
【００５０】
本発明の別の態様では、ＣＭＳ６１０及びＶＭＳ６２０、６３０、６４０が、グループ及び／又はネットワーク内の装置の保守を行う際の作業の流れを調整することができる。作業工程の優先順位は故障の種類だけでなく、地理的位置によっても決まる。幹線道路又は交差点上の照明地点が故障する場合、かかる故障は田園道路上の照明地点の故障よりも高い修理の優先順位を有するべきである。様々な場所の種類の優先順位は、規格と法規から得られ得る。更に、ＯＬＮによって交通情報が集められる場合、交通量に比例して優先順位が設定されても良い。
【００５１】
ＣＭＳ６１０及びＶＭＳ６２０、６３０、６４０はどちらも、自らが集めたＯＬＮデータに基づいて作業工程を生成することができる。
【００５２】
従って、保守サービスが中央機関によって提供される場合、ＣＭＳ６１０及びＶＭＳ６２０、６３０、６４０によって生成される全ての作業工程が統合され、それに応じて保守作業員を派遣させることができる。
【００５３】
図７は、本発明の原理による一例示的作業工程のプロセス７００を示す。この図示の例では、保守サービスが複数のエンティティ（例えば異なるベンダＶＭＳ  Ａ、ＶＭＳ  Ｂ）により独自の保守作業員を使って提供される場合、保守エンティティ間の調整が必要とされる。
【００５４】
例えば、ベンダＶＭＳ  Ａ７１０及びＶＭＳ  Ｂ７２０のそれぞれは、例えば図３に関して説明されたようにネットワーク要素の属性の測定を行う（又はデータを集める）こと（７３０）により、その対応するネットワーク内の要素の特性を求めることができる。
【００５５】
ベンダ７１０、７２０のそれぞれは、同じく前に説明されたように対応するネットワークの要素の異常（又は異常が発生する可能性）を更に明らかにし（７４０）、作業工程を生成することができる（７５０）。
【００５６】
この例示的事例では、作業工程を完了するのに必要な活動を調整するために、異常及び作業工程に関する情報がＣＭＳユニット７７０に与えられ得る。ＣＭＳユニット７７０は更に、ネットワーク要素からデータを集め（７７５）、異常を明らかにし（７８０）、作業工程を生成する（７８５）ことができる。
【００５７】
その後ＣＭＳ７７０は、異常を直すために作業員を派遣し、又は作業員の派遣を調整して異常を適時に高効率で直すためにＶＭＳ７１０、７２０の１つ又は複数にスケジュールを提供することができる。従って、ＣＭＳの調整により、ＶＭＳ７１０、７２０は、従業員が適切な時間に派遣されるようにスケジュールすることができる。
【００５８】
図８は、エンティティ間の効率的調整をもたらすために、複数の保守エンティティ間の作業を調整するプロセスの一例を示す。各エンティティは、独自の専門分野を持つエンジニアの一覧を有する。各作業工程は、必要とされる作業員の専門分野の種類及び数を有する。例えば、作業工程Ｗ１は、２つの専門分野Ｓ１及び１つのＳ２を必要とする。その場合、エンジニアＥ１、Ｅ２、及びＥ３を派遣してＷ１に従事させることができる。更に、Ｗ２はＷ１と独立しているので、エンジニアＥ４を派遣してＷ２に従事させることができる。しかしながら、Ｗ３はＷ１が完了したときにしか開始することができない。
【００５９】
この例示的な例では、作業工程が生成された後、その作業工程がその指定の保守エンティティに送られる。各エンティティは、スケジューリングアルゴリズムを使用して自らの作業工程をスケジュールすることができる。それに加え、各エンティティは、自らの作業工程一覧及び予定、進行中、スケジュール準備完了、他の作業工程の待機中等の対応する状態も保持する。更に、スケジュールされた各作業工程は融通性の時間枠を有しても良く、この時間枠の中では全体的な作業工程のスケジューリングに影響することなしに各作業工程が何時でも自由に開始され得る。例えば図８に示されているように、作業工程Ｗ２は、作業工程Ｗ１よりも遅くならずに終えることができる限り、何時でも開始される融通性を有する。
【００６０】
保守エンティティは、自らの作業工程一覧並びにその状態及び融通性の時間枠を公開／サブスクライブ方式によって共有することができる。例えば、各エンティティは一覧を自らのウェブサイト又はオープンデータベース上で公開することができ、又は特定の種類の（例えば特定の地域内の又は特定の作業の種類を伴う）作業工程をサブスクライブしている他のエンティティに新規の作業工程を送ることができる。
【００６１】
各エンティティは、他のエンティティからのスケジュールされた作業工程及び進行中の作業工程に対して自らのスケジュールされた作業工程を調べる。エンティティが調整の可能性を見出す場合、そのエンティティは他のエンティティと交渉を始める。調整の可能性とは、２つの作業工程が非常に近い位置にあり、それらの融通性が時間枠の重複を許容することであり得る。その後、備品を共有し又は交通の混乱を減らすことができるよう、２つの作業工程が同時であるようにスケジュールされ得る。
【００６２】
本発明による上記の方法は、ハードウェア、ファームウェアによって、又はＣＤ  ＲＯＭ、ＲＡＭ、フロッピディスク、ハードディスク、光磁気ディスク等の記録媒体内に記憶可能なソフトウェア若しくはコンピュータコードとして、又は元々離れた記録媒体若しくは非一時的な機械可読媒体上に記憶されており、ローカル記録媒体上に記憶される、ネットワークを介してダウンロードされるコンピュータコードとして実装されても良く、それにより本明細書に記載の方法を、汎用コンピュータ若しくは専用プロセッサを使用して記録媒体上に記憶されるかかるソフトウェアによって、又はＡＳＩＣやＦＰＧＡ等のプログラム可能若しくは専用ハードウェアによって果すことができる。当技術分野で理解されるように、コンピュータ、プロセッサ、マイクロプロセッサ、コントローラ、又はプログラム可能ハードウェアはメモリ要素、例えばＲＡＭ、ＲＯＭ、フラッシュ等を含み、かかるメモリ要素は、コンピュータ、プロセッサ、又はハードウェアによってアクセスされ、実行されるとき、本明細書に記載の処理方法を実施するソフトウェア又はコンピュータコードを記憶し若しくは受け取ることができる。更に、本明細書に示される処理を実施するためのコードに汎用コンピュータがアクセスする場合、コードを実行することが、その汎用コンピュータを本明細書に示される処理を実行するための専用コンピュータに変えることが理解される。
【００６３】
本発明の基本的特徴及び新規の特徴が、本発明の好ましい実施形態に適用されるものとして図示され、説明され、指摘されてきたが、説明された機器、開示された装置の形式、詳細、及びその動作における様々な省略、置換、及び変更が、本発明の趣旨から逸脱することなく当業者によって加えられても良いことが理解される。
【００６４】
同じ結果を実現するためにほぼ同じ方法でほぼ同じ機能を果たす要素のあらゆる組合せが、本発明の範囲に含まれることが明確に意図される。記載された或る実施形態の要素を別の実施形態の要素に置換することも完全に意図され、考えられる。
【図１】
0006422862.tif 000003
【図２】
0006422862.tif 000004
【図３】
0006422862.tif 000005
【図４】
0006422862.tif 000006
【図５】
0006422862.tif 000007
【図６】
0006422862.tif 000008
【図７】
0006422862.tif 000009
【図８】
0006422862.tif 000010