JP2013152627A - 車載端末、及び、アプリケーション実行環境プログラム - Google Patents

Abstract

【課題】品質を損ねることなく、アプリケーション実行環境上で稼動するアプリケーションの再起動を行うことができる車載端末を提供する。
【解決手段】車載端末に搭載されている追加アプリケーション実行環境は、共有リソース資源の残量が低下すると、追加アプリケーションを再起動させて共有リソース資源を解放するが、この再起動時には、追加アプリケーションに対し、今回の起動が再起動であることが通知される（Ｓ３３５）。このため、起動時に起動アニメーション表示等の起動処理を行う追加アプリケーションは、再起動時には起動処理を省略することができ、車載端末の稼動中に起動アニメーション等が表示され、品質を損ねてしまうといった事態を防ぎつつ、追加アプリケーションを再起動して共有リソース資源を解放することができる。
【選択図】図４

Description

本発明は、アプリケーション実行環境が搭載された車載端末等に関する。

近年のカーナビゲーションなどの車載端末は、携帯電話やスマートフォン等の携帯端末向けに発達した技術を取り込み、各種のウェブブラウザや、Ａｄｏｂｅ社のＦｌａｓｈ（登録商標）や、トヨタ社のＥｎｔｕｎｅのように、外部からダウンロードした追加アプリケーションを実行する環境が搭載されている。現状では、車両メーカや車載端末メーカがアプリケーションプロバイダとして配信する追加アプリケーションを管理し、ユーザへ公開する形態が一般的である。しかし、今後は、携帯電話やスマートフォンで行われているような公開型のアプリケーション配信サービスを通じてユーザが自由に追加アプリケーションを取得し、車載端末上で実行する形態が増えることが予想されている。

このような追加アプリケーションは、各実行環境における動作の互換性が保証されており、複数種類の車載端末上で動作する。しかしながら、各車載端末は、ＣＰＵ性能，グラフィック性能，メモリ量等にハードウェア的な違いがあるため、追加アプリケーションが多数の車載端末上で確実に動作することを保証するのは極めて困難である。

また、多くの場合、アプリケーションプロバイダでの追加アプリケーションの管理は、サーバ側のインフラ整備や最低限の基本動作の確認に限定されており、車載端末上での追加アプリケーションの動作保証は開発元に委ねられている。このため、品質の劣る追加アプリケーションが配信される恐れがあり、特に複数の追加アプリケーションを同時に車載端末上で動作させた場合の品質保証は十分とは言えない。

さらに、従来の車載端末では、一般的な組込みソフトウェアと同様、必要となる全てのリソースが起動時点で予め確保されていた。しかし、車載端末の出荷時点では、搭載される追加アプリケーションの構成が確定しておらず、さらに、追加アプリケーションの中には、車載端末に搭載されていてもほとんど使用されないものも存在する。このため、車載端末に搭載される全ての追加アプリケーションが同時に動作できるだけのリソースを予め用意することは、コスト面で実用的ではない。したがって、各追加アプリケーションは、必要となったタイミングで必要な量のリソースを確保し、不要となったタイミングで確保したリソースを解放する、リソースの動的確保方式を採用するのが一般的である。そして、このようなリソースの動的確保を行う場合、車載端末の出荷段階では、リソース量が十分に足りていることを保証することはできない。

また、車載端末では、ナビゲーション機能や車両状態のインジケータや警告等、車の運転のサポートを確実に行わなければならず、例え低品質の追加アプリケーションがメモリ不足等による異常状態を引き起こした場合でも、このような運転サポート機能を動作させる必要がある。これを実現させるため、追加アプリケーションを運転サポート機能とは別のタスクにより動作させると共に、追加アプリケーションが生成する画像と運転サポート機能の画像を別の表示レイヤにて生成し、ハードウェアによる画像合成をしながら表示を行うという構成が採用されている。これにより、仮に追加アプリケーションがメモリ等のリソース不足を引き起こした場合でも、運転サポート機能による画像表示を維持したまま、追加アプリケーションのタスクだけを再起動してリソースを解放させることができ、運転サポート機能への影響を排除することができる。

しかしながら、追加アプリケーションの再起動により、追加アプリケーションの画像欠け，白抜け，黒抜け等の異常が発生すると共に、初期化により一時的に画像が消えるため、ユーザに対して見苦しさを与えてしまい、車載端末の品質を大きく損ねてしまう。

このような問題の回避策として、追加アプリケーションのリソース使用量を監視すると共に、このリソース使用量が一定値を超えたか否かや、システム全体のリソース残量が一定値を下回るか否かを判定し、リソース不足を事前検出することが提案されている。そして、リソース不足を事前に検出した時点で、正常に生成された画像を固定化した状態で追加アプリケーションを再起動し、再起動の完了後に画像の更新を再開するのである。無論、このときに固定化される画像は追加アプリケーションに対応する表示レイヤに描かれたもののみであり、他の機能に対応する表示レイヤの更新はそのまま継続される。こうすることにより、再起動による画像の乱れを防ぎつつ、追加アプリケーションを起動直後の安定的な状態に戻すことができ、追加アプリケーションの再起動の影響を極小化することができる。

また、これ以外にも、特許文献１には、リソース不足により新たに追加されたアプリケーションを実行できない場合には、実行中のアプリケーションのうち、ユーザに指定されたものを終了させ、新たなアプリケーションの実行に必要なリソースを確保するというリソースの管理方法について記載されている。

また、特許文献２には、アプリケーションが異常終了した場合に、他のアプリケーションと異常終了したアプリケーションとの間の通信を一旦停止し、異常終了したアプリケーションの再起動後に該通信を再開するアプリケーションの復帰方法について記載されている。このような方法によれば、正常なアプリケーションの稼動を停止することなく、異常終了したアプリケーションを復帰させることができる。

