JP2018073303A - イベント制御装置、イベント制御方法、及びプログラム - Google Patents

Abstract

【課題】イベントの発生を契機として処理を実行するシステムにおいて、イベントの優先度に応じて、適切に処理を実行することを可能とする技術を提供する。【解決手段】受信したイベント情報を出力するための制御を行うイベント制御装置において、優先度毎のキューを有するマルチキューと、受信したイベント情報の優先度に対応するキューに、当該イベント情報を格納する入力制御手段と、イベント情報取得要求を受信した場合に、前記マルチキューにおける出力可能なイベント情報を格納するキューのうち、最も優先度の高いキューからイベント情報を取得し、出力する出力制御手段とを備える。【選択図】図２

Description

本発明は、各種のデバイス等から受信したイベント情報の出力制御を行う技術に関連するものである。

近年、家庭用ロボットの技術向上は著しく、高性能なロボットを安価に購入することが可能となってきている。家庭用ロボットの中でも、コミュニケーション能力に特化したロボット（以下コミュニケーションロボット）は、気軽に購入できるだけでなく、簡単な商品の説明、客の呼び込みや受付対応といった接客業務に利用することができるため、注目されている。

コミュニケーションロボットでは、工場等で使用される従来のロボットと比較して、人間らしい振る舞いが求められる。従来のロボット制御方式では、通知された全てのイベントを順番に処理するシーケンス制御が一般的である。

例として、あるディベロッパーツールでは、有限オートマトンのように状態ＸでイベントＩを受信したら処理Ｆを実行するといった、シーケンス制御でロボットを制御する。従って、状態Ｘで受信可能なイベントＩ以外のイベントを受信した場合、そのイベントを破棄することになる。

また、非特許文献１に開示されているＲ−ｅｎｖではキューを用いることで受信したイベントをプールし、全てのイベントを破棄することなく、実行する。

細淵 貴司、山田 智広 ： ＡＩ を活用したロボットなど，デバイス連携サービスを容易に開発可能とする技術「Ｒ−ｅｎｖ：連舞(r)」、エレクトロニクス実装学会誌 Ｖｏｌ． １９ Ｎｏ． ６ （２０１６）

しかしながら、人間らしい振る舞いが求められるコミュニケーションロボットでは、必ずしも通知された全てのイベントを処理することが人間らしい振る舞いになるとは限らない。例えば、カメラによる人認識や音声による呼びかけを契機として接客を行うロボット（以下接客ロボット）について考えると、ロボットがある処理を実行中にお客様（お客様Ａとする）からのアクションとして、商品に関する質問を受けた（契機イベントが発生した）場合、ロボットは実行中の処理が終了した後に、お客様Ａからのイベントを処理する。しかし、実行中の処理が終了するまでに時間がかかった場合、お客様Ａが接客用ロボットの前に留まっているとは限らない。場合によっては、接客ロボットからお客様Ａが離れ、別のお客様が接近してきた時に、お客様Ａからの質問に対する商品の説明を行う可能性がある。また、新しいお客様が来店したタイミングで、別のお客様が商品に関して質問した場合、一般的な人間ならば商品について質問してきたお客様の対応を先に行う。しかし、従来の制御手法では、来店客の対応を先に行う可能性がある。

すなわち、イベントの発生を契機として処理を実行するコミュニケーションロボット等のシステムにおいて、従来技術では、イベントの優先度に応じて、適切に処理を行うことができなかった。なお、このような問題は、コミュニケーションロボットに限らず、イベントの発生を契機として処理を実行する他のシステムにも発生し得る問題である。

本発明は上記の点に鑑みてなされたものであり、イベントの発生を契機として処理を実行するシステムにおいて、イベントの優先度に応じて、適切に処理を実行することを可能とする技術を提供することを目的とする。

開示の技術によれば、受信したイベント情報を出力するための制御を行うイベント制御装置であって、
優先度毎のキューを有するマルチキューと、
受信したイベント情報の優先度に対応するキューに、当該イベント情報を格納する入力制御手段と、
イベント情報取得要求を受信した場合に、前記マルチキューにおける出力可能なイベント情報を格納するキューのうち、最も優先度の高いキューからイベント情報を取得し、出力する出力制御手段と
を備えることを特徴とするイベント制御装置が提供される。

開示の技術によれば、イベントの発生を契機として処理を実行するシステムにおいて、イベントの優先度に応じて、適切に処理を実行することを可能とする技術が提供される。

