JP4935392B2 - 出力調停プログラム及び装置 - Google Patents

Description

本発明は、情報の出力を調停するための技術に関する。

例えば、無線配信されるＶＩＣＳ（Vehicle Information and Communication System）情報により道路の混雑状況を出力したり、車載カメラで取得した周囲の映像を出力したりするなど、カーナビゲーション・システム等の車載端末を用いて、車内外の情報を運転手に通知することが行われている。走行状態の安全性を高めるためには、車載端末が受け付けた様々な情報を理解し易い形で提供することは勿論、早く効率的に、運転手に通知することが望まれている。

そのため、例えば、特開平１０−１０４００３号公報には、過度に情報が提供されることなく、且つ的確に必要な情報を提供することのできるナビゲーション装置が開示されている。具体的には、情報をドライバに提供するナビゲーション装置は、提供すべき情報が複数存在するときに、予め設定された優先順位に従って順位の高い情報を選択する手段と、選択された情報を選択された順にドライバに提供する手段を有する。但し、以下で述べるような本発明のきめ細やかな出力調停は不可能である。
特開平１０−１０４００３号公報

従って、本発明の目的は、短時間に必要な情報を効率的に利用者に提供することができるようにするための新規の技術を提供することである。

本発明の第１の態様に係る出力調停方法は、アクションキューに登録されている第１のアクションに係る第１の情報の出力が完了する前に、アクションキューに次以降に登録されている第２のアクションが、当該第２のアクションに係る第２の情報の出力に用いられる特定の出力機能が空き状態であるか又は割込制御無しの機能であるかという条件を含む所定の条件を満たしているか否か判断する判断ステップと、第２のアクションが所定の条件を満たしていると判断された場合には、第１の情報の出力が完了しているか否かにかかわらず、第２のアクションに係る第２の情報の出力を特定の出力機能に要求するステップとを含む。

例えば、出力に時間のかかる音声の出力と、出力機能の異なる画像の出力とが並行して行われれば、短時間に必要な情報を効率的に利用者に提供できる。なお、同じスピーカから出力されるものであっても、音声合成出力とビープ音出力についても上で述べた条件が満たされれば並行して行われる。

また、上で述べた所定の条件が、第２のアクションの重要度が、第１の情報及び第２の情報を知覚するユーザの負荷状態に連動する閾値以上であるという条件を含むようにしてもよい。これによって、ユーザの負荷状態が高い場合には、重要度が相対的に低い情報については出力されなくなる。

さらに、上で述べた判断ステップが、出力機能毎に割り込み種別及び状態を管理する管理テーブルを、第２のアクションに係る第２の情報の出力に用いられる特定の出力機能で検索するステップを含むようにしてもよい。このような管理テーブルを用いれば、効率的に処理を行うことができる。

なお、第１のアクションの優先度は、第２のアクションの優先度より高い場合には、割り込みとはならず、上で述べたような並行的な出力が実施される。

また、本発明の第１の態様において、第２のアクションが所定の条件を満たしていないと判断された場合、第２のアクションの実行状態を待機状態に設定するステップをさらに含むようにしても良い。並行して出力できない場合には、第１の情報の出力が終了するまで待機する。

本発明の第２の態様に係る出力調停方法は、アクションキューに登録されている第１のアクションに係る第１の情報の出力中に、アクションキューに第１のアクションより優先度が高く且つ第１のアクションに係る第１の情報の出力に用いられる特定の出力機能が同じ第２のアクションが登録された場合、特定の出力機能による第１の情報の出力を停止させる停止ステップと、第２のアクションに係る第２の情報の出力を特定の出力機能に要求するステップと、第２のアクションに係る第２の情報の出力が完了した後であってアクションキューに登録されている第１のアクションを再度処理する順番になった場合、第１のアクションに係る第１の情報の出力が予め定められた部分まで完了していたか判断するステップと、第１のアクションに係る第１の情報の出力が予め定められた部分まで完了していた場合には、第１の情報の出力をキャンセルさせるステップとを含む。

１回目の出力で内容が伝わる程度まで出力できていれば、中断した後に再度同じような出力を行わないようにすれば、短時間に効率的に情報を伝達することができるようになる。

また、上で述べた停止ステップが、出力機能毎に割り込み種別を管理する管理テーブルを特定の出力機能で検索して、特定の出力機能が割り込み可の出力機能であるか判断するステップと、特定の出力機能が割り込み可の出力機能である場合、特定の出力機能に第１の情報の出力を停止させるステップとを含むようにしてもよい。このようにすれば、割り込み可の出力機能であることが確認される。

なお、第２の情報の出力中に、例えば緊急情報などの第２のアクションよりも優先度の高い情報が割り込んでも構わない。

なお、上記予め定められた部分が、第１の情報の出力割合で特定される場合もある。また、特定のキーワードの位置に基づき決定するようにしても良い。

さらに、上で述べた特定の出力機能が、第１のアクションによって指定された変数に第１の情報の出力割合を登録するステップをさらに含むようにしても良い。

また、第１のアクションに係る第１の情報の出力が予め定められた部分まで完了していない場合、第１の情報の出力を再度特定の出力機能に要求するステップをさらに含むようにしても良い。不明瞭な出力となってしまった情報を再度利用者に伝えるためである。

なお、本方法をコンピュータに実行させるためのプログラムを作成することができ、このプログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークなどを介してデジタル信号として配信される場合もある。尚、中間的な処理結果はメインメモリ等の記憶装置に一時保管される。

本発明によれば、短時間に必要な情報を効率的に利用者に提供することができるようになる。

図１に本発明の一実施の形態に係るエージェントフレームワークのアーキテクチャを示す。本エージェントフレームワークが実装されるシステムは、例えば車載端末の例を想定して説明するが、必ずしも車載端末である必要はない。

本エージェントフレームワークは、ランタイム・エンジンであるエージェントフレームワーク・ランタイム１と、サービスアプリケーションを作成するためのＳＤＫ（Software Development Kit）であるエージェントフレームワークＳＤＫ９とで構成される。なお、アーキテクチャとしては、エージェントフレームワーク・ランタイム１を利用するアプリケーション層３と、エージェントフレームワーク・ランタイム１と連携する基盤ミドルウェア層５と、例えば車載端末に搭載される各種デバイスを含むデバイス層７とをさらに含む。

エージェントフレームワークＳＤＫ９は、開発用ＡＰＩ（Application Program Interface）・ライブラリ９４を含む。開発用ＡＰＩ・ライブラリ９４は、シナリオロジック用インタフェースとイベントアグリゲーションロジックインタフェースとを含むロジック開発用インタフェースと基盤ミドルウェア層向けインタフェース定義とを含む。後でも述べるがアプリケーション層３におけるシナリオロジック３２は、シナリオＸＭＬから動的に呼び出すことのできるＣ＋＋関数である。シナリオロジック３２には、状態に付随する状態ロジック、遷移に付随する遷移ロジック、起動及び終了時に全状態及び全遷移で呼び出される起動終了ロジックの３種類がある。シナリオロジック用インタフェースは、これらロジックが後に述べるシナリオエンジン１１からロードできるようにするためのインタフェース仕様を規定している。また、イベントアグリゲーションロジックインタフェースは、イベントアグリゲーションロジックを、後に述べるイベントアグリゲータ１２２がロード・実行できるようにするインタフェース仕様を規定する。基盤ミドルウェア層向けインタフェース定義は、エージェントフレームワークから適用先システム（例えば車載端末）のデバイスを制御できるようにするためのゲートウェイコンポーネントであり、適用先システムの要件に応じてデバイス毎に開発されるべきものである。基盤ミドルウェア層５における実装コンポーネントがアクションコンダクタ１３及びイベントエンジン１２とインタラクションを行えるように、デバイス制御機能用インタフェース及びデバイスステータス更新用インタフェースが定義されている。デバイス制御機能用インタフェースは、アクションコンダクタ１３からの実行要求・キャンセル要求を実装するため、コールバックインタフェースとしてコマンド要求インタフェース、コマンドキャンセルインタフェースを定義する。デバイスステータス更新用インタフェースは、イベントエンジン１２が管理するイベントデータテーブル３４に対し、デバイスのステータスが変化した際にデータを更新するためのインタフェースを提供する。このようなエージェントフレームワークＳＤＫ９は、他にも本エージェントフレームワークには必要な機能を提供するものもあるが、本実施の形態に主要部ではないので、これ以上述べない。

エージェントフレームワーク・ランタイム１は、シナリオエンジン１１と、イベントエンジン１２と、アクションコンダクタ１３とを有する。シナリオエンジン１１は、シナリオマネージャ１１１と、シナリオインタプリタ１１２とを有する。イベントエンジン１２は、イベントマネージャ１２１と、イベントアグリゲータ１２２とを有する。アクションコンダクタ１３は、アクション制御エンジン１３１と、マルチモーダルエンジン１３２とを有する。