特開２００４−６４３３９号公報 特開２００２−３４２０９５号公報

リソース不足を事前に検出した時点で、正常な画像を固定化した状態で追加アプリケーションを再起動し、再起動完了後に画像の更新を再開する上述の方法により、追加アプリケーションの再起動時の画像の乱れを避けることができる。しかしながら、追加アプリケーションの中には、例えば、起動時に００：００を表示すると共に、現在時刻まで高速にカウントアップし、その後通常の時刻表示を行うといった具合に、起動時に起動アニメーションを表示するものがある。そして、このような追加アプリケーションを再起動した場合には、上述の方法を用いたとしても起動アニメーションが表示されてしまい、ユーザに対して見苦しさを与え、車載端末の品質を大きく損ねてしまう。

本願発明は上記課題に鑑みてなされたものであり、品質を損ねることなく、アプリケーション実行環境上で稼動するアプリケーションの再起動を行うことができる車載端末等を提供することを目的とする。

上記課題に鑑みてなされた請求項１に係る発明は、アプリケーションを動作させるアプリケーション実行環境が搭載された車載端末に関するものである。そして、このアプリケーション実行環境は、当該アプリケーション実行環境の起動後にアプリケーションを起動すると共に、予め定められたタイミングでアプリケーションを再起動する起動手段と、起動手段によりアプリケーションが起動される際に、該アプリケーションに対し、該起動が、当該アプリケーション実行環境の起動後、最初に行われたものであるか否かを通知する通知手段と、を備える。

このような構成によれば、アプリケーション実行環境上で動作するアプリケーションは、当該アプリケーションの起動が、アプリケーション実行環境の起動後、最初に行われたものであるか、２回目以降に行われたものであるかを把握することができる。このため、このアプリケーションが起動時に起動アニメーションの表示等といった起動処理を行うよう構成されている場合には、該アプリケーションは、２回目以降の起動時（再起動時）に起動処理を省略することができる。すなわち、リソース残量の低下時等にアプリケーションの再起動が行われたとしても、再起動されるアプリケーションにて起動アニメーションの表示等を省略することで、車載端末の稼動中にもかかわらず突然起動アニメーションが表示されてしまう等の事態を回避することが可能となる。

したがって、ユーザに対し見苦しさを与えてしまうことを防ぐことができ、品質を損ねることなく、アプリケーション実行環境上で稼動するアプリケーションの再起動を行うことができる。

また、通常、アプリケーション実行環境上で動作しているアプリケーションを停止させた場合には、このアプリケーションは確保しているリソースを解放する。しかしながら、品質の低いアプリケーションが車載端末に搭載されてしまう可能性もあり、このようなアプリケーションでは、動作を停止させてもリソースの解放が正常に行われないという可能性もある。

そして、アプリケーションを停止させてもリソースが解放されないという場合には、再起動時等にアプリケーションを停止させる度に利用可能なリソースが減少し、車載端末の動作に異常をきたすおそれがある。

そこで、請求項２に記載の車載端末では、アプリケーション実行環境は、アプリケーションの動作を停止させる停止手段と、停止手段によりアプリケーションの動作が停止された後、該アプリケーションにより確保されたままとなっている、当該アプリケーション実行環境を動作させるコンピュータでの処理に用いられるリソースを解放する解放手段と、を備える。

このような構成によれば、停止されたアプリケーションにより確保されたままとなっているリソースを解放させることができる。このため、仮に不具合を有するアプリケーションが搭載された場合であっても、再起動等により利用可能なリソースが減少してしまうことを防ぐことができる。

また、品質の低いアプリケーションが車載端末に搭載された場合には、このアプリケーションにより必要以上に多量のリソースが消費されてしまうという可能性もある。
そこで、請求項３に記載の車載端末では、アプリケーション実行環境は、リソースの残量の低下を検出する検出手段をさらに備え、停止手段は、検出手段によりリソースの残量の低下が検出された際に、全てのアプリケーションの動作を停止させ、起動手段は、リソースの残量の低下により停止手段により全てのアプリケーションが停止された後のタイミングに、停止されたアプリケーションを再起動する。

このような構成によれば、リソースの残量が低下した際には、全てのアプリケーションが停止されて確保されているリソースが全て解放された後、これらのアプリケーションが再起動される。このため、アプリケーションにより多量のリソースが消費され、アプリケーション実行環境上で動作するアプリケーション以外の他のプログラムにより実現される他の機能に異常をきたすことを防ぐことができる。

なお、請求項４には、請求項１に記載のアプリケーション実行環境として車載端末に搭載されたコンピュータを動作させるアプリケーション実行環境プログラムについて記載されている。

このようなプログラムを、例えば、ＤＶＤ，ＣＤ−ＲＯＭ，ハードディスク等のコンピュータが読みとり可能な非一時的な記録媒体に記録し、必要に応じてコンピュータにロードして起動することにより、請求項１に記載の車載端末として機能させることができる。また、プログラムはネットワークを用いて流通させることも可能であるため、車載端末の機能向上も容易となる。

車載端末のハードウェア構成とソフトウェア構成を示すブロック図である。 表示レイヤの構成についての説明図である。 追加アプリケーション実行処理についてのフローチャートである。 追加アプリケーション実行環境初期化処理についてのフローチャートである。 平均残量算出処理についてのフローチャートである。 車載端末をなすナビゲーション装置における表示画面を示す説明図である。

以下、本発明の実施形態について図面を用いて説明する。なお、本発明の実施の形態は、下記の実施形態に何ら限定されることはなく、本発明の技術的範囲に属する限り種々の形態を採りうる。

