JP2013058068A - プラットフォームのプログラムおよびそれを搭載した端末装置 - Google Patents

Abstract

【課題】自動車内で使用することを想定したアプリケーションを開発する際に、安全時・非安全時の差異があっても、開発工数を増やすことなく、また、安全・非安全の判定基準をアプリケーション間で統一することによりドライバの混乱を防ぐ。
【解決手段】端末装置のコンピュータで実行され、自動車での走行中の実行を想定して安全時用リソース３２２と非安全時用リソース３２３とを備えるアプリケーションプログラム３２０のリソースを管理するプラットフォーム３１０のプログラムであって、車両情報を入力する車両情報入力ステップと、車両情報に基づいて、安全・非安全状態を判定する安全判定ステップと、安全判定手段の判定結果に基づいて、安全時用リソースと非安全時用リソースのいずれかを選択するリソース選択ステップとを実行させる。
【選択図】図３

Description

本発明は、自動車で走行中の実行を想定したアプリケーションプログラムに対して、安全に表示・操作することを担保するプラットフォームのプログラムおよびそれを搭載した端末装置に関するものである。

カーナビゲーションシステムやディスプレイ付きカーオーディオセット、ＰＮＤ（Ｐｏｒｔａｂｌｅ Ｎａｖｉｇａｔｉｏｎ Ｄｅｖｉｃｅ）など、予め自動車上での使用を目的とした車載端末が普及している。これらの車載端末においては、走行中の画面表示や操作が安全上の規制の対象となる場合がある。たとえば、日本においては、「画像表示装置の取り扱いに関する自工会ガイドライン」があり、非安全時のテレビ、ビデオ等の映像の表示を禁止することとなっている。また、安全時の複雑な表示や小さいフォントの表示を制限することで、ドライバに対する情報量を抑制する措置がとられている。

従来技術としては、サイドブレーキや車速信号を検知して、安全時と非安全時で表示を変化させるソフトウェアが発案されている（たとえば、特許文献１参照）。

特開２００９−４２１２６号公報

昨今は、先述した車載端末に加えて、タブレット端末やスマートフォンなどのモバイル端末で、ナビゲーションやオーディオ等自動車上での使用が想定されたアプリケーションを搭載することのできる端末が増加している。これらの端末では、アプリケーションプログラムが動作するソフトウェアプラットフォームを構築し、クラスライブラリのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｌａｔｆｏｒｍ Ｉｎｔｅｒｆａｃｅ）を公開することで、さまざまな企業や一般の開発者が端末上で動作するプログラムを開発することができる仕組みを備える場合が多い。

しかし、開発者は、自動車内での使用を想定したアプリケーションを開発する際に、安全時と非安全時で別々に挙動を記述する必要があるため、プログラムステップ数が増大し、そのための開発工数・コストが増大していた。また、ドライバにとっては、安全・非安全の判定基準がアプリケーションによって異なる可能性があるため、ドライバに対し混乱の原因となる可能性があった。

本発明は、上記従来の課題を解決するもので、安全時・非安全時の差異があっても、開発工数を増やすことなく、また、安全・非安全の判定基準をアプリケーション間で統一することができるためドライバの混乱を防ぐことができるプラットフォームのプログラムおよび端末装置を提供することを目的とする。

上記目的を達成するために、本発明のプラットフォームのプログラムは、端末装置のコンピュータで実行され、自動車での走行中の実行を想定して安全時用リソースと非安全時用リソースを備えるアプリケーションプログラムのリソースを管理する。本発明のプラットフォームのプログラムは、車両情報を入力する車両情報入力ステップと、車両情報に基づいて、安全・非安全状態を判定する安全判定ステップと、安全判定手段の判定結果に基づいて、安全時用リソースと非安全時用リソースのいずれかを選択するリソース選択ステップとを端末装置のコンピュータに実行させる。

ここで、車両情報は、車両の現在位置、車速、シフトノブの位置、パーキングブレーキの位置、ステアリングホイールの舵角のうち少なくとも一つを含む。

また、本発明のプラットフォームのプログラムは、記憶媒体に記憶され、端末装置に搭載される。

本発明のプラットフォームのプログラムによれば、アプリケーションプログラムの開発者は、安全時・非安全時の差異によってコードの変更を必要としないため、コードのステップ数およびコード開発者の工数を低減し、デバッグを容易にすることが可能となる。また、安全判定のアルゴリズムをアプリケーション間で統一することができ、ドライバの混乱を防ぐことができる。

