JP2021051665A - 車載情報処理システム、車載機器及び車載情報処理プログラム - Google Patents

Abstract

【課題】携帯通信端末のリソースを有効に利用する。【解決手段】車載機器１は、携帯通信端末２のリソースの空き状態を監視し、車載情報を処理するためのタスクを携帯通信端末２に対して処理することを要求する。これにより、携帯通信端末２のリソースを有効に利用することができる。【選択図】図２

Description

本発明は、車載情報処理システム、車載機器及び車載情報処理プログラムに関する。

近年、車載機器に搭載されたアプリケーションプログラムの処理が複雑化しており、車載機器のリソースが不足気味となることがあるものの、車載機器のリソースを簡単に交換することは困難である。このため、車載機器の動作時にリソースが不足して車載機器の操作性が悪化するような不具合が生じるにしても、車載機器を継続して利用しているのが実情である。

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

このように車載機器のリソースに余裕がない場合は、特許文献１のようにオプションの拡張ボードを車載機器に接続し、拡張ボードのリソースを使用するのが一般的である。
しかしながら、拡張ボードは高価であることから、ユーザが所持するスマートフォンやタブレット等の携帯通信端末のリソースを利用することが望まれている。

近年、このような携帯通信端末のリソースを利用する技術として、Ａｐｐｌｅ社のＡｐｐｌｅＣａｒ Ｐｌａｙ（登録商標）やＧｏｏｇｌｅ社のＡｎｄｒｏｉｄＡｕｔｏ（登録商標）が提供されており、携帯通信端末内に搭載されたアプリケーションやデータを車載機器で利用することができる。

ところが、Ａｐｐｌｅ Ｃａｒ ＰｌａｙやＡｎｄｒｏｉｄ Ａｕｔｏは携帯通信端末内のアプリケーションやデータを車載機器で利用する機能であり、車載機器が携帯通信端末のリソースを利用する機能ではないので、携帯通信端末のリソースに余裕がある場合であっても、車載機器の操作性を向上することはできない。

本発明は上記事情に鑑みてなされたもので、その目的は、携帯通信端末のリソースを有効に利用することができる車載情報処理システム、車載機器及び車載情報処理プログラムを提供することにある。

請求項１の発明によれば、リソース監視部（３ａ）は、携帯通信端末（２）のリソースの空き状況を監視する。車載機器（１）に設けられた処理部（３ｂ）は、リソース監視部（３ａ）による監視結果に基づいて車載情報を処理するためのタスクを携帯通信端末（２）に対して処理することを要求する。携帯通信端末（２）に設けられた応答部（３１）は、車載機器（１）から要求されたタスクを処理し、その処理結果を応答する。車載機器（１）に設けられた処理部３ｂは、携帯通信端末からの応答に応じて車載情報を処理する。

一実施形態における車載情報処理システムを示す機能ブロック図 車載機器と携帯通信端末との間の処理手順を示す図 車載機器と携帯通信端末との間の処理手順を示す図（変形例） リソースの余裕度を示す図 他のアプリケーションを圧縮した状態におけるリソースの余裕度を示す図 携帯通信端末が有する規格に応じた処理を実行する場合の手順を示す図

以下、車載情報処理システムの一実施形態について図面を参照して説明する。
図１に示すように車両には例えばカーナビゲーションのような車載機器１が搭載されており、携帯通信端末２と通信可能に構成されている。

車載機器１は、車載側制御部３、ＢＴ（Bluetooth（登録商標））モジュール４（車載側通信部に相当）、ＵＳＢ（Universal Serial Bus）モジュール５（車載側通信部に相当）、Ｉ／Ｆ６、記憶部７、位置取得部８、表示部９、操作入力部１０などを備えている。

