JP2007128432A - 車両用マルチメディア装置 - Google Patents

Abstract

【課題】アプリケーションの各機能の変更や修正が容易な車両用マルチメディア装置を提供すること。
【解決手段】ナビゲーション機能、音声・動画再生機能等の複数のアプリケーションコンポーネント２５、２４と、複数のアプリケーションコンポーネント２５，２４にそれぞれ対応した機能を提供する機能実装部２２と、複数のアプリケーションコンポーネントの動作状態をそれぞれ制御する制御手段２３とを有し、複数のアプリケーションコンポーネント２５，２４がそれぞれ独立に変更可能であることを特徴とする車両用マルチメディア装置を提供する。
【選択図】図３

Description

本発明は、車両用マルチメディア装置に関し、特に、マルチメディアを構成する複数の機能の実装及び変更が容易な車両用マルチメディア装置に関する。

車両にカーナビゲーションや音楽、動画の再生装置等が一体に搭載されたマルチメディア装置が提供されている。マルチメディア装置が搭載する各機能はアプリケーションソフトウェアをＯＳ上で実行することで提供される（例えば、特許文献１参照。）。

図１は従来のカーナビゲーション装置の機能構成図を示す。ハードウェアとしてのＣＰＵ及びこのＣＰＵで実行されるＯＳを基本プラットフォームとし、Ｊａｖａ仮想マシン（ＶＭ）ソフトウェア（Ｊａｖａは登録商標です。）を組み込むことで、特定のＣＰＵやＯＳに依存せずＪａｖａで開発したプログラムを実行することができる。ＪａｖａＶＭは、Ｊａｖａ標準ＡＰＩを有し、アプリケーション側でこのＡＰＩを呼び出すことで、各種のデータ処理を実行することができる。

ＪａｖａＶＭ上で動作するナビゲーションプログラムはナビゲーションに必要な機能、すなわち経路探索機能、案内支援機能（推奨経路の交差点での案内やカーブ路進入の際の速度警告など）、地図データアクセス機能、画面・地図表示機能がそれぞれ一つのまとまりをなして互いに機能分離され、それぞれ独立に存在している。そして、各機能は、地図データを利用して種々のサービスをユーザに提供するアプリケーションプログラムとＪａｖａ仮想マシンとの間に介在し、アプリケーションプログラムがナビゲーションの基本的な機能を利用する場合には、これらの機能を呼び出して利用する。アプリケーションと各機能との間のインターフェイスは共通化されており、したがってアプリケーションプログラム側では、例えば地図データのフォーマットについての知識がなくても、共通化されたインターフェースを用いることで、容易に地図データを利用することが可能となる。また、ナビゲーションの基本的な機能がこのように分離独立して存在するため、例えば経路探索機能の一部を改良する必要が生じた場合にも、他の機能に影響を与えることなく、経路探索機能のプログラムだけを修正すればよく、短時間に修正することが可能となる。
特開２００１−２３５３３４号公報

しかしながら、図１のような構成では各機能モジュールがインターフェイスと機能実装部とを一体に有しているため、機能実装部のロジックは変更せずにアプリケーションとのインターフェイスのみを修正する場合でも機能モジュール全体を更新する必要が生じる。機能モジュールを更新するような場合、公衆回線を利用して更新モジュールを配信することが多いが、機能モジュール全体を配信すると通信コストが過大となってしまう。
また、ナビゲーションだけでなく音声等の機能を提供するアプリケーションが存在するマルチメディア装置の場合、複数のアプリケーションを制御する機能がないため、複数のアプリケーションを切り替えて実行することができない。

また、複数のアプリケーションは複雑に依存関係を有しており、アプリケーションの追加に対する統一的な仕様も定まっていないため、アプリケーションを追加することが困難である。また、複数のアプリケーションの依存関係によっては、他のアプリケーションの修正も必要となってしまう。

本発明は、上記問題に鑑み、アプリケーションの各機能の変更や修正が容易な車両用マルチメディア装置を提供することを目的とする。

上記問題に鑑み、本発明は、ナビゲーション機能、音声・動画再生機能等の複数のアプリケーションコンポーネントと、複数のアプリケーションコンポーネントにそれぞれ対応した機能を提供する機能実装部と、複数のアプリケーションコンポーネントの動作状態をそれぞれ制御する制御手段（例えば、コンポーネント管理ＦＷ２３）と、を有し、複数のアプリケーションコンポーネントがそれぞれ独立に変更可能である、ことを特徴とする車両用マルチメディア装置を提供する。

