JP2007317121A - 車載多機能装置、メタデータ - Google Patents
車載多機能装置、メタデータ Download PDFInfo
- Publication number
- JP2007317121A JP2007317121A JP2006148680A JP2006148680A JP2007317121A JP 2007317121 A JP2007317121 A JP 2007317121A JP 2006148680 A JP2006148680 A JP 2006148680A JP 2006148680 A JP2006148680 A JP 2006148680A JP 2007317121 A JP2007317121 A JP 2007317121A
- Authority
- JP
- Japan
- Prior art keywords
- scenario
- unit
- layout
- event
- lsui
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Navigation (AREA)
- User Interface Of Digital Computer (AREA)
- Traffic Control Systems (AREA)
Abstract
【課題】処理とユーザインターフェイスとを分離して、多様なシチュエーションにおいて適切なユーザインターフェイスを提供し、また、システムの拡張が容易な車載多機能装置及びメタデータを提供すること。
【解決手段】ユーザインターフェイス2,6、7を介してユーザからの入力を受け付け、出力装置6,7からユーザにサービスを提供する車載多機能装置1において、メタデータにより記述されたユーザインターフェイス及びサービスの内容を記憶したメタデータ記憶手段9と、メタデータを解釈してユーザインターフェイス又はサービスを生成する制御部20と、を有することを特徴とする。
【選択図】図1
【解決手段】ユーザインターフェイス2,6、7を介してユーザからの入力を受け付け、出力装置6,7からユーザにサービスを提供する車載多機能装置1において、メタデータにより記述されたユーザインターフェイス及びサービスの内容を記憶したメタデータ記憶手段9と、メタデータを解釈してユーザインターフェイス又はサービスを生成する制御部20と、を有することを特徴とする。
【選択図】図1
Description
本発明は、車両においてユーザに様々なサービスを提供する車載多機能装置及びメタデータに関する。
従来、車両には、カーナビゲーションシステムやラジオやテレビ、動画の再生など、マルチメディア機能が搭載されている(例えば、特許文献1参照。)。車両のマルチメディア機能は、ユーザとの対話に基づき処理を実行し、次の画面や処理結果を表示するものであるが、このようなコンピュータ上で提供されるシステムの実現方法としてMVC(Model View Controller)アーキテクチャが知られている。
図1(a)はMVCアーキテクチャの概念図を示す。MVCアーキテクチャでは、アプリケーションの構成要素を、処理(Model)M、表示(View)V、入力(Controller)Cの3つで構成する。
Modelはアプリケーションの処理を受け持つ部分であり、アプリケーションで必要となるデータを保持しており、入力Cからの入力に応じて処理を実行する。Viewは、Modelの状態を表示する部分であり、液晶などの表示装置上に表示されるウィンドウ等である。Viewは、情報の配置又は配置の方法を規定するものであるので、頻繁に変更の要請が生じる。また、Controllerは、ユーザの入力、タッチパネルや押しボタン、音声などの入力を受け取り、入力内容を処理する。Controllerは、例えば、表示画面の更新を行う場合にはViewを呼び出したり、入力内容を適切に変換してModelに渡す。
特開2001−235334号公報
しかしながら、図1(a)のようなMVCアーキテクチャでは、ViewとModelの依存関係が強いため、ユーザインターフェイスと処理を分離することが困難である。車両では多様なシチュエーションにおいてマルチメディア機能を利用することが想定されるため、車載されたマルチメディア機能は、ユーザと密接に関わるユーザインターフェイスを、車両のモデル・車種・ユーザの嗜好等に応じて拡張可能な仕組みが要請される。
また、カーナビゲーションシステムや動画の再生機能などは今後も進化が予想されるため、ソフトウェアのロジック(処理部)を部品化しその再利用が容易であることや、進歩・多様化していくハードウェアやOS、デバイス等の低レベルなプラットフォーム層に依存しない仕組みを有することが必要とされる。
本発明は、上記問題に鑑み、処理とユーザインターフェイスとを分離して、多様なシチュエーションにおいて適切なユーザインターフェイスを提供し、また、システムの拡張が容易な車載多機能装置及びメタデータを提供することを目的とする。
上記課題を解決するため、本発明は、ユーザインターフェイスを介してユーザからの入力を受け付け、出力装置(例えば、表示装置6、スピーカ7)からユーザにサービスを提供する車載多機能装置において、メタデータにより記述されたユーザインターフェイス及びサービスの内容を記憶したメタデータ記憶手段(例えば、記憶装置9)と、メタデータを解釈してユーザインターフェイス又はサービスを生成する制御部(例えば、UIサーバ20)と、を有することを特徴とする。
また、本発明の好ましい一形態において、前記メタデータ記憶手段は、前記ユーザインターフェイス又はサービスの遷移をメタデータにより記述した遷移情報(例えば、レイアウトML、シナリオML、ボイスML)を記憶している、ことを特徴とする。
本発明によれば、処理とユーザインターフェイス及びサービスとを分離した車載多機能装置を提供できる。なお、サービスとは、車載されたデバイスを制御して出力・表示されるもの、例えば、音声や表示の内容をいう。また、ユーザインターフェイスとは、視覚によるものだけでなく、聴覚や嗅覚によるものを含む。ユーザインターフェイスやサービスの内容や遷移がメタデータにより記述されることで、ユーザインターフェイスやサービスに容易に拡張性をもたらすことができる。
また、本発明の一形態において、ユーザインターフェイス及びサービスの内容を記述したメタデータはそれぞれ独立して変更可能である、ことを特徴とする。すなわち、サービスを定義したシナリオML、画面構成/遷移を定義したレイアウトML、音声による対話制御を定義したボイスML等のXMLファイルは、それぞれ独立に記述されているため、いずれかの変更が他に影響を与えることがない。
本発明によれば、ユーザインターフェイスやサービスを後から追加、拡張することができ、追加、拡張がそれ以外の機能に与える影響が少ない。
また、本発明の一形態において、更新頻度の高い描画を反映する動画用アダプタ(例えば、MMP動画再生用実体(Drawing Adapter))を有し、更新頻度の高い描画がある場合、制御部はユーザインターフェイスに描画領域を設け、動画アダプタが描画領域に描画する、ことを特徴とする。
本発明によれば、動画のように更新頻度の高い描画も、ユーザインターフェイスとして扱えるので、動画の取り扱いが容易になる。
また、本発明の一形態において、前記ユーザを識別する手段と、道路の交通状況、日時等のシチュエーションを判別する手段とを有し、制御部は、ユーザ又はシチュエーションに応じて、メタデータ記憶手段に記憶されたメタデータを抽出し、制御部は、ユーザ又はシチュエーションに応じたユーザインターフェイス又はサービスを生成する、ことを特徴とする。
本発明によれば、ユーザやシチュエーションに応じて、自動的にユーザインターフェイスやサービスを提供できる。
処理とユーザインターフェイスとを分離して、多様なシチュエーションにおいて適切なユーザインターフェイスを提供し、また、システムの拡張が容易な車載多機能装置及びメタデータを提供することができる。
図1(b)は、本実施の形態のマルチメディアアーキテクチャの概念図を示す。本実施の形態のマルチメディアアーキテクチャは、ModelとView及びControllerの間に、シナリオという概念を挿入した。
シナリオは、Modelと動的に結合する機構を有する。シナリオは、View又はControllerをイベントと変数のマッピングにより結合させる機構を持つことにより、それぞれの依存関係を疎結合化している。これにより、ユーザインターフェイスと処理のロジックとを完全に分離することが可能となる。
図2(a)は、本実施の形態のマルチメディアアーキテクチャが適用された車載多機能装置のハードウェア構成図を示す。カーナビ装置3は、GPS衛星から送信される航法データに基づいて車両の現在位置を検出し、現在位置を含む道路地図に目的地までの走行経路などを制御装置10に供給する。テレビ/ラジオユニット4は、UHFやVHFのテレビ放送電波や地上波デジタル放送を受信して、映像及び音楽等を制御装置10に供給する。また、AM、FM放送や地上波デジタルラジオ放送を受信して、音楽等を制御装置10に供給する。なお、テレビ/ラジオユニット104は準天頂衛星からの電波を受信するものであってもよい。メディアプレーヤ5は、DVDやCD、メモリカードのデータを読み出して再生し、映像及び音楽等を制御装置10へ供給する。
通信ユニット8は、携帯電話、PHS等の移動体通信又は無線LAN等により、基地局やアクセスポイントに接続すると共に、ネットワークを介して情報を受信して制御装置10へ供給したり、制御装置10から指示された情報をネットワークを介して外部に送信する。なお、通信ユニット8は、情報センタに蓄積されている渋滞情報その他の交通情報をビーコン等により取得して制御装置10に供給する。
表示装置6は、液晶ディスプレイやプロジェクタなどで構成され、カーナビ装置3から供給される地図、テレビ/ラジオユニット4から供給されるテレビ画像、メディアプレーヤ5から供給される動画などを表示する。また、表示装置6は、車載多機能装置1を操作するための操作メニューを表示する。スピーカ7は、カーナビ装置3による音声案内、テレビ/ラジオユニット4から供給される音声、メディアプレーヤ5から供給される音声などを出力する。入力装置2は、押しボタンやリモコン、表示装置6と一体のタッチパネル等により構成され、ユーザが所望の機能を選択したり、カーナビ装置の目的地の入力、テレビやラジオの選局の入力を可能とする。なお、入力装置2は、マイクロフォンを備えて音声による操作も可能である。
制御装置10は、車載多機能装置1を制御するための制御装置であり、CPU、ROM、RAM及びNVRAMなどをバスにより接続したコンピュータにより構成される。CPUはROMや記憶装置9に格納されているプログラムを実行して、入力に応じた処理や画面表示の切り替え等、後述する処理を実行する。記憶装置9はハードディスクドライブや書き換え可能な光ディスク、フラッシュメモリ等により構成され、OS等や地図データ、ファイル(メタデータ)、プログラムなどを格納している。メタデータ、プログラム、地図データ等は、車両に設けられたコネクタや無線通信を介し記憶装置9にインストールされる。なお、メタデータはネットワークを介してダウンロードされ、記憶装置9にインストールしてもよい。
図2(b)は、マルチメディアアーキテクチャの全体システム構成図を示す(以下、図2(b)のUIサーバを単にシステムということがある)。マルチメディアアーキテクチャのシステムは、ディスプレイやスピーカ、マイクロフォン等のハードウェアとそれらのドライバからなるH/W、システム全体を統括するSystem、分散環境を実現する為の分散FW、データ等を管理するContentsサーバ、サービスの個別部品としてソフトウェア処理を行うModel、本実施の形態で説明するユーザインターフェイスを制御するUIサーバ20から構成される。なお、UIサーバ20とハードウェア以外の構成を外部サブシステムと称す。
図2(b)のUIサーバ20は、分散FWのライフサイクル管理から起動され、取り付けられるデバイスや外部サービスと連携して、ユーザにサービスを提供する。UIサーバ20は、サービスの状態遷移を受け持つシナリオ処理部12、画面を受け持つレイアウト部13及びグラフイック部16、音を受け持つボイス部及びサウンド部17、サブシステム間で共有するオブジェクトのリファレンスを格納する為のUIリポジトリ及びLSuI(Life Scene User Interface)との連携の際に使用するLSuI連携部11を有する。
LSuI連携部11は、LSuIとUIサーバ20の他のサブシステムとが連携する際にメッセージMLの送受信を行う。サブシステム間の連携について説明する。図3(a)は、XML(eXtensible Markup Language)メッセージによるサブシステム間の疎結合の概略を示す図である。
本システムでは、サブシステム間のデータ授受に際し、言語やプラットフォームに依存しない形とする為、メタデータ、主にXMLメッセージを用いる。これにより、サブシステム間の疎結合化が可能となる。XMLメッセージとは、XMLを用いてメッセージのやり取りを行うことをいう。すなわち、図3(a)に示すように、シナリオ処理部とレイアウト部、シナリオ処理部とボイス部は、XMLメッセージを用いて、例えば、XML読み込み依頼などの内容を相互にやり取りする。したがって、「メッセージML」のように「〜ML」と表示されるものは、XMLメッセージにより対象となる処理に関する連携を行うことを示す。
本システムで使用するXML規格は、大きくシナリオ、レイアウト、ボイスの3つについてのXMLと、XML間の情報をマッピングするD.D.(Deployment Descriptor)から成る(D.D.もXMLファイルである)。代表的な「〜ML」は次のようになる。
・シナリオML
本システムが提供するサービスの定義。シナリオMLがレイアウトML、ボイスML及びモデルと繋がる基点となる。
・シナリオML用リソースML
シナリオML、モデル用D.D.に対するテキストリソースを定義する。シナリオML用リソースMLを差し替えることにより、同一のシナリオのままで、使用する文字を変更することが可能となる。(例:日本語→英語)
・レイアウトML
本システムが提供するグラフィックデバイス向けユーザインタフゴースの構成、遷移を定義する。
・レイアウトML用D.D.
シナリオMLとレイアウトMLの、イベント及び変数の関連づけを定義する。レイアウトML用D.D.により、シナリオML中の変数とレイアウトML中の変数が紐付けされ、データが共有される。また、レイアウトML用D.D.により、シナリオML中のイベントとレイアウトML中のイベントが紐付けされ、処理のタイミンクの同期がとられる。
・レイアウトML用スキンML
レイアウトMLに対する画面意匠を定義する。レイアウトML用スキンMLを差し替えることにより、同一の画面構成、画面遷移のままで画面意匠を変更することが可能となる。
・レイアウトML用リソースML
レイアウトMLに対するテキストリソースを定義する。レイアウトML用リソースMLを差し替えることにより、同一の画面構成、画面遷移のままで表示する文字を変更することが可能となる。(例:日本語→英語)
・ボイスML
本システムが提供するサウンドデバイス向けユーザインターフェイスの構成、音声による対話制御を定義する。
・ボイスML用D.D.
シナリオMLとボイスMLの、イベント及び変数の関連づけを定義する。ボイスML用D.D.により、シナリオML中の変数とボイスML中の変数がひも付けされ、デ−タが共有される。また、ボイスML用D.D.により、シナリML中のイベントとボイスML中のイベントが紐付けされ、処理のタイミングの同期がとられる。
・ボイスML用スキンML
ボイスMLに対する音声意匠を定義する。ボイスML用スキンMLを差し替えることにより、同一の対話内容のまま、声色を変更することが可能となる。
・ボイスML用リソースML
ボイスMLに対する発話内容を定義する。ボイスML用リソースMLを差し替えることにより同一の対話内容のまま、発話内容、及び認識辞書を変更することが可能となる。
・モデル用D.D.
シナリオMLとモデルの、インタフュースの関連づけを定義する。モデル用D.D.によりシナリオML中の変数とモデルに対するバラメタが紐づけされ、データが共有される。
・モデルML
モデルのインターフェイスや付加情報を定義する。
・デバイスML
本システムが利用可能なデバイス情報の出力形式を定義する。本定義は、本システムが内部で収集しているデバイスの情報を、サブシステム間で受渡しする際に用いる。
・メッセージML
本システムのサブシステム間、及びサブシステム内のコンポーネント間で情報を受渡しする際に用いる、XMLメッセージである。なお、コンポーネントについては後述するが、コンポーネントは、抽象概念系、実装系及び実体系の3層に構成した各サブシステムをいう。
・インデックスML
LSuIがレイアウトML、スキンML、リソースMLに関し最適なMLを提供するために用いる判断材料を記述したものであり、URI(Uniform Resource Identifiers(後述))が列挙されている。
・シナリオML
本システムが提供するサービスの定義。シナリオMLがレイアウトML、ボイスML及びモデルと繋がる基点となる。
・シナリオML用リソースML
シナリオML、モデル用D.D.に対するテキストリソースを定義する。シナリオML用リソースMLを差し替えることにより、同一のシナリオのままで、使用する文字を変更することが可能となる。(例:日本語→英語)
・レイアウトML
本システムが提供するグラフィックデバイス向けユーザインタフゴースの構成、遷移を定義する。
・レイアウトML用D.D.
シナリオMLとレイアウトMLの、イベント及び変数の関連づけを定義する。レイアウトML用D.D.により、シナリオML中の変数とレイアウトML中の変数が紐付けされ、データが共有される。また、レイアウトML用D.D.により、シナリオML中のイベントとレイアウトML中のイベントが紐付けされ、処理のタイミンクの同期がとられる。
・レイアウトML用スキンML
レイアウトMLに対する画面意匠を定義する。レイアウトML用スキンMLを差し替えることにより、同一の画面構成、画面遷移のままで画面意匠を変更することが可能となる。
・レイアウトML用リソースML
レイアウトMLに対するテキストリソースを定義する。レイアウトML用リソースMLを差し替えることにより、同一の画面構成、画面遷移のままで表示する文字を変更することが可能となる。(例:日本語→英語)
・ボイスML
本システムが提供するサウンドデバイス向けユーザインターフェイスの構成、音声による対話制御を定義する。
・ボイスML用D.D.
シナリオMLとボイスMLの、イベント及び変数の関連づけを定義する。ボイスML用D.D.により、シナリオML中の変数とボイスML中の変数がひも付けされ、デ−タが共有される。また、ボイスML用D.D.により、シナリML中のイベントとボイスML中のイベントが紐付けされ、処理のタイミングの同期がとられる。
・ボイスML用スキンML
ボイスMLに対する音声意匠を定義する。ボイスML用スキンMLを差し替えることにより、同一の対話内容のまま、声色を変更することが可能となる。
・ボイスML用リソースML
ボイスMLに対する発話内容を定義する。ボイスML用リソースMLを差し替えることにより同一の対話内容のまま、発話内容、及び認識辞書を変更することが可能となる。
・モデル用D.D.
シナリオMLとモデルの、インタフュースの関連づけを定義する。モデル用D.D.によりシナリオML中の変数とモデルに対するバラメタが紐づけされ、データが共有される。
・モデルML
モデルのインターフェイスや付加情報を定義する。
・デバイスML
本システムが利用可能なデバイス情報の出力形式を定義する。本定義は、本システムが内部で収集しているデバイスの情報を、サブシステム間で受渡しする際に用いる。
・メッセージML
本システムのサブシステム間、及びサブシステム内のコンポーネント間で情報を受渡しする際に用いる、XMLメッセージである。なお、コンポーネントについては後述するが、コンポーネントは、抽象概念系、実装系及び実体系の3層に構成した各サブシステムをいう。
・インデックスML
LSuIがレイアウトML、スキンML、リソースMLに関し最適なMLを提供するために用いる判断材料を記述したものであり、URI(Uniform Resource Identifiers(後述))が列挙されている。
図3(b)は、状態遷移の概念を示す図である。XMLを使用することにより、サービスやユーザインターフェイスを構成するデータに意味を持たせることが可能になる為、年次モデルや車種、グレ−ド等に応じた固有の拡張を加えることも可能となる。例えばユーザインターフェイスで一般的な「ボタン」を意味するデータが記述されている場合、ある車種ではこのデータはアイコンで表現されるが、異なる車種では3Dオブジェクトや、ハードスイッチにマッピングされる。
図3(b)に示すように、レイアウトMLにより「画面A」〜「画面F」の画面情報(意匠情報やリソース情報、配置情報)、及び各画面の遷移情報が記述される。同様に、シナリオMLにより状態遷移が記述され、ボイスMLにより対話遷移が記述される。これらの各XMLは、相互に情報のやり取りを行うことにより、相互関係を持つことが可能である。
図2(b)に戻り、UIリポジトリ15は、サブシステム間で共有するオブジェクトのリファレンス(参照という場合がある)を格納している。シナリオ処理部12は、システム本体が提供するサービス(シナリオ)を解釈/実行する。レイアウト部13は、シナリオ処理部12からの通知を受けて、画面遷移を記述したレイアウトMLを解釈し、グラフィック部16と連携する。グラフィック部16は、レイアウト部13と連携し、ディスプレイやタッチパネルなどのグラフィックデバイスとやり取りを行うことによりユーザと対話を行う。ボイス部17は、シナリオ処理部12からの通知を受けて、音声対話を記述したボイスMLを読み込み、サウンド部17と連携し、音声対話サービスを提供する。サウンド部17は、音や音声の出力、音声の入力を受け付けるサービスを提供する。
続いて、本システムの実体系と抽象概念について説明する。図4は、抽象概念層、実装層及び実体層の関係を示す図である。本システムはプラットフォームに依存しない「抽象概念系」と、プラットフォームに依存する「実体層」、抽象概念系と実体層を繋ぐ「実装層」に分離され、これらが連携して機能を提供する。
抽象概念層では、主に、サービスを定義したシナリオML、画面構成/遷移を定義したレイアウトML、音声による対話制御を定義したボイスML等のXMLファイルの解釈を行い、実装層を通じて実行時に必要なデータを実体層に渡す。
抽象概念層は、XMLファイル(シナリオML、レイアウトML、ボイスML)の解釈、実体層向けテー夕(実行時に用いるデータ)の送信、実体層からの依頼の受信及び対応する処理(XMLファイル取得、XMLL解釈等)等を行う。
実体層では抽象概念層から渡されたデータを保持し、それらと実デバイスを利用してサービスを提供する。プラットフォームに依存する部分であるため、実装方法はプラットフォームに応じて設計される。プラットフォームは例えば、車種やPC(パソコン)などである。実体層は、抽象概念層へ依頼事項の送信(XMLファイル取得依頼、XML解釈依頼)を行う。
なお、実体層は、プラットフォームや機種に非依存であり、抽象概念層と実体層のインターフェイスとなる。また、以下では、抽象概念層、実装層及び実体層のメタデータをそれぞれ抽象概念系、実装系及び実体系という。
〔UIリポジトリ〕
UIリポジトリ15について説明する。抽象概念系が実体系部のオブジェクトを指定する際にはURIを用いてオブジェクトの識別を行う。
UIリポジトリ15について説明する。抽象概念系が実体系部のオブジェクトを指定する際にはURIを用いてオブジェクトの識別を行う。
UIリポジトリ15は、本システムの実体系コンポーネントが生成したオブジェクトのリファレンスを格納し、相互に情報のやり取りを行う為に利用するサブシステムである。
図5は、シナリオ処理部、レイアウト部、ボイス部の関係を示す図である。オブジュクトの生成元であるコンポーネントは、生成したオブジェクトのキーとなるURIと、そのオブジュクトのリファレンスを対応づけて格納しており、参照元のコンポーネントがURIをキーとしてオブジェクトのリファレンスを取り出す。
抽象概念系のコンポーネント間は、実体系に依存したオブジェクト(及びそのリファレンス)を送受しないため、実体系に依存していないURIを送受し、実体系のオブジェクトはURIに結び付けられたオブジェクトをUIリポジトリ15から取り出し、相互に情報のやりとりを行う。
〔シナリオ処理部〕
シナリオ処理部12は、システム本体が提供するサービス(シナリオ)を解釈/実行するものであり、システム本体から提供されるシナリオMLに従い、利用者へ適切なHMI(Human Interface)サービスを提供する司令塔的役割を持つ、サブシステムである。
シナリオ処理部12は、システム本体が提供するサービス(シナリオ)を解釈/実行するものであり、システム本体から提供されるシナリオMLに従い、利用者へ適切なHMI(Human Interface)サービスを提供する司令塔的役割を持つ、サブシステムである。
シナリオ処理部12はレイアウト部13、ボイス部14と連携し、サービスを提供する。シナリオMLにはサービス全体の状態遷移を記述することができ、レイアウト部、ボイス部とD.D.に記述されたマッピング定義によって情報の共有、遷移の同期をとることができる。
実体世界では分散FWの提供する共有変数機能を利用して情報が共有される。また、遷移に対しては分散FWの提供するイベント管理機能を利用して同期がとられる。シナリオMLに記述された状態遷移では、サービスで用いる「アクション」と呼ばれるモデルと連携する役割を持ち、車載機が持つ他サービスとの連携を行う。具体的には、シナリオMLに実際にモデルの機能を呼び出すアクションを記述し、イベントの活性化等によってこのアクションを実行することでモデルの提供する機能を利用する。また、レイアウトMLやボイスMLからモデルの提供する機能を利用する場合、イベントを利用しアクションを呼び出すことでモデルとの連携を実現する。
〔レイアウト部〕
レイアウト部13はシナリオ処理部12からの通知を受けて、ユーザとの対話を行う為の画面遷移を記述したレイアウトMLを解釈し、グラフィック部16と連携することにより利用者にユーザインタフュースを提供するサブシステムである。
レイアウト部13はシナリオ処理部12からの通知を受けて、ユーザとの対話を行う為の画面遷移を記述したレイアウトMLを解釈し、グラフィック部16と連携することにより利用者にユーザインタフュースを提供するサブシステムである。
レイアウト部13は、グラフィック部16を介して、実テバイスからのタッチパネルやエスカッションキー入力、実デバイスヘの画面出力を行う。レイアウトMLには画面構成と画面遷移を記述することができ、シナリオMLに記述されたシナリオの状態遷移とは、D.Dに記述されたマッピング定義によって情報の共有、遷移の同期をとることができる。実体世界では分散FWの提供する共有変数機能を利用して情報が共有される。また、遷移に対しては分散FWの提供するイベント管理機能を利して同期がとられる。
レイアウトMLに記述した画面表示中にナビ等のモデルの提供する機能を利用する場合は、シナリオMLに実際にモデルの機能を呼び出すアクションを記述し、イベントの活性化等によってこのアクションを実行することでモデルの提供する機能を利用する。
レイアウトMLに記述した画面遷移中に話す声対話等の音声変化を起こさせる場合は、ボイスMLに実際に音声対話アクション等のアクションを記述し、イベントの活性化等によってこのアクションを実行することでボイス部の提供する機能を利用する。また、レイアウトMLに記述した画面遷移中にナビ等のモデルの提供する機能を利用する場合は、シナリオMLに実際にモデルの機能を呼び出すアクンョンを記述し、イベントの活性化等によってこのアクションを実行することでモデルの提供する機能を利用する。また、ボタン押下時の効果音など一部の音出力に関しては、サウンド部と連携することにより高レスポンスを実現する。
〔グラフィック部〕
グラフィック部16は基本的にレイアウト部13と連携し、ディスプレイやタッチパネルなどのグラフィックデバイスとやり取りを行うことにより、ユーザと対話を行うサブシステムである。ただし、ナビ描画など一部はレイアウト部を経由しないサービスも存在する(ナビ描画の場合、プラグインによりナビモデルから直接描画を行うことによりサービスを提供する。)。
グラフィック部16は基本的にレイアウト部13と連携し、ディスプレイやタッチパネルなどのグラフィックデバイスとやり取りを行うことにより、ユーザと対話を行うサブシステムである。ただし、ナビ描画など一部はレイアウト部を経由しないサービスも存在する(ナビ描画の場合、プラグインによりナビモデルから直接描画を行うことによりサービスを提供する。)。
図6は、グラフィック部16と、シナリオ処理部12、サウンド部17の関係を示す図である。グラフィック部16はディスプレイやタッチパネル、エスカッションキーなどの実デバイスに対して画面の出力や表示内容に関連するイベント(ボタンウィジェットなど)入力を行うことが可能であり、これを行う為のインターフェイスを持つ。また、画面の出力に関して、様々な依頼元からの要求を調停する為の、排他制御や合成を行う機能(画面権管理)を持つ。
グラフィック部16へはレイアウト部13やサウンド部17、描画クライアントと呼ばれるモデル群からの依頼を受け、画面の出力、表示に関連するイベントの入力を行う。
〔ボイス部〕
ボイス部14は、ボイスMLを読み込み、ボイスML中に記述された音声対話サービスを提供するサブシステムである。
ボイス部14は、ボイスMLを読み込み、ボイスML中に記述された音声対話サービスを提供するサブシステムである。
図5に戻り、ボイス部14はサウンド部17を介して、実デバイスからの音声の入力、実デバイスへの音声の出力を行う。ボイスMLには音声対話の状態遷移を記述することができ、シナリオMLに記述されたシナリオの状態遷移とは、D.D.に記述されたマッピング定義によって情報の共有、遷移の同期をとることができる。実体世界では分散FWの提供する共有変数機能を利用して情報が共在される。また、遷移に対しては分散FWの提供するイベント管理機能を利用して同期がとられる。
ボイスMLに記述した音声対話中に画面遷移等の画面変化を起こさせる場合は、レイアウトMLに実際に画面遷移アクションやアニメーション等のアクションを記述し、イベントの活性化等によってこのアクションを実行することでレイアウトの提供する機能を利用する。また、ボイスMLに記述した音声対話中にナビ等のモデルの提供する機能を利用する場合は、シナリオMLに実際にモデルの機能を呼び出すアクションを記述し、イベントの活性化等によってこのアクションを実行することでモデルの提供する機能を利用する。
〔サウンド部〕
サウンド部は音や音声の出力、音声の入力を受け付けるサービスを提供する・サブシステムである。
サウンド部は音や音声の出力、音声の入力を受け付けるサービスを提供する・サブシステムである。
図7は、サウンド部17と、ボイス部14、グラフィック部16の関係を示す図である。サウンド部17はスピーカやマイクなどの実デバイスに対して音声の出力や入力を行うことが可能であり、これを行う為のインターフェイスを持つ。また、音の出力に対して、様々な依頼元からの要求を調停する為の、排他制御やミキシングを行う機能(音権管理)を持つ。
サウンド部17へはボイス部14やグラフィック部16、Soundクライアントと呼ばれるモデル群からの依頼を受けて、音診/音声の出力、音声の入力を行う。
〔URI〕
URIについて説明する。本システムではサブシステム間で共有する全てのリソースの「所在地」を示す方法としてURIを用いる。URIは1つ1つのリソースに対して必ずコニークに割り当てられる。
URIについて説明する。本システムではサブシステム間で共有する全てのリソースの「所在地」を示す方法としてURIを用いる。URIは1つ1つのリソースに対して必ずコニークに割り当てられる。
本システム内でURIを割り当てて参照するリソースとしては以下の様なものが挙げられる。
(i)シナリオML等のXMLファイル
(ii)スキンMLに記述された画像ファイル等
(iii)シナリオML等をパースした結果生成されるインスタンス
(iv)システム起動時に生成されるデバイス等のインスタンス
(v)分散FWが提供する各種リモートサービス
図8は、UIサーバ20がURIを参照する概念図を示す。これらの列挙したリソースの内、(i)(ii)のリソースは、コンテンツサーバ上に管理され、URIを指定して参照、登録することができる。(iii)、(iv)、(v)のリソースは分散FWのロケーション管理上に管理され、そのインスタンスやサービスの参照を、URIを指定して参照、登録することができる。
(i)シナリオML等のXMLファイル
(ii)スキンMLに記述された画像ファイル等
(iii)シナリオML等をパースした結果生成されるインスタンス
(iv)システム起動時に生成されるデバイス等のインスタンス
(v)分散FWが提供する各種リモートサービス
図8は、UIサーバ20がURIを参照する概念図を示す。これらの列挙したリソースの内、(i)(ii)のリソースは、コンテンツサーバ上に管理され、URIを指定して参照、登録することができる。(iii)、(iv)、(v)のリソースは分散FWのロケーション管理上に管理され、そのインスタンスやサービスの参照を、URIを指定して参照、登録することができる。
〔外部サブシステム〕
続いて、外部サブシステムの概要について説明する。外部サブシステムはUIサーバ20と連携して動作する。図2(b)に示したように、外部サブシステムの構成の一例を示す図である。外部サブシステムは、Contents Server、Model、System、分散FWから構成される。
続いて、外部サブシステムの概要について説明する。外部サブシステムはUIサーバ20と連携して動作する。図2(b)に示したように、外部サブシステムの構成の一例を示す図である。外部サブシステムは、Contents Server、Model、System、分散FWから構成される。
Modelは、LSuI及びモデルを有する。分散FWは、「ライフサイクル管理」、「ロケーション管理」、「デバイス管理」からなる管理サービス層、「車載ファシリティ」、「イベント管理」、「イベントID管理」とからなる基本サービス層により構成される。
ライフサイクル管理は、分散FW内で使用するサービスの起動方法やサービスの参照を、サービスリポジトリ管理するサービスである。各OSにひとつずつ存在し、ロケーション管理より待機系サービスの起動要求があった場合にそのサービスを起動する。
ライフサイクル管理の持つ機能として、「ServiceConfiguration」による設定」、「サービスプロセス起動」、「デバイスの追加と削除」が挙げられる。
図9は、ロケーション管理とライフサイクル管理の概要を示す図である。本システムは、ライフサイクル管理の管理下にあるオブジェクトを利用することにより、オブジェクトのライフサイクル管理を分散FWに委任する形とする。通常、ライフサイクル管理の存在は、分散FWのロケーション管理に隠蔽されており、本システムからは意識しない。
ロケーション管理は、分散FWで使用される、分散オブジェクトのオブジェクト参照の登録と検索機能を提供するサービスである。本システムは、ロケーション管理に対して、
・他プロセスから利用するコンポーネントのオブジュクト参照を登録ける。
・利用するコンポーネントのオブジェクト参照を問い合わせ、オブジュクド参照を取得する、
ことにより、サービス(オブジェクト)の実体の位置を意識しない形でサービスを提供・利用することが可能となる。また、オブジェクト参照を登録する際は、登録するオブジェクトのURIを、オブジェクト参照を取得する際のキーとして使用する。
・他プロセスから利用するコンポーネントのオブジュクト参照を登録ける。
・利用するコンポーネントのオブジェクト参照を問い合わせ、オブジュクド参照を取得する、
ことにより、サービス(オブジェクト)の実体の位置を意識しない形でサービスを提供・利用することが可能となる。また、オブジェクト参照を登録する際は、登録するオブジェクトのURIを、オブジェクト参照を取得する際のキーとして使用する。
デバイス管理は、車載多機能装置で使用されるデバイスの構成情報を提供するサービスである。提供されるデバイスの構成情報例は、例えば次のようになる。
全般: 対応座席位置(0 〜 9)
種類
(Graphic/Sound)
デバイスのURI
デバイスの識別
接続先ホスト名
オープニング画面の表示の有無
画面: レイヤーNo.
分割位置No.
本システムは、デバイス管理に対して、
・実デバイスの位置情報を問い合わせる。
全般: 対応座席位置(0 〜 9)
種類
(Graphic/Sound)
デバイスのURI
デバイスの識別
接続先ホスト名
オープニング画面の表示の有無
画面: レイヤーNo.
分割位置No.
本システムは、デバイス管理に対して、
・実デバイスの位置情報を問い合わせる。
・実デバイスのデバイス情報を問い合わせる。
ことにより、プラットフオームに依存する実デバイスの実体を隠蔽し、ボキャブラリデバイスと関連付けることが可能となる。
ことにより、プラットフオームに依存する実デバイスの実体を隠蔽し、ボキャブラリデバイスと関連付けることが可能となる。
ボキャブラリデバイスとは、一般的に言われるXMLのボキャブラリの他に、所定のイベントやデバイスのXMLを要素化したボキャブラリである。本システムで単に「ボキャブラリ」と呼んだものは「所定のイベントやデバイスをXMLの要素化したボキャブラリ」を指す。
ボキャブラリはDTD(Document Type Definition)として規定され、各XML規格に取り込まれて使用される。XML規格はボキャブラリを取り込むことにより、規定のイベント定義やデバイス定義を使用することができる様になる。
ボキャブラリは、プラットフォームに依存するイベントやデバイスを隠蔽し抽象化する為のものであり、
・外部イベントや一部の内部イベントの定義
・本システムが認識可能なデバイスの表現
・シナリオからモデルを呼び出す際に補足する例外の定義
を規定する。
・外部イベントや一部の内部イベントの定義
・本システムが認識可能なデバイスの表現
・シナリオからモデルを呼び出す際に補足する例外の定義
を規定する。
イベント管理は、イベントのやり取りを行う際の、データ送受信、フィルタリングを行う。イベント管理では、イベントサーバを利用したTCP版と、マルチキャスト通信を利用したUDP版を混在して利用可能である。
UIサーバ20では、シナリオ・レイアウト・ボイス間で相互に利用するイベントに対し分散FWのイベント管理へイベント登録/削除を行い、イベント管理とイベントの送受を行うことにより、分散環境下での動作が可能となる。
本システムはイベント管理に対して
・各‐サブシステム間で相互利用するイベントのコールバックを登録する
・各サブシステムの内部でのみ利用するイベントのコールバックを登録する
・ボキャブラリイベントのコールバックを登録する
・登録されたイベントが発生したことを通知する(イベントを活性化する)
ことにより、スレッド間、プロセス間、ホスト間であってもイベント通知を受けることが可能になる。また、イベントを登録する際は、登録するイベントのURIを、イベント通知を受ける際のキーとして使用する。
・各‐サブシステム間で相互利用するイベントのコールバックを登録する
・各サブシステムの内部でのみ利用するイベントのコールバックを登録する
・ボキャブラリイベントのコールバックを登録する
・登録されたイベントが発生したことを通知する(イベントを活性化する)
ことにより、スレッド間、プロセス間、ホスト間であってもイベント通知を受けることが可能になる。また、イベントを登録する際は、登録するイベントのURIを、イベント通知を受ける際のキーとして使用する。
イベントID管理は、車載多機能装置で発生するイベントのID情報を提供する。提供されるイベント情報は、例えば次のようになる。
エスカッションスイッチ : 「ボタン」押下
「日的地ボタン」押下
「現在地ボタン」押下
「ナビメニューボタン」押下
「TVボタン」押下
車両情報 : イルミネーションON
イルミネーションOFF
走行規制ON
走行規制OFF
システム情報: 起動処理完了
終了処理完了
本システムはイベントID管理から、本システムの外部から通知されるプラットフォーム依存のイベントのIDを取得することにより、分散FWのイベント管理と連携してプラットフォーム依存のイベントの通知を受信することが可能となる。受信したプラットフォーム依存のイベントはボキャブラリイベントとして本システム内で使用する。
エスカッションスイッチ : 「ボタン」押下
「日的地ボタン」押下
「現在地ボタン」押下
「ナビメニューボタン」押下
「TVボタン」押下
車両情報 : イルミネーションON
イルミネーションOFF
走行規制ON
走行規制OFF
システム情報: 起動処理完了
終了処理完了
本システムはイベントID管理から、本システムの外部から通知されるプラットフォーム依存のイベントのIDを取得することにより、分散FWのイベント管理と連携してプラットフォーム依存のイベントの通知を受信することが可能となる。受信したプラットフォーム依存のイベントはボキャブラリイベントとして本システム内で使用する。
車載ファシリティは、車載多機能装置で発生する走行規制ON/OFFやイルミネーンョンON/OFF等の車両のイベントを通知する為のサービスである。提供される車両情報は、例えば次のようになる。
効果:イルミネーションON/OFF
規制:走行規制ON/OFF
本システムは、車載ファシリティが発生させるプラットフォーム依存のイベントを、分散FWのイベント管理を通して受信する。受信したプラットフォーム依存のイベントはボキャブラリイベントとして本システム内で使用する。
効果:イルミネーションON/OFF
規制:走行規制ON/OFF
本システムは、車載ファシリティが発生させるプラットフォーム依存のイベントを、分散FWのイベント管理を通して受信する。受信したプラットフォーム依存のイベントはボキャブラリイベントとして本システム内で使用する。
モデルは、外部プログラムを定義したものである。本システムは、シナリオMLやレイアウトML等のXML規格に記述できない複雑な処理を、外部のプログラムとして定義し、シナリオMLから呼び出すことができる。この外部プログラムをモデルと呼ぶ。
図10は、モデルの概要を示す図である。シナリオMLにはモデル実体に関する情報は直接記述しない。図10に示すように、シナリオMLには抽象的にモデルの名称、関数名、パラメータ名が定義され、関数の呼び出し記述に関しても、抽象名を使用して記述される。
これに対し、モデルの実体では、DIL(Dynamic Interface Language)と呼ばれる動的インターフェイス呼び出し用の定義言語を使用してモデルのインターフェイスを定義し、これに対応する本体処理を内部に定義する。
シナリオML中の抽象モデルと、モデル実体との関連付けは、モデル用D.D.に定義する。モデル用D.D.には、抽象モデル名に対する実体モデルのURI、抽象関数名に対するモデル実体の関数名、モデル実体に渡すパラメータの並び順を記述する。
モデル実体は分散FWの提供するロケ−ション管理に、実体モデルURIを基に自身の参照を登録する。このモデルの機能を利用するシナリオインスタンスは、ロケーション管理から実例モデルURIを基にモデル実体の参照を取得し、この参照に対して動的インターフェイス呼び出しを行う。
本システムはLSuIと呼ばれるサブシステムと連携することにより、その時のシチュエーション、利用者の趣味・嗜好に最適なユーザインターフェイスを提供することを実現する。
図11がLSuIの機能概略を示す図である。図11に示すようにLSuIの機能は、例えば次のようになる。
・シナリオ自動生成/実行指示
・レイアウト/スキン/言語リソースの最適化
・レイアウト/スキン/言語リソースの変更依頼
・個人情報取得
LSuIのインスタンスは利用者1人に対して1個生成する。この為、LSuIのインスタンスを生成する、より自立のコンポーネントが必要となる。
・シナリオ自動生成/実行指示
・レイアウト/スキン/言語リソースの最適化
・レイアウト/スキン/言語リソースの変更依頼
・個人情報取得
LSuIのインスタンスは利用者1人に対して1個生成する。この為、LSuIのインスタンスを生成する、より自立のコンポーネントが必要となる。
本システムとLSuIの間の通信はLSuI連携部11を介してメッセージMLを利用して行われる。ただし、ユーザの切替え機能等の、上位のコンポーネントから呼び出されるべき機能に関しては、シナリオ処理部からモデルを呼び出す上述した方法を用い、LSuIの操作を行う方式である。
また、本システムは、コンテンツサーバと連携することにより、異なるホストや異なるプロセスからでも、XMLファイル、設定ファイル、画像ファイル、等の参照・編集を行うことができる。これらのファイルは統一的にURIによって指し示される。
図12はコンテンツサーバの概要を示す図である。本システムの各サブシステムは、コンテンツサーバが提供するライブラリのAPIを利用して、利用するファイルを参照・編集する。コンテンツサーバが提供するライブラリの、参照・編集するファイルへのアクセス方式については、本システムからは隠蔽されている。
以上説明したUIサーバ20のサブシステム間、外部システムとUIサーバ20とが通信することで、ライフシーンに適合したユーザインターフェイスを実現する。サブシステム間の通信について説明する。
本システム内のサブシステム間、及び外部システムと本システム間の通信方式は、大きくは「メッセージML通信」と「CORBA(Common Object Request Broker Architecture)通信」、「イベント」、「共有変数」の4つの方式に分類される。「CORBA」通信に関しては、更に「IDL((リモートインターフェイス呼び出し))、「DIL(動的インターフェイス呼び出し)」、「CLL(コマンドリスト通信)」に分類される。以下に、これらの通信方式の相互作用を記載する。
〔メッセージML通信〕
本システムの抽象概念系のコンポーネント間では、メッセージMLを媒体とする通信が行われる。通信するデータをXML形式にすることにより、サブシステム間の関係を疎にしている。
本システムの抽象概念系のコンポーネント間では、メッセージMLを媒体とする通信が行われる。通信するデータをXML形式にすることにより、サブシステム間の関係を疎にしている。
抽象概念系のコンポーネントはメッセージMLを作成する処理を隠蔽する為に、実装系のインターフェイスを介して実体系のコンポーネントを使用して実際の処理を行わせる。なお、実体系のコンポーネントはコンテンツサーバ上にメッセージMLを生成する。
図13は、メッセージML通信(リクエスト)にサブシステムAからサブシステムBへリクエストメッセージを送信する処理の概念を示す。サブシステムA抽象概念系は、実装系インターフェイスAを介して、サブシステムA実体系にリクユスト内容のメッセージML生成を依頼する。
サブシステムA実体系はコンテンツサーバ上にメッセージMLを作成する(この一連の処理の中で、生成するメッセージMLはURIによって特定される)。サブシステムA抽象概念系は、実装系インターフェイスAを介して、サブシステムA実体系に、リクエストメッセージの送信を依頼する。
サブシステムA実体系はサブシステムB実体系の参照を分散FWのロケーション管理から取得し、IDLで既定された関数を使用して、リクエストメッセージを送信する(この時実際に送信されるのは生成されたメッセージMLのURI)。
サブシステムB実体系は、リクエストメッセージを受け取ったことをサブシステムB抽象概念系に通知する。サブシステムB抽象概念系は、実装系のインターフェイスBを介して、サブシステムB実体系に、メッセージMLの参照を依頼する。サブシステムB抽象概念系はメッセージMLの内容を基にリクエストメッセージに対応する処理を開始する。
図14(a)(b)は、図13の処理の後、サブシステムBからサブシステムAにレスポンスメッセージを送信する処理の概念を示す図である。図14(a)の処理は、レスポンスとして何らかのデータ(XML)を返す場合を、図14(b)の処理は、レスポンスとして戻り値等の簡略な文字列(即値)だけを返す場合を示す。
〔CORBA通信〕
本システムの実体系のコンポーネントは分散FW上に構築される為、実体系のコンポーネント間ではCORBA通信が行われる。CORBA通信においては、一般的に使用される、IDL(Interface Definition Language)を既定してリモートでインタフュースを呼び出す方式の他に、分散FW上で拡張される以下の方式が使用される。
・DILに定義したインターフェイスを持つオブジェクトを生成し、クライアント側のスタブなしで動的にリモ−ト呼び出しする方式(動的インターフェイス呼び出し方式)
・CLL(Command List Language)に定義したコマンドを送受信、バッファリングするオブジェクトを生成し、コマンド呼び出し時の通信回数を削減する方式(コマンドリスト通信方式)
また、分散FWの基本サービスとして提供される「イベント管理」機能や「共有変数」機能も、通信の代替手段として利用する。以下、IDL、DIL、CLL、イベント、共有変数の5つの方式について説明する。
本システムの実体系のコンポーネントは分散FW上に構築される為、実体系のコンポーネント間ではCORBA通信が行われる。CORBA通信においては、一般的に使用される、IDL(Interface Definition Language)を既定してリモートでインタフュースを呼び出す方式の他に、分散FW上で拡張される以下の方式が使用される。
・DILに定義したインターフェイスを持つオブジェクトを生成し、クライアント側のスタブなしで動的にリモ−ト呼び出しする方式(動的インターフェイス呼び出し方式)
・CLL(Command List Language)に定義したコマンドを送受信、バッファリングするオブジェクトを生成し、コマンド呼び出し時の通信回数を削減する方式(コマンドリスト通信方式)
また、分散FWの基本サービスとして提供される「イベント管理」機能や「共有変数」機能も、通信の代替手段として利用する。以下、IDL、DIL、CLL、イベント、共有変数の5つの方式について説明する。
・IDL(リモートインターフェイス呼び出し)
利用する機能のインターフェイスをIDLに定義し、IDLから生成した「スタブ」と呼ばれる代理オブジェクトと、「スケルトン」と呼ばれるサーバオブジェクトが実際の通信を行う。スタブ又はスケルトンを利用する場合、スタブを利用する機能と、スケルトンを継承する実体オブジェクトを作成する。
利用する機能のインターフェイスをIDLに定義し、IDLから生成した「スタブ」と呼ばれる代理オブジェクトと、「スケルトン」と呼ばれるサーバオブジェクトが実際の通信を行う。スタブ又はスケルトンを利用する場合、スタブを利用する機能と、スケルトンを継承する実体オブジェクトを作成する。
この方式は、上述したメッセージML通信の方式における、実体系のコンポーネントが「メッセージ送受信IDL」に規定されるインターフェイスに、リクエストやレスポンスを送信する部分でも使用され、本システムの実体系コンポーネントにおけるもっとも基本的な通信方式である。
開発時には、まずIDLを規定し、IDLよりクライアント側のスタブと、サーバ側のスケルトンを生成する。サーバ側の開発者は、サーバ側のスケルトンを継承するIDLの実体オブジェクトを作成し、クライアント側の開発者はIDLの代理オブジェクトであるスタブを利用する機能を作成する。
実行時には、(異なるプロセスである場合)サーバ側のプロセスの起動時、または実体オブジュクトが利用されるより以前に、実体オブジュクトを生成し分散FWのロケーション管理へ生成した実体オフジュクトの参照を登録する。
クライアントの利用側の機能は、分散FWのロケーション管理から必要とする実体オブジェクトの参照を取得する。この時の実体オブジコクトを特定するキーとしてURIが用いられる。取得した参照に対して関数呼び出しを行うと、スタブはスケルトンの該当関数をリモードで呼び出す。
スケルトンは自身を継承する実体オブジェクトの該当関数を呼び出し、関数の実行結果をリモートでスタブに返す。クライアント側のプロセスはスタブから関数の実行結果を受け取る。また、以上の動作が同一プロセス内で行われる場合に限り、「ショートカット」と呼ばれる機能が働き、リモート呼び出しは行われない。これによってリモート呼び出しによる動作オーバヘットを削減する。以上の動作において、クライアントの利用者側の機能はリモート呼び出しが行われた事を一切認識しない。
スケルトンは自身を継承する実体オブジェクトの該当関数を呼び出し、関数の実行結果をリモートでスタブに返す。クライアント側のプロセスはスタブから関数の実行結果を受け取る。また、以上の動作が同一プロセス内で行われる場合に限り、「ショートカット」と呼ばれる機能が働き、リモート呼び出しは行われない。これによってリモート呼び出しによる動作オーバヘットを削減する。以上の動作において、クライアントの利用者側の機能はリモート呼び出しが行われた事を一切認識しない。
図15(a)は、分散FWのロケーション管理へ生成した実体オフジュクトの参照を登録する処理のシーケンス図を示す。
S1.登録側であるサブシステムAは、上述したように実体オブジュクト(サブシステムAの実体)を生成する。
S2.サブシステムAは、サブシステムAの実体の参照(リファレンス)を取得する。
S3.サブシステムAは、取得したサブシステムAの実体の参照を分散FWのロケーション管理に登録する。これにより、ロケーション管理からサブシステムAのURIを取得できることとなる。
S1.登録側であるサブシステムAは、上述したように実体オブジュクト(サブシステムAの実体)を生成する。
S2.サブシステムAは、サブシステムAの実体の参照(リファレンス)を取得する。
S3.サブシステムAは、取得したサブシステムAの実体の参照を分散FWのロケーション管理に登録する。これにより、ロケーション管理からサブシステムAのURIを取得できることとなる。
図15(b)は、IDL呼び出しのシーケンス図を示す。
S1.サブシステムBは、分散FWのロケーション管理から必要とする実体オブジェクトの参照を取得する。
S2.サブシステムBは、取得したURIに対して関数を呼び出す。
S3.上述したようにサブシステムBのスタブ及びサブシステムAのスケルトンにより、サブシステムAの関数が実行される。
S4.サブシステムBは、関数の実行結果を受信する。
S1.サブシステムBは、分散FWのロケーション管理から必要とする実体オブジェクトの参照を取得する。
S2.サブシステムBは、取得したURIに対して関数を呼び出す。
S3.上述したようにサブシステムBのスタブ及びサブシステムAのスケルトンにより、サブシステムAの関数が実行される。
S4.サブシステムBは、関数の実行結果を受信する。
・DIL(動的インターフェイス呼び出し)
図16は動的インターフェイス呼び出し時におけるCORBA通信の概念を示す図である。基本的な流れはIDLの場合と同様であるが、利用する機能のインターフェイスが規定できない為、以下に挙げる点に違いがある。
・呼び出す関数名やパラメータに関する情報は、外部から動的に与えられる。
・IDLコンパイルと同様にDILコンパイルを実行しても、クライアント側のスタブは動的に生成されない。
図16は動的インターフェイス呼び出し時におけるCORBA通信の概念を示す図である。基本的な流れはIDLの場合と同様であるが、利用する機能のインターフェイスが規定できない為、以下に挙げる点に違いがある。
・呼び出す関数名やパラメータに関する情報は、外部から動的に与えられる。
・IDLコンパイルと同様にDILコンパイルを実行しても、クライアント側のスタブは動的に生成されない。
DILスタブは分散FWの機能として提供される。この方式は、シナリオMLやモデル用D.D.内に動的に定義されるモデルの情報を元に、実際に利用するモデル実体を紐付ける際に使用される。
図17は、DIL呼び出しのシーケンス図を示す。
S1.サブシステムBは、分散FWのロケーション管理から必要とする実体オブジェクトの参照を取得する。
S21〜2n.サブシステムBは、モデル実体が受け取るパラメータを順番に設定する。
S3.サブシステムBは、最後にinvoke(発動)により関数を呼び出す。
S4.サブシステムBのスタブ及びサブシステムAのスケルトンにより、サブシステムAの関数が実行される。
S5.サブシステムBは、関数の実行結果を受信する。
S1.サブシステムBは、分散FWのロケーション管理から必要とする実体オブジェクトの参照を取得する。
S21〜2n.サブシステムBは、モデル実体が受け取るパラメータを順番に設定する。
S3.サブシステムBは、最後にinvoke(発動)により関数を呼び出す。
S4.サブシステムBのスタブ及びサブシステムAのスケルトンにより、サブシステムAの関数が実行される。
S5.サブシステムBは、関数の実行結果を受信する。
・CLL(コマンドリスト通信)
基本的な流れはIDLの場合と同様であるが、通信によるオーバヘッドを削減する為に、利用する機能のリモート呼び出し回数を削減する点においてIDLの場合と異なる。
基本的な流れはIDLの場合と同様であるが、通信によるオーバヘッドを削減する為に、利用する機能のリモート呼び出し回数を削減する点においてIDLの場合と異なる。
図18はコマンドリスト通信におけるCORBA通信の概念を示す図である。この方式は、レイアウト部13とグラフィック部16の間の様に、明らかにリモート呼び出しが発生し、かつ性能が要求される箇所に使用される。
図19(a)は、CLL呼び出しのシーケンス図を示す。
S1.サブシステムBは、分散FWのロケーション管理から必要とする実体オブジェクトの参照を取得する。
S21〜2n.サブシステムBは、サブシステムAに実行を依頼するコマンドを順番に登録する。
S3.サブシステムBは、最後にflushにより一連のコマンドをロケーション管理に発動する。リスト化されたコマンドが1回の通信でサブシステムAに送信される。
S41〜4n.ロケーション管理は、コマンドの実行をサブシステムAに依頼する。サブシステムAは、一連のコマンドを順に実行する。
S5.サブシステムBは、コマンドの実行結果を受信する。
S1.サブシステムBは、分散FWのロケーション管理から必要とする実体オブジェクトの参照を取得する。
S21〜2n.サブシステムBは、サブシステムAに実行を依頼するコマンドを順番に登録する。
S3.サブシステムBは、最後にflushにより一連のコマンドをロケーション管理に発動する。リスト化されたコマンドが1回の通信でサブシステムAに送信される。
S41〜4n.ロケーション管理は、コマンドの実行をサブシステムAに依頼する。サブシステムAは、一連のコマンドを順に実行する。
S5.サブシステムBは、コマンドの実行結果を受信する。
・イベント
イベントによる通信は、両面に表示されたボタンが選択された際に発生させる様な画面系のイベントや、音声認識時に発生させる様な音声系のイベント以外にも、シナリオから呼び出したモデルの実行完了通知や、走行規制のON/OFFの通知に利用される。
イベントによる通信は、両面に表示されたボタンが選択された際に発生させる様な画面系のイベントや、音声認識時に発生させる様な音声系のイベント以外にも、シナリオから呼び出したモデルの実行完了通知や、走行規制のON/OFFの通知に利用される。
図20はイベント通信の概念を示す図である。イベント受信側は分散FWのイベント管理機能に対して、イベントの識別子となるイベントURIに対してコールバック関数の登録を行う。分散FWのイベント管理機能は、イベントの発信側から指定されたイベントURIのイベントの活性化依頼を受けると、登録されたコールバック開放を呼び出す。イベントの受信側は、コ−ルバック関数内にイベントに対応する処理を定義することにより、イベントハンドリングが実現される。
図19(b)は、イベントコールバックのシーケンス図を示す。
S1.イベントを受信したサブシステムAは、イベント管理にイベント(コールバック)の登録を行う。
S2.サブシステムAは、イベントURIをサブシステムBに活性化してほしいイベントのURIを所定の方法で通知する。
S3.イベントURIを通知されたサブシステムBは、イベント管理部にイベントを活性化を依頼する。
S4.イベント管理部は、サブシステムAのコールバックを呼び出す。コ−ルバック関数内にイベントに対応する処理を定義することにより、イベントハンドリングが実現される。
S1.イベントを受信したサブシステムAは、イベント管理にイベント(コールバック)の登録を行う。
S2.サブシステムAは、イベントURIをサブシステムBに活性化してほしいイベントのURIを所定の方法で通知する。
S3.イベントURIを通知されたサブシステムBは、イベント管理部にイベントを活性化を依頼する。
S4.イベント管理部は、サブシステムAのコールバックを呼び出す。コ−ルバック関数内にイベントに対応する処理を定義することにより、イベントハンドリングが実現される。
・共有変数
共有変数を用いた通信は、サブシステム間で共有すべきデータを、専用の領域に保持して共有する。この方式は、シナリオML内に定義された変数の値や、モデルのアウトプットとして得られるデータを、レイアウトMLやボイスML内で使用する場合、シナリオMLと長時間にわたってデータを共有する場合等に使用される。
共有変数を用いた通信は、サブシステム間で共有すべきデータを、専用の領域に保持して共有する。この方式は、シナリオML内に定義された変数の値や、モデルのアウトプットとして得られるデータを、レイアウトMLやボイスML内で使用する場合、シナリオMLと長時間にわたってデータを共有する場合等に使用される。
図21は、共有変数による通信の概念を示す図である。
共有変数の生成者は、分散FWが提供する共有変数の生成関数を利用して共有変数の実体を生成する。この時、実体と共にその参照を得る。生成者はこの参照と変数の識別子(URI)をUIリポジトリ15に登録する。本システム内では、UIリポジトリ15から共有変数の参照を得ることによって、共有変数の参照、登録を行うことができる。
共有変数の生成者は、分散FWが提供する共有変数の生成関数を利用して共有変数の実体を生成する。この時、実体と共にその参照を得る。生成者はこの参照と変数の識別子(URI)をUIリポジトリ15に登録する。本システム内では、UIリポジトリ15から共有変数の参照を得ることによって、共有変数の参照、登録を行うことができる。
この為、共有変数を参照する場合は、まずUIリポジトリから変数URIを指定し、共有変数の参照を取得し、この参照を基に共有変数の値を参照する。また共有変数を更新する場合も同様に、UIリポジトリ15から得た共有変数の参照に対して、値の更新を行う。
共有変数では、必要に応じて、その値を更新した時に更新イベントを発生させることができる。この更新イベントは分散FWのイベント管理の機能を利用して発生させている。コールバックを登録するとによって、共有変数の値が更新された時の通知を受ける。
UIリポジトリ15は、共有変数の参照と、変数URIを関連づける為に必要であり、本システムの共通コンポーネントとして提供される。
続いて、以上の構成を用いて、サブシステム間及び外部システムとの基本相互作用について、システム起動、シナリオパース、認証画面表示及びユーザ認証完了の場合をそれぞれ説明する。
〔システム起動〕
図22は、システムの起動におけるサブシステム間及び外部システムとの基本相互作用を示す図である。図22の数字は以下の数字と対応している。
1.下位PFから分散FWのライフサイクル管理が起動される。
2.分散FWのライフサイクル管理から本システムと外部サブシステムのプロセスが起動される。
図22は、システムの起動におけるサブシステム間及び外部システムとの基本相互作用を示す図である。図22の数字は以下の数字と対応している。
1.下位PFから分散FWのライフサイクル管理が起動される。
2.分散FWのライフサイクル管理から本システムと外部サブシステムのプロセスが起動される。
2−1.ライフサイクル管理から分散FWのその他のサブシステムや、関連するモデル等のシステムが起動される。
2−2 グラフィック部16のプロセスが起動される。
2−3 サウンド部17のプロセスが起動され、起動したことをグラフィック部16に通知する。グラフィック部16はこのプロセス起動通知を受けて、サウンド部17へ起動効果音の出力を依頼し、起動画面を出力する。サウンド部17はグラフィック部16から起動効果音出力依頼を受けて起動効果音を出力する。
2−4 UIリポジトリのプロセスが起動される。
2−5 シナリオ処理部のプロセスが起動される。
2−6 レイアウト部13のプロセスが起動される。
2−7 ボイス部14のプロセスが起動される。
2−8 LSuIのプロセスが起動される。
3.LSuIはユーザ認証用のLSuIインスタンスを生成し、シナリオ処理部12、レイアウト部13、ボイス部14へ、生成したLSuIインスタンス向けの初期化要求を送信する。
4.LSuIインスタンスからシナリオ処理部12へ、起動直後に実行されるシナリオMLを提供する。
3.LSuIはユーザ認証用のLSuIインスタンスを生成し、シナリオ処理部12、レイアウト部13、ボイス部14へ、生成したLSuIインスタンス向けの初期化要求を送信する。
4.LSuIインスタンスからシナリオ処理部12へ、起動直後に実行されるシナリオMLを提供する。
図23は、システム起動のシーケンス図を示す。
S1.まず、本システムにプラットフォームから起動が通知される(例えば、ACCオン)。
S2.UIサーバ20(本システム)はグラフィック部16を起動する。
S3.UIサーバ20はサウンド部17を起動する。グラフィック部16、サウンド部17は、起動画面の表示や起動時の効果音出力を行うため、グラフィック部16とサウンド部17は本システムの中で最初に起動される。
S4.UIサーバ20はUIリポジトリ15を起動する。
S5.UIサーバ20はシナリオ処理部12を起動する。
S6.UIサーバ20はレイアウト部13を起動する。
S7.UIサーバ20はボイス部14を起動する。
S8.UIサーバ20はLSuIを起動する。UIサーバ20は、ユーザ認証用LSuIインスタンスを生成し、専用のシナリオエンジン、レイアウトエンジン等のインスタンスを生成する。
S9.LSuIインスタンスは、LSuIインスタンスのURIをもって、シナリオ処理部12の初期化を要求する。
S10.シナリオ処理部12は、LSuIインスタンス専用のシナリオエンジンインスタンスを生成する。
S11.LSuIインスタンスは、LSuIインスタンスのURIをもって、レイアウト部13の初期化を要求する。
S12.レイアウト部13は、LSuIインスタンス専用のレイアウトエンジンインスタンスを生成する。
S13.LSuIインスタンスは、LSuIインスタンスのURIをもって、ボイス部14の初期化を要求する。
S14.ボイス部14は、LSuIインスタンス専用のボイスエンジンインスタンスを生成する。
S15.LSuIインスタンスは、シナリオMLのURI、各種D.D.のURIをもって、シナリオ処理部にシナリオの起動を依頼する。
S1.まず、本システムにプラットフォームから起動が通知される(例えば、ACCオン)。
S2.UIサーバ20(本システム)はグラフィック部16を起動する。
S3.UIサーバ20はサウンド部17を起動する。グラフィック部16、サウンド部17は、起動画面の表示や起動時の効果音出力を行うため、グラフィック部16とサウンド部17は本システムの中で最初に起動される。
S4.UIサーバ20はUIリポジトリ15を起動する。
S5.UIサーバ20はシナリオ処理部12を起動する。
S6.UIサーバ20はレイアウト部13を起動する。
S7.UIサーバ20はボイス部14を起動する。
S8.UIサーバ20はLSuIを起動する。UIサーバ20は、ユーザ認証用LSuIインスタンスを生成し、専用のシナリオエンジン、レイアウトエンジン等のインスタンスを生成する。
S9.LSuIインスタンスは、LSuIインスタンスのURIをもって、シナリオ処理部12の初期化を要求する。
S10.シナリオ処理部12は、LSuIインスタンス専用のシナリオエンジンインスタンスを生成する。
S11.LSuIインスタンスは、LSuIインスタンスのURIをもって、レイアウト部13の初期化を要求する。
S12.レイアウト部13は、LSuIインスタンス専用のレイアウトエンジンインスタンスを生成する。
S13.LSuIインスタンスは、LSuIインスタンスのURIをもって、ボイス部14の初期化を要求する。
S14.ボイス部14は、LSuIインスタンス専用のボイスエンジンインスタンスを生成する。
S15.LSuIインスタンスは、シナリオMLのURI、各種D.D.のURIをもって、シナリオ処理部にシナリオの起動を依頼する。
〔シナリオパース〕
図24は、シナリオパースにおけるサブシステム間及び外部システムとの基本相互作用を示す図である。
1.LSuIインスタンスから起勤直後に実行されるシナリオのシナリオMLがシナリオ処理部に提供される。
2.シナリオオ処理部12は提供されたシナリオMLに対して、マッピング情報を記載されたD.D.をレイアウト部13、ボイス部14に渡す。
3.シナリオ処理部12は提供されたシナリオMLを解釈する。
図24は、シナリオパースにおけるサブシステム間及び外部システムとの基本相互作用を示す図である。
1.LSuIインスタンスから起勤直後に実行されるシナリオのシナリオMLがシナリオ処理部に提供される。
2.シナリオオ処理部12は提供されたシナリオMLに対して、マッピング情報を記載されたD.D.をレイアウト部13、ボイス部14に渡す。
3.シナリオ処理部12は提供されたシナリオMLを解釈する。
3−1 読み込んだ変数の定義に対してUIリポジトリに共有変数を登録する。
3−2 読み込んだ変数の定義に対しでマッピング情報としてレイアウト部13、ボイス部14に渡す。
3−3 読み込んだイベントの定義に対してマッピング情報としてレイアウト部13、ボイス部14に渡す。
4.シナリオ処理部12は解釈が完了した旨をLSuIインスタンスに通知する。
5.シナリオ処理部12はシナリオMLを解釈した結果を元に状態遷移を開始する(シナリオを実行する。)。
4.シナリオ処理部12は解釈が完了した旨をLSuIインスタンスに通知する。
5.シナリオ処理部12はシナリオMLを解釈した結果を元に状態遷移を開始する(シナリオを実行する。)。
図25は、シナリオパースのシーケンス図を示す。
S1.LSuIはシナリオの起動をシナリオ処理部12に依頼する。ここでは、LSuIはユーザ認証シナリオのURI、各種D.D.のURIをシナリオ処理部12に送信する。
S2.シナリオ処理部12はシナリオインスタンスを生成する。
S3.シナリオ処理部12はレスポンスメッセージとしてシナリオインスタンスのURIをLSuIに送信する。
S4.シナリオインスタンスは、レイアウトML用のD.D.のURIをレイアウト部13に通知する。レイアウト部13は、D.D.マッピング解決のために情報を保持しておく。
S5.シナリオインスタンスは、ボイスML用のD.D.のURIをボイス部14に通知する。ボイス部14は、D.D.マッピング解決のために情報を保持しておく。
S6.レイアウト部13はD.D.をパースする。
S7.ボイス部14はD.D.をパースする。
S8.レイアウト部13とボイス部14はレスポンスをシナリオインスタンスに返す。
S9.シナリオインスタンスは、シナリオMLをパースする。
S10.シナリオインスタンスは、リソースMLを取得するため、リソースインデックスのURIをLSuIに送信する。
S11.LSuIは、レスポンスメッセージとしてリソースMLのURIをシナリオインスタンスに送信する。
S12.シナリオインスタンスは、UIリポジトリ15に変数(変数URI、共有変数識別子)を登録する。
S13.シナリオインスタンスは、イベントマッピングの通知としてイベント名とURIのリストをレイアウト部13に送信する。レイアウト部13は、D.D.マッピング解決のために情報を保持しておく。
S14.シナリオインスタンスは、イベントマッピングの通知としてイベント名とURIのリストをボイス部14に送信する。ボイス部14は、D.D.マッピング解決のために情報を保持しておく。
S15.レイアウト部13とボイス部14はレスポンスをシナリオインスタンスに返す。
S16.シナリオインスタンスは、変数マッピングの通知として変数名とURIのリストをレイアウト部13に送信する。レイアウト部13は、D.D.マッピング解決のために情報を保持しておく。
S17.シナリオインスタンスは、変数マッピングの通知として変数名とURIのリストをボイス部14に送信する。ボイス部14は、D.D.マッピング解決のために情報を保持しておく。
S18.レイアウト部13とボイス部14はレスポンスをシナリオインスタンスに返す。
S19.シナリオインスタンスは状態遷移を登録する。
S20.シナリオインスタンスは、シナリオ起動の完了としてシナリオインスタンスURIをLSuIに送信する。
S21.LSuIはレスポンスをシナリオインスタンスに送信する。
S22.シナリオインスタンスは、状態遷移を開始する。
S1.LSuIはシナリオの起動をシナリオ処理部12に依頼する。ここでは、LSuIはユーザ認証シナリオのURI、各種D.D.のURIをシナリオ処理部12に送信する。
S2.シナリオ処理部12はシナリオインスタンスを生成する。
S3.シナリオ処理部12はレスポンスメッセージとしてシナリオインスタンスのURIをLSuIに送信する。
S4.シナリオインスタンスは、レイアウトML用のD.D.のURIをレイアウト部13に通知する。レイアウト部13は、D.D.マッピング解決のために情報を保持しておく。
S5.シナリオインスタンスは、ボイスML用のD.D.のURIをボイス部14に通知する。ボイス部14は、D.D.マッピング解決のために情報を保持しておく。
S6.レイアウト部13はD.D.をパースする。
S7.ボイス部14はD.D.をパースする。
S8.レイアウト部13とボイス部14はレスポンスをシナリオインスタンスに返す。
S9.シナリオインスタンスは、シナリオMLをパースする。
S10.シナリオインスタンスは、リソースMLを取得するため、リソースインデックスのURIをLSuIに送信する。
S11.LSuIは、レスポンスメッセージとしてリソースMLのURIをシナリオインスタンスに送信する。
S12.シナリオインスタンスは、UIリポジトリ15に変数(変数URI、共有変数識別子)を登録する。
S13.シナリオインスタンスは、イベントマッピングの通知としてイベント名とURIのリストをレイアウト部13に送信する。レイアウト部13は、D.D.マッピング解決のために情報を保持しておく。
S14.シナリオインスタンスは、イベントマッピングの通知としてイベント名とURIのリストをボイス部14に送信する。ボイス部14は、D.D.マッピング解決のために情報を保持しておく。
S15.レイアウト部13とボイス部14はレスポンスをシナリオインスタンスに返す。
S16.シナリオインスタンスは、変数マッピングの通知として変数名とURIのリストをレイアウト部13に送信する。レイアウト部13は、D.D.マッピング解決のために情報を保持しておく。
S17.シナリオインスタンスは、変数マッピングの通知として変数名とURIのリストをボイス部14に送信する。ボイス部14は、D.D.マッピング解決のために情報を保持しておく。
S18.レイアウト部13とボイス部14はレスポンスをシナリオインスタンスに返す。
S19.シナリオインスタンスは状態遷移を登録する。
S20.シナリオインスタンスは、シナリオ起動の完了としてシナリオインスタンスURIをLSuIに送信する。
S21.LSuIはレスポンスをシナリオインスタンスに送信する。
S22.シナリオインスタンスは、状態遷移を開始する。
〔認証画面表示〕
図26は、認証画面表示におけるサブシステム間及び外部システムとの基本相互作用を示す図である。
図26は、認証画面表示におけるサブシステム間及び外部システムとの基本相互作用を示す図である。
シナリオが実行された以後、状態の初期(entry)アクションや、イベントに対応するアクションとしてcreateLayout(指定されたレイアウトを生成する要素)が実行された場合に、レイアウトMLの解釈・実行が行われる。
1.シナリオ処理部12はシナリオを実行する。
2.シナリオ処理部12はcreateLayoutアクションを実行する。
3.シナリオ処理部12はレイアウト部13に対してcreateLayoutアクションが実行された旨を通知する。
4.レイアウト部13はメッセージMLを解釈し、LSuIインスタンスにレイアウトMLの最適化を依頼する(シナリオ処理部12が通知したメッセージMLに指定されているレイアウトインデックスをLSuIに渡す。)。
1.シナリオ処理部12はシナリオを実行する。
2.シナリオ処理部12はcreateLayoutアクションを実行する。
3.シナリオ処理部12はレイアウト部13に対してcreateLayoutアクションが実行された旨を通知する。
4.レイアウト部13はメッセージMLを解釈し、LSuIインスタンスにレイアウトMLの最適化を依頼する(シナリオ処理部12が通知したメッセージMLに指定されているレイアウトインデックスをLSuIに渡す。)。
LSuIインスタンスは、レイアウトインデックスの中に記述されたレイアウトMLの内、最適なレイアウトMLを選定し、そのURIをレイアウト部13に通知する。
5.レイアウト部13はレイアウトMLを解釈する。
5.レイアウト部13はレイアウトMLを解釈する。
5−1 レイアウト部13はLSuIインスタンスにスキンMLとリソースMLの最適化を依頼する(レイアウトMLに指定されているスキンインデックスとリソースインデックスをLSuIに渡す。)。
LSuIインスタンスはスキンインデックスとリソースインデックスの中に記述されたスキンMLとリソースMLの内、最適なスキンMLとリソースMLを選定し、そのURIをレイアウト部13に通知する。
5−2 レイアウト部13はスキンMLとリソースMLを解釈する。
5−3 レイアウト部13はレイアウトML中のスタイルにスキンMLの内容を、リソースにリソースMLの内容を、マッピングされる変数・イベントに「シナリオパース」時にシナリオ処理部12から渡されたマッピング情報を充て込む。
6.レイアウト部13はレイアウトMLの解釈が完了すると、シナリオ処理部12に対して、解釈が完了したことを通知する(メッセージML通信を利用して、ボキャブラリイベントとして通知する。)。
7.レイアウト部13はレイアウトMLを解釈した結果を元に状態遷移を開始する(レイアウトを実行する。)。
6.レイアウト部13はレイアウトMLの解釈が完了すると、シナリオ処理部12に対して、解釈が完了したことを通知する(メッセージML通信を利用して、ボキャブラリイベントとして通知する。)。
7.レイアウト部13はレイアウトMLを解釈した結果を元に状態遷移を開始する(レイアウトを実行する。)。
レイアウトが実行された以後、すぐには画面上に表示されない。レイアウトは画面表示用の何らかのイベントを受け取った後に始めて画面を表示する(実際にはシナリオML上の何らかのイベントと、レイアウトML上の画面表示用のイベントがマッピングされていて、このマッピングされたイベントが図28に示すように活性化されることにより、画面が表示される。)。
8.シナリオ処理部12は画面表示イベントを活性化するアクションを実行する。
9.画面表示イベントがレイアウト部13に通知される。
10.レイアウト部13は通知されたイベントに対して対応するアクションを実行する。 この場合はシーン切替えを行う。
11.レイアウト部13は切替えられたシーンに対応する描画コマンドを生成し、グラフィック部16に送信する。
12.グラフィック部16は描画コマンドを解釈し、物理デバイスに描画する。
8.シナリオ処理部12は画面表示イベントを活性化するアクションを実行する。
9.画面表示イベントがレイアウト部13に通知される。
10.レイアウト部13は通知されたイベントに対して対応するアクションを実行する。 この場合はシーン切替えを行う。
11.レイアウト部13は切替えられたシーンに対応する描画コマンドを生成し、グラフィック部16に送信する。
12.グラフィック部16は描画コマンドを解釈し、物理デバイスに描画する。
図27は認証画面表示のシーケンス図を示す。
S1.シナリオ処理部12はレイアウトの生成をレイアウト部13に依頼する。シナリオ処理部12はレイアウト識別名、レイアウトインデックスのURI、デバイスのURI、レイアウトインスタンスのURIを、レイアウト部13に送信する。
S2.レイアウト部13は、レイアウトMLの取得するため、LSuIにレイアウトインデックスのURIを送信する。
S3.LSuIは、レスポンスとしてレイアウトMLのURIをレイアウト部13に送信する。
S4.レイアウト部13は、レイアウトMLをパースする。なお、パースはレイアウト生成のパラメータである「デバイスURI」の数だけ繰り返す。
S5.レイアウト部13は、スキンMLを取得するためスキンインデックスのURIをLSuIに送信する。
S6.LSuIはレスポンスとしてスキンMLのURIをレイアウト部13に送信する。
S7.レイアウト部13は、リソースMLを取得するためリソースインデックスのURIをLSuIに送信する。
S8.LSuIはレスポンスとしてリソースMLのURIをレイアウト部13に送信する。
S9.レイアウト部13はレイアウトインスタンスを生成する。
S10.レイアウトインスタンスは、各種の設定を行う。
S11.レイアウト部13はイベントを活性化するため、レイアウト生成完了イベントURI、レイアウトインスタンスのURIをシナリオ処理部12に送信する。シナリオ処理部12は、レイアウトインスタンスのURIがレイアウト生成時にパラメータ指定していたURIであれば、画面表示開始イベントを活性化する。なお、ボイス部との同期が必要であれば、シナリオMLの記述において条件判定が行われる。
S12.シナリオ処理部12はイベントを活性化する。すなわち、画面表示を開始する。
S13.シナリオ処理部12はレイアウト部13にイベントを通知する。
S14.レイアウト部13は、グラフィック部16にイベントを通知する。
S15.グラフィック部16は、シーングラフを生成すると共に描画し、実デバイスに描画する。
S1.シナリオ処理部12はレイアウトの生成をレイアウト部13に依頼する。シナリオ処理部12はレイアウト識別名、レイアウトインデックスのURI、デバイスのURI、レイアウトインスタンスのURIを、レイアウト部13に送信する。
S2.レイアウト部13は、レイアウトMLの取得するため、LSuIにレイアウトインデックスのURIを送信する。
S3.LSuIは、レスポンスとしてレイアウトMLのURIをレイアウト部13に送信する。
S4.レイアウト部13は、レイアウトMLをパースする。なお、パースはレイアウト生成のパラメータである「デバイスURI」の数だけ繰り返す。
S5.レイアウト部13は、スキンMLを取得するためスキンインデックスのURIをLSuIに送信する。
S6.LSuIはレスポンスとしてスキンMLのURIをレイアウト部13に送信する。
S7.レイアウト部13は、リソースMLを取得するためリソースインデックスのURIをLSuIに送信する。
S8.LSuIはレスポンスとしてリソースMLのURIをレイアウト部13に送信する。
S9.レイアウト部13はレイアウトインスタンスを生成する。
S10.レイアウトインスタンスは、各種の設定を行う。
S11.レイアウト部13はイベントを活性化するため、レイアウト生成完了イベントURI、レイアウトインスタンスのURIをシナリオ処理部12に送信する。シナリオ処理部12は、レイアウトインスタンスのURIがレイアウト生成時にパラメータ指定していたURIであれば、画面表示開始イベントを活性化する。なお、ボイス部との同期が必要であれば、シナリオMLの記述において条件判定が行われる。
S12.シナリオ処理部12はイベントを活性化する。すなわち、画面表示を開始する。
S13.シナリオ処理部12はレイアウト部13にイベントを通知する。
S14.レイアウト部13は、グラフィック部16にイベントを通知する。
S15.グラフィック部16は、シーングラフを生成すると共に描画し、実デバイスに描画する。
〔ユーザ認証&シナリオ切り替え〕
図28は、ユーザ認証及びシナリオ切り替えにおけるサブシステム間及び外部システムとの基本相互作用を示す図である。
図28は、ユーザ認証及びシナリオ切り替えにおけるサブシステム間及び外部システムとの基本相互作用を示す図である。
シナリオが実行された以後、利用者からタッチパネル等を通じて、ユーザ認証のイベントが発生した場合、このイベントを受けてユーザ切替えのモデルが実行される。
1.タッチパネル上のボタンのタッチ信号がデバイスドライバ等からグラフィック部16に通知される。
2.グラフィック部16はPF依存の形式でレイアウト部13にボタン押下イベントを通知する。
3.レイアウト部13はグラフィック部16からのイベント通知を受けて、マッピングされたユーザ認証イベントを活性化する。
4.シナリオ処理部12にユーザ認証イベントが通知される。この時、イベントがマッピングされていなければレイアウト部12、ボイス部14には通知されない。
5.シナリオ処理部12はユーザ認証イベントを受けて、イベントに対応するアクションとしてcal1Modelアクションを実行する(この場合はLSuIモデルのユーザ切替え処理)。
1.タッチパネル上のボタンのタッチ信号がデバイスドライバ等からグラフィック部16に通知される。
2.グラフィック部16はPF依存の形式でレイアウト部13にボタン押下イベントを通知する。
3.レイアウト部13はグラフィック部16からのイベント通知を受けて、マッピングされたユーザ認証イベントを活性化する。
4.シナリオ処理部12にユーザ認証イベントが通知される。この時、イベントがマッピングされていなければレイアウト部12、ボイス部14には通知されない。
5.シナリオ処理部12はユーザ認証イベントを受けて、イベントに対応するアクションとしてcal1Modelアクションを実行する(この場合はLSuIモデルのユーザ切替え処理)。
LSuIモデルのユーザ切替え処理が実行され、切替わったユーザ用に新しくLSuIインスタンスが生成される(以降の説明では、切り替わる前のLSuIインスタンスを「旧LSuIインスタンス」、切替わった後のLSuIインスタンスを「新LSuIインスタンス」と称する)。
新LSuIインスタンスモデルの処理依頼でシナリオが切替わり、旧LSuIインスタンスが実行したシナリオが破棄され、LSuIインスタンスが破棄される。図29は元のシナリオを破棄する場合のサブシステム間及び外部システムとの基本相互作用を示す図である。
6.LSuIモデルは認証されたユーザ用に新LSuIインスタンスを生成し、シナリオ処理部12、レイアウト部13、ボイス部14へ新LSuIインスタンス向けの初期化要求を送信する。
7.新LSuIインスタンスは認証されたユーザ用に、シナリオ処理部12に対して新しいシナリオを提供する。以降の処理は、シナリオパースと同じであるため省略する。
8.旧LSuIインスタンスは、目身が実行していたシナリオの破棄を、シナリオ処理部12に対して要求する。
9.シナリオ処理部12は、旧LSuIインスタンスのシナリオ破棄要求に対して、レイアウト部13とボイス部14にシナリオ破棄要求を送信する。シナリオ処理部12、レイアウト部13、ボイス部14はそれぞれ指定されたシナリオに関連するリソースを解放する。
10.旧LSuIインスタンスは、シナリオ処理部12、レイアウト部13、ボイス部14に対し、自身が初期化したリソースの解放を依頼する。
6.LSuIモデルは認証されたユーザ用に新LSuIインスタンスを生成し、シナリオ処理部12、レイアウト部13、ボイス部14へ新LSuIインスタンス向けの初期化要求を送信する。
7.新LSuIインスタンスは認証されたユーザ用に、シナリオ処理部12に対して新しいシナリオを提供する。以降の処理は、シナリオパースと同じであるため省略する。
8.旧LSuIインスタンスは、目身が実行していたシナリオの破棄を、シナリオ処理部12に対して要求する。
9.シナリオ処理部12は、旧LSuIインスタンスのシナリオ破棄要求に対して、レイアウト部13とボイス部14にシナリオ破棄要求を送信する。シナリオ処理部12、レイアウト部13、ボイス部14はそれぞれ指定されたシナリオに関連するリソースを解放する。
10.旧LSuIインスタンスは、シナリオ処理部12、レイアウト部13、ボイス部14に対し、自身が初期化したリソースの解放を依頼する。
図30は、ユーザ認証とシナリオ切り替えのシーケンス図を示す。
S1.グラフィック部16は、イベント通知として選択されたボタンをレイアウト部13に送信する。
S2.レイアウト部13は、ユーザ認証イベントの活性化をイベント管理に依頼する。
S3.イベント管理は、ユーザ認証イベントの活性化をシナリオ処理部12に通知する。
S4.シナリオ処理部12は、LSuIから関数(認証、ユーザID等)を呼び出す。LSuIは、ユーザ認証を行い、選択されたユーザ用LSuIインスタンスを生成する。
S5.ユーザ用LSuIインスタンスは、LSuIインスタンスのURIを通知して、シナリオ処理部12に初期化を要求する。
S6.ユーザ用LSuIインスタンスは、LSuIインスタンスのURIを通知して、レイアウト部13に初期化を要求する。
S7.ユーザ用LSuIインスタンスは、LSuIインスタンスのURIを通知して、ボイス部13に初期化を要求する。
S8.ユーザ用LSuIインスタンスは、シナリオMLのURI、各種D.D.のURIを通知して、シナリオ処理部12にシナリオの起動を依頼する。
S9.LSuIモデルのユーザ切り替え処理が実行されると、旧LSuIインスタンスが破棄され、新LSuIインスタンスが生成される。新LSuIインスタンスは、シナリオインスタンスのURIを通知して、シナリオ処理部12にシナリオの破棄を依頼する。
S10.シナリオ処理部12は、シナリオインスタンスのURIを通知して、レイアウト部にシナリオを破棄を依頼する。
S11.シナリオ処理部12は、シナリオインスタンスのURIを通知して、ボイス部にシナリオを破棄を依頼する。
S12.シナリオ処理部12は、レスポンスをLSuIに送信する。
S1.グラフィック部16は、イベント通知として選択されたボタンをレイアウト部13に送信する。
S2.レイアウト部13は、ユーザ認証イベントの活性化をイベント管理に依頼する。
S3.イベント管理は、ユーザ認証イベントの活性化をシナリオ処理部12に通知する。
S4.シナリオ処理部12は、LSuIから関数(認証、ユーザID等)を呼び出す。LSuIは、ユーザ認証を行い、選択されたユーザ用LSuIインスタンスを生成する。
S5.ユーザ用LSuIインスタンスは、LSuIインスタンスのURIを通知して、シナリオ処理部12に初期化を要求する。
S6.ユーザ用LSuIインスタンスは、LSuIインスタンスのURIを通知して、レイアウト部13に初期化を要求する。
S7.ユーザ用LSuIインスタンスは、LSuIインスタンスのURIを通知して、ボイス部13に初期化を要求する。
S8.ユーザ用LSuIインスタンスは、シナリオMLのURI、各種D.D.のURIを通知して、シナリオ処理部12にシナリオの起動を依頼する。
S9.LSuIモデルのユーザ切り替え処理が実行されると、旧LSuIインスタンスが破棄され、新LSuIインスタンスが生成される。新LSuIインスタンスは、シナリオインスタンスのURIを通知して、シナリオ処理部12にシナリオの破棄を依頼する。
S10.シナリオ処理部12は、シナリオインスタンスのURIを通知して、レイアウト部にシナリオを破棄を依頼する。
S11.シナリオ処理部12は、シナリオインスタンスのURIを通知して、ボイス部にシナリオを破棄を依頼する。
S12.シナリオ処理部12は、レスポンスをLSuIに送信する。
〔画面切り替え〕
続いて画面の切替について説明する。画面切替えの相互作用は切替えの方式に応じて以下の4パターンが存在する。
・レイアウト部13の内部で切替えが完結する。
・スキンML(またはリソースML)が切り替わる。
・レイアウトMLが切り替わる。
・シナリオMLが切り替わる。
続いて画面の切替について説明する。画面切替えの相互作用は切替えの方式に応じて以下の4パターンが存在する。
・レイアウト部13の内部で切替えが完結する。
・スキンML(またはリソースML)が切り替わる。
・レイアウトMLが切り替わる。
・シナリオMLが切り替わる。
・レイアウト部13の内部での切り替え
図31は、レイアウト部13の内部で画面切替えが行われる場合の相互作用の概略を示す図である。
1.タッチパネル上のボタンのタッチ信号がデバイスドライバ等からグラフィック部16に通知される。
2.グラフィック部16はプラットフォーム依存の形式でレイアウト部13にボタン押下イベントを通知する。これと同時にグラフィック部16はサウンド部17にボタン押下に対応する効果音の出力を依頼し、サウンド部17はスピーカに効果音を出力する。
3.レイアウト部13はグラフィック部16からのイベント通知を受けて、対応するアクション(この場合は画面切替え)を実行し、切り替えられた画面に対応する描画コマンドを生成し、グラフィック部16に送信する。
4.グラフィック部16は描画コマンドを解釈し、物理デバイスに描画する。
図31は、レイアウト部13の内部で画面切替えが行われる場合の相互作用の概略を示す図である。
1.タッチパネル上のボタンのタッチ信号がデバイスドライバ等からグラフィック部16に通知される。
2.グラフィック部16はプラットフォーム依存の形式でレイアウト部13にボタン押下イベントを通知する。これと同時にグラフィック部16はサウンド部17にボタン押下に対応する効果音の出力を依頼し、サウンド部17はスピーカに効果音を出力する。
3.レイアウト部13はグラフィック部16からのイベント通知を受けて、対応するアクション(この場合は画面切替え)を実行し、切り替えられた画面に対応する描画コマンドを生成し、グラフィック部16に送信する。
4.グラフィック部16は描画コマンドを解釈し、物理デバイスに描画する。
図32は、レイアウト部の内部における画面切り替えのシーケンス図を示す。
S1.タッチパネル上のボタンのタッチ信号がデバイスドライバ等からグラフィック部16に通知される。
S2.グラフィック部16は、プラットフォーム依存の形式でレイアウト部13にボタン押下イベントを通知する。
S3.グラフィック部16は、サウンド部17に効果音の出力を依頼する。
S4.サウンド部17は、スピーカから効果音を出力する。
S5.レイアウト部13は、画面の切り替えを実行する。
S6.レイアウト部13は、切り替えられた描画に対応する描画コマンドをグラフィック部16に送信する。
S7.グラフィック部16は、描画コマンドを解釈しタッチパネルディスプレイを描画する。
S1.タッチパネル上のボタンのタッチ信号がデバイスドライバ等からグラフィック部16に通知される。
S2.グラフィック部16は、プラットフォーム依存の形式でレイアウト部13にボタン押下イベントを通知する。
S3.グラフィック部16は、サウンド部17に効果音の出力を依頼する。
S4.サウンド部17は、スピーカから効果音を出力する。
S5.レイアウト部13は、画面の切り替えを実行する。
S6.レイアウト部13は、切り替えられた描画に対応する描画コマンドをグラフィック部16に送信する。
S7.グラフィック部16は、描画コマンドを解釈しタッチパネルディスプレイを描画する。
・スキンML又はリソースMLの切り替え
図33は、スキンMLが切り替わる相互作用の概略を示す図である。なお、リソースMLの切り替えは、スキンMLと同じであるので説明は省略する。
1.タッチパネル上のボタンのタッチ信号がデバイスドライバ等からグラフィック部16に通知される。
2.グラフィック部16は、PF依存の形式でレイアウト部13にボタン押下イベントを通知する。これと同時にグラフィック部16はサウンド部17にボタン押下に対応する効果音の出力を依頼し、サウンド部17はスピーカに効果音を出力する。
3.レイアウト部13はグラフィック部16からのイベント通知を受けて、対応するアクション(この場合はスキンML切替えイベントの活性化)を実行し、スキンML切り替えイベントを活性化する。
4.活性化されたスキンML切替えイベントがシナリオ処理部12に通知される。
5.シナリオ処理部12はスキンML切替えイベントを受けて、対応するアクション(この場合はモデル呼び出し)を実行し、LSuI(モデル)にスキンML切替え依頼を行う。
6.LSuI(モデル)はスキンML切替え依頼に応じて、レイアウト部13にスキンML切替え依頼メッセージを送信する。
7.レイアウト部13はスキンML切替え依頼メッセージを受信し、LSuIにスキンMLの最適化を依頼する(レイアウトMLに指定されているスキンインデックスとリソースインデックスをLSuIに渡す。)。
8.LSuIはスキンインテックスの中に記述されたスキンMLの内、最適なスキンMLを選定し、そのURIをレイアウト部13に通知する。
9.レイアウト部13はスキンMLを解釈し、レイアウトML中のスタイルにスキンMLの内容を再度充て込む。
10.レイアウト部13は現在表示中の画面に対応する描画コマンドを生成し、グラフィック部16に送信する。
11.グラフィック部16は描画コマンドを解釈し、物理デバイスに描画する。
図33は、スキンMLが切り替わる相互作用の概略を示す図である。なお、リソースMLの切り替えは、スキンMLと同じであるので説明は省略する。
1.タッチパネル上のボタンのタッチ信号がデバイスドライバ等からグラフィック部16に通知される。
2.グラフィック部16は、PF依存の形式でレイアウト部13にボタン押下イベントを通知する。これと同時にグラフィック部16はサウンド部17にボタン押下に対応する効果音の出力を依頼し、サウンド部17はスピーカに効果音を出力する。
3.レイアウト部13はグラフィック部16からのイベント通知を受けて、対応するアクション(この場合はスキンML切替えイベントの活性化)を実行し、スキンML切り替えイベントを活性化する。
4.活性化されたスキンML切替えイベントがシナリオ処理部12に通知される。
5.シナリオ処理部12はスキンML切替えイベントを受けて、対応するアクション(この場合はモデル呼び出し)を実行し、LSuI(モデル)にスキンML切替え依頼を行う。
6.LSuI(モデル)はスキンML切替え依頼に応じて、レイアウト部13にスキンML切替え依頼メッセージを送信する。
7.レイアウト部13はスキンML切替え依頼メッセージを受信し、LSuIにスキンMLの最適化を依頼する(レイアウトMLに指定されているスキンインデックスとリソースインデックスをLSuIに渡す。)。
8.LSuIはスキンインテックスの中に記述されたスキンMLの内、最適なスキンMLを選定し、そのURIをレイアウト部13に通知する。
9.レイアウト部13はスキンMLを解釈し、レイアウトML中のスタイルにスキンMLの内容を再度充て込む。
10.レイアウト部13は現在表示中の画面に対応する描画コマンドを生成し、グラフィック部16に送信する。
11.グラフィック部16は描画コマンドを解釈し、物理デバイスに描画する。
図34は、スキンMLの画面切り替えのシーケンス図を示す。
S1.タッチパネル上のボタンのタッチ信号がデバイスドライバ等からグラフィック部16に入力される。
S2.グラフィック部16は、PF依存の形式でレイアウト部13にボタン押下イベントを通知する。効果音の出力についてはレイアウト内部の画面切り替えと同様である。
S3.レイアウト部13はスキンML切替えイベントを活性化し、シナリオ処理部12に通知する。
S4.シナリオ処理部12はスキンML切替えイベントの通知を受けて、モデル呼び出しを実行する。
S5.また、シナリオ処理部12は、LSuI(モデル)にスキンML切替えを依頼する。
S6.LSuIは、スキンML切替え依頼に応じて、レイアウト部13にスキンML切替え依頼メッセージを送信する。
S7.レイアウト部13は、スキンMLをLSuIに問い合わせる。
S8.LSuIは、スキンMLの内、最適なスキンMLを選定し、そのURIをレイアウト部13に通知する。
S9.レイアウト部13はスキンMLを解釈し、レイアウトML中のスタイルにスキンMLの内容を再度充て込む。
S10.レイアウト部13は現在表示中の画面に対応する描画コマンドを生成し、グラフィック部16に送信する。
S11.グラフィック部16は描画コマンドを解釈し、タッチパネルディスプレイに描画する。
S1.タッチパネル上のボタンのタッチ信号がデバイスドライバ等からグラフィック部16に入力される。
S2.グラフィック部16は、PF依存の形式でレイアウト部13にボタン押下イベントを通知する。効果音の出力についてはレイアウト内部の画面切り替えと同様である。
S3.レイアウト部13はスキンML切替えイベントを活性化し、シナリオ処理部12に通知する。
S4.シナリオ処理部12はスキンML切替えイベントの通知を受けて、モデル呼び出しを実行する。
S5.また、シナリオ処理部12は、LSuI(モデル)にスキンML切替えを依頼する。
S6.LSuIは、スキンML切替え依頼に応じて、レイアウト部13にスキンML切替え依頼メッセージを送信する。
S7.レイアウト部13は、スキンMLをLSuIに問い合わせる。
S8.LSuIは、スキンMLの内、最適なスキンMLを選定し、そのURIをレイアウト部13に通知する。
S9.レイアウト部13はスキンMLを解釈し、レイアウトML中のスタイルにスキンMLの内容を再度充て込む。
S10.レイアウト部13は現在表示中の画面に対応する描画コマンドを生成し、グラフィック部16に送信する。
S11.グラフィック部16は描画コマンドを解釈し、タッチパネルディスプレイに描画する。
・レイアウトMLの切り替え
図35は、レイアウトMLが切り替わる相互作用の概略を示す図である。
1.タッチパネル上のボタンのタッチ信号がデバイスドライバ等からグラフィック部に通知される。
2.グラフィック部16はPF依存の形式でレイアウト部13にボタン押下イベントを通知する。これと同時にグラフィック部16はサウンド部17にボタン押下に対応する効果音の出力を依頼し、サウンド部17はスピーカに効果音を出力する。
3.レイアウト部13はグラフィック部16からのイベント通知を受けて、対応するアクション(この場合はレイアウトML切替えイベントの活性化)を実行し、レイアウトML切替えイベントを活性化する。
4.活性化されたレイアウトML切替えイベントがシナリオ処理部12に通知される。
5.シナリオ処理部12はレイアウトML切替えイベントを受けて、対応するアクション(この場合はモデル呼び出し)を実行し、LSuI(モデル)にレイアウトML切替え依頼を行う。
6.シナリオ処理部12はレイアウト部13にdeleteLayoutメッセージ(指定されたレイアウトインスタンスを削除する要素)を送信する。
7 シナリオ処理部12はレイアウト部13にcreateLayoutメッセージを送信する。
8.deleteLayoutメッセージ受信後の処理は、初期画面表示時のcreateLayoutメッセージ受信後の処理と同じである為、説明は省略する。
9.何らかのタイミングで画面を表示する(切替える)イベントが発生し、表示する画面に対応する描画コマンドを生成し、グラフィック部16に通知する。
10.グラフィック部16は描画コマンドを解釈し、物理デバイスに描画する。
図35は、レイアウトMLが切り替わる相互作用の概略を示す図である。
1.タッチパネル上のボタンのタッチ信号がデバイスドライバ等からグラフィック部に通知される。
2.グラフィック部16はPF依存の形式でレイアウト部13にボタン押下イベントを通知する。これと同時にグラフィック部16はサウンド部17にボタン押下に対応する効果音の出力を依頼し、サウンド部17はスピーカに効果音を出力する。
3.レイアウト部13はグラフィック部16からのイベント通知を受けて、対応するアクション(この場合はレイアウトML切替えイベントの活性化)を実行し、レイアウトML切替えイベントを活性化する。
4.活性化されたレイアウトML切替えイベントがシナリオ処理部12に通知される。
5.シナリオ処理部12はレイアウトML切替えイベントを受けて、対応するアクション(この場合はモデル呼び出し)を実行し、LSuI(モデル)にレイアウトML切替え依頼を行う。
6.シナリオ処理部12はレイアウト部13にdeleteLayoutメッセージ(指定されたレイアウトインスタンスを削除する要素)を送信する。
7 シナリオ処理部12はレイアウト部13にcreateLayoutメッセージを送信する。
8.deleteLayoutメッセージ受信後の処理は、初期画面表示時のcreateLayoutメッセージ受信後の処理と同じである為、説明は省略する。
9.何らかのタイミングで画面を表示する(切替える)イベントが発生し、表示する画面に対応する描画コマンドを生成し、グラフィック部16に通知する。
10.グラフィック部16は描画コマンドを解釈し、物理デバイスに描画する。
図36は、レイアウトMLの切り替えのシーケンス図を示す。
S1.タッチパネル上のボタンのタッチ信号がデバイスドライバ等からグラフィック部16に通知される。
S2.グラフィック部16はプラットフォーム依存の形式でレイアウト部13にボタン押下イベントを通知する。効果音の出力についてはレイアウト内部の画面切り替えと同様である。
S3.レイアウト部13はレイアウトML切替えイベントの活性化を実行し、レイアウトML切替えイベントを活性化する。
S4.シナリオ処理部12は、対応するアクション(この場合はモデル呼び出し)を実行する。
S5.シナリオ処理部12は、LSuIにレイアウトML切替え依頼を行う。
S6.シナリオ処理部12はレイアウト部13にdeleteLayoutメッセージ(指定されたレイアウトインスタンスを削除する要素)を送信する。
S7.レイアウト部13はレイアウトインスタンスを破棄する。
S8.シナリオ処理部12は、レイアウト部13にcreateLayoutメッセージを送信する。
S9.レイアウト部13は、初期画面表示時のcreateLayoutメッセージ受信後の処理と同様に画面を生成する。
S10.レイアウト部13は描画コマンドをグラフィック部16に送信する。
S11.グラフィック部16は、タッチパネルディスプレイに描画する。
S1.タッチパネル上のボタンのタッチ信号がデバイスドライバ等からグラフィック部16に通知される。
S2.グラフィック部16はプラットフォーム依存の形式でレイアウト部13にボタン押下イベントを通知する。効果音の出力についてはレイアウト内部の画面切り替えと同様である。
S3.レイアウト部13はレイアウトML切替えイベントの活性化を実行し、レイアウトML切替えイベントを活性化する。
S4.シナリオ処理部12は、対応するアクション(この場合はモデル呼び出し)を実行する。
S5.シナリオ処理部12は、LSuIにレイアウトML切替え依頼を行う。
S6.シナリオ処理部12はレイアウト部13にdeleteLayoutメッセージ(指定されたレイアウトインスタンスを削除する要素)を送信する。
S7.レイアウト部13はレイアウトインスタンスを破棄する。
S8.シナリオ処理部12は、レイアウト部13にcreateLayoutメッセージを送信する。
S9.レイアウト部13は、初期画面表示時のcreateLayoutメッセージ受信後の処理と同様に画面を生成する。
S10.レイアウト部13は描画コマンドをグラフィック部16に送信する。
S11.グラフィック部16は、タッチパネルディスプレイに描画する。
・シナリオMLの切り替え
図37は、シナリオMLが切り替わる相互作用の概略を示す図である。
1.タッチパネル上のボタンのタッチ信号がデバイストライバ等からグラフィック部16に通知される。
2.グラフィック部16はPF依存の形式でレイアウト部13にボタン押下イベントを通知する。これと同時にグラフィック部16はサウンド部17にボタン押下に対応付ける効果官の出力を依頼し、サウンド部17はスピーカに効果音を出力する。
3.レイアウト部13はグラフィック部16からのイベント通知を受けて、対応するアクション(この場合はシナリオML切替えイベントの活性化)を実行し、シナリオML切替えイベントを活性化する。
4.活性化されたシナリオML切替えイベントがシナリオ処理部12に通知される。
5.シナリオ処理部12はシナリオML切替えイベントを受けて、対応するアクション(この場合はモデル呼び出し)を実行し、LSuI(モデル)にレイアウトML切替え依頼を行う。
6.LSuI(モデル)はシナリオML切替え依頼に応じて、シナリオ処理部12にシナリオML破棄依頼メッセージを送信する。
7.シナリオ処理部12はシナリオML破棄依頼メッセージを受信し、対象のシナリオMLに関する一連のデータを破棄する。
8.LSuI(モデル)はシナリオ処理部12にシナリオMLを提供する。
9.以後は初期画面表示におけるシナリオパース以後の処理と同じであるため、説明は省略する。
図37は、シナリオMLが切り替わる相互作用の概略を示す図である。
1.タッチパネル上のボタンのタッチ信号がデバイストライバ等からグラフィック部16に通知される。
2.グラフィック部16はPF依存の形式でレイアウト部13にボタン押下イベントを通知する。これと同時にグラフィック部16はサウンド部17にボタン押下に対応付ける効果官の出力を依頼し、サウンド部17はスピーカに効果音を出力する。
3.レイアウト部13はグラフィック部16からのイベント通知を受けて、対応するアクション(この場合はシナリオML切替えイベントの活性化)を実行し、シナリオML切替えイベントを活性化する。
4.活性化されたシナリオML切替えイベントがシナリオ処理部12に通知される。
5.シナリオ処理部12はシナリオML切替えイベントを受けて、対応するアクション(この場合はモデル呼び出し)を実行し、LSuI(モデル)にレイアウトML切替え依頼を行う。
6.LSuI(モデル)はシナリオML切替え依頼に応じて、シナリオ処理部12にシナリオML破棄依頼メッセージを送信する。
7.シナリオ処理部12はシナリオML破棄依頼メッセージを受信し、対象のシナリオMLに関する一連のデータを破棄する。
8.LSuI(モデル)はシナリオ処理部12にシナリオMLを提供する。
9.以後は初期画面表示におけるシナリオパース以後の処理と同じであるため、説明は省略する。
図38は、シナリオMLの切り替えのシーケンス図を示す。
S1.タッチパネル上のボタンのタッチ信号がデバイストライバ等からグラフィック部16に入力される。
S2.グラフィック部16はプラットフォーム依存の形式でレイアウト部13にボタン押下イベントを通知する。効果音の出力についてはレイアウト内部の画面切り替えと同様である。
S3.レイアウト部13はグラフィック部16からのイベント通知を受けて、対応するアクション(この場合はシナリオML切替えイベント)を実行する。
S4.レイアウト部13はシナリオML切替えイベントをシナリオ処理部12に通知する。
S5.シナリオ処理部12はシナリオML切替えイベントの通知を受けて、対応するアクション(この場合はモデル呼び出し)を実行する。
S6.シナリオ処理部12は、LSuI(モデル)にレイアウトML切替え依頼を行う。
S7.LSuI(モデル)はシナリオML切替え依頼に応じて、シナリオ処理部12にシナリオML破棄依頼メッセージを送信する。以後は初期画面表示におけるシナリオパース以後の処理と同じであるため、説明は省略する。
S8.シナリオ処理部12は、対象のシナリオMLに関する一連のデータの破棄を、レイアウト部13,ボイス部14に依頼する。
S9.シナリオ処理部12は、破棄が終了したらシナリオ破棄の完了をLSuIに通知する。
S1.タッチパネル上のボタンのタッチ信号がデバイストライバ等からグラフィック部16に入力される。
S2.グラフィック部16はプラットフォーム依存の形式でレイアウト部13にボタン押下イベントを通知する。効果音の出力についてはレイアウト内部の画面切り替えと同様である。
S3.レイアウト部13はグラフィック部16からのイベント通知を受けて、対応するアクション(この場合はシナリオML切替えイベント)を実行する。
S4.レイアウト部13はシナリオML切替えイベントをシナリオ処理部12に通知する。
S5.シナリオ処理部12はシナリオML切替えイベントの通知を受けて、対応するアクション(この場合はモデル呼び出し)を実行する。
S6.シナリオ処理部12は、LSuI(モデル)にレイアウトML切替え依頼を行う。
S7.LSuI(モデル)はシナリオML切替え依頼に応じて、シナリオ処理部12にシナリオML破棄依頼メッセージを送信する。以後は初期画面表示におけるシナリオパース以後の処理と同じであるため、説明は省略する。
S8.シナリオ処理部12は、対象のシナリオMLに関する一連のデータの破棄を、レイアウト部13,ボイス部14に依頼する。
S9.シナリオ処理部12は、破棄が終了したらシナリオ破棄の完了をLSuIに通知する。
〔動画再生〕
続いて動画の再生について説明する。図39は、動画を再生する際の相互作用の概念図を示す。
続いて動画の再生について説明する。図39は、動画を再生する際の相互作用の概念図を示す。
実際に動画を再生する処理の部分以外は、以下に示す点を除き他の相互作用と同様になる。
・シナリオ部に変数としてMMP動画再生用実体のリファレンスを保管する領域を用意する。MMP動画再生用実体を呼び出すと動画が再生されるが、図39ではMMP動画再生用実体をDrawing Adapter D.A.とした。なお、この変数はレイアウト部と共有する。
・MMPのモデル本体に、MMP動画再生用実体のリファレンスを取得する為のメソッド(図39のD.A.生成依頼)が必要となる。
・レイアウト部でMMP動画再生用実体のリファレンスを利用してテクスチャマッピングを行うオブジェクト(図39中の「Canvas」)を用意する。
・シナリオ部に変数としてMMP動画再生用実体のリファレンスを保管する領域を用意する。MMP動画再生用実体を呼び出すと動画が再生されるが、図39ではMMP動画再生用実体をDrawing Adapter D.A.とした。なお、この変数はレイアウト部と共有する。
・MMPのモデル本体に、MMP動画再生用実体のリファレンスを取得する為のメソッド(図39のD.A.生成依頼)が必要となる。
・レイアウト部でMMP動画再生用実体のリファレンスを利用してテクスチャマッピングを行うオブジェクト(図39中の「Canvas」)を用意する。
1.シナリオ処理部12は、コンテンツの記述に従い、モデル(図39ではMMP)にD.A.の生成を依頼する。
2.モデルはMMPの出力する動画の描画用にD.A.を生成する。
3.シナリオ処理部12はコンテンツの記述に従い、モデルに描画開始を依頼する。
4.既にcreatLayoutを実施済みの場合、シナリオ処理部12はMMP用レイアウトの画面表示開始のイベントを活性化する。
5.レイアウト部13は活性化されたイベントを受けて、MMP画面の描画コマンドをグラフィック部に送信する。
6.グラフィック部は描画コマンドを解析し、キャンバスを生成する。
2.モデルはMMPの出力する動画の描画用にD.A.を生成する。
3.シナリオ処理部12はコンテンツの記述に従い、モデルに描画開始を依頼する。
4.既にcreatLayoutを実施済みの場合、シナリオ処理部12はMMP用レイアウトの画面表示開始のイベントを活性化する。
5.レイアウト部13は活性化されたイベントを受けて、MMP画面の描画コマンドをグラフィック部に送信する。
6.グラフィック部は描画コマンドを解析し、キャンバスを生成する。
この時、コンテンツ上でキャンバスに関連付けられているD.A.と実際に関連付けを行う。
7.D.A.は関連付けられたキャンバスの持つ描画領域へMMP出力する動画の映像を描き出す。
8.グラフィック部はキャンバスを含めMMP画面の全ての部品を描画する。
7.D.A.は関連付けられたキャンバスの持つ描画領域へMMP出力する動画の映像を描き出す。
8.グラフィック部はキャンバスを含めMMP画面の全ての部品を描画する。
図40は、動画再生のシーケンス図を示す。
S1.シナリオ処理部12は、モデル(MMP)にD.A.の生成を依頼する。
S2.モデルはMMPの出力する動画の描画用にD.A.を生成する。なお、D.A.のリファレンスは共有変数に格納され、グラフィック部からもモデルからも相互に利用することができる。
S3.シナリオ処理部12はコンテンツの記述に従い、モデルに描画開始を依頼する。
S4.既にcreatLayoutを実施済みの場合、シナリオ処理部12はMMP用レイアウトの画面表示開始のイベントを活性化する。
S5.レイアウト部13は活性化されたイベントを受けて、MMP画面の描画コマンドをグラフィック部に送信する。
S6.グラフィック部は描画コマンドを解析し、キャンバスを生成する。
S7.グラフィック部は、コンテンツ上でキャンバスに関連付けられているD.A.とキャンバスとを実際に関連付けする。
S8.モデル(MMP)は、キャンバスが生成した描画領域のリファレンスを取得する。
S9.グラフィック部はキャンバスを含めMMP画面の全ての部品を描画する。
S10.D.A.は関連付けられたキャンバスの持つ描画領域へMMP出力する動画の映像を描き出す。以降は、順次、描画が更新される。
S1.シナリオ処理部12は、モデル(MMP)にD.A.の生成を依頼する。
S2.モデルはMMPの出力する動画の描画用にD.A.を生成する。なお、D.A.のリファレンスは共有変数に格納され、グラフィック部からもモデルからも相互に利用することができる。
S3.シナリオ処理部12はコンテンツの記述に従い、モデルに描画開始を依頼する。
S4.既にcreatLayoutを実施済みの場合、シナリオ処理部12はMMP用レイアウトの画面表示開始のイベントを活性化する。
S5.レイアウト部13は活性化されたイベントを受けて、MMP画面の描画コマンドをグラフィック部に送信する。
S6.グラフィック部は描画コマンドを解析し、キャンバスを生成する。
S7.グラフィック部は、コンテンツ上でキャンバスに関連付けられているD.A.とキャンバスとを実際に関連付けする。
S8.モデル(MMP)は、キャンバスが生成した描画領域のリファレンスを取得する。
S9.グラフィック部はキャンバスを含めMMP画面の全ての部品を描画する。
S10.D.A.は関連付けられたキャンバスの持つ描画領域へMMP出力する動画の映像を描き出す。以降は、順次、描画が更新される。
〔ソフトウェア構成〕
続いて、ソフトウェア構成について説明する。図41は、3層にサブシステムが配置された概略コンポーネント図を示す。上述したように、本システムはプラットフォーム、機種に依存しない「抽象概念系」と、プラットフォーム、機種に依存する「実体系」と、「抽象概念系」と「実体系」を分離させる為のインターフェイスを規定する「実装系」の3層構造をとる。これに併せてサブシステム単位においても、コンポーネント構成は3層構造となる。なお、「」内がコンポーネント名となる。
続いて、ソフトウェア構成について説明する。図41は、3層にサブシステムが配置された概略コンポーネント図を示す。上述したように、本システムはプラットフォーム、機種に依存しない「抽象概念系」と、プラットフォーム、機種に依存する「実体系」と、「抽象概念系」と「実体系」を分離させる為のインターフェイスを規定する「実装系」の3層構造をとる。これに併せてサブシステム単位においても、コンポーネント構成は3層構造となる。なお、「」内がコンポーネント名となる。
「シナリオ処理部抽象概念系」
・シナリオMLを解釈し、シナリオML内の状態遷移データを、実装系を通じて実体部に渡す。
・各種D.D.の記載内容に応じて、他のサブシステムとシナリオ処理部12、またはシナリオ処理部内で利用するデータとイベントのマッピングを行う。これにより、サブシステム間でのデータの共有と、サブシステム間での処理の同期を行う。
・本システムの外部で発生するイベントメッセーシ(XML)を解釈し、本システム内部に通知する。
・シナリオMLの内部に定義されたデバイスの抽象表現を具象化する。
・シナリオMLを解釈し、シナリオML内の状態遷移データを、実装系を通じて実体部に渡す。
・各種D.D.の記載内容に応じて、他のサブシステムとシナリオ処理部12、またはシナリオ処理部内で利用するデータとイベントのマッピングを行う。これにより、サブシステム間でのデータの共有と、サブシステム間での処理の同期を行う。
・本システムの外部で発生するイベントメッセーシ(XML)を解釈し、本システム内部に通知する。
・シナリオMLの内部に定義されたデバイスの抽象表現を具象化する。
「シナリオ処理部実装系」
・シナリオ処理部の抽象概念系−実体系間のインターフェイスを規定する。
・シナリオ処理部の抽象概念系−実体系間のインターフェイスを規定する。
「シナリオ処理部実体系」
・実装系が規定するインターフェイスによって、シナリオMLに記載されたデータを保持し、実行する役割が課せられるが、実現方式、機能(役割)は規定しない。
・実装系が規定するインターフェイスによって、シナリオMLに記載されたデータを保持し、実行する役割が課せられるが、実現方式、機能(役割)は規定しない。
「レイアウト部抽象概念系」
・レイアウトMLを解釈し、必要とするスキンML、リソースMLを取り込んだ上で、画面の構成、意匠、遷移情報を、実装系を通じて実体系に渡す。
・レイアウトMLを解釈し、必要とするスキンML、リソースMLを取り込んだ上で、画面の構成、意匠、遷移情報を、実装系を通じて実体系に渡す。
「レイアウト部実装系」
・レイアウト部の抽象概念系−実体系間のインターフェイスを規定する。
・レイアウト部の抽象概念系−実体系間のインターフェイスを規定する。
「レイアウト部実体系」
・実装系が規定するインターフェイスによって、画面の構成、意匠、遷移情報を保持し、グラフィックスデバイスに出力する役割が課せられるが、実現方式、機能(役割)は規定しない。
・実装系が規定するインターフェイスによって、画面の構成、意匠、遷移情報を保持し、グラフィックスデバイスに出力する役割が課せられるが、実現方式、機能(役割)は規定しない。
「グラフィック部」
・レイアウト部と連携し、ディスプレイやタッチパネルなどのグラフィックデバイスとやり取りを行うことにより、ユーザと対話を行う。
・レイアウト部と連携し、ディスプレイやタッチパネルなどのグラフィックデバイスとやり取りを行うことにより、ユーザと対話を行う。
「ボイス部抽象概念系」
・ボイスMLを解決し、必要とするスキンML、リソースMLを取り込んだ上で、音声による対話内容、音声意匠を、実装系を通じて実体系に渡す。
・ボイスMLを解決し、必要とするスキンML、リソースMLを取り込んだ上で、音声による対話内容、音声意匠を、実装系を通じて実体系に渡す。
「ボイス部実装系」
・ボイス部の抽象概念系−実体系間のインターフェイスを規定する。
・ボイス部の抽象概念系−実体系間のインターフェイスを規定する。
「ホイス部実体系」
・実装系が規定するインターフェイスによって、音声による対話内容、音声意匠を保持し、サウンドデバイスに出力する役割が課せられるが、実現方式、機能(役割)は規定しない。
・実装系が規定するインターフェイスによって、音声による対話内容、音声意匠を保持し、サウンドデバイスに出力する役割が課せられるが、実現方式、機能(役割)は規定しない。
「サウンド部」
・ボイス部から渡されるデータを保対し、実デバイスと連携することによって保持した内容の音声対話を実現する。また、ナビ等のモデルから直接音声対話を実行することもできる。
〔LSuIの動作〕
以上説明した車載多機能装置によれば、ユーザインターフェイスをユーザやその他のシチュエーションに応じて自由に構成することができる。図42は、車載多機能装置の利用形態の一例を示す図である。
・ボイス部から渡されるデータを保対し、実デバイスと連携することによって保持した内容の音声対話を実現する。また、ナビ等のモデルから直接音声対話を実行することもできる。
〔LSuIの動作〕
以上説明した車載多機能装置によれば、ユーザインターフェイスをユーザやその他のシチュエーションに応じて自由に構成することができる。図42は、車載多機能装置の利用形態の一例を示す図である。
例えば、父、母、子の3人が車両に搭乗するものとして、この3人の個人情報を車載多機能装置に登録する。登録する個人情報は、例えば、趣味、嗜好、性別、年齢、職業、生年月日、星座、血液型、家族構成等である。父は、例えば、ゴルフや株価情報に興味があることが、母は、ショッピングやセキュリティに興味があることが、子はゲーム、映画、音楽、チャットに興味があることが登録される。
また、車載多機能装置には、その時のシチュエーションが情報に応じて自動的に入力される。入力されるシチュエーションは、例えば、日時、曜日、天気、時間帯、目的地、現在地、出発地等である。日時、曜日、時間帯は車載のカレンダや外部から取得でき、天気は天気予報や温度センサ、日射センサ等から取得でき、目的地、現在地、出発地等はカーナビ装置3から取得できる。また、車載多機能装置には、車載しているハードウェアからアクセス可能な周辺のインフラの情報が得られる。例えば、お買い得情報、イベント情報、道路情報等である。
車両に父が搭乗すれば、スマートキーや生体認識情報、ボタンなどによる入力により、車載多機能装置は父が搭乗したことを検知する。そして、LSuIは父の個人情報とシチュエーションに応じて、最適なシナリオを抽出し、プラットフォームに提供する。LSuIは、例えば、夕刻であればその日の株価情報を表示し、また、道路が混み始めたら交通情報を提供するシナリオを実行する。その日、ゴルフのトーナメントがあれば、その結果を表示することもできる。このとき表示される画面は、父の好むレイアウトやフォント、スキンであり、父の好む音声である。
また、車両に、さらに母と子が搭乗するような場合、子がゲームを実行していても、時間帯やシチュエーションによっては、LSuIが近くのレストランやショッピングの情報を表示するシナリオを実行するので、母がレストランを選択できる。なお、シート毎にディスプレイを設けてもよい。
以上のように、本実施の形態の車載多機能装置は、ユーザに対するシステムの振る舞いをメタデータ(XML)で記述したため、ユーザ毎に適切なヒューマンインターフェイスを提供できる。メタデータを補充することで、容易に特徴のあるヒューマンインターフェイスを追加、拡張することができる。
また、MVCアーキテクチャにシナリオという概念を導入したため、ユーザインターフェイスとロジックとを分離できる。メタデータを実行する抽象概念系は、プラットフォームに依存しないため、別の車両への移植等も容易である。
1 車載多機能装置
2 入力装置
3 カーナビ装置
4 ラジオ/テレビユニット
5 メディアプレーヤ
6 表示装置
7 スピーカ
8 通信ユニット
9 記憶装置
10 制御装置
11 LSuI連携部
12 シナリオ処理部
13 レイアウト部
14 ボイス部
15 UIリポジトリ
16 グラフィック部
17 サウンド部
20 UIサーバ
2 入力装置
3 カーナビ装置
4 ラジオ/テレビユニット
5 メディアプレーヤ
6 表示装置
7 スピーカ
8 通信ユニット
9 記憶装置
10 制御装置
11 LSuI連携部
12 シナリオ処理部
13 レイアウト部
14 ボイス部
15 UIリポジトリ
16 グラフィック部
17 サウンド部
20 UIサーバ
Claims (6)
- ユーザインターフェイスを介してユーザからの入力を受け付け、出力装置からユーザにサービスを提供する車載多機能装置において、
メタデータにより記述された前記ユーザインターフェイス及び前記サービスの内容を記憶したメタデータ記憶手段と、
前記メタデータを解釈して前記ユーザインターフェイス及び前記サービスを生成する制御部と、
を有することを特徴とする車載多機能装置。 - 前記メタデータ記憶手段は、前記ユーザインターフェイス又は前記サービスの遷移をメタデータにより記述した遷移情報を記憶している、
ことを特徴とする請求項1記載の車載多機能装置。 - 前記ユーザインターフェイス及び前記サービスの内容を記述したメタデータはそれぞれ独立して変更可能である、
ことを特徴とする請求項1記載の車載多機能装置。 - 更新頻度の高い描画を反映する動画用アダプタを有し、
更新頻度の高い描画がある場合、前記制御部は前記ユーザインターフェイスに描画領域を設け、
前記動画アダプタが前記描画領域に描画する、
ことを特徴とする請求項1ないし3いずれか記載の車載多機能装置。 - 前記ユーザを識別する手段と、道路の交通状況、日時等のシチュエーションを判別する手段とを有し、
前記制御部は、前記ユーザ又は前記シチュエーションに応じて、前記メタデータ記憶手段に記憶された前記メタデータを抽出し、
前記制御部は、前記ユーザ又は前記シチュエーションに応じた前記ユーザインターフェイス又は前記サービスを生成する、
ことを特徴とする請求項1〜4いずれか記載の車載多機能装置。 - ユーザインターフェイス及びサービスの内容がそれぞれ独立に記述されると共に、前記ユーザインターフェイス及び前記サービスの遷移情報を規定したメタデータであって、
コンピュータに、
前記遷移情報に基づき前記ユーザインターフェイス又は前記サービスを生成するステップを、
実行させるためのメタデータ。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2006148680A JP2007317121A (ja) | 2006-05-29 | 2006-05-29 | 車載多機能装置、メタデータ |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2006148680A JP2007317121A (ja) | 2006-05-29 | 2006-05-29 | 車載多機能装置、メタデータ |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2007317121A true JP2007317121A (ja) | 2007-12-06 |
Family
ID=38850900
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2006148680A Pending JP2007317121A (ja) | 2006-05-29 | 2006-05-29 | 車載多機能装置、メタデータ |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2007317121A (ja) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2458755A (en) * | 2009-02-24 | 2009-10-07 | Promethean Ltd | Creating a document using a software application by associating content with a state of the software application |
JP2012240617A (ja) * | 2011-05-23 | 2012-12-10 | Tokai Rika Co Ltd | 検出位置制御装置及び表示制御システム |
US8527144B2 (en) | 2009-10-30 | 2013-09-03 | Denso Corporation | In-vehicle apparatus and method for controlling same |
JP2017049778A (ja) * | 2015-09-01 | 2017-03-09 | 富士ゼロックス株式会社 | 表示方法変更プログラム及び情報処理装置 |
JP2019510404A (ja) * | 2016-02-19 | 2019-04-11 | ジーボ インコーポレーテッドXevo Inc. | 自動車及びクラウドのハイブリッド環境のためのダイナミックなアプリケーションの実行 |
-
2006
- 2006-05-29 JP JP2006148680A patent/JP2007317121A/ja active Pending
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2458755A (en) * | 2009-02-24 | 2009-10-07 | Promethean Ltd | Creating a document using a software application by associating content with a state of the software application |
US8527144B2 (en) | 2009-10-30 | 2013-09-03 | Denso Corporation | In-vehicle apparatus and method for controlling same |
JP2012240617A (ja) * | 2011-05-23 | 2012-12-10 | Tokai Rika Co Ltd | 検出位置制御装置及び表示制御システム |
JP2017049778A (ja) * | 2015-09-01 | 2017-03-09 | 富士ゼロックス株式会社 | 表示方法変更プログラム及び情報処理装置 |
JP2019510404A (ja) * | 2016-02-19 | 2019-04-11 | ジーボ インコーポレーテッドXevo Inc. | 自動車及びクラウドのハイブリッド環境のためのダイナミックなアプリケーションの実行 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2021164631A1 (zh) | 投屏方法及终端设备 | |
US20160189444A1 (en) | System and method to orchestrate in-vehicle experiences to enhance safety | |
JP5205965B2 (ja) | コンピュータシステム、サーバー処理装置、端末装置及び方法 | |
JP2020527753A (ja) | ビューに基づく音声インタラクション方法、装置、サーバ、端末及び媒体 | |
US7478171B2 (en) | Systems and methods for providing dialog localization in a distributed environment and enabling conversational communication using generalized user gestures | |
MX2007015894A (es) | Experiencia de usuario dinamica con objetos ricos en semantica. | |
CN112163086B (zh) | 多意图的识别方法、显示设备 | |
JP2007086859A (ja) | 情報処理装置および表示画面制御方法 | |
WO2020239001A1 (zh) | 一种哼唱识别方法及相关设备 | |
JP2007317121A (ja) | 車載多機能装置、メタデータ | |
CN114064024A (zh) | 微应用的开发方法、装置、设备、存储介质及程序产品 | |
WO2015093425A1 (ja) | 車載端末、コンテンツ表示システム、コンテンツ表示方法、およびコンピュータプログラム製品 | |
CN112182196A (zh) | 应用于多轮对话的服务设备及多轮对话方法 | |
CN116401349A (zh) | 一种多模态回复生成的方法、装置、电子设备及存储介质 | |
WO2022089102A1 (zh) | 一种控制方法、装置及电子设备 | |
CN113066491A (zh) | 显示设备及语音交互方法 | |
US20230139886A1 (en) | Device control method and device | |
CN110908629A (zh) | 电子设备操作方法、装置、电子设备和存储介质 | |
JP2005147925A (ja) | 車載端末装置および車両向け情報提示方法 | |
CN115273848A (zh) | 一种显示设备及显示设备的控制方法 | |
CN113079400A (zh) | 显示设备、服务器及语音交互方法 | |
CN113076427B (zh) | 一种媒资资源搜索方法、显示设备及服务器 | |
CN113207042B (zh) | 一种媒资播放方法及显示设备 | |
CN115019792A (zh) | 显示设备、服务器及语音帮助内容的显示方法 | |
CN116056019B (zh) | 一种用于卡片推荐的短信解析方法及电子设备 |