本発明の実施の形態におけるイベント処理システムの全体構成図である。 イベント制御装置１００の機能構成図である。 キューを説明するための図である。 イベント制御装置１００のハードウェア構成図である。 イベント処理システムにおける基本的な処理の流れを説明するためのシーケンス図である。 優先度別に要素をエンキューする動作を説明するための図である。 複数の優先度の要素がエンキューされる場合の処理の流れを説明するためのシーケンス図である。 後に発生したイベントの要素が先にエンキューされる場合のキューの動作を説明するための図である。 後に発生したイベントの要素が先にエンキューされる場合の処理の流れを説明するためのシーケンス図である。 タイムアウト処理を説明するための図である。 全体動作例を説明するための図である。 イベント制御装置１００の動作を示すフローチャートである。

以下、図面を参照して本発明の実施の形態（本実施の形態）を説明する。以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。例えば、本実施の形態では、本発明に係るイベント制御技術をコミュニケーションロボットに適用する例を示しているが、これは一例である。本発明に係るイベント制御技術をコミュニケーションロボット以外のシステムに適用することも可能である。

また、以下では、基本的に、センサ等のデバイスが検知する事象（例：人がある商品についての質問をすること）を「イベント」と呼び、イベントを検知したデバイスが送信する情報を「イベント情報」と呼び、キューに格納される情報及びキューから出力される情報を、「イベント情報」又は「要素」と呼ぶ。また、イベントを検知したデバイスが送出する情報を「メッセージ」と呼ぶ場合もある。

ただし、本明細書及び特許請求の範囲において、「イベント」は、センサ等のデバイスが検知する事象に限られるわけではなく、当該事象以外も含まれる。

例えば、本発明は、優先度に応じてデータの処理を行って、優先度の低いデータは破棄してかまわないようなデータを扱うシステム全般に適用でき、「イベント」には、当該システムで扱われるデータに関連する事象全般が含まれる。

より具体的には、例えば、本発明をウェアラブル端末等で人に情報（天気の通知、人が位置する場所の見どころ等）を提供する仕組みに適用してもよい。この場合において、「イベント」は、天気の変化である場合もあるし、人の位置である場合もあるし、その他の事象である場合もある。当該イベントの発生を示すイベント情報は、イベント制御装置（ウェアラブル端末等）が他の装置から受信する場合もあるし、イベント制御装置自身が取得する（つまり、外部環境から受信する）場合もある。

また、提供する情報を選別する条件として、本実施の形態のように時間を使用することは一例である。提供する情報を選別する条件として時間に関する条件以外の条件（例：位置に関する条件）を使用してもよい。

（概要）
本実施の形態では、イベント制御装置１００により、コミュニケーションロボットが、重要度の高いイベントから優先して処理することを可能としている。また、イベント発生時刻が古すぎる場合に、当該イベントに対する処理を行うことなく次のイベントを処理することも可能としている。これらにより、コミュニケーションロボットが従来よりも人間らしい振る舞いを行うことが可能となる。

上記動作を可能ならしめるために、イベント制御装置１００は、優先度毎のキューを備える。コミュニケーションロボットに対してイベント情報をデキューする際には、優先度の高いキューからイベント情報を順にデキューすることで、重要なイベントを優先的に処理することを可能としている。

キューの中にエンキューする要素は、イベントの識別情報、及びイベント発生時刻（タイムスタンプ）を含む。イベント制御装置１００は、コミュニケーションロボットへのイベント情報のデキューに際し、タイムスタンプと現在の時刻とを比較し、Ｘ秒以上前に発生したイベントのイベント情報を無視する。

複数のデバイスから発生したイベントを一つのキューにエンキューする場合、後に発生したイベントが先にエンキューされる可能性がある。本実施の形態ではキューの先頭（先にエンキューされた要素）からＫ個の要素間のイベント発生時刻を比較することで、先に発生したイベントを先に処理することを可能としている。

（システム全体構成）
図１に、本実施の形態におけるイベント処理システムの全体構成図を示す。図１に示すように、当該イベント処理システムは、イベント制御装置１００、コミュニケーションロボット２００、複数のセンサ３００、複数の端末４００を含む。また、コミュニケーションロボット２００は、イベント処理機能部２１０を有する。

イベント制御装置１００は、コミュニケーションロボット２００内の装置（機能）であってもよいし、コミュニケーションロボット２００の外部の装置であってもよい。いずれの場合も、イベント制御装置１００は、センサ３００や端末４００等のデバイスから発出されるイベント情報を受信し、当該イベント情報を、優先度毎に、各優先度専用のキューにエンキューする。なお、デバイスの数は１つであってもよい。また、イベント制御装置１００は、コミュニケーションロボット２００が有するイベント処理機能部２１０からデキュー要求を受けた場合に、Ｘ秒以内に発生したイベントの内、最も優先度の高いイベントのイベント情報をデキューし、当該イベント情報をイベント処理機能部２１０に送信する。