シナリオエンジン１１は、サービスのインタラクション手順を記述したシナリオ３１をシステムに投入・削除し、シナリオ実行時には、サービス利用者（ユーザ）の入力や周辺の状況変化から検出されたイベントに応じて各々のシナリオの状態管理と、出力アクションの要求を行うことで、インタラクションの進行を制御するシナリオ実行コンポーネントである。ユーザは、複数のサービスを、状況に応じて切替えながら、臨機応変に利用することができる。シナリオエンジン１１は、ユーザにサービスを、便利・快適・安全に利用してもらうことを目的として、サービス利用のインタラクション進行を制御する機能を有する。システムで利用される複数のサービスに関する状態管理を行い、サービスのインタラクション進行を記述するシナリオ３１に従って、ユーザの入力イベントやセンサ入力の変化イベントに対応する出力アクションや次のイベント要求を決定し、ユーザとサービスの間のインタラクションを進行させる。また、複数のサービスを同時に動作させた場合には、それらを違和感なく切替えて利用できるようにする。

シナリオエンジン１１のシナリオマネージャ１１１は、シナリオエンジン１１内の各モジュールの起動を制御するモジュールである。シナリオエンジン１１起動時に、設定情報を読み込み、各モジュールのインスタンスを生成する。このモジュールによって生成されるモジュールは、シナリオインタプリタ１１２を含む。シナリオマネージャ１１１は、シナリオインタプリタ１１２を、実行されるシナリオ３１の数だけ生成し、シナリオ定義ファイルを読み込んで登録する。

シナリオインタプリタ１１２は、シナリオ３１の定義に従って、インタラクション進行を制御するモジュールである。入力されたイベント（イベントエンジン１２から通知される）に応じて、シナリオ３１で定義された出力アクションを決定すると共に、次に必要となる入力イベントを決定する。決定されたアクション要求やイベント要求は、それぞれアクションコンダクタ１３やイベントエンジン１２に送付され、処理される。シナリオ定義はシナリオマネージャ１１１によって読み込まれ、シナリオインタプリタ１１２生成時に登録される。

シナリオエンジン１１は、状態遷移モデルで表されるシナリオ３１に従って、サービス利用者にサービスを提供する。シナリオ３１には、サービスを受けるためのインタラクション手順が記述されており、ユーザの入力やセンサの変化などの入力イベントに応じた応答を決定する。

状態遷移モデルは、いくつかの「状態」と、状態から状態への「遷移」により表現される。この表現は、状態をノード、遷移をアークとしたネットワーク構造となる。状態遷移シナリオでは、遷移を定義する条件が真の時に、その遷移先である状態に変化する。本フレームワークで用いるシナリオＸＭＬでは、ｓｔａｔｅ要素がノード、ｔｒａｎｓｉｔｉｏｎ要素がアークに対応する。例えば、状態遷移シナリオにおける状態は、画面への表示や音声による発話といった、利用者に対しての働きかけや、接続されているデバイスなどへの制御命令といった、外部への働きかけ（アクション）を行うことを意味する。状態シナリオにおける遷移は、ユーザによるボタン押下やキー操作、発話などの入力や、デバイスからのイベントを受け付けることを意味する。

本システムにおける状態（ｓｔａｔｅ）には、外部への出力や内部処理を記述する。外部への出力はアクション（ａｃｔｉｏｎ）と呼び、音声やＨＴＭＬ（Hyper Text Markup Language）ブラウザ向けの表現、カーナビゲーション・システムなどの機器制御コマンドなどを記述する。また、内部処理は、プログラム言語で記述されるシナリオロジック３２に定義し、実行時に特定のタイミングで呼び出される。

アクションは、外部出力を制御するコマンドの集合で、制御するモダリティ（本実施の形態においてモダリティとは、デバイス、ミドルウェアをまとめて１つの入力／出力機能単位としたものである。）毎のコマンドで記述する。アクションには、以下で述べるように、重要度と優先度を設定することができ、通常はサービスに与えられる重要度と優先度が使用されるので、明示的に指定する必要はない。重要度は、アクションコンダクタ１３において、外部から与えられる重要度の閾値に従って出力を自動的に抑制したり再開したりする制御のために使用される。この機能によって、例えば、ユーザの負荷状態と連動して重要度の閾値を変化させ、負荷が高い場合には重要なアクションしか出力しないというアプリケーションを実現できる。一方、優先度は、アクションコンダクタ１３において、複数アクションの出力要求が競合している場合に、出力するアクションを調停するために使用される。この機能によって、優先度の低いアクションを出力している途中でも、優先度の高いアクションを割り込ませて出力したり、その逆に、優先度の高いアクションを出力している途中であれば、優先度の低いアクションの出力を待たせたりすることができる。

本システムにおける遷移（ｔｒａｎｓｉｔｉｏｎ）は、状態から状態への遷移関係を定義する。遷移は「現在実行中の状態（カレントコンテキストとも呼ぶ）」から伸びるものが有効となる。遷移の配下には、状態遷移を発生させるイベントを記述する。シナリオインタプリタ１１２は、有効な遷移に記述されたイベントが発生した場合、通知をしてもらえるようにイベントエンジン１２に要求する。

本システムに対する入力は、イベント（ｅｖｅｎｔ）と呼ぶ。イベントは、シナリオ３１で検出対象とする入力を決定するもので、遷移（ｔｒａｎｓｉｔｉｏｎ）の配下に記述される。１つの遷移に複数のイベントを記述した場合には、ＯＲ結合となって、いずれか一方のイベントが発生すれば、状態遷移が起こる。

イベントには、ユーザが定義するイベントであるユーザ定義イベントと、センサ入力のように基盤ミドルウェアで予め定義されているイベントである定義済みイベントと、システム動作に伴う定義済みのイベントである特殊イベントである。ユーザ定義イベントは、シナリオ３１でユーザが定義しているイベントを受理するもので、例えば、音声認識が発生した時に認識結果を受け取ると共にイベント発生を通知してもらうような場合に使用する。定義済みイベントは、シナリオ３１とは別な場所で予め定義されているイベントで、センサ類の入力などがこれにあたる。シナリオ開発者は予め定義済みイベントに関する知識を持っているという前提で、これを利用したシナリオ３１を書くことになる。特殊イベントは、システムの動作に関係するイベントであり、予め定義済みとなっているイベントである。アクションの出力状況を通知するためのイベントなどが含まれる。本フレームワークでは特殊イベントとして以下のような６種類の出力状態に関するイベントが用意されている。
待機：アクション出力要求が何らかの原因で開始できない場合に通知。
開始：アクション出力要求が実際に開始されたタイミングで通知。
中断：出力中のアクションが何らかの原因で中断された場合に通知。
再開：中断されたアクションが再度、開始された場合に通知。
完了：アクションの出力が（タイムアウトを含めて）完了した場合に通知。
エラー：アクションの出力がエラーとなった場合に通知。

これらを指定する特殊なイベント定義を記述することで、出力状態の変化に応じたシナリオ３１を記述することができる。

複数モダリティからの入力を同一のイベントとして扱いたい場合には、各モダリティに対して、コマンドで指定するイベントの書き込み先が同一になるように設定する。例えば、音声入力で「はい」と入力された場合と、画面の「Ｙｅｓ」ボタンが押された場合を同一視する場合、音声と画面のモダリティへのコマンドで同じ場所に入力結果を書き込むように指定する。

また、シナリオ３１の状態や遷移の処理の、特定のタイミングで実行される関数を、シナリオロジックと呼ぶ。これらの関数には、デフォルトの動作が用意されており、何も指定されていない場合にはそれらが呼び出される。ユーザが必要な処理を定義すると、デフォルトの動作はオーバーライドされ、ユーザ定義の処理が行われる。

シナリオロジック３２の中には、シナリオ３１で記述しきれない複雑な内部処理や、アウトバウンズで制御する外部アプリケーションへの操作などを記述する。

シナリオロジック３２を呼び出すタイミングを、状態ａから遷移ｔを通って状態ｂに状態遷移が発生する場合を例にして示す。まず、カレントが、状態ａにあるときに、遷移ｔのイベントが発生すると、そのイベントを受理するかどうかの判定処理の一環で、遷移ｔの遷移判定ロジックが実行される。判定の結果、遷移可能となった場合には、状態ａの状態終了ロジックが実行され、引き続き遷移ｔの遷移実行ロジックが実行される。そして、状態ｂに遷移後、状態ｂのアクション要求ロジックが実行される。この後、アクションコンダクタ１３にアクション要求がなされるが、このアクションが実際に実行される直前のタイミングで、状態ｂのコマンド確定ロジックが実行される。この後は、次のイベントが発生したところで、同様の処理を繰り返す。

イベントエンジン１２は、サービス利用者自身の状態、サービス利用者周辺の状態、あるいはサービスの実行状態など様々な状態をイベントデータテーブル３４に収集・管理し、各イベントの監視元に対し、イベントが発生した際にイベント発生通知を行うことによって、イベント発生を契機にサービスを提供するイベント駆動型サービスを実現するためのイベント管理コンポーネントである。