車載側制御部３は、図示しないＣＰＵ、ＲＡＭ、ＲＡＭ、ＲＯＭおよびＩ／Ｏバスなどを有する周知のマイクロコンピュータで構成されており、例えばＯＳとしてＬｉｎｕｘ（登録商標）が搭載されている。車載側制御部３は、ＲＯＭあるいは記憶部７などの非遷移的実体的記憶媒体に記憶されているコンピュータプログラムに従って、通信動作やデータ管理動作など車載機器１の動作全般を制御する。

ＢＴモジュール４は、携帯通信端末２との間でＢＴ通信回線を通じてデータ通信を行う。
ＵＳＢモジュール５は、図示しない接続ケーブルによりＵＳＢ端子１１を介して携帯通信端末２に接続可能であり、接続状態で携帯通信端末２との間でＵＳＢ通信回線によりデータ通信を行う。

記憶部７は、例えばハードディスクドライブなどの不揮発性の記憶媒体で構成されており、上記したコンピュータプログラムやアプリケーションプログラム（以下、ＡＰＰと称する）などの各種のプログラム、および各プログラムで利用されるデータなどを記憶している。このＡＰＰには、コンテンツを実行するためのＡＰＰも含まれている。記憶部７は、車載機器１に内蔵されている構成であってもよいし、車載機器１から取り外し可能な外部記憶媒体を用いる構成であってもよい。
表示部９は、例えば液晶表示器や有機ＥＬで構成されており、車載側制御部３の指令に基づいて各種の情報を表示する。

操作入力部１０は、ユーザによる操作を検知し、その検知結果を車載側制御部３に出力する。車載側制御部３は、操作入力部１０に対する操作に基づいて表示部９に情報を出力するとともに、操作内容を通信可能に接続された携帯通信端末２に通知する。

位置取得部８は、図示しない周知の地磁気センサ、ジャイロスコープ、車速センサおよびＧＰＳ受信機などを備えている。位置取得部８は、これら地磁気センサ、ジャイロスコープ、車速センサ及びＧＰＳ受信機などから入力される検出信号を互いに補完することにより車両の現在の位置情報を取得する。位置取得部８は、要求される検出精度で車両の位置情報を取得可能であれば、これら全ての要素を備える必要はなく、また、ステアリングの舵角を検出するステアリングセンサや各車輪の回転を検出する車輪センサ（いずれも図示せず）などと組み合わされて構成されていても良い。位置取得部８は、取得した自車両の位置情報を車載側制御部３に出力する。車載側制御部３は、位置取得部８で取得した車両の位置情報に基づいて経路案内する。

Ｉ／Ｆ６は車載端子１２と接続されており、その車載端子１２に接続された図示しない拡張ボードと通信可能である。拡張ボードが車載端子１２に接続された状態では、車載機器１のメインボードは拡張ボードとアクセス可能となる。

本実施形態では、携帯通信端末２としてスマートフォンやタブレットを想定している。この携帯通信端末２は、電話通信網１００を介して外部のセンターに設けられているサーバからコンテンツを取得可能である。

携帯通信端末２は、端末側制御部２１、電話通信部２２、ＢＴモジュール２３（端末側通信部に相当）、ＵＳＢモジュール２４（端末側通信部に相当）、記憶部２５、表示部２６、操作キー入力部２７などを備えている。

端末側制御部２１は、図２に示すＣＰＵ２９、ＲＡＭ３０、ＲＯＭおよびＩ／Ｏバスなどを有する周知のマイクロコンピュータで構成されている。端末側制御部２１は、ＲＯＭあるいは記憶部２５などに記憶されているコンピュータプログラムに従って、通信動作やデータ管理動作、ならびに後述するコンテンツの取得および実行など携帯通信端末２の動作全般を制御する。

電話通信部２２は、電話通信網１００との間で電話通信を実行する。電話通信網１００は、図示しない携帯電話基地局や基地局制御装置などの周知の公衆回線網を利用する携帯電話通信サービスを提供する設備を含むものである。また、電話通信部２２は、電話通信網１００に接続している図示しないサーバから、ＡＰＰや楽曲や画像（映像含む）などの各種コンテンツを取得する。