本発明によれば、複数のアプリケーションコンポーネントがそれぞれ独立に変更可能であることで、アプリケーションの各機能の変更や修正が容易な車両用マルチメディア装置を提供することができる。なお、特許請求の範囲におけるアプリケーションコンポーネントには、インターフェイスコンポーネントを含めてもよい。

また、本発明の一形態において、機能実装部とアプリケーションコンポーネントが動作するプラットフォームを有し、機能実装部はプラットフォームに依存した言語で記述され、アプリケーションコンポーネントはプラットフォームと異なるプラットフォームでも動作可能な言語で記述されている、ことを特徴とする。

本発明によれば、プラットフォームに依存しない部分はＪａｖａのようなハードウェアに依存しない言語で記述するので種々のプラットフォームで高い互換性を確保でき、プラットフォームに依存する部分はプラットフォームに最適な形態で実装できるので、処理内容や処理速度を向上できる。

また、本発明の一形態において、機能実装部の第１のプラットフォーム（例えば図１０の機能部１００）とアプリケーションコンポーネントの第２のプラットフォーム（例えば図１０のコンポーネント部２００）とがネットワークを介して接続されている、ことを特徴とする。

本発明によれば、機能実装部を別体のプラットフォームに設け、相互にネットワークに接続したので、機能実装部を搭載する自由度が向上する。

また、本発明の一形態において、アプリケーションコンポーネントが機能実装部から機能の提供をうける場合、制御手段はアプリケーションコンポーネントが指定したアプリケーションコンポーネントの動作状態を制御する、ことを特徴とする。

本発明によれば、何らかの機能を実行する場合、制御手段がアプリケーションコンポーネントの動作状態を制御するので、複数のアプリケーションを切り替えて実行することができる。

また、本発明の一形態において、複数のアプリケーションコンポーネントは、該アプリケーションコンポーネントを開始又は停止するための共通のインターフェイスを有し、制御手段は、共通のインターフェイスを介してアプリケーションコンポーネントを制御する、ことを特徴とする。

本発明によれば、制御手段が共通インターフェイスを介して各コンポーネントを制御するので、開発者は機能実装部の構成を知悉していなくても共通のインターフェイスを記述することでアプリケーションを作成できる。

また、本発明の一形態において、動作状態は、アプリケーションコンポーネントの登録状態、開始状態又は停止状態であり、制御手段は、動作状態の遷移を制御することを特徴とする。

本発明によれば、制御手段がアプリケーションコンポーネントの登録状態、開始状態又は停止状態等の動作状態の遷移を制御することができるので、必要なコンポーネントを適宜実行できる。

また、本発明の一形態において、制御手段は、アプリケーションコンポーネントの開始、停止、インストール、アンインストール又はアップデートの少なくとも１つ以上を制御して前記動作状態を遷移させる、ことを特徴とする。

本発明によれば、制御手段が、開始、停止、インストール又はアンインストール等を制御するので、コンポーネントのインストール又はアンインストールを動的に行うことができる。

アプリケーションの各機能の変更や修正が容易な車両用マルチメディア装置を提供することができる。

以下、本発明を実施するための最良の形態について図面に基づき説明する。図２は本実施の形態の車両用マルチメディア装置の構成図を示す。ＧＰＳ１１は、ＧＰＳ衛星からの信号に基づいて車両の現在位置を検出し、制御装置１０に供給する。センサ１２は、車速センサやジャイロセンサなどで構成され、検出値を制御装置１０に供給する。ディスクプレーヤ１３は、DVDやCDのデータを読み出して、映像及び音楽等を出力装置１７から出力する。テレビ／ラジオユニット１４は、ＵＨＦやＶＨＦのテレビ放送電波や地上波デジタル放送を受信して、映像及び音楽等を出力装置１７から出力する。また、ＡＭ、ＦＭ放送や地上波デジタルラジオ放送を受信して、音楽等を出力装置１７から出力する。なお、テレビ／ラジオユニット１０４は準天頂衛星からの電波を受信するものであってもよい。通信ユニットは携帯電話、ＰＨＳ等の移動体通信又は無線ＬＡＮ等により、基地局やアクセスポイントに接続してネットワークから取得した情報を制御装置１０へ供給する。また、ビーコン等により情報センタに蓄積されている渋滞情報その他の交通情報を取得して制御装置１０に供給する。

