JP2009187554A

JP2009187554A - 検知システム拡張システム及び方法

Info

Publication number: JP2009187554A
Application number: JP2009025147A
Authority: JP
Inventors: Maurice Chu; チュモーリス; Juan Liu; リウジュアン
Original assignee: Palo Alto Research Center Inc
Current assignee: Palo Alto Research Center Inc
Priority date: 2008-02-11
Filing date: 2009-02-05
Publication date: 2009-08-20
Also published as: US9104430B2; US20090204370A1; JP2014170582A

Abstract

【課題】検知システムの拡張性とシステム構成の単純性を両立させられるようにする。
【解決手段】複数個のセンサノード、デバイスデータベース２０８、検知モジュールレジストリ２１０、検知ニーズモニタ２０４及び自動コンポーザ２０２によって分散型検知システムを実現する。データベース２０８は、センサノードのうち少なくとも１個とやりとりし少なくとも１個についての物理情報を蓄える。レジストリ２１０には、センサノード出力からの情報取出に使用可能な諸ソフトウェアモジュールを登録する。モニタ２０４は、それぞれアプリケーション／ユーザ側検知ニーズを表す複数個のコンテキスト対をリスト化して保持する。コンポーザ２０２は、それらと連携し且つ当該検知ニーズが充足されるよう、その稼働中にソフトウェアモジュールのコンポジションを生成する。
【選択図】図２

Description

本発明は、検知システムに拡張性を与える技術、より詳細にはソフトウェアモジュールのコンポジションを検知システム上で生成しその検知システム上に展開することにより検知アプリケーションを実行可能化する技術に関する。

知的検知システムはサービス向上に役立つシステムである。それは、その利用によって精度を向上させることができ、またその情報処理過程に文脈性（コンテキスト）がもたらされるからである。

しかしながら、従来の検知システムには設計の面倒さ、拡張の困難さ、望外な高価格等の問題がある。とりわけ問題なのは柔軟性に欠けその拡張が困難なことである。即ち、種々のセンサの設置及び構成が単目的的であり、その出力を後日他のアプリケーションに援用することはほとんど考慮されていない。そのため、そのセンサノードやセンサ出力を全く共用できない複数の検知システムが、同一スペースに設置されることがしばしばあった。

こうした“拡張想定外”型既存システムへの機能追加は、しばしば、面倒で手間暇のかかる作業になる。それくらいなら、別にセンサノードを一組誂え個別のシステムを設置した方が、簡単、正確且つ経済的な選択になるものである。近視眼的に“新品か援用か”と捉える設計思想の許では、ロバスト且つ正確なやり方にて適用乃至拡張することができない複数の検知システムが併設されることとなる。

ここに、本発明の一実施形態に係る分散型検知システムは、複数個のセンサノード、デバイスデータベース、検知モジュールレジストリ、検知ニーズモニタ及び自動コンポーザを備える。デバイスデータベースは、センサノードのうち少なくとも１個とやりとりし少なくとも１個についての物理情報を蓄える。検知モジュールレジストリには、センサノード出力からの情報取出に使用可能な諸ソフトウェアモジュールが登録される。検知ニーズモニタは、それぞれアプリケーション／ユーザ側検知ニーズを表す複数個のコンテキスト対をリスト化して保持する。自動コンポーザは、デバイスデータベース、検知モジュールレジストリ、検知ニーズモニタ及び複数個のセンサノードと連携し且つ当該検知ニーズが充足されるよう、その稼働中にソフトウェアモジュールのコンポジションを生成する。

各センサノードには、例えば、音響信号、モーション信号、振動信号、輝度信号、接近信号、圧力信号、温度信号、輻射信号、タイミング信号、湿度信号、電磁界強度信号、高度信号、重量信号、気中浮遊微粒子信号、速度信号、方向信号及び距離信号のうち１個又は複数個を検知する検知デバイスを１個又は複数個設ける。

自動コンポーザは、例えば、現在のセンサノード配置及び構成ではセンサ覆域が不適切になりユーザ／アプリケーション側検知ニーズを充足できないときその旨を通知する。

各コンテキスト対は、例えば、センサノード出力の基礎データ又は情報の種類を表す名称フィールドｎａｍｅと、当該センサノード出力の由来位置又はその領域を表す位置フィールドｌｏｃａｔｉｏｎと、を含む名称位置対
＜ｎａｍｅ，ｌｏｃａｔｉｏｎ＞
なる形態で、個々の検知ニーズを表す。

各コンテキスト対は、或いは、センサノード出力の基礎データ又は情報の種類を表す名称フィールドｎａｍｅと、当該センサノード出力の由来位置又はその領域及び発生時刻を表す時空フィールドｌｏｃａｔｉｏｎ／ｔｉｍｅと、を有する名称時空対
＜ｎａｍｅ，ｌｏｃａｔｉｏｎ／ｔｉｍｅ＞
なる形態で、個々の検知ニーズを表す。

検知ニーズモニタは、例えばユーザに対し提供されるＧＵＩ(Graphical User Interface)を介し、ユーザによるコンテキスト対の追加及び削除操作を受ける。

デバイスデータベースは、例えば、レンズ歪係数、カメラ方向、センサノード位置又はその任意の組合せを含むセンサ別校正情報を、センサノードの物理情報として保持する。

自動コンポーザは、ユーザ／アプリケーション側検知ニーズを充足させるべくその稼働中にソフトウェアモジュールのコンポジションを生成するに当たり、例えばまずその検知ニーズを充足させるのに必要なソフトウェアモジュール及びセンサノードを求め、各ソフトウェアモジュールの割り振り所要個数（所要インスタンス数）、その構成設定、並びにその割り振り先センサノードを求め、そしてそのコンポジションが実行されるよう諸センサノードの構成を設定する。

自動コンポーザは、例えば、センサノード不調が検知されたときに、利用できるセンサノードだけを用いその稼働中に、ソフトウェアモジュールのコンポジションを更新する。

本発明の一実施形態に係る検知システム及びその情報処理環境の一例構成を示す図である。本発明の一実施形態における自動コンポジションサービスの機能を示す図である。本発明の一実施形態に係る分散型検知システムを示す図である。本発明の一実施形態における複数アプリケーション間ソフトウェアモジュール援用手法を示す図である。本発明の一実施形態における検知ニーズと、一群のカメラにより形成される覆域との関係について、その一例を示す図である。図５Ａの部分拡大図である。図５Ａの部分拡大図である。本発明の一実施形態における検知ニーズモニタ用ＧＵＩを示す図である。本発明の一実施形態におけるコンポジションビュワ用ＧＵＩを示す図である。本発明の一実施形態に係る検知システムへのセンサノード追加手順を示すフローチャートである。本発明の一実施形態に係る検知システムへの新規ソフトウェアモジュール導入手順を示すフローチャートである。本発明の一実施形態に係る検知システムのセンサノード切断時回復手順を示すフローチャートである。本発明の一実施形態におけるセンサノード構成設定手順を示すフローチャートである。本発明の一実施形態におけるコンポジション生成手順を示すフローチャートである。本発明の一実施形態に係る分散型検知システムを構成する情報処理装置の一例を示す図である。

［はじめに］
まず、集積性及び拡張性の高い検知システムには幾つか利点がある。例えば、後にセンサノード機能を援用できるのであれば、センサノードの当初設置個数及び機能を抑えることができる。即ち、当初のハードウェア設置費用及びソフトウェア作成費用を抑えることができる。その費用も、そのシステムが使えなくなるまでの長期間に亘りずっと、複数のアプリケーションに振り分けて償却することができる。また、センサノードを多数にしそのセンサノードに多数の検知デバイスを設けることができるのであれば、センサノードの多様性に依拠し性能を増強すること、例えばその検知精度を高めることができる。

こうした高拡張型検知システムの設計に際しては、センサノード配置のシンプルさを保ちながら新機能を追加できるようにしなければならないが、実際にはそれはかなり困難なことである。それは、開発担当者が離職し他プロジェクトへ移動し或いはその構成の細部を忘れる等して、システム運用スキルが時間と共に徐々に失われていくからである。

本発明に係る設計方式は、検知における“物理的な位置”の重要性を梃子にし、より単純な構成の高拡張型検知システムを実現することを目指している。その手段としては、諸デバイス上で稼働するコンポーネント化されたソフトウェア即ちソフトウェアモジュールを自動的に集積しその連携形態を整える自動コンポジションサービスを提供する。本検知システムによれば、その検知面でアプリケーションを拡張することができる。

また、複数の開発担当者が個々別々に検知アプリケーションを開発した場合、通常、それらのアプリケーション間で諸検知デバイス及び諸ソフトウェアを共用するのは難しい。即ち、どのアプリケーションも他アプリケーションへの援用をほとんど考えずに作成されるので、共存は可能だが相容れない複数のセンサネットワークが併設されることとなってしまう。システム設置コストからすると、既存アプリケーションで使用していたデバイス乃至ソフトウェアを援用して機能拡張する方が有利である。