ＢＴモジュール２３は、車載機器１との間でＢＴ通信回線を通じたＢＴ通信を行う機能を有する。ＢＴモジュール２３は、ＢＴの通信規格で規定されている複数のプロファイルを同時接続可能に構成されている。これら複数のプロファイルは、機能ごとに定義された通信プロファイルを意味している。

ＵＳＢモジュール２４は、ＵＳＢ端子２８を介して車載機器１との間でＵＳＢ通信回線によりデータ通信を行う。記憶部２５は、各種データを記憶する記憶領域を有していると共に、上記したコンピュータプログラム、および取得したコンテンツやそのコンテンツを実行するためのＡＰＰを記憶している。この記憶部２５は、例えばメモリカードなど取り外し可能に構成してもよい。

表示部２６は、例えば液晶表示器や有機ＥＬ表示器などで構成されており、端末側制御部２１の指令に基づいて各種の情報を表示する。この表示部２６は、例えば周知の電話帳、受信したメール、取得したコンテンツに関する情報およびコンテンツに対する操作画面などを表示する。

操作キー入力部２７は、表示部２６の画面上に設けられたタッチスイッチ、表示部２６の周囲や近傍に設けられているスイッチ類とを含む各種の図示しない操作キーを備えている。操作キー入力部２７は、ユーザが操作キーを操作したことに応じて操作検出信号を端末側制御部２１へ出力する。端末側制御部２１は、操作キー入力部２７から入力した操作検出信号に基づいてユーザによる操作内容を特定するとともに、その操作内容をＢＴ通信により接続相手側の機器である車載機器１に通知する。

車載機器１は、車載機器とＢＴ通信可能に接続する場合は携帯通信端末２とペアリングを実行する。つまり、ユーザが乗車することで携帯通信端末２と車載機器１とがＢＴによる通信が可能な近距離に配置されたときに、携帯通信端末２と車載機器１とは互いにＢＴにより通信可能に接続する。

ＢＴ通信による接続が過去に行われている状態、即ち、車載機器１及び携帯通信端末２に互いのＢＴ通信に必要な情報が登録されている状態で互いがＢＴ通信可能な近距離に配置されたときには、ユーザが操作を行うことなくＢＴ通信可能に接続される。

さて、車載側制御部３は、車載端子１２を介して拡張ボードが接続された状態では当該拡張ボードのリソースを利用可能であり、車載機器１側のリソースの空き領域が不足するような場合は拡張ボードのリソースを利用して車載情報を処理する。これにより、処理中の車載情報を動作速度が遅くなることなく処理することができるので、車載機器１の操作性が悪化してしまうことを防止することができる。

しかしながら、拡張ボードは比較的高価であることから、拡張ボードを用いることなく車載情報を処理可能な構成が望まれている。
このような事情から、本実施形態では、ユーザが携帯している携帯通信端末２を拡張ボードに代えて利用するようにした。つまり、携帯通信端末２のリソースは運転中には利用されることはないので、携帯通信端末２のリソースを拡張ボードに代えて利用するのである。

このように拡張ボードに代えて携帯通信端末２のリソースを利用することを実現するために、携帯通信端末２には端末側ＡＰＰ３１（応答部に相当）がインストールされており、その端末側ＡＰＰ３１により車載モードが実行される。つまり、携帯通信端末２は、通常時は携帯モードを実行するようになっているが、端末側ＡＰＰ３１が起動されると車載モードを実行するようになる。端末側ＡＰＰ３１により車載モードが実行される場合は、拡張ボードに代えて携帯通信端末２のリソースの利用が可能となる。ユーザが端末側ＡＰＰ３１を起動することにより車載モードに切替可能であるが、車載機器１との接続時に端末側ＡＰＰ３１を立上げることにより携帯モードから車載モードに自動的に切替えるようにしてもよい。