［構成の説明］
図１は、本実施形態の車載端末１の構成を示すブロック図である。車載端末１は、ＣＰＵ１１，ＲＡＭ１０，ディスプレイコントローラ１３，グラフィックコントローラ１２を備えており、ＲＡＭ１０上にロードされた車載端末ソフトウェア１００をＣＰＵ１１及びグラフィックコントローラ１２が処理することで動作する。

また、車載端末１は、表示デバイス２０，入力デバイス３０，外部記憶デバイス４０を備えており、自車両に搭載された外部機器として各種のセンサ５０や、他のＥＣＵ６０と接続されている。

車載端末１のＣＰＵ１１は、マルチタスク動作が可能なＯＳをサポートしており、このＣＰＵ１１として、例えば、ＡＲＭ社のＣＰＵコアＡＲＭ１１を利用することができる。
また、ディスプレイコントローラ１３は、図２に記載されているように、複数の表示レイヤ１１１ａ〜１１１ｃに描画された画像を合成し、一つの表示出力画像として表示デバイス２０へ出力する。また、車載端末１のディスプレイコントローラ１３としては、ＣＰＵベンダのカスタムディスプレイコントローラを利用することができる。

また、グラフィックコントローラ１２は、ＣＰＵ１１からの描画指示に従って表示レイヤ１１１上に画像データを生成する。同様の機能はＣＰＵ１１によって実現することもできるが、処理速度を向上するためにグラフィックコントローラ１２を利用する。なお、車載端末１のグラフィックコントローラ１２は、例えば、Ｉｍａｇｉｎａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｉｅｓ社のＰｏｗｅｒＶＲ ＳＧＸ５３５を利用することができる。

また、ＲＡＭ１０には、プログラムやデータが保存され、ＣＰＵ１１は、ＲＡＭ１０に対し、プログラムを処理する時の命令の読込やデータの読み書きを行うことができる。なお、車載端末１のＲＡＭ１０としては、例えば、ＤＤＲ３ ＤＲＡＭを利用することができる。

また、表示デバイス２０は、グラフィックコントローラ１２或いはＣＰＵ１１の処理によって生成され、複数の表示レイヤ１１１に保存されている画像データを合成して一画面に表示される表示出力画像を生成し、表示する機能を有する。なお、車載端末１の表示デバイス２０として、例えば、フルカラーの液晶パネルを利用することができる。

また、入力デバイス３０は、ユーザの操作を検知し、操作信号を出力するよう構成されており、この入力デバイス３０として、例えば、感圧式のタッチパネルや抵抗変化型スイッチを利用することができる。

なお、センサ５０や他のＥＣＵ６０は、車載端末ソフトウェア１００との間で各種データの送受信を行うが、本発明とは特に関連しないため、説明を省略する。
次に、車載端末１に搭載された車載端末ソフトウェア１００について説明する。車載端末ソフトウェア１００は、オペレーティングシステム１１５（以下、ＯＳと略す）等を含むソフトウェアプラットフォーム１１０や、ソフトウェアプラットフォーム１１０上で動作する組込アプリケーション１３０，追加アプリケーション実行環境１２０や、追加アプリケーション実行環境１２０上で動作するプリインストールアプリケーション１４０，追加アプリケーション１５０，１６０等から構成される。

ソフトウェアプラットフォーム１１０は、ＯＳ１１５，入力イベント生成機能１１４，車両通信機能１１６，描画機能１１２，アプリケーション間通信基盤１１３等を有すると共に、表示デバイス２０に出力する画像データを生成するための複数の表示レイヤ１１１を、ＲＡＭ１０上に確保している。

このＯＳ１１５は、ファイルシステムをサポートしており、外部記憶デバイス４０からソフトウェアのプログラムを読み出してＲＡＭ１０上にロードし、ロードしたプログラム実行する機能や、複数のアプリケーションに個別のタスクを割り当てて並列に実行するタスク管理機能等を有している。なお、車載端末１のＯＳ１１５として、例えば、ｅＳＯＬ社のｅＴ−Ｋｅｒｎｅｌ等のＲＴＯＳを利用できる。

また、入力イベント生成機能１１４は、入力デバイス３０から入力された操作信号を検出し、各アプリケーションに対して操作イベントとして通知する。この入力イベント生成機能１１４は、例えば、ＡＤ変換などの定期処理を行う割り込みハンドラと、チャタリング防止などのイベント処理を行う専用タスクを有するソフトウェアモジュールとして構成することができる。

また、車両通信機能１１６は、外部のセンサ５０や他のＥＣＵ６０との間で各種データの送受信を行う。
また、描画機能１１２は、アプリケーションからの指示に従い、各表示レイヤ１１１に対する描画処理を行う。この描画処理においては、表示レイヤ１１１の塗りつぶしや、図形や文字の描画の他、複数ある表示レイヤ１１１間での画像データのコピーや、各表示レイヤ１１１上に描かれた画像を合成する対象とするか否かの設定等が行われる。なお、車載端末１の描画機能１１２として、例えば、ＳＧＸ５３５用のＯｐｅｎＧＬ／ＥＳ１．１ドライバ及びＥＧＬドライバを利用することができる。

また、アプリケーション間通信基盤１１３は、組込アプリケーション１３０と、プリインストールアプリケーション１４０，追加アプリケーション１５０，１６０の三種類のアプリケーションとして動作しているタスク間で、データ交換を行う仕組みを提供する。なお、車載端末１のアプリケーション間通信基盤１１３では、例えば、ＲＡＭ１０に設けられた共有メモリ上にリングバッファを作成し、メッセージをＦＩＦＯ方式で受け渡しする方法や、ＯＳ１１５が提供するタスク間メッセージを使った方法を利用することが考えられる。