［センサシステム］
図１に本発明の一実施形態に係る検知システム１００を示す。本システム１００は複数のコンピュータシステムから構成されるシステムである。その構成要素となりうるコンピュータシステムの種類には概ね制限がなく、例えばマイクロプロセッサ、メインフレームコンピュータ、ＤＳＰ(Digital Signal Processor)、携帯情報処理装置、電子手帳、デバイスコントローラ、情報処理エンジン内蔵機器等、様々な性質のものを使用することができる。より具体的には、図示のシステム１００は、ネットワーク１０２、検知モジュールレジストリ１０４、情報処理装置１０６、デバイスデータベース１０８、センサノード１１０及び１１２、検知デバイス１１４〜１２２、ラップトップマシン１２４、デスクトップマシン１２６、その他のデバイス１２８等を有するネットワーク型検知システムとして構成されている。

ネットワーク１０２は情報処理装置乃至ノード間を接続可能な通信回線から構成されている。その回線の種類は問わない。有線回線でも無線回線でもよい。例えばローカルエリアネットワーク、ワイドエリアネットワーク、インターネット、電話回線網、携帯電話回線網、それらの任意の組合せ等をネットワーク１０２として使用することができる。

検知デバイス１１４〜１２２として使用できる装置には、カメラ、マイクロホン、モーション検知器、ＵＷＢ(Untra-WideBand)センサ、赤外センサ、磁力計、温度計、気圧計、重量計等がある。この他、例えば、音響、モーション、振動、輝度、電磁界強度、接近、圧力、温度、輻射、タイミング、湿度、高度、重量、気中浮遊微粒子、速度、方向、距離等の特性やその任意の組合せを信号として検知する様々な種類のセンサを、使用することができる。

センサノード１１０及び１１２には情報記憶用メモリ（例えば所要容量のＲＡＭ）及びソフトウェアモジュール実行機構が実装されている。ソフトウェアモジュールとは、検知デバイスや他のソフトウェアモジュールからデータを受け取り、それを処理して特定形態の出力をもたらすソフトウェアユニットのことである。出力形態はデータでもよいしユーザに対する通知でもよい。

本システム１００は、自システム内のセンサノード１１０及び１１２から出力される信号を利用し諸現象を検知（検出、推定、追尾、モニタ等々）する。即ち、人物や物体の位置及び挙動を検知し（例えば老人の居所及び行動を見守り）、或いは特定現象の発生を検知する（例えば台所の火災を発見する）。

検知モジュールレジストリ１０４には、センサノード１１０及び１１２の出力から情報を取り出すのに使用可能な諸ソフトウェアモジュールが登録される（レジストリ情報が書き込まれる）。デバイスデータベース１０８は、センサノード１１０及び１１２のうち少なくとも１個とのやりとりを通じ、センサノード１１０及び１１２のうち少なくとも１個についての物理情報を蓄える。情報処理装置１０６は、後に図２を参照して説明する検知ニーズモニタ２０４、自動コンポーザ２０２等の機能を果たすように構成されている。

検知モジュールレジストリ１０４やデバイスデータベース１０８は、情報処理装置１０６に内蔵させてもよいし外付けでもよい。

ラップトップマシン１２４及びデスクトップマシン１２６は、ネットワーク１０２のいずれかのノードに接続されており、情報処理機能やネットワーク１０２を介して通信する機能を有している。

デバイス１２８は、クライアント例えばラップトップマシン１２４との接続、ネットワーク例えば１０２との接続等を介し、情報処理装置１０６に接続可能な装置である。具体的には、携帯電話、ＰＤＡ(Personal Digital Assistants)、スマートホン等である。本システム１００への接続に使用可能な装置ならどのような装置でもよい。

ユーザ１３０〜１３４となりうるのは、例えば個人、団体、個別組織、共同組織、コンピュータシステム、コンピュータネットワーク等である。本システム１００を利用できる者／物なら誰／何でもよい。

なお、本発明には種々の実施形態がある。実施形態が違えば構成も違う。従って、図示した検知システム１００の構成にこだわり本発明を限定解釈してはならない。例えば、情報処理装置１０６上でウェブサーバアプリケーションを実行し、そのアプリケーションによって本システム１００を実現するようにしてもよい。或いは、ラップトップマシン１２４、デスクトップマシン１２６又はデバイス１２８上で実行されるアプリケーションにより、本システム１００を実現するようにしてもよい。また、ユーザ１３０〜１３４が本システム１００にアクセスする際には、例えば情報処理装置１０６経由、ラップトップマシン１２４経由、デスクトップマシン１２６経由、デバイス１２８経由等、様々な装置を経由することができる。

［自動コンポジションサービス］
図２に、本発明の一実施形態における自動コンポジションサービス２００の機能を示す。このサービス２００は４個のサブサービス、即ち自動コンポーザ２０２、検知ニーズモニタ２０４、検知モジュールレジストリ２１０及びデバイスデータベース２０８から構成されており、当該自動コンポーザ２０２によってコンポジション２０６を生成するサービスである。コンポジション２０６とは、一群のセンサノードに対する一群のソフトウェアモジュールの割り振り先を示し、目的とする検知アプリケーションを実施に移す詳細プランのことである。コンポジション２０６は、諸センサノードに割り振る（インスタンス化する）べき一群のソフトウェアモジュール、それらのモジュールの割り振り先になる一群のセンサノードの識別子、並びに割り振られたモジュール間に確立すべき一群のインタフェースから構成されている。

自動コンポーザ２０２は、コンポジション２０６の適用先となるネットワーク型検知システムに指令を発し、必要な処理及び通信タスクを実行させる。その際、コンポーザ２０２は、検知ニーズモニタ２０４上、検知モジュールレジストリ２１０上及びデバイスデータベース２０８上の状態情報、即ちアプリケーション／ユーザ側検知ニーズを表す情報、利用可能なソフトウェアモジュールについての情報並びにネットワーク上におけるセンサノード設置状況についての情報（同順）を利用して、次の三タスクを実行する。第１のタスクは、諸検知ニーズを充足させるのにどのソフトウェアモジュール及びセンサノードが必要かを決めるブローカタスクである。第２のタスクは、ソフトウェアモジュールの種類別所要個数、ソフトウェアモジュール間連携に必要なソフトウェアモジュール構成の設定、並びにソフトウェアモジュール割り振り先センサノードを決めるアーキテクトタスクである。第３のタスクは、そのプランをコンポジション２０６として送りつけて諸デバイスに実行させるタスクである。

（検知ニーズモニタ）
これらのサブサービスのうち検知ニーズモニタ２０４では、アプリケーション／ユーザ側検知ニーズを表すコンテキスト対、例えば名称位置対を、リスト化して保持している。ユーザは、ＧＵＩを利用しこのサブサービスとやりとりすることによって、収集したい情報に応じた名称位置対を自ら追加及び削除することができる。アプリケーションも、そのプログラムに従いこのサブサービスを利用し名称位置対を追加及び削除することができる。従って、このサブサービスでは、次の式
Ａ＝｛Ａ_i｝_i=1〜_L
で表される情報が蓄積されることとなる。この式中、Ｌは名称位置対の個数、Ａ_iは第ｉ名称位置対を表している（以下添え字ｉを省くことがある；他の変数についても同様）。

また、このサブサービスでは、与えられた名称位置対Ａからその名称フィールドｎａｍｅを取り出す関数ｎａｍｅ（Ａ）及び位置フィールドｌｏｃａｔｉｏｎを取り出す関数ｌｏｃａｔｉｏｎ（Ａ）を使用する。

（検知モジュールレジストリ）
次に、検知モジュールレジストリ２１０は、諸ソフトウェアモジュールのうちセンサ出力からの情報取出に利用できるもの全てのレジストリ情報を保持している。具体的には、各ソフトウェアモジュールの実コードと、そのモジュールの有効入出力等を表すメタデータとである。検知システムへの新規ソフトウェアモジュール追加とは、そのモジュールについてのレジストリ情報をこのサブサービスに登録することである。従って、このサブサービスでは次の式
Ｆ＝｛Ｆ_i（ｘ）｝_i=1〜_M
で表される情報が蓄積されることとなる。この式中、Ｍはソフトウェアモジュールの個数、Ｆ_i（ｘ）は第ｉソフトウェアモジュールを表している。モジュールＦ_iの式は各センサノード乃至検知デバイスの位置ｘに明に依存している。

また、コンポジション２０６を自動生成するには各ソフトウェアモジュールに係るメタデータを取得する必要がある。そのため、このサブサービスでは次の関数を使用する。これらの関数は開発担当者が定義する：
・ｎ＝ｏｕｔｐｕｔＮａｍｅ（Ｆ） … ソフトウェアモジュールＦから出力される名称ｎを返す関数；なお、１個のソフトウェアモジュールは名称ｎを一通りしか出力しないものとする；
・（ｎ_i，ｘ_i）_i=1〜_K＝ｉｎｐｕｔＰａｉｒｓ（Ｆ，ｘ_out） … モジュールＦから位置ｘ_outにて出力を得るのに必要な入力を表す名称位置対（ｎ_i，ｘ_i）の集合を返す関数；
・｛ｘ〜_i｝_i=1〜_K，ｘ〜_out＝ｆｉｌｔｅｒＩｎｐｕｔＬｏｃａｔｉｏｎｓ（Ｆ，ｘ_out，（ｎ_i，ｘ_i）_i=1〜_K） … 自動コンポーザ２００がコンポジション２０６の自動生成タスクで実行する関数；入力即ちＫ通りの名称位置対（ｎ_i，ｘ_i）に基づき、モジュールＦに入力すべきＫ通りの位置の集合｛ｘ〜_i｝_i=1〜_Kと、その集合｛ｘ〜_i｝_i=1〜_Kを入力したとき生じるであろう実際の出力位置ｘ〜_outとを返す。