イベントエンジン１２は、イベント管理機能（イベントマネージャ１２１による機能）、イベント通知機能（イベントマネージャ１２１による機能）、イベントアグリゲーション機能（イベントアグリゲータ１２２の機能）とを有する。イベント管理機能は、イベントをイベントデータテーブル３４に格納・管理する機能である。イベントを新規登録、更新、削除、検索する機能を提供する。イベント通知機能は、イベントの監視元に対し、イベント発生を通知する機能である。イベントの監視元は、監視するイベントに対して予め監視登録（Ｓｕｂｓｃｒｉｂｅ）を要求しておくことにより、Ｓｕｂｓｃｒｉｂｅ対象のイベントが発生すると、イベントエンジン１２からイベント通知（Ｎｏｔｉｆｙ）を受けることができる。イベント監視元は、Ｓｕｂｓｃｒｉｂｅ時に通知を受けるためのイベント通知条件を指定（条件付きＳｕｂｓｃｒｉｂｅ）することによって、不必要なイベント通知をフィルタリングすることができる。イベントアグリゲーション機能は、開発者の定義した外部ロジック（以下、イベントアグリゲーションロジック）により、各種デバイスなどから得られる詳細なイベントデータを、アプリケーションが取り扱いやすいイベントデータに加工する機能を提供する。例えば、車載センサーから得られるウインカー、ハンドル操舵角度、アクセル開度、ブレーキ強度の値を総合して、運転手の繁忙度合い（低〜中〜高）を算出し新しいイベントデータとする。イベントアグリゲーションロジックは、予めシェアドライブラリに登録され、イベントエンジン１２からロードされる。

イベントロジック３３は、アプリケーション層３においてイベントデータテーブル３４を処理するものであり、開発者によって定義される。

アクションコンダクタ１３は、アクション制御エンジン１３１と、マルチモーダルエンジン１３２とを有する。アクション制御エンジン１３１は、サービスからのアクション要求を管理し、出力順序を調停したり、出力を抑制したりすると共に、アクション出力状況の通知を行うモジュールである。複数のサービスから非同期にアクション要求を受信し、それらの優先度に従った出力順序を変更する出力調停機能や、負荷に応じて重要度の高いアクションだけを実行する出力抑制機能、アクションの出力状況に合わせてイベントタイプを更新する出力状況通知機能を提供する。マルチモーダルエンジン１３２は、シナリオエンジン１１のアクション記述内容に応じて、アクションコンダクタ１３が管理する複数のモダリティに対し制御（モダリティに対してコマンド送信及びモダリティからのレスポンス受信）するモジュールである。

アクションは、サービスが各モダリティに対する命令内容を定義するもので、各モダリティの制御コマンドや優先度・重要度、処理結果の書き込み場所などから構成される。アクションは、サービスからの要求によって生成され、アクションコンダクタ１３に後に述べるアクションキューで管理されるが、サービスからのアクションのキャンセル要求やアクション完了のタイミングでアクションコンダクタ１３が廃棄する。

アクションに関するデータ構造を図２に示す。図２は、１つのアクションについてのデータ構造を示している。アクション要求情報構造体は、アクションＩＤ、アクション要求元ＩＤ、アクション実行状態、アクション優先度、アクション重要度、コマンド構造体配列の先頭アドレス、コマンド数、コマンド確定コールバック関数のアドレス、コマンド確定パラメータのアドレス、イベント書き込み先のアドレスなどを含む。１つのアクションには複数のコマンドを含むことが可能であり、コマンド数でその数が規定される。また、コマンド構造体配列の先頭アドレスは、当該アクションに関係するコマンド情報構造体の先頭アドレスを示している。コマンド情報構造体は、命令先入出力ミドルウェアの識別情報と、コマンドと、コマンドパラメータとを含む。また、イベント書き込み先情報のアドレスは、イベント書き込み先情報構造体の先頭アドレスを示している。イベント書き込み先情報構造体は、完了イベント書き込み先のイベントタイプ名、待機イベント書き込み先のイベントタイプ名、開始イベント書き込み先のイベントタイプ名、中断イベント書き込み先のイベントタイプ名、再開イベント書き込み先のイベントタイプ名、エラーイベント書き込み先のイベントタイプ名を含む。コマンドは、モダリティに対する制御コマンドである。コマンド情報構造体において、命令先入出力ミドルウェアの識別情報はアクションコンダクタ１３によって利用されるが、それ以外の内容は出力先のモダリティによって解釈される。重要度は、負荷に応じた出力抑制制御に用いられる。優先度は、アクションの出力調停に利用される。

なお、出力の抑制機能や出力順序の調停機能により、アクションを要求されるタイミングと、実際に出力が行われるタイミングは大きく異なる場合がある。このような場合に、アクション要求時の制御コマンドをそのまま利用しては、出力内容が不適切になったりする。それを避けるため、出力直前に制御コマンドの内容を確定させたい場合がある。コマンド確定コールバック関数が指定されると、実際の出力直前のタイミングで呼び出され、コマンド内容が確定した後に出力が行われる。コマンド確定パラメータは、コマンド確定コールバック関数で用いられるパラメータである。コマンド確定コールバック関数については後に詳述する。

アクション要求元ＩＤは、優先度が同じ場合には、同じ要求元からのアクションを継続して出力するように制御するために指定される。

アクション要求は、以下の流れで処理される。
（１）アクション要求
サービスは、アクションコンダクタ１３に対して、アクション出力の要求を登録する。アクションコンダクタ１３は、送られてきた要求に対して、重要度や優先度によって出力の可否を判定する。アクションが直ぐに出力できる場合も、実際にアクションの出力を行うタイミングで、（２）コマンド確定処理が行われる。アクション要求は、複数のサービスから非同期に行われる可能性がある。

出力できなかった、すなわち保留されたアクションは、アクションコンダクタ１３が記憶しており、次回の出力判定タイミングで再度、出力可能性を判定する。保留されていたアクションが新たに出力可能になった場合は、必要に応じて開始イベントが通知される。

（２）コマンド確定
アクションコンダクタ１３は、アクションを実際に出力するタイミングで、コマンド内容を確定させるためのコールバック関数を呼び出す。サービスは、呼び出されたコールバック関数内で、必要に応じてコマンドの差し替えを行う。なお、要求時に指定したモダリティを変更することはできない。要求時のアクションにコマンド確定のためのコールバック関数が登録されていない場合には、これらの処理は行われず、アクション要求時のコマンドがそのまま利用される。アクション要求時にコマンドもコールバック関数も指定されていない場合にはエラーとして要求時に処理される。アクションの中断・再開によって、複数回、出力が開始される場合があるが、その際にはコールバック関数は、その都度呼び出される。

（３）アクションのキャンセル
出力が完了したアクション要求は、アクションコンダクタ１３によって破棄される。一方、不要となったアクションは、サービスが明示的にキャンセルを発行する必要がある。アクション要求時に返却されるアクションＩＤを用いてキャンセル対象を指定する。キャンセル要求されたアクションは、出力状況にかかわらず削除される。出力中であれば、その時点で出力を中止する。

実際のアクションキャンセル要求は、アクション要求（キャンセルされるアクションの次のアクションの要求）のタイミングと同時に行われる。これは、アクションキャンセル処理と次のアクションの要求の間にタイムラグが生ずると、本来出力すべきでない別なアクションが出力される可能性があり、これを防止するためである。

アクション制御エンジン１３１の出力調停機能としては、出力調停機能を有する。

アクションキューでは、図３に示したように、優先度順に、アクション要求情報構造体へのアドレスが並べられている。図３の例では、音声出力についてのアクションＡ、アイコン出力についてのアクションＢ、音声出力についてのアクションＣが、この順番の優先度で存在する場合には、アクション要求情報構造体Ａへのアドレス、アクション要求情報構造体Ｂへのアドレス、アクション要求情報構造体Ｃへのアドレスが順番に並べられている。

なお、アクションのキャンセルと要求は同じタイミングで行われるので、キャンセルされるアクションが実行中、あるいは、完了後であり、次のアクションが存在すれば、この処理が行われる。

次に出力調停機能について説明する。アクションコンダクタ１３は、アクション要求の有する優先度に従って、アクションを出力する順番を調停する機能を有する。複数のサービスが非同期に動作している場合、アクション出力の要求が競合する場合がある。例えば以下の場合である。
［１］あるサービスがアクション出力を行っている最中に、別にサービスがアクション出力の要求を行う。
［２］異なるサービスが同時にアクション出力の要求を行う。

アクション出力調停機能は、このようなアクション要求の競合が発生した場合に、重要なアクションを優先的に出力するように調停する機能を提供する。

上で述べたように、アクションには優先度が定義されており、この値を用いて次のような調停を行う。
［１］現在出力中のアクションより優先度が高いアクション要求は、現在の出力を中断して出力する。
［２］現在出力中のアクションより優先度が低いか、同じ優先度のアクション要求は、現在の出力が完了するまで待たされる。