車載機器１は、端末側ＡＰＰ３１による車載モード実行時は、携帯通信端末２で使用していないＣＰＵ２９やＲＡＭ３０等のリソースにおける不使用部分（図２の斜線領域）を車載側ＡＰＰで利用可能となり、車載側ＡＰＰが携帯通信端末２のリソースを利用して車載情報を処理することができる。
尚、図２で示すＣＰＵ２９の斜線領域はＣＰＵ２９の余裕度を示し、ＲＡＭ３０の斜線領域はＲＡＭ３０の余裕領域を示している。

具体的には、図２に示すように車載機器１の車載側制御部３には、携帯通信端末２のＲＡＭ３０の空き状態を監視するリソース監視部３ａと処理部３ｂが構成されている。リソース監視部３ａが車載機器１に対してリソースの空き領域の大きさを問合わせると、端末側ＡＰＰ３１は、車載機器１からの要求に応じてリソースの空き領域の大きさを応答する。これにより、リソース監視部３ａは、携帯通信端末２のリソースの空き領域の大きさを確認することができる。

車載側制御部３には、プログラムによりスケジューラ３ｃ（割振部に相当）が実現されている。このスケジューラ３ｃは、車載情報を処理するためのタスクをリアルタイムキュー（高速処理部に相当）と汎用キュー（汎用処理部に相当）とに適宜割振るもので、高速処理が要求されるタスクはリアルタイムキューに割振るようになっている。

処理部３ｂは、汎用キューの空き状態を監視しており、汎用キューに割振可能なタスク数が不足するような場合は、携帯通信端末２のリソースの空き領域を確認してから、汎用キューに保持されている最古のタスクを携帯通信端末２で処理するように要求する。
携帯通信端末２の端末側ＡＰＰ３１は、要求されたタスクを処理し、その処理結果を車載機器１に返信する。
車載機器１のＡＰＰは、車載機器１からの処理結果に基づいて車載情報の処理を継続して実行する。
以上のような動作により、車載機器１は、携帯通信端末２のリソースを利用して車載情報を処理することができる。

図３に示すように携帯通信端末２にリソース監視部２ａを搭載することも可能である。この場合、リソース監視部２ａは、自己のリソースが空いている場合に車載機器１側へリソースが空いていることを通知する。これにより、処理部３ｂは、汎用キューに割振可能なタスクが不足するような場合は、車載機器１にタスクの処理を要求するようになる。

ところで、携帯通信端末２のリソースは、通常時は他のＡＰＰ（以下、他ＡＰＰと称する）３２も使用しているのが一般的である。このように他ＡＰＰ３２がリソースを使用している場合は、図４に示すようにリソースの空き領域が制限されることから、携帯通信端末２のリソースを有効活用することができない。

そこで、端末側ＡＰＰ３１は、携帯通信端末２のリソースを利用している他ＡＰＰ３２を圧縮させることで、車載側ＡＰＰが利用可能な携帯通信端末２のリソースの拡大を図るようにした。

端末側ＡＰＰ３１は、車載側ＡＰＰから処理が要求された場合は、図５に示すようにリソースを利用している他ＡＰＰ３２を圧縮し、処理が終了した場合は圧縮した他ＡＰＰ３２を解凍して復帰する。また、他ＡＰＰ３２を一旦終了し、処理が終了した場合に他ＡＰＰ３２を起動するようにしてもよい。

以上のように車載側ＡＰＰが携帯通信端末２のリソースを利用可能とすることで、車載機器１を所有するユーザは拡張ボードを購入することなく車載機器１のリソース不足に対処可能となる。

上述のように携帯通信端末２のリソースを有効活用する方法としては、例えばエッジコンピューティングにおいて携帯通信端末２でも処理が求められる場合に、携帯通信端末２を計算リソースとして利用することが想定される。具体的には、携帯通信端末２で定期的にＣＰＵ２９やＲＡＭ３０の利用率を計算し、余裕があれば、車載側制御部３の計算処理の一部を受取り、携帯通信端末２内で計算し、計算結果を車載機器１に送信する。