センサ３００は、コミュニケーションロボット２００の内部のデバイスであってもよいし、コミュニケーションロボット２００の外部のデバイスであってもよい。図１では、外部のデバイスのイメージを示している。

各センサ３００は、例えば、マイクを有するデバイス、カメラを有するデバイス、タッチセンサを有するデバイス等である。あるセンサ３００は、人から話しかけられると、例えば、話の内容（例：商品に対する質問）に対応するイベントを検知し、当該イベントの発生を通知するイベント情報をイベント制御装置１００に送信する。また、例えば、あるセンサ３００は、顔が近づくと、その顔の人物に対応するイベントを検知し、当該イベントの発生を通知するイベント情報をイベント制御装置１００に送信する。また、例えば、あるセンサ３００は、なでられる（例：ロボットの頭をなでる）と、それに対応するイベントを検知し、当該イベントの発生を通知するイベント情報をイベント制御装置１００に送信する。イベント情報には、イベントＩＤ、イベント発生時刻、及び優先度が含まれる。なお、デバイスが送信するイベント情報には優先度が含まれないこととしてもよい。その場合、例えば、イベント制御装置１００が、イベント情報の送信元のデバイス及び／又は当該イベント情報の元となる情報（例：センサが検知した音声／映像等の情報）等に基づいて、優先度を決定することができる。

図１に示すように、イベント情報は、ユーザが操作する端末４００から送信することも可能である。端末４００は、例えば、スマートフォン、ＰＣ等である。

コミュニケーションロボット２００におけるイベント処理機能部２１０は、イベント制御装置１００から取得するイベント情報を解釈し、コミュニケーションロボット２００にイベントに応じた動作を実行させる。より具体的には、イベント処理機能部２１０は、コミュニケーションロボット２００において、あるイベントに対応して現在行われている処理を終了する度に、イベント制御装置１００に対して、デキュー要求を行うことで、イベント情報のデキューが可能かどうかを問い合わせる。デキュー可能な場合に、イベント制御装置１００からイベント情報を取得し、処理を行う。

以下、イベント制御装置１００の構成と動作をより詳細に説明する。

（イベント制御装置１００の構成）
図２に、イベント制御装置１００の機能構成図を示す。図２に示すように、イベント制御装置１００は、入力部１０１、キュー部１０２、出力部１０３、及び制御部１０４を有する。

入力部１０１は、イベント情報を受信し、当該イベント情報をキュー部１０２に渡す。キュー部１０２は、優先度毎のキューからなる複数のキュー（マルチキューと呼ぶ）を有する。制御部１０４により、イベント情報が、対応する優先度のキューに格納される。制御部１０４は、イベント情報のキューへの格納、及びイベント情報のデキューに係る制御を行う。以降で説明するイベント制御装置１００における制御動作は、主に制御部１０４により実行されるものである。

なお、制御部１０４における入力に係る機能を入力部１０１に含め、制御部１０４における出力に係る機能を出力部１０３に含めることで、制御部１０４を備えないこととしてもよい。

＜マルチキューの構成＞
図３に、キューの構成例を示す。図３の（ａ）に示すように、キュー部１０２が備えるマルチキューは、優先度毎のキューを含む。制御部１０４は管理用配列を有する。マルチキューにおける各キューの実体は、メモリの記憶領域であり、ソフトウェア上では配列で表現される。管理用配列は、キューの数（＝優先度の数）を示す最大優先度と、各キューへのポインタ（キューのアドレス）を有する。

なお、各優先度のキューはそれぞれ独立しているため、キュー毎に設定を変更することが可能である。

また、制御部１０４は、キュー毎に、（ｂ）に示す管理情報を保持する。管理情報は、キュー内に存在する全要素数、デキューする際に比較する要素数、及びタイムアウト時間を保持する。また、（ｂ）に示すように、各キューにエンキューされる各要素は、イベント発生時刻（タイムスタンプ）、イベントＩＤ、及び優先度を保持している。なお、キューと優先度とは対応付けられるので、各要素は優先度を含まないこととしてもよい。

＜イベント制御装置１００のハードウェア構成例＞
本実施の形態に係るイベント制御装置１００は、例えば、コンピュータに、本実施の形態で説明する処理内容を記述したプログラムを実行させることにより実現可能である。当該コンピュータは、コミュニケーションロボット２００内のコンピュータ（＝メモリとＣＰＵ等を有する構成）でもよいし、コミュニケーションロボット２００外のコンピュータでもよい。

すなわち、イベント制御装置１００が有する機能は、当該コンピュータに内蔵されるＣＰＵやメモリ、ハードディスクなどのハードウェア資源を用いて、イベント制御装置１００で実施される処理に対応するプログラムを実行することによって実現することが可能である。上記プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メールなど、ネットワークを通して提供することも可能である。