なお、同時に複数のアクション要求が発生した場合でも、実際の処理はシリアライズされるため、順番に要求される場合と同じになる。

アクションコンダクタ１３は、負荷の大きさに応じてアクションの出力を抑制するアクション出力抑制機能をも有している。負荷の大きさに対応する重要度の閾値はイベントタイプとして用意され、値の変化に応じてアクションコンダクタ１３がイベント受けるように設定される。

アクションコンダクタ１３は、イベントを受け付けて、内部的に重要度の閾値の変化を保持する。この閾値と、要求されたアクション、又は実行中のアクションの重要度とを比較し、出力の抑制制御を実施する。具体的には、以下の２つのケースで異なった出力抑制制御を実施する。

［ａ］アクション要求時
アクションの要求時には、アクションの重要度と閾値とを比較し、アクションの重要度の方が高いか等しい場合には出力可能とする。そうでない場合、出力を抑制し、アクションの要求は保留される。
［ｂ］閾値の変化時
重要度の閾値が変化した場合、出力中を含む全てのアクション要求に対して重要度を比較し、重要度が閾値より高いか等しいものだけを集めて、出力調停処理を実施する。この結果、出力中のアクションが他のアクションに割り込まれる可能性がある。また、出力中のアクションの重要度が低くて出力できなくなった場合には、他のアクション出力が出なかったとしても中断される。

出力抑制機能によって出力できなかったアクションには、必要に応じて待機イベントが通知される。また、待機していたアクションが、負荷が下がって（すなわち重要度の閾値が下がり）出力可能となった場合には、必要に応じて開始イベントが通知される。出力中に負荷が高くなって中断されたアクションには、必要に応じて中断イベントが通知され、負荷が下がって再度（最初から）出力を行う場合には、必要に応じて再開イベントが通知される。

アクションコンダクタ１３は、各アクションの出力状況を管理し、必要に応じて通知を行うアクション出力状態通知機能を有する。アクションの出力状況は、図２に示したアクション要求情報構造体における「アクション実行状態」において管理される。アクション実行状態としては、図４に示すような状態のいずれかが設定される。

図４に示すように、アクションのデータが登録された状態（初期状態）である「登録済み」状態と、アクションが直ぐに出力できず、待たされる状態である「待機」状態と、アクションを開始した状態である「開始」状態と、出力中のアクションが何らかの原因で中断された状態である「中断」状態と、一度中断されたアクションを再度出力し直す状態である「再開」状態と、アクション出力が完了した状態である「完了」状態と、アクション出力がエラーとなった状態である「エラー」状態とが定義されている。

「登録済み」状態は、アクションコンダクタ１３内にアクション要求が登録された直後であり、アクション出力抑制／出力調停が行われていない状態である。「待機」状態は、具体的には、要求したアクションが、出力調停機能によって出力を待たされる場合、あるいは、出力抑制機能によって出力が待たされる場合に発生する。「開始」状態は、要求されたアクションが初めて出力される場合に発生する。アクションが出力待ちになっていなくても、初めて出力が開始されるタイミングで発生する。「中断」状態は、出力中のアクションが、完了していない段階で停止させられる場合に発生する。具体的には、他のサービスの要求アクションによる出力調停で出力を中断する場合と、出力抑制機能によって出力が抑制される場合に発生する。「再開」状態は、中断状態にあったアクションが、再度実行可能になったタイミングで発生する。具体的には、他のサービスが完了して、中断されていたアクションが再度実行可能になった場合や、出力抑制機能で抑制されていたものが解除された場合に発生する。「完了」状態は、出力中のアクションが完了した場合に発生する。アクションの完了はモダリティによって異なり、例えば、音声合成であれば指定された発話内容とタイムアウト時間が経過した段階で完了となる。通常は、モダリティからアクションコンダクタ１３に完了が通知され、マルチモーダルエンジン１３２で、複数モダリティの完了状態を統合して完了を統合して、完了を判定する。「エラー」状態は、出力しようとした又は出力中のアクションが、何らかの原因でエラーとなった場合に発生する。エラー発生の例としては、マルチモーダルエンジン１３２のモダリティ制御機能でのアクション実行エラーがある。

「待機」「開始」「登録済み」「完了」「エラー」の状態は、アクション出力を通じて１度しか発生しないが、「中断」「再開」のイベントは複数回発生する可能性がある。

なお、ここでは簡略化のため「通知」と記述しているが、実際には、イベントエンジン１２の提供するＳｕｂｓｃｒｉｂｅ機能を用いてサービスがあるイベントタイプ名とイベント通知を要求しておき、同じイベントタイプ名に対して書き込み機能を用いて値の書き込みを行うことで通知が行われる。

各アクションには、これらの状態に対応する通知場所（図２におけるイベント書き込み先情報構造体における書き込み先のイベントタイプ名）が指定される。イベント通知が不要な場合には、指定がないため、書き込み処理も行われない。

マルチモーダルエンジン１３２は、マルチモーダル機能を有する。マルチモーダル機能は、シナリオエンジン１１のアクション記述内容に応じて、アクションコンダクタ１３が管理する複数のモダリティに対して制御（モダリティに対してコマンド送信及びモダリティからのレスポンス受信）する機能を提供する。具体的には、マルチモーダル機能は、モダリティ管理機能と、モダリティ制御機能とを有する。

モダリティ管理機能は、モダリティ新規登録機能と、モダリティ制御一時停止機能と、モダリティ制御再開機能と、モダリティ登録削除機能とを有する。

モダリティ新規登録機能は、基盤ミドルウェア層５のモダリティが、アクションコンダクタ１３から制御されるために、モダリティの起動時にモダリティの情報を新規登録する機能である。モダリティ制御一時停止機能は、モダリティ新規登録機能により登録済みのモダリティが何らかの事情により一時的に制御不能状態になったとき（例えば、自動車が走行中になり、画面出力を抑制する必要がある場合など）に、アクションコンダクタ１３に対して制御を一時的に抑止することを宣言する機能である。モダリティ制御再開機能は、モダリティ制御一時停止機能により一時停止中のモダリティが、状況が変化し制御可能となったときに、制御の再開を宣言する機能である。モダリティ登録削除機能は、モダリティ新規登録機能により登録済みのモダリティが、システム終了などにより処理を終了する場合に、登録を削除する機能である。

モダリティ制御機能は、モダリティ状態管理機能と、モダリティ出力調停機能とを有する。

モダリティ状態管理機能は、アクションに記述される各モダリティへのコマンド要求とそのレスポンスを監視し、各モダリティが空き状態であるかビジー状態であるか（ビジー状態である場合は、当該アクションの優先度も保持）を常時管理する機能である。

モダリティ状態管理機能では、図５に示すような入出力ミドルウェア（モダリティ）管理テーブルを管理している。図５の例では、モダリティＩＤ、モダリティ名、割り込み種別と、実行アクション情報とを管理している。この実行アクション情報として、ビジーや、待機といった状態に関するデータが含まれる。割り込み種別については、他の優先度の高いアクションによって割り込みが行われる「割込可」と、割込制御が全く行われず、並列動作を許容する「割込制御無し」と、割り込みが全く認められない「割込不可」などがある。

モダリティ出力調停機能は、アクション制御エンジン１３１から渡される複数のアクション要求を、アクション要求に記述される各モダリティへの個々のコマンドが出力可能かどうか判定（モダリティ管理機能とモダリティ状態管理機能を参照し、モダリティが存在するかどうか、存在する場合には当該モダリティがビジーであるかどうかを判定）し、アクション要求の衝突を調停する機能である。

具体的には、アクション要求に記述される入力コマンドに対応するモダリティの状態に応じて図６に示すようなチェック結果を得て、さらに出力コマンドに対応するモダリティの状態に応じて図７に示すようなチェック結果を得る。さらに、チェック結果から図８に示すようなアクション実行判定を実施する。なお、入出力コマンドについては、入力コマンドとしてチェックを行い、さらに出力コマンドとしてもチェックを行う。

図６の入力コマンドとチェック結果の対応テーブルには、未登録のモダリティ、登録済みであって制御一時停止のモダリティ、登録済みであってビジー状態のモダリティ、登録済みであって空き状態のモダリティについて、入力コマンドに係るモダリティの一部について該当する場合、又は全てが該当する場合におけるチェック結果がまとめてある。なお、「割込制御無し」のモダリティについては、常に「空き状態」としてチェックする。

具体的には、入力コマンドに係るモダリティの状態が全て未登録であれば「エラー」として判定され、全て一時停止であれば「保留」と判定され、一部のモダリティがビジーであれば「保留」と判定され、一部が未登録又は一時停止のモダリティの場合には「保留」と判定され、それ以外の場合に「実行可」と判定される。

同様に、図７の出力コマンドとチェック結果の対応テーブルには、未登録のモダリティ、登録済みであって制御一時停止のモダリティ、登録済みであってビジー状態のモダリティ、登録済みであって空き状態のモダリティについて、出力コマンドに係るモダリティの一部について該当する場合、又は全てが該当する場合におけるチェック結果がまとめてある。なお、「割込制御無し」のモダリティについては、常に「空き状態」としてチェックする。