また、組込アプリケーション１３０は、重要度の高い機能を実現するアプリケーションであり、プリインストールアプリケーション１４０，追加アプリケーション１５０，１６０は、付加的な機能やサービスを追加するアプリケーションである。なお、プリインストールアプリケーション１４０は、追加アプリケーション１５０，１６０の一種だが、車載端末１の出荷時点から搭載されており、ユーザが後から追加する追加アプリケーション１５０，１６０と区別する。また、組込アプリケーション１３０，プリインストールアプリケーション１４０，追加アプリケーション１５０，１６０は、システムの仕様に応じて搭載するものであり、何れのアプリケーションも搭載しないことも考えられるし、複数搭載することも考えられる。

また、通常、各組込アプリケーション１３０には一つ以上のタスクが設けられ、これらは並行して動作することが可能となっている。なお、車載端末１の組込アプリケーション１３０としては、例えば、ナビゲーション機能を実現するための地図描画アプリ，ルート探索アプリ，目的地検索アプリ等が考えられる。

また、追加アプリケーション実行環境１２０は、追加アプリケーションプログラム処理機能（追加アプリ処理機能とも記載）１２１，アプリケーション画面生成機能１２４，アプリケーション間通信機能１２５，入力イベント処理機能１２６，リソース監視機能１２２等を有し、アプリケーション間通信機能１２５や入力イベント処理機能１２６にて取得されたデータ等を保存するためのデータバッファ１２３を、ＲＡＭ１０上に確保している。

この追加アプリ処理機能１２１は、プリインストールアプリケーション１４０及び追加アプリケーション１５０，１６０のプログラムを解釈して実行する。すなわち、プリインストールアプリケーション１４０や追加アプリケーション１５０，１６０（以後、単に追加アプリケーション等とも記載）は、スクリプト言語や中間命令コードにより動作が記述されたプログラムとして構成されており、追加アプリ処理機能１２１は、このスクリプト言語や中間命令コードを解釈するインタプリタを備え、スクリプト言語等に従って処理を行う。

なお、これ以外にも、追加アプリ処理機能１２１は、予めスクリプト言語や中間命令コードをコンパイラにより機械語命令コードに変換し、該機械語命令コードに従って処理を行うといった構成であっても良い。

また、この処理の中に描画処理が含まれている場合、追加アプリ処理機能１２１は、アプリケーション画面生成機能１２４から取得した描画用フレームバッファに対して描画処理を行う。

また、追加アプリ処理機能１２１は、アプリケーション間通信機能１２５や入力イベント処理機能１２６により受信データやユーザ操作のイベントを取得し、追加アプリケーション等のプログラムに従い対応するイベント処理を行う。さらに、追加アプリケーション等での処理に他のアプリケーションへのデータ送信処理が含まれている場合には、アプリケーション間通信機能１２５により、該アプリケーションにデータ送信を行う。

また、この追加アプリ処理機能１２１にて、共有メモリやセマフォ等の共有リソース資源の確保，解放がなされる場合があるが、リソース監視機能１２２は、ソフトウェアプラットフォーム１１０にアクセスすることで、追加アプリ処理機能１２１での共有リソース資源の消費量を逐次監視するよう構成されている。

なお、車載端末１の追加アプリ処理機能１２１としては、例えば、Ａｄｏｂｅ Ｆｌａｓｈ Ｌｉｔｅ（登録商標）等のスクリプト処理機能を持ったリッチアニメーション実行環境を利用することができる。

また、アプリケーション画面生成機能１２４は、２枚以上のフレームバッファをソフトウェアプラットフォーム１１０の描画機能１１２から取得する。そして、そのうちの一枚のフレームバッファを描画用フレームバッファとして追加アプリ処理機能１２１に渡し、追加アプリケーション等に対し、該描画用フレームバッファを用いた描画処理を行わせる。また、他のもう一枚のフレームバッファを、表示用フレームバッファとして対応する表示レイヤ１１１に設定することで、追加アプリケーション等での描画処理中に、表示デバイス２０の画面に乱れが生じないようにする。このように、車載端末１のアプリケーション画面生成機能１２４としては、描画用フレームバッファと表示用フレームバッファを交互に入れ替えるダブルバッファ方式を利用することができる。

また、アプリケーション間通信機能１２５は、ソフトウェアプラットフォーム１１０のアプリケーション間通信基盤１１３を用いて、組込アプリケーション１３０，他のＥＣＵ６０，センサ５０と、追加アプリケーション等との間のタスク間通信を行う。

このタスク間通信における受信処理は、追加アプリ処理機能１２１の動作とは非同期で行われる。すなわち、タスク間通信の受信データは、データバッファ１２３上に受信順序及び通信相手が分かる状態で保存され、新たな受信データの受信時に受信状態が「受信済み」に設定される。そして、追加アプリ処理機能１２１は、受信状態が「受信済み」となっている場合には、受信データをデータバッファ１２３から読み出すと共に、読み出し済の受信データをデータバッファ１２３上から削除し、全ての受信データを読み出すと、受信状態を「未受信」に設定する。また、読み出された受信データは追加アプリ処理機能１２１に提供され、追加アプリケーション等にて、受信データに応じた処理が行われる。

なお、車載端末１のアプリケーション間通信機能１２５としては、例えば、ＲＡＭ１０に設けられた共有メモリ上のリングバッファとしてデータバッファ１２３を構築すると共に、ＯＳ１１５が提供するタスク間共有リソース資源の一種であるイベントフラグによって、受信状態を設定することが考えられる。