一方、車載機器１では対応していないが、携帯通信端末２であれば対応している映像や通信等の規格があれば、携帯通信端末２に処理させ、処理後の画像や通信情報等を車載機器１に転送させることが考えられる。
例えば、車載機器１と携帯通信端末２とが接続した際に、携帯通信端末２がサポートする規格の一覧を車載機器１で管理する。

即ち、携帯通信端末２からデコードできるメディアのフォーマット（ｍｐ４やａａｃ等）や、対応しているＷｉＦｉの規格（１１ａｃや１１ａｘ等）を通知し、車載機器１がその規格を使用する処理する場合、携帯通信端末２に対して当該処理することを要求する。
具体的には、図６に示すように携帯通信端末２から車載機器１に対して、携帯通信端末２が対応している規格を予め通知しており、ＡＰＰやユーザから規格の処理が要求された際に携帯通信端末２がその規格をサポートしている場合は、携帯通信端末２に規格に沿った処理を要求し、携帯通信端末２は、処理したデータを車載機器１に転送する。

また、車載機器１よりも携帯通信端末２の方が買い替える頻度が高く、新しいＯＳや高スペックなＣＰＵ２９やＲＡＭ３０が搭載されている可能性が高いことから、リソースとしての機能の向上を期待することができる。さらに、映像や通信等の最新規格にも対応している可能性が高いことから、それらを処理することも想定される。

このような実施形態によれば、次のような効果を奏することができる。
車載機器１は、携帯通信端末２のリソースの空き状態を監視し、車載情報を処理するためのタスクを携帯通信端末２に対して処理することを要求するので、携帯通信端末２のリソースを有効に利用することができる。
タスクとして高速処理が要求されないタスクを携帯通信端末２に対して処理することを要求するので、携帯通信端末２によるタスク処理が遅れてしまうことを抑制できる。

スケジューラ３ｃによりタスクをリアルタイムキューと汎用キューとに割振り、通常のキューに保持された最古のタスクを携帯通信端末２に対して処理することを要求するので、直ちに処理することが要求されるタスクを効果的に処理することができる。
端末側ＡＰＰ３１は、車載機器１がリソースを利用する場合に他ＡＰＰ３２がリソースを使用していた場合は、他ＡＰＰ３２を圧縮し、処理の実行後に他ＡＰＰ３２を解凍して復帰するので、リソースで使用可能な領域を拡大することができる。

（その他の実施形態）
長時間使われていないＡＰＰをフラッシュメモリに移したり、ＡＰＰの処理優先度を下げたりしてもよい。
車載機器１側にあるスケジューラ３ｃが割込みや優先順位を決め、実行順番を決めてもいい。例えば優先度の高い処理や期限の近い処理を優先的に処理する。

携帯通信端末２に処理を要求するタスクとして、例えば優先度の高い処理や期限の近い処理を優先的に要求してもよい。
上記実施形態では、車載機器１のＯＳとしてＬｉｎｕｘを搭載したが、例えばＡｎｄｒｏｉｄ（登録商標）やｉＯＳ（登録商標）やＲＴＯＳ（Real Time Operating System）を搭載するようにしてもよい。

本開示は、実施形態に準拠して記述されたが、本開示は当該実施形態や構造に限定されるものではないと理解される。本開示は、様々な変形例や均等範囲内の変形をも包含する。加えて、様々な組み合わせや形態、さらには、それらに一要素のみ、それ以上、あるいはそれ以下、を含む他の組み合わせや形態をも、本開示の範疇や思想範囲に入るものである。

本開示に記載の制御部及びその手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリーを構成することによって提供された専用コンピュータにより、実現されてもよい。あるいは、本開示に記載の制御部及びその手法は、一つ以上の専用ハードウエア論理回路によってプロセッサを構成することによって提供された専用コンピュータにより、実現されてもよい。もしくは、本開示に記載の制御部及びその手法は、一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリーと一つ以上のハードウエア論理回路によって構成されたプロセッサとの組み合わせにより構成された一つ以上の専用コンピュータにより、実現されてもよい。また、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体に記憶されていてもよい。