具体的には、出力コマンドに係るモダリティの状態が全て未登録であれば「エラー」として判定され、全て一時停止であれば「保留」と判定され、一部のモダリティがビジーであれば「保留」と判定され、一部が未登録又は一時停止のモダリティの場合には「保留」と判定され、それ以外の場合に「実行可」と判定される。

図８は、入力コマンド群のチェック結果と出力コマンド群のチェック結果とを総合して、アクション実行判定の結果を示すテーブルである。具体的には、入力コマンド群のチェック結果と出力コマンド群のチェック結果とのいずれかが「エラー」であれば「エラー」と判定され、入力コマンド群のチェック結果又は出力コマンド群のチェック結果が「保留」であれば「保留」と判定され、さらに入力コマンド群のチェック結果も出力コマンド群のチェック結果も「実行可」であれば「実行可」と判定される。なお、いずれかのチェック結果がエラーであれば、必要に応じて警告ログを出力する。

上でも述べたが、基盤ミドルウェア層５には、入力ミドルウェア１（５１）、入力ミドルウェア２（５２）、．．．．、出力ミドルウェア１（５３）、出力ミドルウェア２（５４）、．．．などを含む。このように、デバイス層７に含まれる各種センサー７１やマイク７３などからイベントを検出してイベントエンジン１２に出力するイベント入力ミドルウェア、デバイス層７に含まれるディスプレイ７２やスピーカ７４などに対してコマンドに応じた出力処理を実施する出力モダリティミドルウェアを含む。

デバイス層７は、車載端末などの各種センサーや出力デバイスなどを含む。

次に、本実施の形態に係る主要な処理について図９乃至図１８を用いて説明する。アクション制御エンジン１３１は、シナリオエンジン１１からのアクション要求又はキャンセル、重要度の閾値更新イベントの発生、アクション実行状態の更新タイミングで、以下の処理を実施する。

まず、上で述べたような事象が発生してアクション出力抑制／調停開始指示を受信するまで、開始指示待ちとなる（ステップＳ１）。そして、アクション出力抑制／調停開始指示を受信すると、現在の重要度の閾値と、アクションキュー中における実行中のアクションに規定されている重要度とを比較する（ステップＳ３）。図２に示したアクション要求情報構造体に含まれるアクション重要度と、内部構造に保持されている現在の重要度の閾値とを比較する。複数のアクションがアクションキューに登録されている場合には、図２に示したアクション要求情報構造体に含まれるアクション実行状態を参照して、「実行中」であるアクションについて比較を実施する。

比較の結果として、重要度＜閾値である実行中のアクションがある場合には、この条件を満たす全ての実行中のアクションを中断にする（ステップＳ５）。すなわち、図２に示したアクション要求情報構造体に含まれるアクション実行状態を「中断」に設定する。そして、ステップＳ７に移行する。一方、比較の結果として、重要度＜閾値である実行中のアクションがなければステップＳ７に移行する。

その後、現在アクションキューにキューイングされているアクション情報全てに対して、図２に示したアクション要求情報構造体に含まれる優先度順に出力調停を行い、優先度順にアクション情報（アクション要求情報構造体及びそれからリンクする情報）をアクションキューから取得する（ステップＳ７）。そして、現在の重要度の閾値と今回取得されたアクション情報に含まれるアクションの重要度の比較を行う（ステップＳ９）。ここで重要度＜閾値であれば、次の優先度のアクションの処理に移行するためステップＳ７に戻る。一方、閾値≦重要度であれば、今回取得したアクション情報からアクション実行状態判定を実施する（ステップＳ１１）。アクション情報に含まれるアクション実行状態が、「開始」「再開」「完了」又は「エラー」であるか判断する。このような場合には、再度アクション実行判定を実施する必要はないので、次の優先度のアクションの処理に移行するためステップＳ７に戻る。

一方、アクション情報に含まれるアクション実行状態が、「登録済み」「待機」又は「中断」であれば、マルチモーダルエンジン１３２でアクション実行判定を行う（ステップＳ１３）。実行可能であれば、この段階で実行する。この処理については、図１０を用いて説明する。そして、アクションキューに出力調停が実施されていないアクションが存在すればステップＳ７に戻る。一方、アクションキューに出力調停が実施されていないアクションが存在しない場合には、ステップＳ１に戻る。

次に、図１０を用いてマルチモーダルエンジン１３２によるアクション実行判定について説明する。まず、アクション要求情報構造体からリンクされたコマンド情報構造体から特定される入力コマンド及び入出力コマンドについて、当該コマンドの実行対象モダリティの状態チェックを、図５に示した入出力ミドルウェア管理テーブルを参照して実施する（ステップＳ２１）。図５に示した入出力ミドルウェア管理テーブルにおける実行アクション情報から実行対象モダリティの状態をチェックする。なお、上でも述べたが、割り込み種別も関係しており、割り込み種別が「割込制御無し」のモダリティであれば必ず「空き状態」と特定される。割込不可でビジーであれば、実行保留となる。

また、アクション要求情報構造体からリンクされたコマンド情報構造体から特定される出力コマンド及び入出力コマンドについて、当該コマンドの実行対象モダリティの状態チェックを、図５に示した入出力ミドルウェア管理テーブルを参照して実施する（ステップＳ２３）。図５に示した入出力ミドルウェア管理テーブルにおける実行アクション情報から実行対象モダリティの状態をチェックする。割込不可でビジーであれば、実行保留となる。

そして、図６に関連して説明したように、入力コマンド及び入出力コマンドの実行判定を実施する（ステップＳ２５）。ここでは「エラー」「保留」又は「実行可」のいずれかが特定される。同様に、図７に関連して説明したように、出力コマンド及び入出力コマンドの実行判定を実行する（ステップＳ２７）。ステップＳ２５と同様に、「エラー」「保留」又は「実行可」のいずれかが特定される。

その後、図８に関連して説明したように、アクション実行判定を実施する（ステップＳ２９）。これによって、「エラー」「保留」又は「実行可」のいずれかが特定される。

「エラー」が特定されると、完了イベント発生として、図２のアクション実行状態に「完了」を登録する（ステップＳ３１）。そして元の処理に戻る。

「保留」が特定されると、ステップＳ１１と同様に、アクション実行状態判定を実施する（ステップＳ３３）。そして、登録済みという状態であれば、待機イベント発生として、図２のアクション実行状態に「待機」を登録する（ステップＳ３５）。一方、「登録済み」以外の状態であれば、元の処理に戻る。

「実行可」が特定されると、ステップＳ１１と同様に、アクション実行状態判定を実施する（ステップＳ３７）。これによって、「登録済み」「待機」「中断」「完了」「エラー」「開始」又は「再開」のいずれかが特定される。そして、「登録済み」又は「待機」であれば、開始イベント発生として、図２のアクション実行状態に「開始」を登録する（ステップＳ３９）。そしてステップＳ４３に移行する。一方、「登録済み」又は「待機」以外であれば、再開イベント発生として、図２のアクション実行状態に「再開」を登録する（ステップＳ４１）。そしてステップＳ４３に移行する。

そして、コマンド確定コールバック関数が図２のアクション要求情報構造体において登録されている場合には、コマンド確定処理を実施する（ステップＳ４３）。コマンド確定コールバック関数の処理については、以下に詳細に説明するため、ここではコマンド確定コールバック関数については登録されていないものとして説明する。この場合ステップＳ４３をスキップする。

そして、コマンドの実行対象モダリティの状態を図５の入出力ミドルウェア管理テーブルを参照してチェックし、コマンド実行中の場合はそのコマンドの処理を中断する（ステップＳ４５）。コマンド実行中の場合には、図２のアクション実行状態に「中断」を登録する。なお、基本的には、ステップＳ２１又はＳ２３と同様のチェックを行う。

コマンドの実行対象モダリティの状態が「エラー」や「ビジー」ではない場合には、アクションの実行を行う（ステップＳ４７）。そして元の処理に戻る。

以上のような処理を実施しすることによって、図１１に示すような処理が可能となる。例えば、アクションキューに、第１優先度のアクションとして音声出力というアクションと、第２優先度のアクションとしてアイコン出力というアクションとが登録されている場合を想定する。なお、ここでは重要度の閾値より各アクションの重要度は高いものとする。このような場合、図９及び図１０のフローに従って第１優先度のアクションの出力調停を実施する（ステップＳ５１）。ここでテキスト音声出力モダリティ（ＴｅｘｔＴｏＳｐｅｅｃｈモダリティ）がビジーでなければ、第１優先度のアクションの出力処理が実施され、音声合成モダリティによって音声出力が開始される（ステップＳ５３）。