なお、イベント制御装置１００が保持するキューについては、上記のプログラムにより実現されてもよいし、上記のプログラム以外の機構で実現されてもよい。

図４は、イベント制御装置１００をコンピュータで実現する場合における当該装置のハードウェア構成例を示す図である。図４に示すイベント制御装置１００は、それぞれバスＢで相互に接続されているドライブ装置１５０、補助記憶装置１５２、メモリ装置１５３、ＣＰＵ１５４、インタフェース装置１５５、表示装置１５６、及び入力装置１５７等を有する。

当該イベント制御装置１００での処理を実現するプログラムは、例えば、ＣＤ−ＲＯＭ又はメモリカード等の記録媒体１５１によって提供される。プログラムを記憶した記録媒体１５１がドライブ装置１５０にセットされると、プログラムが記録媒体１５１からドライブ装置１５０を介して補助記憶装置１５２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１５１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１５２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１５３は、プログラムの起動指示があった場合に、補助記憶装置１５２からプログラムを読み出して格納する。ＣＰＵ１５４（プロセッサ）は、メモリ装置１５３に格納されたプログラムに従って当該装置に係る機能を実現する。インタフェース装置１５５は、ネットワークに接続するためのインタフェースとして用いられる。表示装置１５６はプログラムによるＧＵＩ（Graphical User Interface）等を表示する。入力装置１５７はキーボード及びマウス、ボタン、又はタッチパネル等で構成され、様々な操作指示を入力させるために用いられる。

図４に示すイベント制御装置１００がコミュニケーションロボット２００内に備えられる場合において、例えば、イベント処理機能部２１０は、バスＢに接続される。また、バスＢには、コミュニケーションロボット２００のモータ等を制御する制御回路が接続されてもよい。

（基本的な動作例）
図５を参照して、本実施の形態におけるイベント処理システムの基本的な動作例を説明する。

ステップＳ１０１において、イベント制御装置１００は要求待ちの状態にある。ステップＳ１０２において、イベント制御装置１００は、センサ３００からイベント情報を受信する。イベント情報には、イベントＩＤ、タイムスタンプ、優先度が含まれる。ステップＳ１０３において、イベント制御装置１００は、イベント情報を解読し、当該イベント情報に含まれる優先度に対応するキューに、イベント情報をエンキューする。

ステップＳ１０４において、イベント制御装置１００は、イベント処理機能部２１０からデキュー要求を受信する。イベント制御装置１００は、デキューする要素を選択し、当該要素（イベント情報）をキューから取得して、イベント処理機能部２１０に通知する（ステップＳ１０５、Ｓ１０６）。ステップＳ１０７〜Ｓ１１１において、別のセンサ３００から送信されるイベント情報により、ステップＳ１０２〜Ｓ１０６と同様の処理が行われる。

上記のとおり、本実施の形態におけるイベント処理システムにおいて、各デバイスはイベント発生時刻（タイムスタンプ）、イベントＩＤ、優先度を含むイベント情報をイベント制御装置１００へ通知する。イベント制御装置１００は、例えば複数のデバイスからイベント情報を受信する。イベント制御装置１００は受信した各イベント情報を優先度別に独立したキューへエンキューする。更に、イベント制御装置１００は、イベント発生タイミングによるＦＩＦＯ動作、及びタイムアウト動作を実行する。

以下、「複数デバイスから受信したイベント情報を優先度別にエンキューする動作」、「イベント発生タイミングによるＦＩＦＯ動作」、及び「タイムアウト動作」のそれぞれについてより詳細に説明する。

（複数デバイスから受信したイベント情報を優先度別にエンキューする動作例）
まず、イベント情報を優先度別にエンキューする動作例を説明する。イベント制御装置１００は、受信する可能性のあるイベント情報の優先度毎に専用のキューを保持し、受信したイベント情報を、当該イベント情報に対応する優先度専用のキューにエンキューする。

一例を図６に示す。図６は、イベント制御装置１００が、センサ１，２，３からイベント情報を受信する例を示す。本例において、センサ１とセンサ２は優先度１のイベント情報を通知し、センサ３は優先度２のイベント情報を通知する。従って、イベント制御装置１００は、センサ１とセンサ２から受信したイベント情報を優先度１専用のキューにエンキューし、センサ３から受信したイベント情報を優先度２専用のキューにエンキューする。各キューには、対応する優先度のイベント情報を受信した順番で、イベント情報が格納される。

コミュニケーションロボット２００において現在行っている処理が終了すると、イベント処理機能部２１０からイベント制御装置１００へデキュー処理が要求される。イベント制御装置１００は、イベント処理機能部２１０からデキュー要求を受信すると、優先度の高いキューから順にデキュー可能か否かを調べ、デキュー可能なキューのうち最も優先度の高いキューからデキューを行う。なお、デキュー可能なキューとは、要素が存在するキューである。また、デキュー可能なキューとは、タイムアウトしていない要素が存在するキューであることとしてもよい。