また、入力イベント処理機能１２６は、ソフトウェアプラットフォーム１１０の入力イベント生成機能１１４から操作イベントを受け取り、プリインストールアプリケーション１４０及び追加アプリケーション１５０，１６０に対応する操作イベント処理を実行する。

この入力イベント処理機能１２６における操作イベント処理は、追加アプリ処理機能１２１の動作とは非同期で行われる。すなわち、入力イベント処理機能１２６は、操作イベントをソフトウェアプラットフォーム１１０から取得すると、該操作イベントをデータバッファ１２３上に保存し、操作イベント状態を「操作有り」に設定する。一方、追加アプリ処理機能１２１は、操作イベント状態が「操作有り」となっている場合には、操作イベントをデータバッファ１２３から読み出すと共に、読み出し済の操作イベントをデータバッファ１２３上から削除し、全ての操作イベントを読み出すと、操作イベント状態を「操作無し」に設定する。また、読み出された操作イベントは追加アプリ処理機能１２１に提供され、追加アプリケーション等では、操作イベントに応じた処理が行われる。

なお、車載端末１の入力イベント処理機能１２６としては、例えば、ＲＡＭ１０に設けられた共有メモリ上のＦＩＦＯバッファとしてデータバッファ１２３を構築すると共に、ＯＳ１１５が提供するタスク間共有リソース資源の一種であるイベントフラグによって、操作イベント状態を設定することが考えられる。

また、リソース監視機能１２２は、ソフトウェアプラットフォーム１１０が提供する共有リソース資源の残量と、追加アプリケーション実行環境１２０が利用している共有リソース資源の消費量を監視する。ここで、追加アプリケーション実行環境１２０での消費量を監視する共有リソース資源とは、例えば、ＯＳ１１５が提供する共有メモリや、セマフォ，イベントフラグ等のタスク間同期機構資源である。また、残量を監視する共有リソース資源は、消費量を監視する共有リソース資源に加えて、例えば、描画機能１１２が提供するフレームバッファや、ＯＳ１１５が提供するファイル処理用のファイルディスクリプタ等が考えられる。

また、リソース監視機能１２２は、各追加アプリケーション等により確保されている共有リソース資源のＩＤやアドレス等を監視しており、追加アプリケーション等により共有リソース資源の解放が適切に行われない場合には、該共有リソース資源を強制的に解放する。

［動作の説明］
次に、車載端末１の動作について説明する。車載端末１は、インターネット等から入手され、インストールされた追加アプリケーションを、追加アプリケーション実行環境１２０上で動作させることができるが、品質の悪い追加アプリケーションがインストールされる可能性もある。そして、このような場合には、追加アプリケーションにより多量の共有リソース資源が確保されてしまい、共有リソース資源が不足し、組込アプリケーション１３０等の異常を引き起こす可能性がある。

これに対し、車載端末１では、このような場合にも組込アプリケーション１３０等を正常に動作させるため、共有リソース資源の残量が低下した場合には追加アプリケーションやプリインストールアプリケーション（追加アプリケーション等とも記載）を再起動し、追加アプリケーションにより確保されている共有リソース資源を解放する。

また、追加アプリケーション等の中には、起動時に起動アニメーションの表示等といった起動処理を行うものがあり、車載端末１の稼動中、このような追加アプリケーション等を再起動することで起動アニメーションの表示等がなされると、ユーザに見苦しさを与えてしまう。これに対し、車載端末１は、追加アプリケーション等の起動時に、追加アプリケーション等に対し初回起動であるか再起動であるかを通知し、再起動時には追加アプリケーション等にて起動処理を省略することができるよう構成されている。

以下では、車載端末１における追加アプリケーション等の再起動や初期化について、詳しく説明する。なお、以下の説明では、車載端末ソフトウェア１００にて実行される各種処理について記載されているが、これは、車載端末ソフトウェア１００に従って動作するＣＰＵ１１により実行される処理であることは、言うまでも無い。

（１）追加アプリケーション実行処理について
まず、追加アプリケーション等を動作させると共に、共有リソース資源の残量が低下した際に、追加アプリケーション等を再起動する追加アプリケーション実行処理について、図３に記載のフローチャートを用いて説明する。なお、本処理は、追加アプリケーション実行環境１２０にて実行される処理であり、車載端末１の起動後、最初に追加アプリケーション等が起動される際に開始される。

Ｓ２０５では、追加アプリケーション実行環境１２０を初期化し、追加アプリケーション等を起動する追加アプリケーション実行環境初期化処理が行われる。
続くＳ２１０では、共有リソース資源の残量が検出されると共に、該残量と予め定められた閾値とが比較され、共有リソース資源の低下が検出される。具体的には、ソフトウェアプラットフォーム１１０により提供される平均残量算出処理（詳細は後述する）により算出された、瞬間的な共有リソース資源の残量Ｒ_siと、共有リソース資源の残量の平均値Ｒ_saが読み出される。また、各追加アプリケーション等の実行時に算出された、追加アプリケーション実行環境１２０における共有リソース資源の消費量Ｒ_aiが読み出される。

また、閾値として、瞬間残量限界Ｇ_siと、平均残量限界Ｇ_saと、瞬間アプリ最大リソース限界Ｇ_aiとが定義されており、Ｇ_si≧Ｒ_si，Ｇ_sa≧Ｒ_sa，Ｇ_ai＜Ｒ_aiの３条件のうちのいずれかが成立したか否かが判定される。

そして、続くＳ２１５では、上記３条件のうちのいずれかが成立した場合には、共有リソース資源の残量が低下したとみなし（Ｓ２１５：Ｙｅｓ）、追加アプリケーション等の再起動を行うべくＳ２４０に処理が移行される。一方、いずれの条件も成立していない場合には（Ｓ２１５：Ｎｏ）、Ｓ２２０に処理が移行される。