ステップＳ５３と並行して、図９及び図１０のフローに従って第２優先度のアクションの出力調停が実施される（ステップＳ５５）。第２優先度のアクションに係るモダリティが実行可（すなわち「空き」）状態であるか又は「割込制御無し」である場合には（ステップＳ５７：Ｙｅｓルート）、第２優先度の出力を開始させる（ステップＳ５９）。すなわち、アイコン表示モダリティは「割込制御無し」であるので、音声とアイコンが重複出力される。一方、第２優先度のアクションに係るモダリティが実行可状態でなく且つ「割込制御無し」でもない場合には（ステップＳ５７：Ｎｏルート）、第２優先度のアクションについて「待機」という状態を設定する（ステップＳ６１）。

例えば第２優先度のアクションに係るモダリティが「アイコン表示」でなくとも、表示装置に画像を表示するものであったり、ビープ音を出力するものであっても同様に重複出力が行われる。

このようにフレキシブルに重複出力を可能とする構成であるため、短時間で多くの情報をユーザに提供することができるようになる。

次に、コマンド確定コールバック関数について図１２乃至図１８を用いて説明する。上では図１０におけるステップＳ４３でコマンド確定コールバック関数が規定されていない場合を示したが、ここでは、図１２のシナリオ１（３１１）において、図１３に示すように、状態ｓｔａｔｅ１内のアクションａｃｔｉｏｎ１については、ｌｏｇｉｃ属性で指定された”ｓｔ１”という文字列を接頭辞としたロジック群を使用するものとして規定されているとする。これにより、コマンド確定ロジックの場合、”ｓｔ１_ａｃｔｉｏｎ（・・・）”という関数が指定されたことになる。

シナリオエンジン１１は、このようなシナリオ１（３１１）に基づき、図１２に左下に示すアクション要求１をアクションコンダクタ１３に出力する（ステップ（１０１））。アクション要求１には、開始イベントの書き込み先のイベントデータ変数名（イベントタイプ名）「＄ａｃｔｉｏｎ０１＿ｓｔａｒｔ」、完了イベントの書き込み先のイベントデータ変数名（イベントタイプ名）「＄ａｃｔｉｏｎ０１＿ｃｏｍｐｌｅｔｅ」などを含む。また、アクション要求１は、図１２の中央下に示されているコマンド情報を含む。このコマンド情報では、命令先入出力ミドルウェア「ＴＴＳ（ＴｅｘｔＴｏＳｐｅｅｃｈモダリティ）」と、コマンド「テキスト読み上げ」と、出力内容「今日の天気は晴れです」と、進捗状況通知先「＄ｗｅａｔｈｅｒ＿ｐｒｏｇｒｅｓｓ」などのデータを含む。

アクションコンダクタ１３は、図９及び図１０で説明したアクションの出力調停及び実行判定を実施し（ステップ（１０２））、アクション要求１の実行を決定すると、開始イベントの書き込み先として指定されている、イベントエンジン１２のデータ管理テーブル内のイベントデータ変数「＄ａｃｔｉｏｎ０１＿ｓｔａｒｔ」をＦＡＬＳＥからＴＲＵＥに変更する（ステップ（１０３））。そして、図１０におけるステップＳ４３でコマンド確定コールバック関数を呼び出す（ステップ（１０４））。コマンド確定コールバック関数として指定されているコマンド確定ロジック３２２は、コマンド情報で指定されている、イベントエンジン１２のデータ管理テーブル内のイベントデータ変数「＄ｗｅａｔｈｅｒ＿ｐｒｏｇｒｅｓｓ」を参照して０％となっていることを確認する（ステップ（１０５））。そうすると、コマンド確定ロジック３２２は、現在のコマンド情報について変更を行う必要がないと判断する（ステップ（１０６））。そこで、アクションコンダクタ１３は、コマンド情報をＴｅｘｔＴｏＳｐｅｅｃｈミドルウェア５５に出力する（ステップ（１０７））。ＴｅｘｔＴｏＳｐｅｅｃｈミドルウェア５５は、コマンド情報に従ってスピーカ７４を介して「今日の天気は晴れです」の音声データを合成して出力する。さらに、その出力の進捗状態を、コマンド情報で指定されている、イベントエンジン１２のデータ管理テーブル内のイベント変数「＄ｗｅａｔｈｅｒ＿ｐｒｏｇｒｅｓｓ」を更新して、８０％まで音声データを出力して、上記イベント変数を８０％に変更するところまで来たものとする（ステップ（１０８））。

この段階で、図１４に示すように、シナリオエンジン１１が、シナリオ２（３１２）に従ってアクション要求２をアクションコンダクタ１３に出力したものとする（ステップ（２０１））。なお、アクション要求２の優先度は、アクション要求１の優先度より高いものとする。そうすると、アクションコンダクタ１３は、図９及び図１０で示した出力調停を実施して、アクション要求１についてのコマンドの出力を中断させる（ステップ（２０２））。コマンドの出力先であるＴｅｘｔＴｏＳｐｅｅｃｈミドルウェア５５は、割込可であるから割り込みがなされることになる。割込不可であれば、アクション要求２は割り込みできない。そして、アクションコンダクタ１３は、アクション要求２についてのコマンド情報２をＴｅｘｔＴｏＳｐｅｅｃｈミドルウェア５５に出力する（ステップ（２０３））。この例では、「前方の車に注意してください」という音声データが合成され、スピーカ７４から出力される。

このような出力が完了すると、図１５に示すように、再開トリガーとなって（ステップ（３０１））、アクションキューに格納されたアクション要求１が再度出力調停の対象となり、アクションコンダクタ１３は出力調停及び実行判定を実施する（ステップ（３０２））。そして、再度、図１０のステップＳ４３でコマンド確定コールバック関数を呼び出す（ステップ（３０３））。コマンド確定コールバック関数として指定されているコマンド確定ロジック３２２は、コマンド情報で指定されている、イベントエンジン１２のデータ管理テーブル内のイベントデータ変数「＄ｗｅａｔｈｅｒ＿ｐｒｏｇｒｅｓｓ」を参照して、出力されたデータの割合が８０％以上であるか判断する（ステップ（３０４））。８０％未満であれば、コマンド情報の変更は行わないが、この例では８０％以上であるので、コマンド情報の出力内容を「ＮＵＬＬ」に変更する（ステップ（３０５））。そして、アクションコンダクタ１３は、変更されたコマンド情報をＴｅｘｔＴｏＳｐｅｅｃｈミドルウェア５５に出力する（ステップ（３０６））。ＴｅｘｔＴｏＳｐｅｅｃｈミドルウェア５５は、コマンド情報の出力内容を出力しようとするが、「ＮＵＬＬ」であるから出力するものが無く、直ぐに進捗状況通知先である、イベントエンジン１２のデータ管理テーブル内のイベントデータ変数「＄ｗｅａｔｈｅｒ＿ｐｒｏｇｒｅｓｓ」を８０％から１００％に変更する（ステップ（３０７））。そうすると、ＴｅｘｔＴｏＳｐｅｅｃｈミドルウェア５５は、処理の終了を通知してアクションコンダクタ１３の処理に復帰する（ステップ（３０８））。そうすると、アクション要求１で指定されている完了イベントの書き込み先イベントデータ変数「＄ａｃｔｉｏｎ０１＿ｃｏｍｐｌｅｔｅ」をＦＡＬＳＥからＴＲＵＥに変更する（ステップ（３０９））。このようにして処理を完了する。

図１２乃至図１５で示したような処理を行う場合、コマンド確定ロジック３２２は、図１６のような処理を実施する。すなわち、アクション１（３１１）のコマンド情報を解釈し、参照すべきイベントデータ変数を特定する（ステップＳ７１）。そして、＄ｗｅａｔｈｅｒ＿ｐｒｏｇｒｅｓｓ＜８０％であれば特に処理を行わず終了する。一方、＄ｗｅａｔｈｅｒ＿ｐｒｏｇｒｅｓｓ≧８０％であれば、コマンド情報の出力内容、ここでは天気の発声を無効化する（ステップＳ７３）。そして処理を終了する。

また、ＴｅｘｔＴｏＳｐｅｅｃｈミドルウェア５５は、図１７に示すような処理を実施する。まず、コマンド情報に含まれる出力内容を参照し（ステップＳ８１）、出力内容が「ＮＵＬＬ」であれば、処理を行わず元の処理に復帰する。一方、出力内容に出力すべきテキスト（ＴＥＸＴ）が含まれている場合には、音声合成処理を実施し、出力バッファに格納する（ステップＳ８３）。ここでは、テキストからＰＣＭ（Pulse Code Modulation）データを生成する。そして、出力バッファの終わりに到達した場合には元の処理に復帰する。一方、出力バッファに残りがある場合には、音声バッファ再生処理を実施し、スピーカ７４を介して音声出力を行う（ステップＳ８５）。そして、再生済みデータ量／音声データ全体を、コマンド情報で指定されている＄ｗｅａｔｈｅｒ＿ｐｒｏｇｒｅｓｓに格納する（ステップＳ８７）。このような処理を出力バッファの終わりに到達するまで繰り返す。

８０％は一例であって、コマンド毎に変更するようにしても良い。例えば、特定のキーワードが出力されるまでの割合を指定するようにしても良い。