制御装置１０は、車両用マルチメディア装置を制御するための制御装置であり、ＣＰＵ、ＲＯＭ、ＲＡＭ及びＮＶＲＡＭなどにより構成される。ＣＰＵは記憶装置１６に格納されているＯＳやＪａｖａ ＶＭ、プログラム等を実行してカーナビゲーションなどのマルチメディア機能を実現する。記憶装置１６はハードディスクドライブや書き換え可能な光ディスク、フラッシュメモリ等により構成され、上記のＯＳ等や地図データ、ファイル、プログラムなどを格納している。

出力装置１７はスピーカや液晶ディスプレイなどで構成され、スピーカからナビゲーションシステムの音声案内や音楽等を出力し、ディスプレイに地図データやＤＶＤ，テレビの映像を出力したり、操作するための操作メニューを表示する。操作装置２２は、キーボードやマウスで構成され、ユーザがナビゲーションの目的地や経由地を入力したり、テレビやラジオの選局、カーナビやテレビ等の切替を行うために操作される。マイクロフォンを備えて音声により操作可能であってもよい。

制御装置１０は、記憶装置１６にインストールされた所定のプログラムを実行することで車両用マルチメディア装置の各機能を提供する。図３は本実施の形態の車両マルチメディア装置のシステム構成図の一例を示す。図３に示すように、車両用マルチメディア装置のプログラムはハードウェア及びＯＳからなるプラットフォーム２１上で実行される。

プラットフォーム２１上では、まず、ミドルウェア機能実装部（以下、単に機能実装部という）２２が実行される。機能実装部２２は各車載装置に必要な複数の機能として、ナビゲーション、地図・画面表示、音声認識・合成、音楽・動画再生、通信、その他の機能を実装した複数のミドルウェアモジュールである。ミドルウェアモジュールはプラットフォーム２１のＯＳ等に依存するプログラムである。

複数のインターフェイスコンポーネント（以下、Ｉ／Ｆコンポーネントという）２４は、機能実装部２２が提供する機能を、プラットフォーム２１に依存しない形式で規定された機能に変換して複数のアプリケーションコンポーネントから利用可能にする。

アプリケーションコンポーネント（以下、アプリコンポーネントという）２５は、Ｉ／Ｆコンポーネント２４により変換された機能実装部２２が提供する機能を利用して、アプリケーションコンポーネントが互いに要求する機能やユーザの操作により要求された処理結果を取得する。

なお、図３ではアプリケーションコンポーネント２５は一つに記載されているが、実際にはＩ／Ｆコンポーネント２４の各機能に対応してアプリケーションコンポーネント２５も複数のＩ／Ｆコンポーネントから構成されている。また、後述するようにアプリコンポーネント２５又はＩ／Ｆコンポーネント２４から、コンポーネント管理フレームワーク２３を呼び出す場合、アプリコンポーネント２５とＩ／Ｆコンポーネント２４に明確な区別はない。

コンポーネント管理フレームワーク（以下、コンポーネント管理ＦＷという）２３は、車両用マルチメディア装置が機能実装部２２により提供される機能を利用するための制御手段であり、コンポーネント管理ＦＷ２３はアプリコンポーネント２５に指定された後述のコンポーネントパッケージを呼び出してその動作状態を制御する。なお、コンポーネント管理ＦＷ２３はプラットフォーム２１に依存しないように構成される。

このように、プラットフォームに依存する部分と依存しない部分とを分割し、コンポーネント管理ＦＷ２３がＩ／Ｆコンポーネント２４やアプリコンポーネント２５を管理及び制御することで、機能の追加・更新を容易に行うことができる。

システム構成についてより詳細に説明する。図４は図３のシステム構成からナビゲーションの機能を抽出したシステム構成図である。なお、図４において図３と同一構成部分には同一の符号を付しその説明は省略する。

図４では、ハードウェア及びＯＳからなるプラットフォーム２１については図３と同様であるが、ナビゲーション機能において機能実装部２２に相当するナビ機能実装部２２ａがＯＳ上に記載されている。ナビ機能実装部２２ａはプラットフォーム２１に依存している（してもよい）ので、例えば、Ｃ／Ｃ＋＋などプラットフォーム２１のネイティブコードでプログラムが記述されたものである。