更に、ソフトウェアモジュール階層中で最下層に位置するのは、検知デバイスと直接やりとりし生データを得るモジュールである。例えば、カメラのＵＳＢ(Universal Serial Bus)ドライバと直接やりとりして画像データを受け取り、そのデータに「カメラ画像」なる名称を付して出力するカメラ撮影モジュールである。例外として、そうしたセンサドライバモジュールは更に次に示す二種類の関数を使用してサポートする：
・ｉｓＤｒｉｖｅｒ（Ｆ） … ソフトウェアモジュールＦがセンサドライバであるときに「真」値を返す関数；
・ｉｎｐｕｔＤｒｉｖｅｒＴｙｐｅ（Ｆ） … モジュールＦがセンサドライバであるときに限り適用され、そのモジュールＦがやりとりできる検知デバイスの種類名称、例えば「ＵＳＢウェブカム」を返す関数。

また、どのソフトウェアモジュールでも、どの位置ｘにも適用できるよう共通体系で位置を表現しているので、非決定論的な集合を形成するどの名称位置対についても出力を得ることができる。また、どのソフトウェアモジュールも、そのモジュール向けに定義された関数で個別のメタデータを指定できるように設計されている。これらの構成上の特徴は、検知システムの拡張性、適応性及びロバスト性の向上要因になっている。

（デバイスデータベース）
デバイスデータベース２０８には、その検知システムを構成する全デバイスを網羅するようセンサ位置情報及びセンサ別校正情報が格納される。センサ位置情報とはセンサノード又はその検知デバイスを特定しその物理的位置を示す情報のことであり、センサ別校正情報とはそのセンサノード又は検知デバイスに固有の情報（例えばカメラならそのレンズ歪や視角等といった情報）のことである。従って、このサブサービスでは、次の式
Ｄ＝｛Ｄ_i｝_i=1〜_N
で表される情報が蓄積されることとなる。この式中、Ｎは検知デバイスの個数を、Ｄ_iは第ｉ検知デバイスを、それぞれ表している。また、このサブサービスでは次の関数を使用する：
・ｄｅｖｉｃｅＴｙｐｅ（Ｄ） …検知デバイスＤの種類を返す関数；
・ｃｏｖｅｒａｇｅＬｏｃａｔｉｏｎ（Ｄ） … センサ覆域の位置又は範囲を返す関数；例えば、下方を撮影するため天井にカメラを取り付け、そのカメラをセンサノードに接続したとする；その場合、その検知デバイス（カメラ）の覆域は二次元平面上の方形領域、即ちその部屋の床面上でのそのカメラの視野となる；カメラ方向をより一般的に即ち三次元的に表すこともできる；その場合、センサ覆域もより一般的な表現で表される。

更に、デバイスデータベース２０８上のセンサ別校正情報、例えばレンズ歪係数、カメラ方向、センサノード位置又はその任意の組合せを読み取るには、その検知デバイスの種類に応じて定義した一組の関数を使用する。

（自動コンポーザ）
そして、自動コンポーザ２０２は自動コンポジションサービス２００の中核をなすサブサービスである。コンポーザ２０２は、検知ニーズモニタ２０４上、検知モジュールレジストリ２１０上及びデバイスデータベース２０８上の状態情報を利用し、諸検知デバイスから得られる生データに基づき且つ諸検知ニーズが充足されるようにソフトウェアモジュールのコンポジション２０６を生成する。図７に示す例から読み取れるように、生成されるコンポジション２０６はフィードフォワード型位置指定有向グラフＧ＝（Ｖ，Ｅ，ｌｏｃ）で表すことができる。ＶはこのグラフＧを構成するノードｖ即ちソフトウェアモジュールのインスタンスの集合、Ｅは出力ｖ₁と入力ｖ₂を結ぶエッジｅ＝（ｖ₁，ｖ₂）即ちモジュール間インタフェースの集合、ｌｏｃ（ｖ）は集合Ｖに属する各グラフノードｖの位置を返す関数である。コンポーザ２０２の稼働アルゴリズムＣｏｍｐｏｓｅＭｏｄｕｌｅｓＦｏｒ（Ａ）は、こうしたグラフＧを構築してそのノードｖ全ての位置ｌｏｃ（ｖ）を特定することを、目指すアルゴリズムである。このアルゴリズムでは、位置ｌｏｃａｔｉｏｎ（Ａ_i）におけるセンサ出力に名称ｎａｍｅ（Ａ_i）が含まれるグラフノードｖ（但しｖ∈Ｖ）が、モニタ２０４によって保持されているどの名称位置対Ａ_iについても存在することとなるようグラフＧを構築する。また、それを、データベース２０８によって保持されている情報即ち検知デバイスＤ＝｛Ｄ_i｝_i=1〜_Nについての情報並びにレジストリ２１０によって保持されている情報即ち利用可能ソフトウェアモジュールＦ＝｛Ｆ_i｝_i=1〜_Mについての情報だけで行う。そして、諸検知デバイスの連携で形成される覆域に“抜け”があるとどれかの検知ニーズを充足できなくなる可能性がある。重要なことに、このアルゴリズムでは、現在のセンサノード配置・構成ではセンサ覆域に“抜け”が生じ検知ニーズを充足できないことを検知し、そのことをユーザ等に通知することができる。

（コンポジション生成アルゴリズム）
次に、コンポジション２０６を生成するためのアルゴリズムを、実際のプログラムコードを模した形態で示す。このアルゴリズムＣｏｍｐｏｓｅＭｏｄｕｌｅｓＦｏｒ（Ａ）は、諸検知ニーズＡを充足するよう諸ノードに諸ソフトウェアモジュールを割り振る関数、具体的には未完成のコンポジションＧにノードを追加していきニーズＡの充足に直接寄与するノードの集合Ｖ_directを返す次の関数によって実現される：
・ＣｏｍｐｏｓｅＭｏｄｕｌｅｓＦｏｒ（Ａ） …
１．現状の未完成コンポジションＧでは出力が得られない領域Ｒ_remainを
ａ．コンポジションＧ内既存ノードｖのうち名称ｎａｍｅ（Ａ）を出力するものの集合Ｖ_exist
ｉ．Ｖ_exist：＝｛ｖ∈Ｇ｜ｎａｍｅ（ｖ）＝ｎａｍｅ（Ａ）｝
を求め、
ｂ．そのコンポジションＧで既にカバーされている領域Ｒ_exist

を求め、
ｃ．残りの領域Ｒ_remain
ｉ．Ｒ_remain：＝ｌｏｃａｔｉｏｎ（Ａ）−Ｒ_exist
を求めることによって求める；
２．領域Ｒ_remainが空集合ならルーチンから出て空集合を返す（Ｖ_direct：＝Φ）；
３．新規追加ノードを保持するための変数Ｖ_addedに空集合をセットする；
４．検知モジュールレジストリ２１０に登録されているソフトウェアモジュールＦのうち名称ｎａｍｅ（Ａ）を出力するものの集合Ｆ_A
ａ．Ｆ_A＝｛Ｆ∈Ｆ｜ｏｕｔｐｕｔＮａｍｅ（Ｆ）＝ｎａｍｅ（Ａ）｝
を求める；
５．集合Ｆ_Aに属する各モジュールＦについて
ａ．関数ｉｓＤｒｉｖｅｒ（Ｆ）が「真」値なら
ｉ．モジュールＦで駆動できるデバイスの集合Ｄ_F
１．Ｄ_F：＝｛Ｄ∈Ｄ：ｉｎｐｕｔＤｅｖｉｃｅＴｙｐｅ（Ｆ）＝ｄｅｖｉｃｅＴｙｐｅ（Ｄ）｝
を求め、
ｉｉ．類似ノードがコンポジションＧ上に未存在なら、ソフトウェアモジュールＦについての集合Ｄ_F内のデバイスＤ毎に新規ノードｗを生成し、ｌｏｃ（ｗ）：＝ｃｏｖｅｒａｇｅＬｏｃａｔｉｏｎ（Ｄ）を求め、
ｉｉｉ．ｌｏｃ（ｗ）が領域Ｒ_remainと交差するなら
１．ノードｗをコンポジションＧ及び集合Ｖ_addedに追加する；
２．Ｒ_remain：＝Ｒ_remain−ｌｏｃａｔｉｏｎ（ｗ）
を実行することによって領域Ｒ_remainを更新し、
ｂ．関数ｉｓＤｒｉｖｅｒ（Ｆ）が「真」値でないなら
ｉ．モジュールＦに入力すべき名称位置対の集合Ｉ_F
１．Ｉ_F：＝ｉｎｐｕｔＰａｉｒｓ（Ｆ，Ｒ_remain）
を求め、
ｉｉ．集合Ｉ_Fに属する各名称位置対Ｉについて、コンポジションＧ内ノードのうちその名称位置対Ｉを直に充足させるものの集合Ｖ_I
１．Ｖ_I：＝ＣｏｍｐｏｓｅＭｏｄｕｌｅｓＦｏｒ（Ｉ）
を求め、
ｉｉｉ．モジュールＦについて、判明した名称位置対の集合Ｐ_F