図６に示す例では、優先度１専用キューが要素を持っているため、優先度１専用キューからデキューされる。仮に優先度１専用キューが空であった場合、次に優先度の高い優先度２専用キューからデキューされる。

図７は、複数の優先度の要素がエンキューされる場合の処理の流れを示すシーケンス図である。

ステップＳ２０２において、イベント制御装置１００は、センサ３００から、優先度２のイベントＹが１０：１２に発生したことを示すイベント情報を受信する。ステップＳ２０３において、イベント制御装置１００は、イベントＩＤがＹ、タイムスタンプが１０：１２を格納した要素を優先度２のキューにエンキューする。

続いて、ステップＳ２０４において、イベント制御装置１００は、別のセンサ３００から、優先度１のイベントＸが１０：１３に発生したことを示すイベント情報を受信する。ステップＳ２０５において、イベント制御装置１００は、イベントＩＤがＸ、タイムスタンプが１０：１３を格納した要素を優先度１のキューにエンキューする。

ステップＳ２０６において、イベント制御装置１００は、イベント処理機能部２１０からデキュー要求を受信する。イベント制御装置１００は、デキューする要素として優先度１のイベントＸの要素を選択し（ステップＳ２０７）、選択した優先度１のイベントＸを示すイベント情報をイベント処理機能部２１０に通知する（ステップＳ２０８）。

（イベント発生タイミングによるＦＩＦＯ動作例）
次に、イベント発生タイミングによるＦＩＦＯ動作例を図８、図９を参照して説明する。イベント制御装置１００は、複数のデバイスからイベント情報を受信し、受信した順番でイベント情報のエンキュー処理を行うため、イベント発生時刻とエンキュー処理のタイミングが逆転する可能性がある。

図８は、センサ１で１２：５０に優先度１のイベント情報が発生し、センサ２で１２：５１に優先度１のイベント情報が発生した場合の例を示している。本来であれば、先に発生したセンサ１のイベント情報が先にエンキューされるべきであるが、図８の例では、通信時の遅延やマルチスレッドの制御等の理由からセンサ２で発生したイベントが先にエンキューされている。

そこで、本実施の形態に係るイベント制御装置１００は、本事象への対策として、デキュー時にキューの先頭からＫ個（Ｋは比較要素数であり、０以上の整数である）の要素のタイムスタンプを比較し、最も古いイベント情報をデキューすることとしている。図８の例では、キューの先頭Ｋ個の中で最も古いイベントが１１：２３に発生したイベントであるため、１１：２３に発生したイベントのイベント情報をデキューしている。なお、キューの先頭からＫ個の要素のタイムスタンプを比較し、最も古いイベント情報をデキューすることは一例に過ぎない。この条件以外の所定の条件に基づいてデキューを行うこととしてもよい。例えば、所定の位置あるいはエリアを示すイベント情報がキューにある場合に、当該イベント情報をデキューすることとしてもよい。

図９は、後に発生した要素が先にエンキューされる場合の処理の流れを示すシーケンス図である。

ステップＳ３０２において、イベント制御装置１００は、センサ３００から、優先度１のイベントＸが１２：５１に発生したことを示すイベント情報を受信する。ステップＳ３０３において、イベント制御装置１００は、イベントＩＤがＸ、タイムスタンプが１２：５１を格納した要素を優先度１のキューにエンキューする。

続いて、ステップＳ３０４において、イベント制御装置１００は、別のセンサ３００から、優先度２のイベントＹが１２：５０に発生したことを示すイベント情報を受信する。ステップＳ３０５において、イベント制御装置１００は、イベントＩＤがＹ、タイムスタンプが１２：５０を格納した要素を優先度１のキューにエンキューする。

ステップＳ３０６において、イベント制御装置１００は、イベント処理機能部２１０からデキュー要求を受信する。イベント制御装置１００は、デキューする要素として、発生時刻が早い（古い）ほうの優先度１のイベントＹの要素を選択し（ステップＳ３０７）、選択した優先度１のイベントＹを示すイベント情報をイベント処理機能部２１０に通知する（ステップＳ３０８）。