本発明の一実施の形態における端末装置のブロック図 図１の制御部１０８の概念構成図 本発明の一実施の形態におけるソフトウェア構成を示す機能ブロック図 安全判定手段３１２が用いる判定基準の一例を示す図で、（ａ）条件が一つの場合の判定基準１の例を示す図、（ｂ）条件が二つの場合の判定基準２の例を示す図 表示部１０１に表示する画面の設計例を示す図で、（ａ）安全時の画面を示す図、（ｂ）非安全時の画面を示す図 リソースＩＤと各リソースの関係の一例示す図 プラットフォーム３１０の動作の一例を示すフローチャート

以下、本発明の一実施の形態に係わる端末装置について図面を参照しながら説明する。図１は、本実施の形態の端末装置１００のブロック図を示している。端末装置１００は、表示部１０１、スピーカ１０２、入力部１０３、記憶部１０４、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）１０５、センサ１０６、通信部１０７、制御部１０８から構成されている。

表示部１０１は、液晶ディスプレイなどで構成され、各種アプリケーションの情報を表示する。スピーカ１０２は、各種アプリケーションの音声情報を出力する。入力部１０３は、表示部１０１上に設置されたタッチパネル等で構成され、ユーザは各種アプリケーションの操作のための入力をすることができる。例えば、アプリケーションが経路案内のためのナビゲーションの場合、ユーザは経路設定のために目的地や経由地等を入力することができる。

記憶部１０４は、ハードディスク、フラッシュメモリ等で構成され、地図データ等のデータを記憶している。ＧＰＳ１０５は、ＧＰＳ衛星からの信号を受信して車両の現在位置を算出し、制御部１０８に供給する。

センサ１０６は、車速センサやジャイロセンサ、車のシフトノブの位置センサ、パーキングブレーキのＯＮ／ＯＦＦセンサ、ステアリングホイールの舵角センサなどで構成され、検出値を制御部１０８に供給する。ここで、端末装置１００は、ＧＰＳ１０５、車速を検出する車速センサとしての加速度センサ、角速度を検出するジャイロセンサなどを内部に含んでいてもよいし、それらセンサが車に搭載されており、コネクタにより有線で、もしくは通信部１０７を介して無線でそれらからの検出信号を取得するような構成にしてもよい。

また、車のシフトノブの位置センサ、パーキングブレーキのＯＮ／ＯＦＦセンサ、ステアリングホイールの舵角センサは車に搭載されており、端末装置１００はそれらセンサからの検出信号をコネクタにより有線で、もしくは通信部１０７を介して無線でそれらからの検出信号を取得する。

通信部１０７は、外部の情報センタに蓄積されている渋滞情報その他の交通情報を取得して制御部１０８に供給する。また、通信部１０７は前述したように車に搭載された各種センサからの検出信号を取得して制御部１０８に供給する。交通情報については通信部１０７は光ビーコンや電波ビーコンで構成することで情報を取得したり、外部のネットワークにインターネット接続することで情報を取得するようにしてもよい。光ビーコンや電波ビーコンについては、端末装置１００の内部に含んでいてもよいし、それらが車に搭載されており、通信部１０７でそれらからの検出信号を取得するような構成にしてもよい。

制御部１０８は、ＣＰＵで構成され、内部のＲＯＭ、ＲＡＭに格納される所定のプログラムを実行することで各種アプリケーションを実行する。例えば、アプリケーションが経路案内のためのナビゲーションの場合、制御部１０８はナビゲーション機能を実行する。制御部１０８は、記憶部１０４にアクセスし、検出された車両の現在位置近傍の地図データを読み出して表示部１０１に出力する。そして、入力部１０３から入力された目的地や経由地は制御部１０８に供給され、制御部１０８は記憶部１０４に記憶されている地図データを読み出して目的地に至る経路を探索する。そして、地図情報等を表示部１０１に出力し、経路案内のための音声情報をスピーカ１０２に出力することで、経路案内を行う。

ここで、スピーカは端末装置１００の内部に含まれていてもよいし、端末装置１００が音声情報のみ出力して、車内に搭載されているスピーカから音声出力する構成としてもよい。