を形成し、
ｉｖ．モジュールＦ（Ｒ_remain）に入力すべき位置の集合Ｘ_F，領域Ｒ_out
１．Ｘ_F，Ｒ_out：＝ｆｉｌｔｅｒＩｎｐｕｔＬｏｃａｔｉｏｎｓ（Ｆ，Ｒ_remain，Ｐ_F）
を求め、
ｖ．領域Ｒ_outが空集合でなければ
１．モジュールをＦとし更にｌｏｃ（ｗ）：＝Ｒ_outとして生成した新規ノードｗをコンポジションＧに追加し、
２．集合ノードｗを集合Ｖ_addedに追加し、
３．条件

を満たしており且つ集合Ｘ_F内の対応する位置ｘが空集合でない全てのノードについて、有向エッジ（ｖ，ｗ）をそのグラフＧに追加し、
４．Ｒ_remain：＝Ｒ_remain−Ｒ_out
を求めることによって領域Ｒ_remainを更新する；
６．領域Ｒ_remainが空集合でなければステップ５を繰り返す。領域Ｒ_remainが変わらず且つ空集合でもない場合は、センサ覆域が不十分で名称ｎａｍｅ（Ａ）及び位置ｌｏｃａｔｉｏｎ（Ａ）に係る検知ニーズを充足できないということであるので、ルーチンを出て集合Ｖ_direct：＝Ｖ_added∪Ｖ_existを返す；
７．領域Ｒ_remainが空集合ならルーチンを出て集合Ｖ_direct：＝Ｖ_added∪Ｖ_existを返す。

このアルゴリズムＣｏｍｐｏｓｅＭｏｄｕｌｅｓＦｏｒ（Ａ）の基本的な仕組みは、所望の出力からスタートして検知デバイスへと遡りコンポジションＧを構築する、というものである。このアルゴリズムでは、コンポジションＧ＝（Ｖ，Ｅ，ｌｏｃ）をその生成途上の各段階で保持しつつ、また集合Ｖに属する各グラフノードｖについて
・コンポジションＧでノードｖに関連づけられているソフトウェアモジュールＦを返す関数ｓｅｎｓｉｎｇＭｏｄｕｌｅ（ｖ）
・そのノードｖに関連づけられているソフトウェアモジュールから出力される名称を返す関数ｎａｍｅ（ｖ）
・そのノードｖに関連づけられているソフトウェアモジュールについて、指定されている位置パラメタを返す関数ｌｏｃ（ｖ）
を適用しつつ、コンポジションＧを完成させていく。即ち、新規ソフトウェアモジュールをインスタンス化し、その位置パラメタを指定した上で、それら新規ソフトウェアモジュールの入力元及び出力先を選定、組織化していく。

こうして生成されるコンポジションＧには、諸検知ニーズＡの充足に役立たないノードが含まれる可能性がある。不要ノードを削除するフェーズがあるのはそのためである。更に、ネットワーク型検知システム向けコンポジションＧを生成する際には、そのコンポジションＧを構成している諸ソフトウェアモジュールをどのセンサノード上にインストールするか決定するステップを、手順の最後に実行する。その決定ルールとしては、各センサノードに対しできるだけ多数の機能をインストールするというルールを用いてもよいし、種々の負荷バランス法及び分散型プロセス移送法を活用するルールを用いてもよい。後者であれば、各所に散在しているセンサノード上に、種々のコスト条件が充足されるようソフトウェアモジュールをうまく展開することができる。

また、ｆｉｌｔｅｒＩｎｐｕｔＬｏｃａｔｉｏｎｓ関数を用いるのは、出力計算に使用する入力集合の規模を絞り込むためである。開発担当者はこの関数を様々に設計できる。例えば、使用できる入力のうち１個だけを選択するようこの関数を設計すれば、自動コンポーザ２０２にて同一ソフトウェアモジュールのコピーを複数個作成し、それらを互いに別々の入力領域上に割り振って稼働させることができる。逆に、どの入力も選択できるようこの関数を設計すれば、割り振るコピーの個数はソフトウェアモジュール１個当たり１個になる。上掲のコンポジション生成アルゴリズムＣｏｍｐｏｓｅＭｏｄｕｌｅｓＦｏｒ（Ａ）では、ステップ５．ｂ．ｖ．４における領域Ｒ_remainの計算が複数回実行されうるので、ソフトウェアモジュール１個につき複数個のコピーが作成され割り振られることがある。

そして、上述のコンポジション生成アルゴリズムには、設計上の柔軟度をかなり高める効果がある。例えばノード割り振り次数を選択できることや、コンポジション２０６に含めるノードを選択できることである。これらの工夫は、生成されるコンポジション２０６の能力向上に大きく寄与している。例えば、コンポジション２０６内ノード数を最小限に抑えることも、また冗長なノードを付加することもできるので、効率とロバスト性の間のトレードオフを好適に解決することができる。

［ネットワーク型検知システムの例］
図３に本発明の一実施形態に係る分散型検知システム３００を示す。本システム３００は２個のセンサネットワーク３０２及び３０４から構成されており、各ネットワーク３０２，３０４は複数個のセンサノード３０６を有している。本システム３００では、各ノード３０６上で実行されるソフトウェアモジュール３０８のコンポジション２０６をその物理的位置に従い自動生成する。特に、本システム３００は、自動コンポーザノード３１０複数個からなる段とセンサノード３０６複数個からなる段を有する二段構成のシステムであるので、個々のノード３０６はモート状デバイスでよく、フルフレッジなコンピュータである必要はない。

各自動コンポーザノード３１０は、対応するサブセットのセンサノード３０６に対する集中管制機能を有している。即ち、どのソフトウェアモジュール３０８をどのノード３０６に割り振るか、どのようなメッセージをノード３０６間で交換させるかを、コンポジション２０６に従い決めて指令する。各ノード３０６は、どのアプリケーションに自ノード出力を送信すべきか、対応するノード３１０から指令を受け、その指令に従いアプリケーションに自ノード出力を直接送信する。ノード３１０は、また、受信したメッセージに応じ、検知ニーズモニタ、検知モジュールレジストリ及びデバイスデータベースに蓄積されている状態情報を保持させる。更に、本実施形態では、そのノード３１０として情報処理能力が十分高く稼働中にコンポジション２０６を計算できるものを使用し、ノード３１０・ノード３０６間のリンクとしても信頼性が高いものを使用する。

他方、センサノード３０６は情報処理能力のある端末であり、それぞれ１個又は複数個の検知デバイスを配下においている。各ノード３０６にはランタイムソフトウェアが搭載されており、ソフトウェアモジュール３０８の割り振りやメッセージの交換は、自動コンポジションサービス２００（自動コンポーザノード３１０）からの指令に従い、またそのランタイムソフトウェアの実行によって実現されている。それらのランタイムソフトウェアには、更に、他のデバイスを検知する機能、それらのデバイスに対する校正状態及び位置の相違を検知する機能、それら検知結果をノード３１０に送信する機能等も提供する。

このように、本システム３００は、諸センサノード３０６が幾つかのサブセットに区分され、各自動コンポーザノード３１０が対応するサブセットを個別管理する分散型検知システムである。本システム３００は様々な規模で実施することができるが、センサ覆域や検知ニーズが隣接サブセット間で重複することがある。その場合には、それらサブセットを担当するノード３１０同士でその重複を解決する必要がある。

［小売店舗での実施形態］
図４に、本発明の一実施形態における複数アプリケーション間ソフトウェアモジュール援用手法を示す。本手法によれば、諸センサノードを複数の検知アプリケーションで共用可能な高拡張型検知システムが得られる。