このような図１２乃至図１７に示した処理をまとめると、図１８の処理フローのようになる。まず、第１のアクションに係る第１の情報が出力される（ステップＳ９１）。その後、第１の情報の出力が完了する前に、割り込みが発生する（ステップＳ９３）。ここで割り込みに係る第２のアクションの方が優先度が高いとして、第２のアクションに係る第２の情報が出力される（ステップＳ９５）。但し、割込可のモダリティであるか確認した上で、第２の情報を出力するか否かは判断される。この第２の情報の出力が完了すると、第１の情報の出力調停を再度実施し、第１の情報の再出力を決定する（ステップＳ９７）。そして、第１の情報の出力内容を所定割合以上を出力しているか判断する（ステップＳ９９）。第１の情報の出力内容を所定割合以上出力完了している場合には、第１の情報の出力完了を登録する（ステップＳ１０１）。そして、第１の情報については出力せずに処理を終了する。一方、第１の情報の出力内容を所定割合未満しか出力していなかった場合には、第１の情報の再出力を実施する（ステップＳ１０３）。

以上のように、十分な割合の情報が出力済みであれば、出力を再開させる場合においても、再出力を抑制して、他の情報を出力することによって、短時間に多くの情報を出力することができるようになる。

以上本発明の実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、モジュール構成は図１に示したものに限定されず、上で述べたような処理を実施できれば他の構成であってもよい。

なお、上で述べた車載端末は、コンピュータ装置であって、図１９に示すように当該コンピュータ装置においては、メモリ２５０１（記憶部）とＣＰＵ２５０３（処理部）とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ）及びＷｅｂブラウザを含むアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。このようなコンピュータは、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。但し、ＨＤＤ２５０５については他の記憶装置によって代替される場合もある。また、ドライブ装置２５１３や通信制御部２５１７についても備えていない場合もある。車載端末には、図１に示した各種センサや出力装置も備えているが、図１９では示していない。

（付記１）
アクションキューに登録されている第１のアクションに係る第１の情報の出力が完了する前に、前記アクションキューに次以降に登録されている第２のアクションが、当該第２のアクションに係る第２の情報の出力に用いられる特定の出力機能が空き状態であるか又は割込制御無しの機能であるかという条件を含む所定の条件を満たしているか否か判断する判断ステップと、
前記第２のアクションが前記所定の条件を満たしていると判断された場合には、前記第１の情報の出力が完了しているか否かにかかわらず、前記第２のアクションに係る第２の情報の出力を前記特定の出力機能に要求するステップと、
をコンピュータに実行させるための出力調停プログラム。

（付記２）
前記所定の条件が、
前記第２のアクションの重要度が、前記第１の情報及び前記第２の情報を知覚するユーザの負荷状態に連動する閾値以上であるという条件
を含む付記１記載の出力調停プログラム。

（付記３）
前記判断ステップが、
出力機能毎に割り込み種別及び状態を管理する管理テーブルを、前記第２のアクションに係る第２の情報の出力に用いられる前記特定の出力機能で検索するステップ
を含む付記１記載の出力調停プログラム。

（付記４）
前記第１のアクションの優先度が、前記第２のアクションの優先度より高いことを特徴とする付記１記載の出力調停プログラム。

（付記５）
前記第２のアクションが前記所定の条件を満たしていないと判断された場合、前記第２のアクションの実行状態を待機状態に設定するステップ
をさらにコンピュータに実行させるための付記１記載の出力調停プログラム。

（付記６）
アクションキューに登録されている第１のアクションに係る第１の情報の出力中に、前記アクションキューに前記第１のアクションより優先度が高く且つ前記第１のアクションに係る第１の情報の出力に用いられる特定の出力機能が同じ第２のアクションが登録された場合、前記特定の出力機能による前記第１の情報の出力を停止させる停止ステップと、
前記第２のアクションに係る第２の情報の出力を前記特定の出力機能に要求するステップと、
前記第２のアクションに係る第２の情報の出力が完了した後であって前記アクションキューに登録されている前記第１のアクションを再度処理する順番になった場合、前記第１のアクションに係る前記第１の情報の出力が予め定められた部分まで完了していたか判断するステップと、
前記第１のアクションに係る前記第１の情報の出力が予め定められた部分まで完了していた場合には、前記第１の情報の出力をキャンセルさせるステップと、
をコンピュータに実行させるための出力調停プログラム。

（付記７）
前記停止ステップが、
出力機能毎に割り込み種別を管理する管理テーブルを前記特定の出力機能で検索して、前記特定の出力機能が割り込み可の出力機能であるか判断するステップと、
前記特定の出力機能が割り込み可の出力機能である場合、前記特定の出力機能に前記第１の情報の出力を停止させるステップと、
を含む付記６記載の出力調停プログラム。

（付記８）
前記予め定められた部分が、前記第１の情報の出力割合で特定される
付記６記載の出力調停プログラム。

（付記９）
前記特定の出力機能が、前記第１のアクションによって指定された変数に前記第１の情報の出力割合を登録するステップ
をさらにコンピュータに実行させるための付記８記載の出力調停プログラム。

（付記１０）
前記第１のアクションに係る前記第１の情報の出力が予め定められた部分まで完了していない場合、前記第１の情報の出力を再度前記特定の出力機能に要求するステップ
をさらにコンピュータに実行させるための付記６記載の出力調停プログラム。

（付記１１）
アクションキューに登録されている第１のアクションに係る第１の情報の出力が完了する前に、前記アクションキューに次以降に登録されている第２のアクションが、当該第２のアクションに係る第２の情報の出力に用いられる特定の出力機能が空き状態であるか又は割込制御無しの機能であるかという条件を含む所定の条件を満たしているか否か判断する判断ステップと、
前記第２のアクションが前記所定の条件を満たしていると判断された場合には、前記第１の情報の出力が完了しているか否かにかかわらず、前記第２のアクションに係る第２の情報の出力を前記特定の出力機能に要求するステップと、
を含み、コンピュータに実行される出力調停方法。

（付記１２）
前記所定の条件が、
前記第２のアクションの重要度が、前記第１の情報及び前記第２の情報を知覚するユーザの負荷状態に連動する閾値以上であるという条件
を含む付記１１記載の出力調停方法。

（付記１３）
前記判断ステップが、
出力機能毎に割り込み種別及び状態を管理する管理テーブルを、前記第２のアクションに係る第２の情報の出力に用いられる前記特定の出力機能で検索するステップ
を含む付記１１記載の出力調停方法。

（付記１４）
前記第１のアクションの優先度が、前記第２のアクションの優先度より高いことを特徴とする付記１１記載の出力調停方法。

（付記１５）
前記第２のアクションが前記所定の条件を満たしていないと判断された場合、前記第２のアクションの実行状態を待機状態に設定するステップ
をさらに含む付記１１記載の出力調停方法。

（付記１６）
アクションキューに登録されている第１のアクションに係る第１の情報の出力中に、前記アクションキューに前記第１のアクションより優先度が高く且つ前記第１のアクションに係る第１の情報の出力に用いられる特定の出力機能が同じ第２のアクションが登録された場合、前記特定の出力機能による前記第１の情報の出力を停止させる停止ステップと、
前記第２のアクションに係る第２の情報の出力を前記特定の出力機能に要求するステップと、
前記第２のアクションに係る第２の情報の出力が完了した後であって前記アクションキューに登録されている前記第１のアクションを再度処理する順番になった場合、前記第１のアクションに係る前記第１の情報の出力が予め定められた部分まで完了していたか判断するステップと、
前記第１のアクションに係る前記第１の情報の出力が予め定められた部分まで完了していた場合には、前記第１の情報の出力をキャンセルさせるステップと、
を含み、コンピュータに実行される出力調停方法。

（付記１７）
前記停止ステップが、
出力機能毎に割り込み種別を管理する管理テーブルを前記特定の出力機能で検索して、前記特定の出力機能が割り込み可の出力機能であるか判断するステップと、
前記特定の出力機能が割り込み可の出力機能である場合、前記特定の出力機能に前記第１の情報の出力を停止させるステップと、
を含む付記１６記載の出力調停方法。

（付記１８）
前記予め定められた部分が、前記第１の情報の出力割合で特定される
付記１６記載の出力調停方法。

（付記１９）
前記特定の出力機能が、前記第１のアクションによって指定された変数に前記第１の情報の出力割合を登録するステップ
をさらに含む付記１８記載の出力調停方法。

（付記２０）
前記第１のアクションに係る前記第１の情報の出力が予め定められた部分まで完了していない場合、前記第１の情報の出力を再度前記特定の出力機能に要求するステップ
をさらに含む付記１６記載の出力調停方法。