図２は、制御部１０８の概念構成図を示している。制御部１０８は、通常のコンピュータとして構成されており、ＣＰＵ、ＲＯＭ、ＲＡＭ、Ｉ／Ｏ及びこれらの構成を接続するバス（いずれも図示せず）等からなるハードウェア２００と、ソフトウェア３００を備えている。ソフトウェア３００は、プラットフォーム３１０とアプリケーションプログラム３２０によって構成される。また、プラットフォーム３１０は、図１で示した制御部１０８に接続される各種入出力デバイスを制御するデバイスドライバ３３０、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）３４０、標準ＡＰＩ３５０を有する。アプリケーションプログラム３２０側でこの標準ＡＰＩ３５０を呼び出すことで、各種のデータ処理を実行することができる。アプリケーションと各機能との間のインターフェースは共通化されている。従って、例えばアプリケーションプログラム３２０が経路案内のためのナビゲーションの場合、アプリケーションプログラム３２０側では、地図データのフォーマットについての知識がなくても、共通化されたインターフェースを用いることで、容易に地図データを利用することが可能となる。

図３は、本発明の実施の形態のソフトウェア構成の機能ブロック図を示している。プラットフォーム３１０は、車両情報取得手段３１１、安全判定手段３１２、コード実行手段３１３、リソース選択手段３１４から構成されている。

車両情報取得手段３１１は、外部のＧＰＳ１０５、センサ１０６、通信部１０７より、現在の車両情報を入力する。ここで車両情報とは、たとえばＧＰＳ１０５から得られる現在位置データや、センサ１０６あるいは通信部１０７で取得する、車速センサから得られる車速、シフトノブの位置、パーキングブレーキの位置（ＯＮ／ＯＦＦ）、ステアリングホイールの舵角センサから得られる舵角などの情報である。車両情報取得手段３１１は、それら車両情報のうち、少なくとも一つの車両情報を入力する。

安全判定手段３１２は、車両情報取得手段３１１によって取得された車両情報をもとに、その時点時点における表示・操作が安全であるかどうかを、予め定められた論理に基づき判定する。安全判定手段３１２が用いる論理の具体的な例については後述する。

コード実行手段３１３は、アプリケーションプログラム３２０を開始・終了したり、アプリケーションプログラム３２０からの呼び出しに基づいてライブラリの関数を実行する。また、必要に応じてリソース選択手段３１４が選択したリソースを参照する。

リソース選択手段３１４は、安全判定手段３１２の判定結果に基づき、プログラム実行時に表示・音声出力等に用いるリソースを選択する。ここでリソースとは、画像データ、文字列、数値、色データ、アニメーション記述データ、音声ファイル、動画ファイル、プッシュボタンやラジオボタンなどのＧＵＩ部品、そしてそれらのプロパティ（属性）からなる固定のバイナリまたはテキストデータである。リソース選択手段３１４は、安全時は安全時用リソース３２２を選択し、非安全時は非安全時用リソース３２３を選択する。

アプリケーションプログラム３２０は、コンパイル済みコード３２１、安全時用リソース３２２、非安全時用リソース３２３、リソースＩＤリスト３２４とからなる。

コンパイル済みコード３２１は、ソフトウェアの実行順序、関数、変数等が記述されたプログラムの本体である。Ｃ言語、ＪＡＶＡ（登録商標）言語などで記述されたテキストファイルがコンパイラによってコンパイルされているのが通常であるが、インタプリタ言語においてはこの限りではない。

安全時用リソース３２２と非安全時用リソース３２３は、それぞれリソースの集合を格納しており、部品ＩＤと共に画像データ、文字列等が関連づけられて保持されている。そのうち、安全時用リソース３２２は、安全と判定されたときに用いられるリソースであり、非安全時用リソース３２３は非安全と判定されたときに用いられるリソースである。

リソースＩＤリスト３２４は、リソースに含まれる各リソースのＩＤ（識別子）とリソース実体データとの関連を格納している。リソースとリソースＩＤリストの関係、安全時用リソース３２２と非安全時用リソース３２３の相違については、具体的な例をあげて後に詳述する。

なお、本実施の形態では、プラットフォーム３１０とアプリケーションプログラム３２０がどのハードウェアに存在するかを問わない。即ち、プラットフォーム３１０とアプリケーションプログラム３２０は同じハードウェア資源（メモリ）に格納されていても良いし、別のハードウェア資源に格納されていてもよい。別のハードウェア資源に格納されている場合の例として、プラットフォーム３１０が端末装置１００に搭載されていて、アプリケーションプログラム３２０はＳＤカード、ＵＳＢメモリ、ＣＤ、ＤＶＤ等のメディア、またはネットワーク越しの別のストレージに格納されている場合がある。

次に、図３における安全判定手段３１２が用いる判定基準について、図４に示す判定基準の一例を用いて具体的に説明する。判定基準のデータはＲＡＭに格納されており、安全判定手段３１２により適時読み出される。