なお、上記３条件のうちの一つ（或いは二つ）について成立の有無を判定することで、共有リソース資源の低下を検出しても良い。また、Ｒ_si，Ｒ_sa，Ｒ_aiを複数回にわたり検出すると共に平均値を算出し、該平均値に基づき共有リソース資源の低下を検出しても良い。

Ｓ２４０では、追加アプリ処理機能１２１が停止され、追加アプリ処理機能１２１や追加アプリケーション等にて確保されている共有リソース資源が解放される。なお、ここでは、アプリケーション画面生成機能１２４等の他の機能は停止されず、表示用フレームバッファや、受信データ登録用のデータバッファ１２３や、操作イベント登録用のデータバッファ１２３は、そのままの状態が保持される。また、ソフトウェアプラットフォーム１１０は、追加アプリ処理機能１２１が停止されても動作を継続し、対応する表示レイヤ１１１への画像の描画や表示デバイス２０での画像表示は継続して行われる。

このため、追加アプリケーション実行環境１２０に対応する表示レイヤ１１１は状態が維持されるが、組込アプリケーション１３０に対応する表示レイヤ１１１では引き続き描画が行われる。したがって、追加アプリケーション等により生成され、追加アプリ処理機能１２１が停止された時点で表示デバイス２０に表示されている画像のみが固定化された状態となり、他の画像の更新は継続される。

そして、追加アプリ処理機能１２１が停止された段階で、追加アプリケーションの不具合等により解放されていない共有リソース資源が存在している場合、リソース監視機能１２２による共有解放漏れ共有リソース資源強制解放処理にて強制的に共有リソース資源の解放が行われ（Ｓ２４５）、その後、Ｓ２０５に処理が移行される。ただし、再起動時にも動作を継続するリソース監視機能１２２，アプリケーション画面生成機能１２４，アプリケーション間通信機能１２５，入力イベント処理機能１２６が使用している共有リソース資源については、強制解放の対象とはならない。

一方、共有リソース資源の残量が低下していない場合には、追加アプリケーション等の再起動は行われず、アプリケーション間通信データ読出処理（Ｓ２２０）や、入力イベント読出処理（Ｓ２２５）により、各追加アプリケーション等のイベント処理が実行され、追加アプリケーションプログラム実行処理（Ｓ２３０）により、各追加アプリケーション等におけるその他の定期処理やタイマ処理が実行される。なお、これらの処理には、同期的に実行されるアプリケーション間通信のデータ送信処理や、描画用フレームバッファに対する描画処理が含まれる。

そして、最終的に、追加アプリケーション画面生成処理（Ｓ２３５）にて、描画用フレームバッファと表示用フレームバッファの入れ替えが実施され、追加アプリケーション実行環境１２０に対応する表示レイヤ１１１の画像更新が行われ、その後、再度Ｓ２１０に処理が移行される。

なお、これらの処理において、追加アプリケーション等による共有リソース資源の確保，解放が行われた場合には、その共有リソース資源の量から、追加アプリケーション実行環境１２０における共有リソース資源の消費量Ｒ_aiが算出される。車載端末１では、例えば追加アプリケーション実行環境１２０にて共有リソース資源の確保が行われた場合、その確保量Ｒ_inを共有リソース資源の消費量Ｒ_aiに加算することで、Ｒ_aiを算出することが考えられる。また、追加アプリケーション実行環境１２０にて共有リソース資源の解放が行われた場合、その解放量Ｒ_deを共有リソース資源の消費量Ｒ_aiから減算することで、Ｒ_aiを算出することが考えられる。

（２）追加アプリケーション実行環境初期化処理について
次に、追加アプリケーション実行環境１２０を初期化し、追加アプリケーション等を起動する追加アプリケーション実行環境初期化処理について、図４に記載のフローチャートを用いて説明する。なお、本処理は、追加アプリケーション実行環境１２０にて実行される処理であり、追加アプリケーション実行処理からコールされるサブルーチンとして構成されている。

Ｓ３０５では、追加アプリケーション等の起動が、車載端末１の起動後、初回であるか否か（今回実行される追加アプリケーション実行環境初期化処理が、追加アプリケーション実行処理の開始後、最初に実行されるものであるか否か）を判定する。そして、肯定判定が得られた場合には（Ｓ３０５：Ｙｅｓ）、Ｓ３１０に処理を移行し、否定判定が得られた場合には（Ｓ３０５：Ｎｏ）、Ｓ３３５に処理を移行する。

Ｓ３１０では、リソース監視機能１２２の初期化（追加アプリケーション実行環境１２０や追加アプリケーション等にて確保されている共有リソース資源の消費量等を示す変数の初期化等）が行われる。

続くＳ３１５では、追加アプリ処理機能１２１において、追加アプリケーション等を動作させるために必要な共有リソース資源の確保や内部データの初期化等が行われ、さらに、追加アプリケーション等の起動が初回の起動であることを示すよう変数が設定される。追加アプリ処理機能１２１は、初回の起動か否かを通知するインターフェースを追加アプリケーション等に提供しており、追加アプリケーション等は、初回の起動であるか否かに応じて、起動時に異なる処理を行うことができる。

その後、Ｓ３２０にてアプリケーション画面生成機能１２４の初期化（ソフトウェアプラットフォーム１１０の描画機能１１２からのフレームバッファの取得や、フレームバッファの初期化等）が行われ、Ｓ３２５に処理が移行される。

Ｓ３２５では、アプリケーション間通信機能１２５の初期化（アプリケーション間通信基盤１１３への受信処理ハンドラの登録や、受信データ登録用のデータバッファ１２３の初期化や、受信状態の初期化等）が行われ、Ｓ３３０に処理が移行される。