（付記２１）
アクションキューに登録されている第１のアクションに係る第１の情報の出力が完了する前に、前記アクションキューに次に登録されている第２のアクションが、当該第２のアクションに係る第２の情報の出力に用いられる特定の出力機能が空き状態であるか又は割込制御無しの機能であるかという条件を含む所定の条件を満たしているか否か判断する判断手段と、
前記第２のアクションが前記所定の条件を満たしていると判断された場合には、前記第１の情報の出力が完了しているか否かにかかわらず、前記第２のアクションに係る第２の情報の出力を前記特定の出力機能に要求する手段と、
を有する出力調停装置。

（付記２２）
前記所定の条件が、
前記第２のアクションの重要度が、前記第１の情報及び前記第２の情報を知覚するユーザの負荷状態に連動する閾値以上であるという条件
を含む付記２１記載の出力調停装置。

（付記２３）
前記判断手段が、
出力機能毎に割り込み種別及び状態を管理する管理テーブルを、前記第２のアクションに係る第２の情報の出力に用いられる前記特定の出力機能で検索する手段
を有する付記２１記載の出力調停装置。

（付記２４）
前記第１のアクションの優先度が、前記第２のアクションの優先度より高いことを特徴とする付記２１記載の出力調停装置。

（付記２５）
前記第２のアクションが前記所定の条件を満たしていないと判断された場合、前記第２のアクションの実行状態を待機状態に設定する手段
をさらに有する付記２１記載の出力調停装置。

（付記２６）
アクションキューに登録されている第１のアクションに係る第１の情報の出力中に、前記アクションキューに前記第１のアクションより優先度が高く且つ前記第１のアクションに係る第１の情報の出力に用いられる特定の出力機能が同じ第２のアクションが登録された場合、前記特定の出力機能による前記第１の情報の出力を停止させる停止手段と、
前記第２のアクションに係る第２の情報の出力を前記特定の出力機能に要求する手段と、
前記第２のアクションに係る第２の情報の出力が完了した後であって前記アクションキューに登録されている前記第１のアクションを再度処理する順番になった場合、前記第１のアクションに係る前記第１の情報の出力が予め定められた部分まで完了していたか判断する手段と、
前記第１のアクションに係る前記第１の情報の出力が予め定められた部分まで完了していた場合には、前記第１の情報の出力をキャンセルさせる手段と、
を有する出力調停装置。

（付記２７）
前記停止手段が、
出力機能毎に割り込み種別を管理する管理テーブルを前記特定の出力機能で検索して、前記特定の出力機能が割り込み可の出力機能であるか判断する手段と、
前記特定の出力機能が割り込み可の出力機能である場合、前記特定の出力機能に前記第１の情報の出力を停止させる手段と、
を有する付記２６記載の出力調停装置。

（付記２８）
前記予め定められた部分が、前記第１の情報の出力割合で特定される
付記２６記載の出力調停装置。

（付記２９）
前記特定の出力機能が、前記第１のアクションによって指定された変数に前記第１の情報の出力割合を登録する手段
をさらに有する付記２８記載の出力調停装置。

（付記３０）
前記第１のアクションに係る前記第１の情報の出力が予め定められた部分まで完了していない場合、前記第１の情報の出力を再度前記特定の出力機能に要求する手段
をさらに有する付記２６記載の出力調停装置。

本発明の実施の形態に係るエージェントフレームワークのアーキテクチャを示す図である。 アクション要求のための情報構造体の一例を示す図である。 アクションコンダクタのアクションキューを説明するための図である。 アクションの出力状態の種別を説明するための図である。 入出力ミドルウェア管理テーブルの一例を示す図である。 入力コマンドとチェック結果の対応テーブルの例を示す図である。 出力コマンドとチェック結果の対応テーブルの例を示す図である。 チェック結果とアクション実行内容の対応テーブルの例を示す図である。 アクション出力抑制／出力調停のためのアクティビティ図である。 アクション実行判定のアクティビティ図である。 本発明の実施の形態における第１のポイントを説明するための図である。 本発明の実施の形態における第２のポイントを説明するための図である。 シナリオとコマンド確定ロジックとの関係を説明するための図である。 本発明の実施の形態における第２のポイントを説明するための図である。 本発明の実施の形態における第２のポイントを説明するための図である。 コマンド確定ロジックのアクティビティ図である。 テキスト音声出力ミドルウェアのアクティビティ図である。 本発明の実施の形態における第２のポイントを説明するための図である。 コンピュータの機能ブロック図である。

符号の説明

１ エージェントフレームワーク・ランタイム
３ アプリケーション層
５ 基盤ミドルウェア層
７ デバイス層
９ エージェントフレームワークＳＤＫ
１１ シナリオエンジン
１２ イベントエンジン
１３ アクションコンダクタ
３１ シナリオ
３２ シナリオロジック
３３ イベントロジック
３４ イベントデータテーブル
９４ 開発用ＡＰＩ・ライブラリ
１１１ シナリオマネージャ
１１２ シナリオインタプリタ
１２１ イベントマネージャ
１２２ イベントアグリゲータ
１３１ アクション制御エンジン
１３２ マルチモーダルエンジン

Claims (8)

1. アクションキューに登録されている第１のアクションに係る第１の情報の出力が完了する前に、前記アクションキューに次以降に登録されている第２のアクションが、当該第２のアクションに係る第２の情報の出力に用いられる特定の出力機能が割込制御無しの機能であるかという条件を含む所定の条件を満たしているか否か判断する判断ステップと、
   前記第２のアクションが前記所定の条件を満たしていると判断された場合には、前記第１の情報の出力が完了しているか否かにかかわらず前記第１の情報の出力と並行して、前記第２のアクションに係る第２の情報の出力を前記特定の出力機能に要求するステップと、
   をコンピュータに実行させるための出力調停プログラム。
2. 前記所定の条件が、
   前記第２のアクションの重要度が、センサから収集されたデータから推定される、ユーザの繁忙度合いが高くなると大きな値となり且つ低くなると小さな値となる閾値以上である条件
   を含む請求項１記載の出力調停プログラム。
3. 前記判断ステップが、
   出力機能毎に割り込み種別及び状態を管理する管理テーブルを、前記第２のアクションに係る第２の情報の出力に用いられる前記特定の出力機能で検索するステップ
   を含む請求項１記載の出力調停プログラム。
4. アクションキューに登録されている第１のアクションに係る第１の情報の出力中に、前記アクションキューに前記第１のアクションより優先度が高く且つ前記第１のアクションに係る第１の情報の出力に用いられる特定の出力機能が同じ第２のアクションが登録された場合、前記特定の出力機能による前記第１の情報の出力を停止させる停止ステップと、
   前記第２のアクションに係る第２の情報の出力を前記特定の出力機能に要求するステップと、
   前記第２のアクションに係る第２の情報の出力が完了した後であって前記アクションキューに登録されている前記第１のアクションを再度処理する順番になった場合、前記第１のアクションに係る前記第１の情報の出力が予め定められた部分まで完了していたか判断するステップと、
   前記第１のアクションに係る前記第１の情報の出力が予め定められた部分まで完了していた場合には、前記第１の情報の出力をキャンセルさせるステップと、
   をコンピュータに実行させるための出力調停プログラム。
5. 前記停止ステップが、
   出力機能毎に割り込み種別を管理する管理テーブルを前記特定の出力機能で検索して、前記特定の出力機能が割り込み可の出力機能であるか判断するステップと、
   前記特定の出力機能が割り込み可の出力機能である場合、前記特定の出力機能に前記第１の情報の出力を停止させるステップと、
   を含む請求項４記載の出力調停プログラム。
6. 前記予め定められた部分が、前記第１の情報の出力割合で特定される
   請求項４記載の出力調停プログラム。
7. アクションキューに登録されている第１のアクションに係る第１の情報の出力が完了する前に、前記アクションキューに次に登録されている第２のアクションが、当該第２のアクションに係る第２の情報の出力に用いられる特定の出力機能が割込制御無しの機能であるかという条件を含む所定の条件を満たしているか否か判断する判断手段と、
   前記第２のアクションが前記所定の条件を満たしていると判断された場合には、前記第１の情報の出力が完了しているか否かにかかわらず前記第１の情報の出力と並行して、前記第２のアクションに係る第２の情報の出力を前記特定の出力機能に要求する手段と、
   を有する出力調停装置。
8. アクションキューに登録されている第１のアクションに係る第１の情報の出力中に、前記アクションキューに前記第１のアクションより優先度が高く且つ前記第１のアクションに係る第１の情報の出力に用いられる特定の出力機能が同じ第２のアクションが登録された場合、前記特定の出力機能による前記第１の情報の出力を停止させる停止手段と、
   前記第２のアクションに係る第２の情報の出力を前記特定の出力機能に要求する手段と、
   前記第２のアクションに係る第２の情報の出力が完了した後であって前記アクションキューに登録されている前記第１のアクションを再度処理する順番になった場合、前記第１のアクションに係る前記第１の情報の出力が予め定められた部分まで完了していたか判断する手段と、
   前記第１のアクションに係る前記第１の情報の出力が予め定められた部分まで完了していた場合には、前記第１の情報の出力をキャンセルさせる手段と、
   を有する出力調停装置。

Images