同一検知システムを共用可能な複数の検知アプリケーションの例としては、セキュリティ監視システム用のアプリケーション（セキュリティアプリケーション）と店舗単位マーケティングシステム用のアプリケーション（マーケティングアプリケーション）がある。これら二種類のアプリケーション間には機能的に共通な部分があるので、互いに他のアプリケーション用の検知デバイスを利用できれば、実質的に検知デバイスの配備密度を高めることができる。また、それだけなら複数の検知システムを別々に設置、共存させてもよいが、本発明の実施形態に係る手法の方がコスト的により有利になるであろう。即ち、本手法では、既存機能の援用やアプリケーションの当初想定用途を超えた拡張を容易に行えるよう、システムを構築することができる。例えば、図示の通り、ある小売店舗にセキュリティ監視システムが設置されているとする。更に、同図の左列にあるように、複数台のカメラを用い動画を撮影するカメラ撮影モジュール４００や、その動画を解析する機能を備えたソフトウェアモジュール、例えば視野内にいる人間を検知する来客検知モジュール４０２及びその人間の動きを時間を追って調べる来客追跡モジュール４０４が、セキュリティアプリケーション開発担当者により作成され、そのシステム上で稼働しているとする。こうしたシステムが既に設置されている場合、店舗管理者は、店舗内の来客分布を調べ販売員の配置を適正化する作業に既設のシステムを活用できないものか、と考えるであろう。そうした場合、本実施形態では、同図の右列にあるように、元々はセキュリティアプリケーション向けに開発されているモジュール４０２の出力を利用し特定区画への来客数を導出するソフトウェアモジュール、即ち来客計数モジュール４０６を作成するだけでよい。それを担当するマーケティングアプリケーション開発担当者は、セキュリティアプリケーション開発担当者と別人でもよい。セキュリティアプリケーション開発担当者の方は、モジュール４０６の出力を利用し来客密度を監視するソフトウェアモジュール、例えばある狭い区画内に客が集中する等所定条件を満たしたときに警報を発する密度利用警報モジュール４０８を作成することで、セキュリティアプリケーションの機能を拡張することができる。

また、セキュリティ、マーケティングのいずれの分野でも、客の行動を調べることが重要である。まず、警備員は、客の行動例えば商品を手にとるという行動に注意を払い、その人物を監視して万引でないことを確かめる任務を有している。また、販売管理者は、商品を手にした客に販売員を差し向けることや、各商品に寄せられる客の視線を検知して市況を知ることに、鋭意努力するものである。なお、商品への視線に着目するのは、その情報から客の興味関心の所在を知ることができ、ひいては広告の狙いを定めて売上を伸ばすことができるからである。そこで、図示例では、客が商品を手にしたことを検知する手付検知モジュール４１０を、どちらのアプリケーションでも利用できるよう将来の援用を念頭に置いて設計してある。また、客の視線を検知する視線検知モジュール４１２、万引を検知する万引検知モジュール４１４等、新規機能に係るプログラムの作成を同時並行的に進めることができる。担当するプログラマがセキュリティアプリケーションとマーケティングアプリケーションとで別人でもかまわない。新たなセンサノードを作成及び配置する必要もない。

［データへの命名］
次に、あるアプリケーション向けに準備された機能を他のアプリケーションに援用するには、その検知システムにおけるデータ参照手法を共通化する必要がある。そこで、本発明の好適な実施形態では、各センサノードから出力される情報のうち物理的な位置及び時刻についての情報を利用する。これらの情報は、そのセンサノードで検知された現象を解釈しより高度な情報を取り出す際に、諸アプリケーションにて基礎情報として使用される情報である。そうしたコンテキスト情報（脈絡を示す情報）と名称とを関連づける命名システムを策定すれば、センサノードから得られるデータ及びそれから導出される情報をその名称で参照することが可能になる。例えば動画式監視追跡システムで使用されるソフトウェアモジュールのなかには、各センサノード出力から「画像」、「人物の位置」、「移動の軌跡」等といった情報を取り出すものがある。本発明を実施するに当たっては、例えば、各センサノード出力の基礎データ又は情報の種類を表す名称（事象識別子）に、時間及び空間の情報を含むコンテキスト情報によってタグ付けしておくとよい。即ち、名称時空対
＜ｎａｍｅ，ｌｏｃａｔｉｏｎ／ｔｉｍｅ＞
を使用することで、センサノード出力中の興味ある情報を、簡便に参照することが可能になる。

通常は、時刻が現在であると想定して差し支えないので、個別情報の指定に名称位置対
＜ｎａｍｅ，ｌｏｃａｔｉｏｎ＞
を使用できる。

こうした名称位置対が与えられた場合、その名称フィールドｎａｍｅからデータ又は情報の種類を、また位置フィールドｌｏｃａｔｉｏｎからその情報の由来位置又は領域を、それぞれ知ることができる。例えば、名称位置対
＜ＰｅｒｓｏｎＣｏｕｎｔ，ＰａｌｏＡｌｔｏ＞
で指定されるのは、パロアルト（ＰａｌｏＡｌｔｏ）における人数計測結果を示す情報（ＰｅｒｓｏｎＣｏｕｎｔ）である。

［コンポジション例］
図５に、本発明の一実施形態における検知ニーズと、一群のカメラ（センサ）により形成される（コンポジション相当の）覆域との関係について、その一例を示す。この例では、図５Ａ中に破線の方形枠で示した検知ニーズを４個のカメラ（視野：Ａ〜Ｄ）で充足させようとしている。また、図５Ｂは、このコンポジションの一部を示したものである。この部分では、そのコンポジションを形成する各カメラの視野によって検知ニーズが充足されている。更に、図５Ｃは、図５Ａ中の右下隅部分を示したものである。この部分は、現在のセンサノード配置・構成ではカバーできない部分である。

図６に、本発明の一実施形態における検知ニーズモニタ用のＧＵＩ６００を示す。このＧＵＩ６００は２個のウィンドウペインを提供している。そのうち第１ペイン上には、ユーザによる操作でコンポジションに組み込めるように、一群のソフトウェアモジュール６０４がリスト表示されている。即ち、このペインには各モジュール６０４の名称に添えて表示パターンインジケータ６０８及びチェックボックス６０２が表示されているので、対応するボックス６０２にチェックを入れてモジュール６０４を選び、更に検知ニーズ選択ボタン６０６を押すことで、望みのモジュール６０４を手際よく、コンポジション２０６に組み込むことができる。

また、このＧＵＩ６００で提供されるペインのうち第２ペイン上には、検知対象エリアの平面的な地図画像、地図ナビゲーションツール６１０、地図回転ツール６１２、地図ズームツール６１４、検知ニーズ指定インジケータ６１６及び未覆域インジケータ６１８が表示されている。そのうちツール６１０は地図画像を任意方向にシフトさせるためのツールである。これを用いることで、その地図画像をその面沿いに手際よくスクロール即ちナビゲーションすることができる。ツール６１２は地図画像を任意方向に回転させるためのツールである。これを用いることで、その地図画像の向きを任意方向に手際よく変化させることができる。そして、ツール６１４は地図画像を拡大・縮小させるためのツールである。これを用いることで、その地図画像へのズームイン及びその地図画像からのズームアウトを手際よく実行することができる。

検知ニーズ指定インジケータ６１６は、対応する種類及び個数のソフトウェアモジュール６０４の利用個所として指定された領域を、地図画像平面上で指し示している。各インジケータ６１６は第１ペイン上の対応する表示パターンインジケータ６０８のそれと同じ種類の枠線及びシェーディングで表現されているので、そのインジケータ６１６で指し示された個所で使用されるモジュール６０４の種類を、そのインジケータ６１６の枠線又はシェーディングの種類から、読み取ることができる。例えば、インジケータ６１６で指し示されている領域のうち、センサノード配置が適切でモジュール６０４をうまく割り振ることができた領域は濃いシェーディングで、またセンサノード配置が不適切かモジュール６０４の割り振りに成功していない領域はシェーディング無しで示されている。

図７に、本発明の一実施形態におけるコンポジションビュワ７００用のＧＵＩを示す。このビュワ７００では、地図ナビゲーションツール７１０、地図回転ツール７１２及び地図ズームツール７１４と共に、複数個のソフトウェアモジュール７０８からなる有向グラフが可視表示されている。

この有向グラフのリーフに位置するボックス（一番下のボックス）は、センサドライバモジュールとして機能するソフトウェアモジュール７０８、例えばカメラ撮影モジュールを表している。また、この有向グラフのルートに位置するボックス（一番上のボックス）は、検知ニーズモニタ上の個別の検知ニーズで指定されている情報の、直接の出力元となるソフトウェアモジュール７０８を表している。それらの中間に位置する残りのボックス、即ちその入力及び出力が他のボックスにつながっているボックスは、中間結果を導出するソフトウェアモジュール７０８を表している。

図８に、本発明の一実施形態に係る検知システムにセンサノードを追加する手順の流れを示す。この手順では、ユーザが、まず個々のセンサノードをコンフィギュレート即ち構成設定し（８００）、次いでそのノードを相応の物理的位置に設置し（８０２）、そしてそのノードの位置情報及び校正情報をデバイスデータベースに登録する（８０４）。

デバイスデータベース上のセンサノード情報がこうして更新されると、自動コンポーザは、その新たな検知及び処理能力を活かせるようにコンポジションを更新する（８０６）。検知システムは通常の動作を続ける。その間、諸センサノードは対応する検知デバイスからの入力を監視し、各ソフトウェアモジュールは情報を処理する。ユーザ側検知ニーズが充足されたら、検知システムはそのユーザにその旨を通知する（８０８）。

図９に、本発明の一実施形態に係る検知システムに新規ソフトウェアモジュールを導入する手順の流れを示す。この手順では、ユーザが、まず新規ソフトウェアモジュールを構成設定し（９００）、次いでそのモジュールを検知モジュールレジストリに登録する（９０２）。