一方、プラットフォーム２１に依存しないコンポーネント管理ＦＷ２３及びＩ／Ｆコンポーネント２４は、例えばＪａｖａ言語でプログラムが記述されることが好適である。したがって、コンポーネント管理ＦＷ２３及びＩ／Ｆコンポーネント２４は、Ｊａｖａ仮想マシン（Ｊａｖａ ＶＭ）上でプログラムを動作させる。Ｊａｖａ言語で記述することで、コンポーネント管理ＦＷ２３及びＩ／Ｆコンポーネント２４はプラットフォーム２１に依存せず、Ｊａｖａ ＶＭが作動する他のプラットフォームでも実行可能となる。なお、ナビゲーション機能における、Ｉ／Ｆコンポーネント２４をナビゲーションＩ／Ｆ２４ａと称する。

ナビアプリコンポーネント２５ａは、「指定地点情報取得依頼」や「指定地点までの経路探索依頼」をナビゲーションＩ／Ｆ２４ａに送出する。また、これらの依頼に応答してナビ機能実装部２２ａが取得した地点情報や経路情報をナビゲーションＩ／Ｆ２４ａから受信する。

ナビ機能実装部２２ａとナビゲーションＩ／Ｆ２４ａはＪＮＩ（Ｊａｖａ Ｎａｔｉｖｅ Ｉｎｔｅｒｆａｃｅ）により接続されている。ＪＮＩは、Ｊａｖａ言語で開発されたプログラム（図４ではナビゲーションＩ／Ｆ２４ａ）から、他の言語で開発されたネイティブコードのプログラム（図４ではナビ機能実装部２２ａ）を利用するためのＡＰＩ（Ａｐｒｉｃａｔｉｏｎ Ｉｎｔｅｒｆａｃｅ）である。この場合、ＪＮＩはＪａｖａとＣ／Ｃ＋＋により作成されている。ナビ機能実装部２２ａとナビゲーションＩ／Ｆ２４ａは、ＪＮＩを介して互いにデータを受け渡すことができる。

ナビ機能実装部２２ａは、ネイティブコードでプログラムされた地点情報提供機能３２と経路探索機能３３を有する。地点情報提供機能３２は、例えばＧＰＳにより得られた緯度経度を住所に変換する機能である。また、経路探索機能３３は地図データに基づき２つの地点の経路を探索する機能である。

ナビゲーションＩ／Ｆ２４ａは、地点情報提供機能３２に対応した地点情報Ｉ／Ｆ３５及び経路探索機能３３に対応した経路探索Ｉ／Ｆ３４を有する。地点情報Ｉ／Ｆ３５は、地点情報提供機能３２により得られた地点情報をプラットフォーム２１に依存しない形式に変換する。同様に、経路探索Ｉ／Ｆ３４は経路探索機能３３により得られた経路情報をプラットフォーム２１に依存しない形式に変換する。

Ｉ／Ｆコンポーネント２４と機能実装部２２は、このように適当な機能単位で分割されている。また、図４では地点情報と経路探索についただけ記載されているがこれら以外でも同様である。

このような構成であれば、プラットフォーム２１に依存する機能実装部２２ではネイティブコードにより高速かつ高機能な機能を提供でき、また、アプリコンポーネント２５やＩ／Ｆコンポーネント２４はプラットフォーム２１に依存しないので、これらの更新や修正を容易に行うことができる。

Ｉ／Ｆコンポーネント２４の動作状態の遷移について説明する。コンポーネント管理ＦＷ２３は、Ｉ／Ｆコンポーネント２４の起動、停止、インストール、アンインストール、アップデート等する場合に、これらの動作状態やその遷移を制御する。

図５は、コンポーネント管理ＦＷ２３が管理するＩ／Ｆコンポーネント２４の動作状態の遷移図を示す。図５では、Ｉ／ＦコンポーネントＦＷ２３が、未登録状態、登録状態、開始状態、停止状態、異常状態、更新中状態、の動作状態を取りうることを示している。

未登録状態とは、複数のうち所定のＩ／Ｆコンポーネントが記憶装置１６に格納された状態やダウンロードされたが未だインストールされていない状態をいう。このような状態は車両の初期状態や所望のＩ／Ｆコンポーネントをダウンロードした場合に生じる。

登録状態とは、車両用マルチメディア装置がインストールされた状態、すなわちアプリコンポーネント２５の要求によりすぐに実行可能な状態をいう。登録状態と未登録状態は双方向に遷移可能である。

開始状態とは、当該Ｉ／Ｆコンポーネントが実行中の状態であることを示す。具体的には後述する共通インターフェイスのＳｔａｒｔ（）が呼び出された状態である。例えば、Ｉ／Ｆコンポーネント２４が機能実装部２２へ処理を依頼し処理結果を待っているような場合である。