図４では、判定基準の例を判定基準１と判定基準２に分けて示している。それぞれの判定基準において、“地域”は、この判定基準が適用される地域を表している。上述したように、安全上の規制は国または地域によってそれぞれの交通事情等にあわせて異なっている。そのため、判定基準が適用される地域を示す情報を格納する。たとえば、図４（ａ）の判定基準１では、「日本と米国」に限って適用されることが記されている。図４（ｂ）の判定基準２では、地域にかかわらず「全世界」で適用されることが記されている。地域の判断については、車両情報取得手段３１１により取得される、ＧＰＳ１０５等によって検出された車両の位置データを用いて行う。

図４の判定基準の“条件”は、車両の状況にもとづいて安全状態であると判断するための項目名とその値によって構成される。たとえば、判定基準１では、“条件”は単数であり、その項目名が「パーキングブレーキ」、値が「ＯＮ」となっている。即ち、パーキングブレーキがＯＮの場合に安全であると判断し、それ以外（パーキングブレーキがＯＦＦ）の場合には非安全と判断する。

それに対し、判定基準２では、“条件”は複数であり、“条件１”の項目名が「シフトレバー」で、値が「リバース」になっている。また、“条件２”の項目名が「車速」で、値が「10km/h未満」となっている。ここで、“条件１”と“条件２”の関係は「ＯＲ」となっている。すなわち、シフトレバーがリバースに入っているとき、または、車速が10km/h未満のときである、停車中または徐行中の場合に安全と判定し、それ以外の場合には非安全と判定する。

なお、図４に示した事例では、説明を分かり易くするために表形式で例をあげたが、実際には、地域や実行条件を可変数持たせることも可能となる。これらを可変数にすることで、より複雑できめ細かい安全・非安全判定ができる等の効果が考えられるが、判定アルゴリズムについて本質的な差異はない。

また、判定基準のデータをＸＭＬなどのファイル形式で、通信可能に接続された外部のサーバに持っておき、必要なときにダウンロードするといった構成も可能である。これにより、判定基準のデータを最新の状態に更新することが可能になる。

次に、安全時用リソース３２２と非安全時用リソース３２３の設計例について、図５を用いて説明する。図５（ａ）は表示部１０１に表示する安全時の画面、図５（ｂ）は非安全時の画面の設計例を表している。図５（ａ）において安全時の画面５１０は、動画再生パネル５１１、プッシュボタン５１２、５１３、５１４とからなる。図５（ｂ）において非安全時の画面５２０は、静止画表示パネル５２１、プッシュボタン５２２、５２３、５２４とからなる。

ここで、画面５１０と画面５２０で対応するリソースは同一のリソースＩＤを持っているものとする。たとえば、動画再生パネル５１１と静止画表示パネル５２１は同一リソースＩＤ“Ｐａｎｅｌ０１”、プッシュボタン５１２とプッシュボタン５２２は同一リソースＩＤ“Ｂｕｔｔｏｎ０１”を持っているものとする。図６に、それぞれのリソースＩＤと各リソースの関係を示す。

図６において、リソースＩＤ“Ｐａｎｅｌ０１”に対し、安全時は動画を再生可能なパネル５１１を割り当て、非安全時は静止画のみ表示可能なパネル５２１を割り当てている。これにより、走行中など非安全時には、動画を再生することによって、ドライバの脇見を誘発することがあるため、動画の再生をせず静止画のみの表示にすることができる。アプリ設計者は、動画再生パネル５１１と静止画表示パネル５２１に同一ＩＤを振ることにより、それらを安全時と非安全時で使い分けることを意図することができる。

また、“Ｂｕｔｔｏｎ０１”に対しプッシュボタン５１２とプッシュボタン５２２を割り当てており、安全時のプッシュボタン５１２が押下可能な状態であるのに対し、非安全時のプッシュボタン５２２は押下不可能な状態（淡色表示状態）を設定している。これにより、走行中など非安全時には実行させるべきではない機能に対し、非安全時の実行を制限することができる。

同様に、図５（ａ）の安全時のプッシュボタン５１３が可視状態であるのに対し、図５（ｂ）の非安全時のプッシュボタン５２３を非可視状態（図５（ｂ）の点線は非表示を表している）とすることができる。これにより、走行中など非安全時に重要度の低いボタンを非表示にして画面上の情報量を少なくすることができる。

同様に、図５（ａ）の安全時のプッシュボタン５１４が通常のサイズであるのに対し、図５（ｂ）の非安全時のプッシュボタン５２４をやや大きめのサイズにすることができる。これにより、走行中など非安全時にタッチ操作で押しやすい大きめのボタンを表示することができる。