（タイムアウト処理）
次に、タイムアウト処理について図１０を参照して説明する。本実施の形態に係るイベント制御装置１００は、一定時間（Ｘ秒）以上古いイベント情報を、処理することなく破棄することとしている。すなわち、イベント制御装置１００は、例えば要素をデキューするタイミングで、キュー内に現在時刻よりもＸ秒以上古いイベントの要素が存在すると、その要素を当該キューから破棄する。「Ｘ秒」は、図３（ｂ）に示したタイムアウト時間として、キュー毎に予め設定される値である。なお、タイムアウト時間は、マルチキュー全体に対して設定される値（各キューに共通の値）であってもよいし、設定するのではなく、キュー毎にあるいはキュー共通に予め定められた固定値であってもよい。なお、一定時間（Ｘ秒）以上古いイベント情報を破棄することは一例に過ぎない。この条件以外の所定の条件に基づいて破棄を行うこととしてもよい。例えば、所定の位置あるいはエリアに存在しないことを示すイベント情報を破棄することとしてもよい。

図１０に示す例では、７秒以上古いイベントを破棄する設定のキューにおける、現在時刻（デキュータイミング）が１２：５２：３４である場合の例である。本例では、１２：５２：２６に発生したイベントが現在時刻よりも７秒以上古いため、このイベントの要素を処理することなく破棄している。なお、タイムアウト判定／要素破棄の処理を行うタイミングは、要素をデキューするタイミングに限らず、他のタイミングであってもよい。例えば、一定時間間隔で、各キューに対し、タイムアウト判定／要素破棄の処理を行ってもよい。

（全体動作例）
上述した３つの動作をまとめた全体の動作例を図１１を参照して説明する。

＜イベント情報通知動作＞
図１１に示す例では、イベント制御装置１００は、センサ１とセンサ２から優先度２のイベント情報を受信し、センサ３から優先度３のイベント情報を受信する。図１１に示すとおり、各センサから受信したイベント情報は、当該イベント情報の優先度に対応するキューへエンキューされる。

＜イベント情報デキュー動作＞
図１１に示すとおり、本例のイベント制御装置１００は、優先度１，２，３専用のキューをそれぞれ保持している。また、優先度専用キュー毎に、時刻比較要素数とタイムアウト時間を保持している。時刻１２：５２：４４にコミュニケーションロボット２００のイベント処理機能部２１０が、イベント制御装置１００に対してデキュー要求を行ったものとする。この場合、以下の流れでデキュー動作が実行される。

ステップＳ１）イベント制御装置１００は、最も優先度の高い優先度１専用キューから、優先度順に、キューの要素がデキュー可能かどうかを検査する。図１１に示すように、優先度１専用キューのタイムアウト時間は１０秒であるのに対し、キュー内の要素は全て現在時刻より１０秒以上過去に発生したイベントの要素であるため、イベント制御装置１００は、優先度１専用キュー内の要素を全て破棄する。

ステップＳ２）イベント制御装置１００は、次に優先度の高い優先度２専用キューにおける要素がデキュー可能かどうかを検査する。図１１に示すように、優先度２専用キューの先頭３つの要素は全て現在時刻より６秒以内に発生したイベントであるため、破棄されない。

ステップＳ３）イベント制御装置１００は、優先度２専用キューが、デキュー可能なキューのうち最も優先度が高いキューと判断しデキューを行うことを決定する。

ステップＳ４）優先度２専用キューの先頭３要素の中で最も古いイベントは１２：５２：３９に発生したイベントであるため、１２：５２：３９のイベントの要素がデキューされる。

（イベント制御装置１００の処理フロー）
次に、図１２に示すフローチャートを参照して、イベント制御装置１００の詳細な処理フローを説明する。図１２に示す例では、最も高い優先度の値は０であり、優先度の降順に１づつ値が増加する。優先度の数は「最大優先度」である。

まず、イベント制御装置１００は要求待ちの状態である（ステップＳ４０１）。イベント制御装置１００の入力部１０１から、受信したメッセージ（ここでは、イベント情報（＝エンキュー要求）、又は、デキュー要求）が入力されると、制御部１０４は、当該メッセージがエンキュー要求か否かを判定する（ステップＳ４０２）。ステップＳ４０２における判定結果がＹｅｓの場合、処理はステップＳ４０３に進む。制御部１０４は、メッセージを解析し、優先度、イベントＩＤ、及びタイムスタンプを取得し（ステップＳ４０３）、イベントＩＤとタイムスタンプを格納した要素を、当該優先度に対応するキューにエンキューする（ステップＳ４０４）。なお、ステップＳ４０３、Ｓ４０４の動作を入力部１０１が行うこととしてもよい。処理が終了しない限り、エンキュー要求を受信する度にステップＳ４０３、Ｓ４０４の処理が実行される。

ステップＳ４０２での判定結果がＮｏである場合（つまり、デキュー要求を受信した場合）、ステップＳ４０６〜Ｓ４１４の側の処理に移る。ここでの処理では、基本的に、優先度毎にＬ１Ａ〜Ｌ１Ｂで示すループが実行され、そのループの中で、Ｌ２Ａ〜Ｌ２Ｂで示すループが実行される。ただし、優先度ｉにおいて、デキュー要素が選択されている場合には、ステップＳ４１１において、優先度ｉのループから抜ける。ステップを順番に説明すると以下のとおりである。