停止状態とは、例えば、機能実装部２２の処理結果を受け取りアプリコンポーネント２５へ返した状態、すなわち所望の処理が終了した状態をいう。具体的には後述する共通インターフェイスのＳｔｏｐ（）が呼び出された状態である。

停止状態と開始状態は双方向に遷移可能であり、また、例えば停止状態のＩ／Ｆコンポーネントはアンインストール指示により未登録状態に遷移する。

異常状態とは、開始状態のＩ／Ｆコンポーネントが正常な処理を実行できない場合に生じる状態をいう。例えば、機能実装部２２から処理結果が送られてこない場合（タイムアウト）や動作状態の情報そのものが喪失されるような場合など例外処理が発生した状態である。

更新中状態とは当該Ｉ／Ｆコンポーネントの更新を行っている状態であり、例えば、新しい機能を通信ユニット１５を使用してダウンロードしている状態である。更新中状態に、例えば通信エラー等が生じ正常に更新が完了しない場合は異常状態に遷移する。また、更新中状態と停止状態は双方向に遷移可能である。

コンポーネント管理ＦＷ２３は、各Ｉ／Ｆコンポーネント２４の動作状態を制御し、図５のように動作状態を管理する。例えば、未登録状態のＩ／Ｆコンポーネントにインストール指示を出せばインストールされ登録状態に遷移する。登録状態のＩ／Ｆコンポーネントにアンインストール指示を出せばアンインストールされ未登録状態に遷移する。登録状態のＩ／Ｆコンポーネントに開始指示を出せば開始状態に遷移する。開始状態のＩ／Ｆコンポーネントに停止指示を出せば停止状態に遷移する。停止状態のＩ／Ｆコンポーネントに開始指示を出せば開始状態に遷移する。停止状態のＩ／ＦコンポーネントにＵＰＤＡＴＥ指示を出せば更新中状態に遷移する。更新が正常に終了すれば停止状態に遷移する。また、開始状態または更新中状態に例外処理が発生すれば異常状態に遷移する。

続いて、アプリコンポーネント２５ａ又はナビゲーションＩ／Ｆ２４ａの動作状態の制御について説明する。

アプリコンポーネント２５ａから何らかの処理が依頼された場合、まず、コンポーネント管理ＦＷ２３が処理依頼を受け取る。そして、コンポーネント管理ＦＷ２３は依頼の処理内容に基づいて、複数のＩ／Ｆコンポーネント２４から指定されたＩ／Ｆコンポーネントを指定して、処理をスタートさせる。

図６はＩ／Ｆコンポーネント２４の構成を示すコンポーネントパッケージの一例を示す。なお、上述したようにコンポーネントパッケージはアプリコンポーネント２５にインターフェイスを提供するものであるので、アプリコンポーネント２５と共通に使用でき、コンポーネントパッケージはアプリコンポーネント２５の構成と表現してもよい。

コンポーネントパッケージは、コンポーネント情報ファイル４１、プログラムコード４３及びプログラムが必要とするその他のデータ４２を有している。コンポーネント情報ファイルは、コンポーネント識別子、コンポーネントのバージョン、コンポーネントの作成者などコンポーネントのプロパティを示す情報である。コンポーネント識別子はＩ／Ｆコンポーネント２４において重複しない識別番号である。

また、プログラムコードは必須の構成としてすべてのＩ／Ｆコンポーネント２４に共通となる共通インターフェイス（以下、単に共通Ｉ／Ｆという）であるｓｔａｒｔ（）とｓｔｏｐ（）とを有する。コンポーネント管理ＦＷ２３は、この共通Ｉ／Ｆを呼び出すことでそれぞれのＩ／Ｆコンポーネントの動作状態を制御する。

共通Ｉ／Ｆ（ｓｔａｒｔ（）又はｓｔｏｐ（））はコンポーネント管理ＦＷ２３以外から呼び出すことはできない仕様であるため、各Ｉ／Ｆコンポーネントはコンポーネント管理ＦＷ２３によりその動作状態が制御される。

なお、プログラムコード４３の外部提供機能インターフェイスは、例えば、システムの管理者（製造者）が当該コンポーネントパッケージをコンポーネント管理ＦＷ２３以外から呼び出し可能とするためのインターフェイスであり、任意の構成である。

また、内部処理ロジックは、当該コンポーネントパッケージに特有の機能を記述したプログラムコードであり、ナビゲーションＩ／Ｆ２４ａであれば指定地点情報取得依頼をナビ機能実装部２２ａへ渡すためのプログラムコードとなる。