図面中、１は車載機器、２は携帯通信端末、３ａはリソース監視部、３ｂは処理部、３ｃはスケジューラ（割振部）、４はＢＴモジュール（車載側通信部）、５はＵＳＢモジュール（車載側通信部）、２３はＢＴモジュール（端末側通信部）、２４はＵＳＢモジュール（端末側通信部）、３１は応答部、３２はアプリケーションである。

Claims (7)

1. 車載機器（１）が携帯通信端末（２）のリソースを利用して車載情報を処理する車載情報処理システムであって、
   前記車載機器に設けられ、前記携帯通信端末と通信可能に接続する車載側通信部（４，５）と、
   前記携帯通信端末のリソースの空き状況を監視するリソース監視部（３ａ）と、
   前記車載機器に設けられ、前記リソース監視部による監視結果に基づいて前記車載情報を処理するためのタスクを前記携帯通信端末に対して処理することを要求すると共に当該携帯通信端末からの応答に応じて前記車載情報を処理する処理部（３ｂ）と、を備え、
   前記携帯通信端末に設けられ、前記車載機器と通信可能に接続する端末側通信部（２３，２４）と、
   前記携帯通信端末に設けられ、前記車載機器と通信可能に接続された状態で前記車載機器から要求された前記タスクを処理し、その処理結果を応答する応答部（３１）と、
   を備えた車載情報処理システム。
2. 前記処理部は、前記タスクとして高速処理が要求されないタスクを前記携帯通信端末に対して処理することを要求する請求項１に記載の車載情報処理システム。
3. 車載情報を処理するためのタスクを要求される処理速度に応じて高速処理部と汎用処理部とに割振る割振部（３ｃ）を備え、
   前記処理部は、前記汎用処理部に保持された最古のタスクを前記携帯通信端末に処理することを要求する請求項２に記載の車載情報処理システム。
4. 前記応答部は、前記車載機器から処理が要求された場合にアプリケーション（３２）がリソースを使用していたときは、前記アプリケーションを圧縮し、処理の実行後に前記アプリケーションを解凍して復帰する請求項１から３のいずれか一項に記載の車載情報処理システム。
5. 前記応答部は、前記車載機器から処理の実行を要求された場合にアプリケーション（３２）がリソースを使用していたときは、前記アプリケーションを終了し、処理の実行後に前記アプリケーションを復帰する請求項１から３のいずれか一項に記載の車載情報処理システム。
6. 携帯通信端末のリソースを利用して車載情報を処理する車載機器（１）であって、
   前記携帯通信端末と通信可能に接続する車載側通信部（４，５）と、
   前記携帯通信端末と通信可能に接続された状態で前記携帯通信端末のリソースの空き状況を監視するリソース監視部（３ａ）と、
   前記リソース監視部による監視結果に基づいて前記車載情報を処理するためのタスクを前記携帯通信端末に対して処理することを要求すると共に当該携帯通信端末からの応答に応じて前記車載情報を処理する処理部（３ｂ）と、
   を備えた車載機器。
7. 携帯通信端末（２）のリソースを利用して車載情報を処理する車載機器（１）に搭載された車載情報処理プログラムであって、
   車載側通信部（４，５）により、前記携帯通信端末と通信可能に接続する手順と、
   リソース監視部（３ａ）により、前記携帯通信端末と通信可能に接続された状態で前記携帯通信端末のリソースの空き状況を監視する手順と、
   処理部（３ｂ）により、前記リソース監視部による監視結果に基づいて前記車載情報を処理するためのタスクを前記携帯通信端末に対して処理することを要求すると共に当該携帯通信端末からの応答に応じて前記車載情報を処理する手順と、
   を実行する車載情報処理プログラム。

Images