制御部１０４は、優先度ｉのキューに要素があるかどうかを判定する（ステップＳ４０６）。ステップＳ４０６での判定がＮｏ（要素がない）の場合、ｉに１を加えることで、次の優先度ｉに移り、ステップＳ４０６からの処理を行う。

ステップＳ４０６での判定がＹｅｓ（要素がある）の場合、Ｌ２Ａ〜Ｌ２Ｂで示すループ（ｊ＝０から「比較要素数」まで、ｊを１づつ増加させるループ）に移る。なお、「比較要素数」は、現在の優先度ｉのキューに対応する「比較要素数」である。また、キューの先頭から０番目の要素は、キューの先頭の要素である。従って、例えば、図１０における「キューの先頭から１番目の要素」は、タイムスタンプが１２：５２：３０の要素である。

制御部１０４は、優先度ｉのキューの先頭からｊ番目の要素のタイムスタンプと現在時刻とを比較することにより、当該要素がタイムアウトしていないかどうかを判定する（ステップＳ４０７）。ここでのタイムアウト時間は、優先度ｉのキューに対応するタイムアウト時間である。

ステップＳ４０７の判定結果がＮｏの場合（タイムアウトしている場合）、制御部１０４は、優先度ｉのキューの先頭からｊ番目の要素を削除し（ステップＳ４０９）、ｊに１を加えて、ステップＳ４０７からの処理に戻る。

ステップＳ４０７の判定結果がＹｅｓの場合（タイムアウトしていない場合）、制御部１０４は、優先度ｉのキューの先頭からｊ番目の要素が、０〜ｊ番目の要素（削除した要素を除く）の中で最も古いかどうかを判定する（ステップＳ４０８）。

ステップＳ４０８の判定結果がＮｏの場合（最も古くはない場合）、制御部１０４は、ｊに１を加えて、ステップＳ４０７からの処理に戻る。

ステップＳ４０８の判定結果がＹｅｓの場合（最も古い場合）、制御部１０４は、優先度ｉのキューの先頭からｊ番目の要素をデキュー要素として選択し（ステップＳ４１０）、ｊに１を加えて、ステップＳ４０７からの処理に戻る。ステップＳ４１０において、既に選択したデキュー要素がある場合は、現在のものに置き換える。

ｊに１を加えることにより、ｊが「比較要素数」に達すると、ステップＳ４１１に移る。ステップＳ４１１では、デキュー要素が選択されている場合に、優先度ｉのループ（Ｌ１Ａ〜Ｌ１Ｂのループ）から抜ける。デキュー要素が選択されていない場合には、ｉに１を加えることにより、次の優先度ｉについてステップＳ４０６からの処理を行う。ステップＳ４１１でループを抜けない場合、ｉに１を加えることにより、ｉが最大優先度に達した時点で優先度ｉのループ（Ｌ１Ａ〜Ｌ１Ｂのループ）から抜ける。

ステップＳ４１２において、制御部１０４は、デキュー要素が選択されているかどうかを判定する。ステップＳ４１２での判定結果がＹｅｓの場合、制御部１０４からの指示に基づき、出力部１０３が、デキュー要素を出力する。つまり、デキュー要素をイベント処理機能部２１０に送信する。ステップＳ４１２での判定結果がＮｏの場合、制御部１０４からの指示に基づき、出力部１０３が、ＮＵＬＬをイベント処理機能部２１０に送信する。

なお、上記のフローにおける処理では、制御部１０４は、キューにおける要素の削除処理をデキュー要求を受信したことに応じて行うこととしているが、デキュー要求の有無に関わらずに、例えば一定時間間隔で、各キューにおける要素の削除処理を行うこととしてもよい。

また、上記のフローにおける処理では、優先度の高いイベントの発生が継続する限り、当該優先度の高いイベントに対する処理の実行が継続されることになるが、例えば、優先度の高いイベント（例：最高優先度のイベント）に対する処理が、予め定めた回数（又は、予め定めた時間長）だけ連続した場合に、次の優先度のキューの優先度を一時的に最高優先度にする等の操作により、次の優先度のイベント情報がデキューされるようにしてもよい。