Ｓ３３０では、入力イベント処理機能１２６の初期化（入力イベント生成機能１１４への操作イベント処理ハンドラの登録や、操作イベント登録用のデータバッファ１２３の初期化や、操作イベント状態の初期化等）が行われ、Ｓ３４０に処理が移行される。

一方、追加アプリケーション等の起動が初回でない場合に移行するＳ３３５では、追加アプリ処理機能１２１において、追加アプリケーション等を動作させるために必要な共有リソース資源の確保や内部データの初期化等が行われる。さらに、追加アプリケーション等の起動が２回目以降の起動であることを示すよう変数が設定され、Ｓ３４０に処理が移行される。

なお、追加アプリケーション等の再起動の際は、リソース監視機能１２２，アプリケーション画面生成機能１２４，アプリケーション間通信機能１２５，入力イベント処理機能１２６は稼動したままとなっており、これらの初期化は行われない。

Ｓ３４０，Ｓ３４５では、プリインストールアプリケーションや追加アプリケーションが起動される。以後、追加アプリ処理機能１２１は、各追加アプリケーション等のプログラムを読み出し、これに従い処理を実行することで各追加アプリケーション等を動作させると共に、動作中の追加アプリケーション等では、随時、共有リソース資源の確保や解放が行われる。

（３）平均残量算出処理について
次に、ソフトウェアプラットフォーム１１０にて実行される、瞬間的な共有リソース資源の残量Ｒ_siと、共有リソース資源の残量の平均値Ｒ_saを算出する平均残量算出処理について、図５に記載のフローチャートを用いて説明する。なお、本処理は、車載端末１の起動時に開始され、追加アプリケーション実行処理に並行して実行される。

Ｓ４０５では、共有リソース資源の残量の合計値Ｒ_ssや、該残量の平均値を算出するためのカウンタであるＮ_rに０が設定され、Ｓ４１０に処理が移行される。
Ｓ４１０では、瞬間的な共有リソース資源の残量であるＲ_siが取得され、その後、合計値Ｒ_ssにＲ_siが加算されると共に、カウンタＮ_rに１が加算される（Ｓ４１５）。

そして、Ｎ_rの値が１０に達したか否かの判定が行われ（Ｓ４２０）、肯定判定が得られた場合には（Ｓ４２０：Ｙｅｓ）、共有リソース資源の残量の合計値Ｒ_ssをＮ_rで除算し、得られた値を、共有リソース資源の残量の平均値Ｒ_saとする（Ｓ４２５）。その後、Ｒ_ss，Ｎ_rに０を設定した後（Ｓ４３０）、Ｓ４３５に処理が移行される。一方、上記判定で否定判定が得られた場合には（Ｓ４２０：Ｎｏ）、Ｓ４３５に処理が移行される。

Ｓ４３５では、予め定められた期間にわたりソフトウェアプラットフォーム１１０による処理が実行され、その後、再度Ｓ４１０に処理が移行される。
［具体例及び効果について］
次に、本実施形態の車載端末１の具体例等について説明する。この車載端末１の具体例としてナビゲーション装置が考えられ、図６には、このようなナビゲーション装置の表示画面５００の一例が記載されている。

そして、このような場合には、例えば、地図描画機能やナビ案内機能を組込アプリケーション１３０として実装することが考えられる。また、地図画像５１０に重ねて表示される地点情報５２０，各種案内５３０，オーディオ情報等の表示機能や、地図操作等のための各種ボタン５４０の表示機能をプリインストールアプリケーションとして実装することが考えられる。さらに、これらに加えて、キャラクタアニメーション等の表示機能を有する追加アプリケーションがユーザによりインターネット等から取得され、実装されることが考えられる。

このような場合において、追加アプリケーションに不具合があり、追加アプリケーションにより確保された共有リソース資源が適切に解放されず、時間の経過と共に追加アプリケーション実行環境１２０により確保された共有リソース資源が増加してしまうおそれがある。

これに対し、車載端末１における追加アプリケーション実行環境１２０では、リソース監視機能１２２により共有リソース資源の残量が監視されており、残量が低下した場合には追加アプリケーション実行環境１２０が再起動され、追加アプリケーション等で確保されている共有リソース資源が解放される。このため、共有リソース資源の残量が著しく低下し、組込アプリケーション１３０やソフトウェアプラットフォーム１１０の動作に影響が出る前に、不適切に確保された共有リソース資源が解放され、リセットやフリーズ等の動作異常の発生を避けることができる。

さらに、ナビゲーション機能による経路案内中等に追加アプリケーション実行環境１２０の再起動が行われても、再起動中に組込アプリケーション１３０やソフトウェアプラットフォーム１１０の動作は継続されるため、地図画像の更新や経路案内等の機能は正常に動作し続ける。また、このとき、表示用フレームバッファ等に保存されたデータが保持されるため、追加アプリケーション等により生成され、表示デバイス２０に表示されている画像は固定化された状態となる。このため、追加アプリケーション実行環境１２０の再起動中に、追加アプリケーション等の画像の乱れ等を防ぐことができ、再起動が行われたことをユーザに気づかれることは無い。

また、追加アプリケーションに不具合があり、追加アプリ処理機能１２１を停止させても追加アプリケーションにより確保されている共有リソース資源が解放されなかった場合であっても、リソース監視機能１２２により、強制的に該共有リソース資源が解放される。このため、追加アプリ処理機能１２１の再起動の度に共有リソース資源の残量が減ってしまうという事態を回避することができる。