その他のデータは、当該コンポーネントパッケージで必要なデータやユーザに表示する静止画等が格納される任意の構成である。

コンポーネント管理ＦＷ２３は、図６のようなＩ／Ｆコンポーネント２４の構成に基づきＩ／Ｆコンポーネント２４の動作状態を制御する。

コンポーネント管理ＦＷ２３について説明する。図７はコンポーネント管理ＦＷ２３の構成の一例を示す。コンポーネント管理ＦＷ２３は、呼び出し可能なインターフェイス４４、コンポーネント管理テーブル４５及び機能インターフェイス管理テーブル４６を有する。

呼び出し可能なインターフェイス４４は、アプリコンポーネント２５又はＩ／Ｆコンポーネント２４からコンポーネント管理ＦＷ２３を呼び出すためのインターフェイスである。コンポーネント管理ＦＷ２３は、呼び出されたインターフェイスに応じてＩ／Ｆコンポーネントの動作状態を制御する。
「開始（コンポーネント識別子）」のインターフェイスが呼び出されれば、コンポーネント管理ＦＷ２３はコンポーネント識別子で指定されるコンポーネントパッケージのｓｔａｒｔ（）インターフェイスを呼び出す。

同様に、「停止（コンポーネント識別子）」のインターフェイスが呼び出されれば、コンポーネント管理ＦＷ２３はコンポーネント識別子で指定されるコンポーネントパッケージのｓｔｏｐ（）インターフェイスを呼び出す。

「インストール（コンポーネントパッケージ）」のインターフェイスが呼び出されれば、コンポーネント管理ＦＷ２３は未登録状態にある指定されたコンポーネントパッケージを車両用マルチメディア装置にインストールする。

「アンインストール（コンポーネント識別子）」のインターフェイスが呼び出されれば、コンポーネント管理ＦＷ２３は登録状態にある指定されたコンポーネントパッケージを車両用マルチメディア装置からアンインストールする。

「アプリケーション一覧取得（）」のインターフェイスが呼び出されれば、コンポーネント管理ＦＷ２３は登録されているコンポーネントパッケージの一覧を取得する。

「機能インターフェイス一覧取得（）」のインターフェイスが呼び出されれば、コンポーネント管理ＦＷ２３は経路探索Ｉ／Ｆ３４等の登録されている機能Ｉ／Ｆの一覧を取得する。

「機能インターフェイス登録（機能インターフェイス）」のインターフェイスが呼び出されれば、コンポーネント管理ＦＷ２３は指定された機能Ｉ／Ｆを所定のコンポーネントパッケージに登録する。

「機能インターフェイス登録（機能インターフェイス）」のインターフェイスが呼び出されれば、コンポーネント管理ＦＷ２３は指定された機能Ｉ／Ｆを所定のコンポーネントパッケージに登録する。

「機能インターフェイス取得（インターフェイス名）」のインターフェイスであれば、指定された機能Ｉ／Ｆを例えば通信ユニット１５を使用して取得する。これにより、当該コンポーネントパッケージの動作状態は更新中となる。

コンポーネント管理テーブル４５は、コンポーネント識別子とその動作状態を対応づけて保持するテーブルであり、機能インターフェイス管理テーブル４６は機能インターフェイスとその動作状態を対応づけて保持するテーブルである。なお、機能インターフェイスはＩ／Ｆコンポーネントに含まれる機能であるので、機能インターフェイス管理テーブル４６の構造はコンポーネント管理テーブル４５と同じである。以下では、コンポーネント管理テーブル４５を使用して説明する。

図８はコンポーネント管理テーブル４５の一例を示す。コンポーネント管理テーブル４５では、コンポーネント識別子と対応づけて、バージョン、作成者及び状態が記録されている。バージョンと作成者については上述したコンポーネント情報ファイルと同じである。

図８の状態は各Ｉ／Ｆコンポーネント２４の動作状態を示し、図５の状態遷移図における開始状態、停止状態、登録状態、異常状態、更新中状態の動作状態を取りうる。なお、未登録状態は、コンポーネント管理テーブル４５に登録されてない状態であるので、コンポーネント管理テーブル４５に未登録状態という動作状態はない。

以上の構成を用いて、コンポーネント管理ＦＷ２３がＩ／Ｆコンポーネント２４又はアプリコンポーネント２５の動作状態を制御する処理について図９のフローチャート図に基づき説明する。