検知モジュールレジストリ上のソフトウェアモジュール情報がこうして更新されると、自動コンポーザは、その機能を活かせるようにコンポジションを更新する（９０６）。検知システムは通常の動作を続ける。その間、諸センサノードは対応する検知デバイスからの入力を監視し、各ソフトウェアモジュールは情報を処理する。ユーザ側検知ニーズが充足されたら、検知システムはそのユーザにその旨を通知する（９０８）。

図１０に、本発明の一実施形態に係る検知システム上のセンサノードが切断されたときにその検知システムを回復させる手順の流れを示す。この手順では、まず、ユーザが保守その他の目的でセンサノードを故意に切断したり、センサノードやその検知デバイスの不調でセンサノードが不意に切断されたりしたときに（１０００）、検知システムがそのセンサノードの消失を検知する（１００２）。

デバイスデータベース上の状態情報、即ち消失したセンサノードを含め設置済のセンサノードの状態を表す情報がこうして更新されると、自動コンポーザは、ユーザが利用可能なセンサノード及び検知デバイスだけを使用するようコンポジションを更新する（１００６）。検知システムは通常の動作を続ける。その間、諸センサノードは対応する検知デバイスからの入力を監視し、各ソフトウェアモジュールは情報を処理する。ユーザ側検知ニーズが充足されたら、検知システムはそのユーザにその旨を通知する（１００８）。

図１１に、本発明の一実施形態におけるセンサノード構成設定手順（１１００）の流れを示す。この手順では、ユーザが、まず１個又は複数個の検知デバイスをセンサノードにインストールし（１１０２）、更に、コンポジションで規定されている検知デバイス割り振り及びメッセージ交換のため、相応のランタイムソフトウェアをそのセンサノードにインストールする（１１０４）。

図１２に、本発明の一実施形態におけるコンポジション生成手順（１２００）の流れを示す。この手順では、まず、自動コンポーザが、諸検知ニーズを充足するのに必要なソフトウェアモジュール及びセンサノードを求め（１２０２）、各ソフトウェアモジュールの割り振り（インスタンス化）所要個数、その構成、並びにその割り振り先センサノードを求め（１２０４）、そしてステップ１２０４にて自分で導出した情報を組み込むことでコンポジションを生成し、そのコンポジションが実行されるよう諸センサノードを構成設定する（１２０６）。

自動コンポーザは、ユーザ側検知ニーズが充足されたか否かを判別する（１２０８）。現在のコンポジションでは充足されないと判別された場合、自動コンポジションサービス（自動コンポーザ）は、現在のセンサノード配置・センサノード構成ではカバーされない物理的領域（未覆域）をユーザに通知する（１２１０）。例えば、ＧＵＩ上で未覆域を明色表示することによって、ユーザに対し未覆域を通知する（図６中の未覆域インジケータ６１８を参照）。

図１３に、本発明の一実施形態に係る分散型検知システムを構成する情報処理装置の一例１３００を示す。本装置１３００は、例えばマイクロプロセッサ、メインフレームコンピュータ、ＤＳＰ、携帯情報処理装置、電子手帳、デバイスコントローラ、情報処理エンジン内蔵機器等、概ねどのような種類の情報処理システムでも実現することができる。より具体的には、図示の装置１３００は、１個又は複数個のプロセッサ１３１０、メモリシステム１３１２、ストレージデバイス１３１４等を備えるほか、ディスプレイ１３０２や複数個の検知デバイス１３０４〜１３０８との接続のためのインタフェースを備えている。

検知デバイス１３０４〜１３０８としては、例えばカメラ、マイクロホン、モーション検知器、ＵＷＢセンサ、赤外センサ、磁力計、温度計、気圧計、重量計等を使用する。この他、例えば、音響、モーション、振動、輝度、電磁界強度、接近、圧力、温度、輻射、タイミング、湿度、高度、重量、気中浮遊微粒子、速度、方向、距離等の特性やその任意の組合せを検知する他種センサも使用できる。

ストレージデバイス１３１４上には、オペレーティングシステム１３１６、デバイスデータベース１３１８、検知モジュールレジストリ１３２０、検知ニーズモニタ１３２２、自動コンポーザ１３２４等が搭載されている。

本装置１３００を稼働させる際には、まず自動コンポーザ１３２４をメモリシステム１３１２上にロードする。プロセッサ１３１０は、その自動コンポーザ１３２４を実行することによって、図２を参照して説明した一群の機能を提供する。

［ネットワーク型検知システムの設置及び拡張］
次に、その検知システム上で稼働するアプリケーションを二種類に増やす場合を例に、検知システム拡張手順の諸段階を説明する。アプリケーションとしては、単純なセキュリティアプリケーション及び個人別広告アプリケーションを想定する。それらのうちセキュリティアプリケーションは、人間の動きを検知して経時追跡し、得られた動画フィードにトラック情報でタグ付けしてローカル保存し、侵入等が発生したら警報を発するアプリケーションである。個人別広告アプリケーションは、店舗入来時のＲＦＩＤ(Radio Frequency IDentification)カード読取で買い物客のプロファイルを検知し、その客を複数個のカメラで追跡し、そして客がディスプレイに近づいたらその客の関心を惹くであろう広告をそのディスプレイに表示させるアプリケーションである。これから段階を追って説明する通り、本発明の好適な実施形態では、検知システムを拡張し新たなアプリケーションの検知ニーズに対応させる作業を簡便に行うことができる。

（段階Ａ：初期設置）
この段階では、まずセキュリティチームが小売店舗内カメラ式検知システム設置プランを作成する。このシステムは、その店舗内の動画を撮影し、店舗内を動き回る客を自動検知して追跡するシステムである。プランを作成したら、そのプランに従い例えば１５個のセンサノードを設置する。また、諸ソフトウェアモジュールの割り振り及びメッセージ交換をコンポジションに基づき行えるよう、それらのセンサノードにランタイムソフトウェア環境をインストールする。更に、それらセンサノードの位置情報や校正情報を、マニュアル計測で取得してデバイスデータベースに登録する。

ソフトウェア作成に当たっては、実行すべき検知タスクを複数個の構成単位に分解し、複数個のソフトウェアモジュールを作成する。作成に当たっては、各モジュールにおける位置表現を互いに同じ要領にし、また個々のモジュールの入出力に名称を付けるようにする。セキュリティチームは、ソフトウェアモジュールとして、まずセンサドライバモジュールを作成する。例えば、天井に取り付けられたカメラとやりとりしカメラ画像情報を生成するカメラ撮影モジュールである。セキュリティチームは、この他、カメラ画像情報を入力しそれに基づき来客検知情報を生成する来客検知モジュールや、その来客検知情報に基づき来客追跡情報を生成する来客追跡モジュールも作成する。

更に、自動コンポーザにて諸ソフトウェアモジュールに係るメタデータが必要とされるので、ｏｕｔｐｕｔＮａｍｅ、ｉｎｐｕｔＰａｉｒｓ、ｆｉｌｔｅｒＩｎｐｕｔＬｏｃａｔｉｏｎｓ、ｉｓＤｒｉｖｅｒ及びｉｎｐｕｔＤｅｖｉｃｅＴｙｐｅの諸関数を定義する。上述の通り、これらの関数は、各ソフトウェアモジュールに係るメタデータが得られるよう、またどの位置でも使用できるよう定義する。従って、自動コンポジションサービスは、その稼働に必要な情報を得ることができる。

こうしてネットワーク型検知システムの構成が確立されたら、検知ニーズモニタ上の情報に基づき、取得すべき情報を指定する。即ち、図６に示したＧＵＩ６００上で、所要個数の名称位置対＜ｎａｍｅ，ｌｏｃａｔｉｏｎ＞を指定する。ＧＵＩ６００上ではその名称に応じた種類の輪郭線やシェーディングが使用され、その位置が方形領域で表される。

（段階Ｂ：検知対象エリアの変更）
この段階では、まず、その小売店舗内に他に監視すべきエリアがないかどうか、セキュリティチームが検討する。上述の通り、どのソフトウェアモジュールも同じ要領で位置を表現しているので、検知対象エリアの変更（追加等）に当たっては、検知ニーズモニタにおける名称位置対の登録内容を変更するだけでよい。自動コンポーザはそれを受けてコンポジションを自動更新する。ユーザはそれ以上何も操作する必要がない。

自動コンポーザは、更新版のコンポジションで適切なセンサ覆域が得られるか否かを判別する。センサ覆域が不適切であると判別した場合、自動コンポーザは、ＧＵＩ上にセンサ覆域の“抜け”（未覆域）を表示させる。例えば、図６に示すように、ＧＵＩ６００上にセンサ覆域及びその“抜け”部分を表示させる。図中、方形の輪郭線でくくられた明るめのエリアが、センサ覆域の“抜け”部分である。こうした情報を表示させることで、検知システムの能力と限界をユーザに知らせること、即ち検知システムに可視性・透明性をもたらすことができる。

（段階Ｃ：新規検知デバイスの追加）
この段階では、セキュリティチームが、センサ覆域に生じている“抜け”を補うべく新たな検知デバイスを追加する。