次に、図３におけるプラットフォーム３１０の主たる動作について、図７のフローチャートを用いて説明する。

プラットフォーム３１０は、起動し初期動作を終えると図７のフローを繰り返すループに入る。ループの最初のステップＳ７０１において、車両情報取得手段３１１は車両情報を取得する。次に、ステップＳ７０２において、安全判定手段３１２は、ステップＳ７０１で取得した車両状況に基づいて、判定基準を参照して安全時か非安全時かを判断する。次に、ステップＳ７０３において、前回の安全・非安全状態と切り替わったどうかを判定する。前回の安全・非安全状態と同じ場合（ステップＳ７０３でＮｏ）は、即座にループを終了する。前回の安全・非安全状態と切り替わった場合（ステップＳ７０３でＹｅｓ）は、ステップＳ７０４に処理を進める。ステップＳ７０４では、リソース選択手段３１４は各アプリケーションのアプリケーションプログラム３２０に対し、判定された安全・非安全状態に応じて、安全時用リソース３２２または非安全時用リソース３２３を選択して再表示するように指示を行い、ループを終了する。

以上、本発明の実施の形態では、安全時および非安全時用のリソースは、リソースIDによって紐づけられており、アプリケーションプログラムの開発者は、安全時・非安全時の差異によって、コードの変更を必要としない。そのため、コードのステップ数およびコード開発者の工数を低減し、デバッグを容易にすることが可能となる。

また、プラットフォーム側で安全・非安全に関する共通の判定基準を用いるため、アプリケーションによって異なる可能性はなくなり、ドライバの混乱を防ぐことができる。

本発明は、上記実施形態の構成に限られるものではなく、特許請求の範囲で示した機能、または上記実施形態の構成が持つ機能が達成できる構成であればどのようなものであっても適用可能である。

また、本発明は、上記実施形態の機能を実現するプログラムを、ネットワークあるいは各種記憶媒体を介して端末装置に供給し、この端末装置のコンピュータが読み出して実行するプログラムも適用範囲である。

以上のように、本発明のプラットフォームのプログラムおよびそれを搭載した端末装置は、アプリケーションプログラムの開発者の工数を削減し、また、利用者の混乱を防ぐことができるという効果を有し、タブレット端末、携帯電話、スマートフォンなどのモバイル端末で、ナビゲーションやオーディオ等自動車上での使用が想定されたアプリケーションプログラムが動作する端末装置等として有効である。

１００ 端末装置
１０１ 表示部
１０２ スピーカ
１０３ 入力部
１０４ 記憶部
１０５ ＧＰＳ
１０６ センサ
１０７ 通信部
１０８ 制御部
２００ ハードウェア
３００ ソフトウェア
３１０ プラットフォーム
３１１ 車両情報取得手段
３１２ 安全判定手段
３１３ コード実行手段
３１４ リソース選択手段
３２０ アプリケーションプログラム
３２１ コンパイル済みコード
３２２ 安全時用リソース
３２３ 非安全時用リソース
３２４ リソースＩＤリスト
３３０ デバイスドライバ
３４０ ＯＳ
３５０ 標準ＡＰＩ

Claims (6)

1. 端末装置のコンピュータで実行され、自動車での走行中の実行を想定して安全時用リソースと非安全時用リソースとを備えるアプリケーションプログラムのリソースを管理するプラットフォームのプログラムであって、予め安全・非安全状態を判定するための判定基準のデータが準備されており、
   車両情報を入力する車両情報入力ステップと、
   前記車両情報と前記判定基準に基づいて、安全・非安全状態を判定する安全判定ステップと、
   前記安全判定手段の判定結果に基づいて、前記安全時用リソースと前記非安全時用リソースのいずれかを選択するリソース選択ステップとを実行させるプラットフォームのプログラム。
2. 前記車両情報は、車両の現在位置、車速、シフトノブの位置、パーキングブレーキの位置、ステアリングホイールの舵角のうち少なくとも一つを含むことを特徴とする請求項１に記載のプラットフォームのプログラム。
3. 前記判定基準のデータは、国あるいは地域ごとに異なる安全判定基準を持つことを特徴とする請求項１に記載のプラットフォームのプログラム。
4. 前記判定基準のデータは外部に接続されたサーバに保管されており、必要なタイミングで前記サーバよりダウンロードされることを特徴とする、請求項１に記載のプラットフォームのプログラム。
5. 請求項１〜４のいずれか一項に記載のプラットフォームのプログラムを格納する記録媒体。
6. 請求項１〜４のいずれか一項に記載のプラットフォームのプログラムを搭載した端末装置。

Images