（実施の形態の効果等について）
従来技術におけるキューを用いたシーケンス制御手法では、イベント情報の到着順に処理を行うため、重要度の高いイベント情報と重要度の低いイベントが同時に発生した際に、重要度の高いイベント情報を優先して処理することができない。また、エンキューされた全ての要素を処理すると、イベント発生から実際の処理までにタイムラグが発生する可能性がある。このため、何らかのイベント（イベントＡとする）発生後、イベントＡがキューに残されたまま、ユーザがコミュニケーションロボット付近から離れた場合に、別のユーザがコミュニケーションロボットに近づいた時に、イベントＡに対する処理を行ってしまうという不自然な動作がなされる可能性がある。

一方、本実施の形態に係る技術では、優先度毎のキューを備え、イベント情報をデキューする際には、優先度の高いキューからイベント情報を順にデキューすることで、重要なイベントを優先的に処理することを可能としている。また、イベント情報のデキューに際し、タイムスタンプと現在の時刻とを比較し、古いイベント情報（例：上記のイベントＡ）を無視することで、上記のような不自然な動作を防止することを可能としている。

すなわち、本実施の形態に係る技術により、コミュニケーションロボットは、イベントの優先度に応じて、適切に処理を実行することが可能となる。より具体的には、コミュニケーションロボットが、より人間らしい振る舞いを行うことが可能となる。

（実施の形態のまとめ）
以上、説明したように、本実施の形態により、受信したイベント情報を出力するための制御を行うイベント制御装置であって、優先度毎のキューを有するマルチキューと、受信したイベント情報の優先度に対応するキューに、当該イベント情報を格納する入力制御手段と、イベント情報取得要求を受信した場合に、前記マルチキューにおける出力可能なイベント情報を格納するキューのうち、最も優先度の高いキューからイベント情報を取得し、出力する出力制御手段とを備えることを特徴とするイベント制御装置が提供される。

なお、実施の形態で説明した入力部１０１及び制御部１０４は入力制御手段の例であり、出力部１０３及び制御部１０４は出力制御手段の例である。

前記出力制御手段は、例えば、前記最も優先度の高いキューにおけるイベント情報のうち、所定の条件を満たすイベントのイベント情報を出力する。

前記出力制御手段は、キューに格納されているイベント情報のうち、イベント情報削除のために定められた所定の条件を満たすイベントのイベント情報を削除することとしてもよい。

前記イベント制御装置は、例えば、コミュニケーションロボットの内部又は外部の装置であり、前記イベント情報を出力することにより、前記コミュニケーションロボットを当該イベント情報に基づき動作させる。

以上、本実施の形態について説明したが、本発明はかかる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１００ イベント制御装置
２００ コミュニケーションロボット
２１０ イベント処理機能部
３００ センサ
４００ 端末
１０１ 入力部
１０２ キュー部
１０３ 出力部
１０４ 制御部
１５０ ドライブ装置
１５１ 記録媒体
１５２ 補助記憶装置
１５３ メモリ装置
１５４ ＣＰＵ
１５５ インタフェース装置
１５６ 表示装置
１５７ 入力装置

Claims (6)

1. 受信したイベント情報を出力するための制御を行うイベント制御装置であって、
   優先度毎のキューを有するマルチキューと、
   受信したイベント情報の優先度に対応するキューに、当該イベント情報を格納する入力制御手段と、
   イベント情報取得要求を受信した場合に、前記マルチキューにおける出力可能なイベント情報を格納するキューのうち、最も優先度の高いキューからイベント情報を取得し、出力する出力制御手段と
   を備えることを特徴とするイベント制御装置。
2. 前記出力制御手段は、前記最も優先度の高いキューにおけるイベント情報のうち、所定の条件を満たすイベントのイベント情報を出力する
   ことを特徴とする請求項１に記載のイベント制御装置。
3. 前記出力制御手段は、キューに格納されているイベント情報のうち、イベント情報削除のために定められた所定の条件を満たすイベントのイベント情報を削除する
   ことを特徴とする請求項１又は２に記載のイベント制御装置。
4. 前記イベント制御装置は、コミュニケーションロボットの内部又は外部の装置であり、前記イベント情報を出力することにより、前記コミュニケーションロボットを当該イベント情報に基づき動作させる
   ことを特徴とする請求項１ないし３のうちいずれか１項に記載のイベント制御装置。
5. 受信したイベント情報を出力するための制御を行うイベント制御装置であって、優先度毎のキューを有するマルチキューを備えるイベント制御装置が実行するイベント制御方法であり、
   受信したイベント情報の優先度に対応するキューに、当該イベント情報を格納する入力制御ステップと、
   イベント情報取得要求を受信した場合に、前記マルチキューにおける出力可能なイベント情報を格納するキューのうち、最も優先度の高いキューからイベント情報を取得し、出力する出力制御ステップと
   を備えることを特徴とするイベント制御方法。
6. コンピュータを、請求項１ないし４のうちいずれか１項に記載のイベント制御装置における各手段として機能させるためのプログラム。

Images