その際、セキュリティチームは、追加する一群のセンサノードにランタイムソフトウェアをインストールし、それらのノードを校正し、そしてそれらのノードを所要位置に所要の向きで設置する。それら、ノードの構成や校正状態を示す情報は、デバイスデータベースに追加登録される。自動コンポーザは、それを受けて、新たな検知及び処理能力を活用できるよう計算によりコンポジションを更新する。こうして新規ノードを設置した結果所要センサ覆域が実現されるに至ったら、図６に示したＧＵＩ６００上で、方形の輪郭線でくくられている明るめのエリアが暗転する。検知システムは、追加されたセンサノード乃至検知デバイスに係る情報が自動コンポジションサービスに提供されると、その能力の活用を自動的に開始する。

（段階Ｄ：検知出力の拡張）
この段階では、自分の店舗内に設置されているカメラを市場調査に利用したい等といった店舗側の意向に応じ、またその現有能力を活用しつつ、検知システムに新規機能を追加する。例えば、その小売店舗内の特定エリアにいる客の人数を数える来客計数機能を追加する。

その際、店舗経営者はまず、検知システムに来客計数機能を組み込むための新規ソフトウェアを作成させる。店舗経営者は、現在その検知システムでサポートされている情報の種類を知るため、サポート対象出力名称のリストを表示させる。店舗経営者は、そのリストからの選択によって１個のソフトウェアモジュールをコンポジションに追加させる。即ち、その名称が「来客計数」、入力が「来客検知」、出力が「来客数」のモジュールを採用させる。その際、店舗経営者は、その来客検知情報がその検知システム内でカメラ画像情報から生成されていることを知らなくてもよい。これは、前述した命名法の利点のうち一つである。当該命名法の更なる利点としては、来客計数モジュールで使用する情報がそのリーフ側にあるモジュールで生成されるよう、後の更新、追加又は交換時にそのモジュールを構成できる点がある。例えば、カメラ撮影モジュールに代え、音声検知・位置特定ソフトウェアがインストールされているマイクロホンアレイによって来客検知を行うようにしたとしても、そのマイクロホン利用型検知モジュールから出力される情報に「来客検知」との名称が付されている限り、来客計数モジュールでは、それまでと同じくその情報を用い、来客数情報を生成することができる。

来客計数モジュールも、前記同様、どの位置でも使用できるよう作成されており、コンポジションの自動生成に必要なメタデータでプログラミングされている。従って、来客計数モジュール等の新規ソフトウェアモジュールを検知モジュールレジストリに追加登録する際に、その検知システムをオフラインに移行させる必要はない。これは、セキュリティアプリケーションのように、検知システムを連続稼働させることが強く求められるアプリケーションにおいては、重要なことである。

そして、締めくくりに、その検知システムから来客数情報を出力させるための名称位置対を、何個か検知ニーズモニタに登録する。これを行うと検知システムにてコンポジションの自動更新動作が始まり、そのコンポジションに従い検知システムの組織化状態が更新される。

（段階Ｅ：ノード不調に対するロバストな対処）
この段階はセンサノードの不調が検知されたときに実行される。この段階では、ノード不調の検知に応じコンポジション更新動作が起動され、利用できるデバイスのみを使用したコンポジションが生成されるので、不調が生じたノードは円滑に排除されることとなる。不調検知前のセンサ覆域に十分ゆとりがあった場合は、不調ノード排除後も、ユーザが何も操作を行うこと無しに全機能が維持されることとなる。

［高拡張型検知システムに対する要請］
高拡張型検知システムを構築するには、システム設置当初の開発担当者（原開発担当者）及び既存機能の援用・拡張を担う開発担当者（拡張担当者）がどのような作業を担うか、よく決めておく必要がある。これは、原開発担当者と拡張担当者が同じ人物でないことが多いからである。以下の段落では、まず、原開発担当者及び拡張担当者の作業に対する要請事項について概略説明する。

（原開発担当者側）
検知システム上の機能のうち援用・拡張の対象になりうるものについては、（１）個別起動可能な複数個の小規模ソフトウェアモジュールに細分して設計する、（２）その援用ができるよう位置を一般的に表現する、という指針に従い設計すべきであるが、原開発担当者にすれば高拡張設計は優先度は低い。即ち、拡張性が望まれるにしても、そのシステムに対し求められている機能を実現することの方を最優先に考えねばならない。また、アルゴリズムを汎用化し諸モジュールに組み込む作業が加わることで、設計難度が無視できないほど増すことともなれば、高拡張設計でシステム性能や寿命が改善されるにしても、当面の作業の簡便さの方が優先されることとなる。従って、次に示す簡便化の要請を勘案すべきである：
要請１ａ：組み込みたい機能を個別起動可能なソフトウェアモジュールに細分する作業を極力省力化すること；
要請１ｂ：アルゴリズムにおける位置表現に一般性を持たせる作業を極力省力化すること。

なお、前掲の小売店舗の例から読み取れるように、機能を複数部分に分解して実現する際には、各ソフトウェアモジュールをブラックボックス化し、その入力、出力及び制御パラメタの指定でそのモジュールを稼働させうるようにする。例えば来客検知機能なら、カメラ画像を入力し来客検知所要エリアを指定すると一組の来客記述子（輪郭線、囲み線、マスク画素等々）が出力されるようにする。

（拡張担当者側）
また、拡張担当者が担う既存ソフトウェアモジュール援用・拡張作業を簡便化するには、モジュール作成に当たり新たな作成要領を採用すること、即ち次に示す要請を満たすことが必要である：
要請２ａ：既存ソフトウェアモジュールの種類並びにその入力、出力及び制御パラメタについての規定を、極力簡便に調べられるようにすること；
要請２ｂ：特殊な熟練無しで既存ソフトウェアモジュールを援用可能にすること；
要請２ｃ：ソフトウェアモジュール集積作業を簡便化し入出力間整合で済むようにすること；
要請２ｄ：既存ソフトウェアモジュールのバージョンアップ及び新規ソフトウェアモジュールの追加を全面的にサポートすること。

前掲の小売店舗でいえば、店舗内で市場調査するためのマーケティングアプリケーションの開発担当者が、既存ソフトウェアモジュールの援用に際し、どのようなソフトウェアモジュールを使用可能かをその検知システム全体に亘り容易に判別できるようにすべきである。即ち、個々のソフトウェアモジュールの作成者がセキュリティアプリケーションの開発担当者かそれともマーケティングアプリケーションの開発担当者かによらず、どのモジュールを援用できるかをそれら開発担当者がほぼ無作業で見定められるようにすべきである（要請２ａ）。次に、それらのアプリケーションの開発担当者が互いに別分野の専門家であること、例えばセキュリティアプリケーションの開発担当者がコンピュータ利用監視の専門家、マーケティングアプリケーションの開発担当者が販売管理の専門家であることがある。従って、検知デバイス及び検知アルゴリズムの利用手法、能力及び限界に関する知識を漏れなく組み込み、門外漢でもアルゴルリズム出力を正しく利用できるようにすることが重要である（要請２ｂ）。

要請２ｃは集積に関わる要請である。即ち、例えば来客検知モジュールと来客計数モジュールのように互いに別のアプリケーション向けに開発されたソフトウェアモジュールを、開発担当者の作業無しで集積させうるようにすべきである、という要請である。例えば、カメラ画像を取り込み指定エリアに存する客の来客記述子を出力する来客検知モジュールと、その来客記述子を取り込み任意領域内に存する客の人数を出力する来客計数モジュールとを集積するには、来客検知モジュールの出力を来客計数モジュールへの入力と整合させればよい。ただ、実際にはソフトウェアモジュールが多数、データの種類も多様であるので、ソフトウェアモジュール間で入出力を整合させる作業をマニュアルで行うと、非常に厄介な作業になってしまう。逆にいえば、入出力間を整合させるルールをうまく定義すれば自動集積が可能になる。これは自動コンポジションサービスの目的でもある。

そして、検知システムの拡張性を高めたことに伴い事後的な機能修正を可能にし、上流機能を停止させることなく差分アップデートを行えるようにすることが肝要である（要請２ｄ）。

（開発担当者及び自動コンポーザの役割）
既存検知システムの機能拡張を担う拡張担当者には次の役割がある。第１に、そのシステムで利用できる機能を、そのシステムで取得可能な情報の種類を示す名称のリストから選択することである。第２に、その情報の取得元となる位置／領域を、名称位置対の指定によって指定することである。注目している領域がセンサ覆域内である限りこれは可能である。そして、第３に、覆域が不適切である旨の通知を前述の自動コンポジションサービスから受けたときにそれに対処することである。

原開発担当者には次の役割がある。第１に、前述のコンポーネント単位開発方式に従い、個別実行可能且つ相互リンク可能な複数個のソフトウェアモジュールに細分された形態で、全機能を組み込むことである。第２に、その開発方式の許で、全ソフトウェアモジュールを、どの位置にも適用できるよう作成することである。諸センサノードの物理的位置はセンサノード出力を解釈する上で不可欠なコンテキスト情報であり、また実際にシステムを設置するまではデバイス位置が確立されないので、位置に関するこうした一般性は重要である。例えば、来客検知情報を出力する画像処理ルーチンをソフトウェアモジュール化する際には、任意の物理的位置／領域で来客検知を行えるようそのモジュールを作成する。