また、追加アプリケーションの中には、起動時に起動アニメーションの表示等といった起動処理を実行するものがある。このような追加アプリケーションの一例として、表示画面５００にて時刻５５０を表示すると共に、起動アニメーションとして、起動時に００：００を表示し、現在時刻まで高速にカウントアップした後に通常の時刻表示を行う時計のガジェットが考えられる。

このような追加アプリケーションが搭載されている場合には、従来は、追加アプリケーション実行環境１２０の再起動により起動アニメーションが実行されてしまい、ユーザが異常に気づいてしまうという問題があった。これに対し、車載端末１では、追加アプリケーションに対して初回の起動か否かが通知されるため、追加アプリケーションでは、再起動時に起動アニメーション等の実行を回避することができ、ユーザに気づかれることなく、追加アプリケーション実行環境１２０を再起動することが可能となる。したがって、ユーザに対し見苦しさを与えてしまうことを防ぐことができ、品質を損ねることなく、追加アプリケーション実行環境１２０の再起動を行うことができる。

［他の実施形態］
（１）本実施形態の車載端末１では、共有リソース資源の残量が低下した際に、追加アプリケーション実行環境１２０上で動作しているプレインストールアプリケーション及び追加アプリケーションが全て再起動される。しかしながら、これに限定されることは無く、例えば、追加アプリケーションのみを対象として、２回目以降の起動であることを通知しつつ再起動を行っても良い。このような構成を有する場合であっても、ユーザに見苦しさを与えることなく、追加アプリケーションにより確保されている共有リソース資源を解放させることができる。

（２）また、本実施形態の車載端末１では、共有リソース資源の残量が低下した際に追加アプリケーション実行環境１２０の再起動が行われるが、これ以外にも、例えば、共有リソース資源の消費量が多い特定の処理が実行される場合等に、同様にして追加アプリケーション実行環境１２０の再起動を行っても良い。このような場合であっても、ユーザに見苦しさを与えることなく、追加アプリケーション等により確保されている共有リソース資源を解放させることができ、該特定の処理を正常に実行することが可能となる。

［特許請求の範囲との対応］
上記実施形態の説明で用いた用語と、特許請求の範囲の記載に用いた用語との対応を示す。

追加アプリケーション実行環境１２０がアプリケーション実行環境に、追加アプリケーション，プリインストールアプリケーションがアプリケーションに相当する。
また、追加アプリケーション実行処理におけるＳ２１０，Ｓ２１５が検出手段に、Ｓ２４０が停止手段に、Ｓ２４５が解放手段に相当する。

また、追加アプリケーション実行環境初期化処理におけるＳ３１５，Ｓ３３５が通知手段に、Ｓ３４０，Ｓ３４５が起動手段に相当する。

１…車載端末、１０…ＲＡＭ、１１…ＣＰＵ、１２…グラフィックコントローラ、１３…ディスプレイコントローラ、２０…表示デバイス、３０…入力デバイス、４０…外部記憶デバイス、５０…センサ、６０…ＥＣＵ、１００…車載端末ソフトウェア、１１０…ソフトウェアプラットフォーム、１１１…表示レイヤ、１１２…描画機能、１１３…アプリケーション間通信基盤、１１４…入力イベント生成機能、１１５…ＯＳ、１１６…車両通信機能、１２０…追加アプリケーション実行環境、１２１…追加アプリ処理機能、１２２…リソース監視機能、１２３…データバッファ、１２４…アプリケーション画面生成機能、１２５…アプリケーション間通信機能、１２６…入力イベント処理機能、１３０…組込アプリケーション、１４０…プリインストールアプリケーション、１５０…追加アプリケーション、１６０…追加アプリケーション。

Claims (4)

1. アプリケーションを動作させるアプリケーション実行環境が搭載された車載端末であって、
   前記アプリケーション実行環境は、
   当該アプリケーション実行環境の起動後に前記アプリケーションを起動すると共に、予め定められたタイミングで前記アプリケーションを再起動する起動手段と、
   前記起動手段により前記アプリケーションが起動される際に、該アプリケーションに対し、該起動が、当該アプリケーション実行環境の起動後、最初に行われたものであるか否かを通知する通知手段と、
   を備えることを特徴とする車載端末。
2. 請求項１に記載の車載端末において、
   前記アプリケーション実行環境は、
   前記アプリケーションの動作を停止させる停止手段と、
   前記停止手段により前記アプリケーションの動作が停止された後、該アプリケーションにより確保されたままとなっている、当該アプリケーション実行環境を動作させるコンピュータでの処理に用いられるリソースを解放する解放手段と、
   を備えることを特徴とする車載端末。
3. 請求項２に記載の車載端末において、
   前記アプリケーション実行環境は、
   前記リソースの残量の低下を検出する検出手段をさらに備え
   前記停止手段は、前記検出手段により前記リソースの残量の低下が検出された際に、全ての前記アプリケーションの動作を停止させ、
   前記起動手段は、前記リソースの残量の低下により前記停止手段により全ての前記アプリケーションが停止された後の前記タイミングに、停止された前記アプリケーションを再起動すること、
   を特徴とする車載端末。
4. アプリケーションを動作させるアプリケーション実行環境として車載端末に搭載されたコンピュータを動作させるアプリケーション実行環境プログラムであって、
   前記アプリケーション実行環境の起動後に前記アプリケーションを起動する共に、予め定められたタイミングで前記アプリケーションを再起動する起動手段と、
   前記起動手段により前記アプリケーションが起動される際に、該アプリケーションに対し、該起動が、当該アプリケーション実行環境の起動後、最初に行われたものであるか否かを通知する通知手段と、
   して前記コンピュータを動作させることを特徴とするアプリケーション実行環境プログラム。