まず、アプリコンポーネント２５又はＩ／Ｆコンポーネント２４（以下、単にコンポーネントと称す）がコンポーネント管理ＦＷ２３に機能の要求を出力する（Ｓ１）。例えば、ユーザの操作により又は所定のコンポーネントが他の機能を利用するため、利用したいコンポーネントを指定してコンポーネント管理フレームワーク２３に出力する。

コンポーネント管理ＦＷ２３への出力は図７に示した構成となる。例えば、他のコンポーネントを開始する依頼であれば、「開始（コンポーネント識別子）」のような依頼がコンポーネント管理ＦＷ２３へ出力される。

コンポーネント管理ＦＷ２３は出力の内容を解析し、コンポーネント管理テーブル４５を参照して現在のコンポーネントパッケージの動作状態を検出する（Ｓ２）。コンポーネントからの要求が「開始」であった場合、コンポーネント管理ＦＷ２３は指定されたコンポーネントパッケージが開始状態になりうる登録状態又は停止状態であることを確認する。登録状態又は停止状態でなければエラーをコンポーネントに返してもよいし、当該コンポーネントパッケージを登録状態又は停止状態に制御してもよい。

登録状態又は停止状態であった場合、コンポーネント管理ＦＷ２３は指定されたコンポーネントパッケージのＳｔａｒｔ（）インターフェイスを呼び出す。これにより、開始処理が実行される（Ｓ３）。開始処理されたコンポーネントパッケージはスレッドとして生成され、複数のスレッドが平行して実行される。複数のスレッド同士は、互いに通信をしたり、相手の処理を待ったり待たせたりしながら協調動作をする。具体的には、コンポーネントパッケージの内部処理ロジックが実行され、ＪＮＩを介して機能実装部２２に機能の提供を依頼する。

ついで、コンポーネント管理ＦＷ２３は、コンポーネント管理テーブル４５における当該コンポーネントパッケージの状態を「開始」に更新し、処理が終了する（Ｓ４）。

以上のように本実施の形態の車両用マルチメディア装置は、機能実装部２２とＩ／Ｆコンポーネント２４及びアプリコンポーネント２５とを独立にして、Ｉ／Ｆコンポーネント２４の動作状態を制御するコンポーネント管理ＦＷ２３を設けたことで、所定の機能（例えば、ナビゲーション）のインターフェイスのみを更新するような場合に、Ｉ／Ｆコンポーネント２４のみ（又はアプリコンポーネント２５を含めて）変更すればよいこととなる。したがって、公衆回線を通じてモジュールを更新するような場合に通信コストを低減できる。

Ｉ／Ｆコンポーネント２４及びアプリコンポーネント２５はすべてが共通のインターフェイス（Ｓｔａｒｔ（）、Ｓｔｏｐ（））を有し、コンポーネント管理ＦＷ２３が共通インターフェイスを介して各コンポーネントを制御するので、複数のアプリケーションを切り替えて実行することができる。すなわち、必要なコンポーネントを適宜実行でき、かつ、コンポーネントのインストール又はアンインストールを動的に行うことができる。

プラットフォームに依存しない部分はＪａｖａのようなハードウェアに依存しない言語で記述するので種々のプラットフォームで高い互換性を確保でき、プラットフォームに依存する部分はプラットフォームに最適な形態で実装できるので、処理内容や処理速度を向上できる。すなわち、処理速度の低下を最小限に抑え、異なるプラットフォームにおけるアプリケーションの再利用性を向上できる。

また、開発者は機能実装部２２の構成を知悉していなくてもＩ／Ｆコンポーネント２４及びアプリコンポーネント２５の機能を知っていれば、共通のインターフェイスを記述することでアプリケーションを作成できる。
〔ネットワークを介して機能実装部が接続されている場合〕
本実施の形態のシステム構成は機能実装部２２がネットワークを経由して機能を提供する場合も好適に適用できる。図１０は、プラットフォーム依存部と非依存部がネットワークを介して接続されたシステム構成の一例を示す。なお、図１０において図４と同一構成部分には同一の符号を付しその説明は省略する。

図１０ではＩ／Ｆコンポーネント２４と機能実装部２２が別体のハードウェアに実装されている。Ｉ／Ｆコンポーネント２４が実装されたコンポーネント部２００と機能実装部２２が実装された機能部１００はハードウェア層がネットワーク１５０を介して接続されている。ネットワーク１５０は、車両に分散して存在するＥＣＵを接続する車両内ＬＡＮや車外のサーバとの接続を可能とする無線ＬＡＮやインターネットである。