そして、原開発担当者及び拡張担当者共に、自動コンポジションサービスを稼働させて諸ソフトウェアモジュールを自動集積させる、という役割がある。諸ソフトウェアモジュールの入出力名称及び設置したセンサノードの種類及び位置についての知識を利用できるので、自動コンポーザによってコンポジションを自動生成させることにより、ソフトウェアモジュールの割り振り、位置パラメタの設定、並びにソフトウェアモジュール間の連携を正しく実行でき、ひいてはアプリケーション／ユーザ側検知ニーズを充足させることができる。

自動コンポーザは諸ソフトウェアモジュールの候補配置・候補構成を案出し自動集積を実行する。従って、検知システム設計の難度は、諸ソフトウェアモジュールの候補配置・候補構成の個数に対して指数的にではなく、ソフトウェアモジュールの個数に対して直線的に増減する。このように、コンポジション自動生成能力は、高拡張型システム設計作業の難度を抑える上で肝要な能力である。

（拡張性への寄与）
要請１ａ … 個別起動可能な複数個のソフトウェアモジュールに機能を細分することは、拡張担当者による機能援用に必要のないソフトウェア間の関わり合い（潜在的依存性）を隠せる点で、望ましいことである。また、そのソフトウェアモジュールの潜在的依存性を最もよく知っているのはそのモジュールの原開発担当者であるので、原開発担当者がそのモジュールの入出力に関するコンテキストなメタデータを作成するようにすれば労力も抑えられる。作成されたメタデータは、自動コンポジションサービスによる検知システムへの機能集積に利用できる。原開発担当者にしてみれば、基本的には、その名称で全入出力を特定できるよう全入出力に名称を付けてソフトウェアモジュールを作成するだけでよい。拡張担当者にしてみれば、互いに分離している諸ソフトウェアモジュールのうちどのモジュールからデータが得られるのかをしかと知る必要がない。そのシステムから得られるデータの名称を知るだけでよい。集積が自動コンポジションサービスで自動実行されるので、ソフトウェアモジュール同士の秘匿されている関係を辿ることも必要ない。

要請１ｂ … どの位置／領域にも適用できるよう検知アルゴリズムを作成することは、原開発担当者にとり付加的な負担にはなるが実り多いことである。例えば、諸センサノードの配置を自在に変化させることや、後の開発担当者が任意の位置で既存機能を下地にソフトウェアモジュールを作成することが可能になる。

要請２ａ … 既存検知システムにどのような検知能力があるのかを調べる際に、検知システムから教えてくれる名称及びその意味を理解するだけでよいということは、開発担当者の作業がその分簡便になるということである。但し、新たなソフトウェアモジュールにてその情報をプログラム的に援用するには、その情報のデータ表記等といった詳細も知る必要があろう。

要請２ｂ … 検知ニーズモニタに名称位置対を入力しどのような種類の検知結果を得たいか表明するだけで既存の検知能力を利用できるということは、開発担当者にしてみれば簡便なことである。また、このように簡便な指定で済むようにすることで、ソフトウェアモジュール間のやりとりの仕方が制約されることになるとはいえ、将来の開発担当者が、特別な熟練無しでもそのソフトウェアモジュールを使用できることとなる。

要請２ｃ … 入出力に係るメタデータを指定しまたそのソフトウェアモジュールを自動コンポジションサービスに登録するだけでよいということは、新規ソフトウェアモジュールを集積する作業が簡便化されるということである。そのモジュールのコピーを複数作成し各所のデバイスに割り振る処理やモジュール間の連携を確立する処理は、自動コンポジションサービスにより自動的に実行されるので、既存検知システムに新規機能を組み込み集積する作業を、開発担当者等が行う必要はない。更に、アプリケーション側全検知ニーズが充足され且つその新規ソフトウェアモジュールが組み込まれるよう、自動コンポジションサービスによってソフトウェアモジュールのコンポジションが自動更新されるので、開発担当者等は、ソフトウェアモジュール間の連携が不意に断たれても、無闇にそれに煩わされることがない。

要請２ｄ … 既存機能を更新する処理は、検知ニーズモニタ上登録されているソフトウェアモジュールを、そのモジュールから出力される名称と同じ名称を出力する新たなバージョンのソフトウェアモジュールに置換することにより、実行される。その新バージョンモジュールの集積は自動コンポジションサービスにより自動実行される。

［オンライン再最適化の効果］
本発明の好適な実施形態に係る検知システムによれば、検知ニーズモニタ、検知モジュールレジストリ及びデバイスデータベースに登録されている状態情報の変化に反応するよう自動コンポジションサービスが作成されているので、オンライン動作中にコンポジションを自動更新させることができ、従って拡張性以外に次のような効果を得ることができる。開発担当者等の更なる作業は必要ない。

適応性 … まず、実施形態に係る検知システム例えば１００では、ユーザ／アプリケーション側ニーズの変化に応じてその処理内容が自動調整される。即ち、検知ニーズモニタ上の状態情報の変化に応じコンポジションが自動更新される。

拡張性 … 次に、実施形態に係る検知システムの機能は、システム動作を一時的にであれ停止させることなく拡張することができる。これは、検知モジュールレジストリ上の状態情報の変化に応じリアルタイムに、コンポジションが自動更新されるためである。

ロバスト性 … そして、実施形態に係る検知システムは、センサノードの不調に対してロバストである。即ち、デバイスデータベース上に登録されているセンサノード又は検知デバイスの不調が検知されると、残りのセンサノード及び検知デバイスで可能な限りで検知ニーズが充足されるようにコンポジションが自動更新される。

１００検知システム、１０２ネットワーク、１０４，１３２０検知モジュールレジストリ、１０６，１３００情報処理装置、１０８，２０８，１３１８デバイスデータベース、１１０，１１２，３０６センサノード、１１４〜１２２，１３０４〜１３０８検知デバイス、１２４ラップトップマシン、１２６デスクトップマシン、１２８デバイス、１３０〜１３４ユーザ、２００自動コンポジションサービス、２０２，１３２４自動コンポーザ、２０４，１３２２検知ニーズモニタ、２０６コンポジション、２１０検知モジュールレジストリ、３００分散型検知システム、３０２，３０４センサネットワーク、３０８，６０４，７０８ソフトウェアモジュール、３１０自動コンポーザノード、４００カメラ撮影モジュール、４０２来客検知モジュール、４０４来客追跡モジュール、４０６来客計数モジュール、４０８密度利用警報モジュール、４１０手付検知モジュール、４１２視線検知モジュール、４１４万引検知モジュール、６００ＧＵＩ、６０２チェックボックス、６０６検知ニーズ選択ボタン、６０８表示パターンインジケータ、６１０，７１０地図ナビゲーションツール、６１２，７１２地図回転ツール、６１４，７１４地図ズームツール、６１６検知ニーズ指定インジケータ、６１８未覆域インジケータ、７００コンポジションビュワ、８００〜１２１０ステップ、１３０２ディスプレイ、１３１０プロセッサ、１３１２メモリシステム、１３１４ストレージデバイス、１３１６オペレーティングシステム、Ａ〜Ｄカメラ又はその視野。

Claims

複数個のセンサノードと、
センサノードのうち少なくとも１個とやりとりし少なくとも１個についての物理的情報を蓄えるデバイスデータベースと、
センサノード出力からの情報取出に使用可能な諸ソフトウェアモジュールが登録される検知モジュールレジストリと、
それぞれアプリケーション／ユーザ側検知ニーズを表す複数個のコンテキスト対をリスト化して保持する検知ニーズモニタと、
デバイスデータベース、検知モジュールレジストリ、検知ニーズモニタ及び複数個のセンサノードと連携し、上記検知ニーズが充足されるようその稼働中にソフトウェアモジュールのコンポジションを生成する自動コンポーザと、
を備える分散型検知システム。
請求項１記載の分散型検知システムであって、各センサノードが、音響信号、モーション信号、振動信号、高度信号、輝度信号、接近信号、圧力信号、温度信号、輻射信号、タイミング信号、湿度信号、電磁界強度信号、高度信号、重量信号、気中浮遊微粒子信号、速度信号、方向信号及び距離信号のうち１個又は複数個を検知すべく、１個又は複数個の検知デバイスを有する分散型検知システム。
請求項１記載の分散型検知システムであって、現在のセンサノード配置及び構成ではセンサ覆域が不適切で上記検知ニーズが充足されないとき、自動コンポーザがその旨を通知する分散型検知システム。
請求項１記載の分散型検知システムであって、各コンテキスト対が、センサノード出力の基礎データ又は情報の種類名称を表す名称フィールドｎａｍｅと、当該センサノード出力の由来位置又はその領域を表す位置フィールドｌｏｃａｔｉｏｎと、を含む名称位置対
＜ｎａｍｅ，ｌｏｃａｔｉｏｎ＞
なる形態で、個々の検知ニーズを表す分散型検知システム。