図１０ではコンポーネント部２００のＯＳ層に分散オブジェクト層２１０が、機能部１００のＯＳ層に分散オブジェクト層１１０がそれぞれ設けられている。分散オブジェクト層２１０及び１１０は、異なるハードウェア間のオブジェクト間でメッセージを交換するための層であり、例えば、ＣＯＲＢＡ（Common Object Request Broker Architecture）である。なお、分散オブジェクト層１１０及び２１０は、異なるハードウェア間の通信を可能とすればよくＤＣＯＭ（Distributed Component Object Model）でもよく、また、ＸＭＬで相互に通信するメッセージを作成すればＳＯＡＰ（Simple Object Access Protocol）を利用してもよい。図１０のシステム構成では、分散オブジェクト層がハードウェア又はプログラム言語の違いを吸収するため、ＪＮＩは備えられていない。

図１０のようなシステム構成であれば、上述した効果に加え、機能部１００とＩ／Ｆコンポーネント部２００とを離して車両に搭載できるので車両の空間を有効に利用できる。

従来のカーナビゲーション装置の機能構成図である。 車両用マルチメディア装置の構成図の一例である。 車両用マルチメディア装置のシステム構成図の一例である。 ナビゲーションの機能を抽出したシステム構成図である。 コンポーネント管理ＦＷが管理するＩ／Ｆコンポーネントの動作状態の遷移図である。 Ｉ／Ｆコンポーネントの構成を示すコンポーネントパッケージの一例である。 コンポーネント管理ＦＷの構成の一例である。 コンポーネント管理テーブルの一例である。 コンポーネント管理ＦＷがＩ／Ｆコンポーネント又はアプリコンポーネントの動作状態を制御する処理のフローチャート図である。 プラットフォーム依存部と非依存部がネットワークを介して接続されたシステム構成の一例である。

符号の説明

１５ 通信ユニット
１６ 記憶装置
２１ プラットフォーム
２２ ミドルウェア機能実装部
２３ コンポーネント管理フレームワーク
２４ インターフェイスコンポーネント
２５ アプリケーションコンポーネント
３１ Ｊａｖａ ＶＭ
１００ 機能部
１１０、２１０ 分散オブジェクト層
１５０ ネットワーク
２００ コンポーネント部

Claims (7)

1. ナビゲーション機能、音声・動画再生機能等の複数のアプリケーションコンポーネントと、
   複数の前記アプリケーションコンポーネントにそれぞれ対応した機能を提供する機能実装部と、
   複数の前記アプリケーションコンポーネントの動作状態をそれぞれ制御する制御手段と、を有し、
   複数の前記アプリケーションコンポーネントがそれぞれ独立に変更可能である、
   ことを特徴とする車両用マルチメディア装置。
2. 前記機能実装部と前記アプリケーションコンポーネントが動作するプラットフォームを有し、
   前記機能実装部は前記プラットフォームに依存した言語で記述され、前記アプリケーションコンポーネントは前記プラットフォームと異なるプラットフォームでも動作可能な言語で記述されている、
   ことを特徴とする請求項１記載の車両用マルチメディア装置。
3. 前記機能実装部の第１のプラットフォームと前記アプリケーションコンポーネントの第２のプラットフォームとがネットワークを介して接続されている、
   ことを特徴とする請求項２記載の車両用マルチメディア装置。
4. 前記アプリケーションコンポーネントが前記機能実装部から前記機能の提供をうける場合、前記制御手段は前記アプリケーションコンポーネントが指定したアプリケーションコンポーネントの動作状態を制御する、
   ことを特徴とする請求項１又は３記載の車両用マルチメディア装置。
5. 複数の前記アプリケーションコンポーネントは、該アプリケーションコンポーネントを開始又は停止するための共通のインターフェイスを有し、
   前記制御手段は、前記共通のインターフェイスを介して前記アプリケーションコンポーネントを制御する、
   ことを特徴とする請求項４記載の車両用マルチメディア装置。
6. 前記動作状態は、前記アプリケーションコンポーネントの登録状態、開始状態又は停止状態、であり、
   前記制御手段は、前記動作状態の遷移を制御する、
   ことを特徴とする請求項５記載の車両用マルチメディア装置。
7. 前記制御手段は、前記アプリケーションコンポーネントの開始、停止、インストール、アンインストール又はアップデートの少なくとも１つ以上を制御して前記動作状態を遷移させる、
   ことを特徴とする請求項５記載の車両用マルチメディア装置。
   
   
   
   
   

Images