JP7484746B2 - 車両用装置、車両用システム - Google Patents

Description

本開示は、車両用装置、車両用システムに関する。

近年、例えば特許文献１に示されているように、車両用装置に複数のオペレーティングシステムを実装することが急速に普及しつつある。以下、オペレーティングシステムをＯＳと称する。このとき、車両用装置には、リアルタイム性が求められる処理に適したいわゆるリアルタイムＯＳと、例えばディスプレイへの表示などのマルチメディア系の処理に適しており、一般的な携帯端末等で利用される汎用的なＯＳとが実装されることがある。

特許第６１３０６１７号

ところで、携帯端末等で利用される汎用的なＯＳは、更新頻度が比較的高く、その更新によってＯＳに搭載される機能も拡充されていく。そして、機能の拡充に伴って必要となるメモリ容量が増加するなど、要求されるハードウェアの性能も高くなっていく。

しかしながら、車両に搭載される車両用装置の場合には、出荷後に例えば１年ごとや数年ごとに部品を取り換えたり追加したりして性能を向上させるといったハードウェアの更新が困難であるという問題がある。また、数年先に必要になることを見越して予め拡張性や将来性に余裕を持たせたハードウェア設計とすることは現時点においては過剰な性能となってしまうこと、また、例えば後からメモリを追加する等の部品の追加や交換は、セキュリティ面や信号品質あるいは信頼性の観点から採用することが困難である。

本開示は、上記した事情に鑑みてなされたものであり、その目的は、出荷後においても
性能向上を図ることができる車両用装置、車両用システムを提供することにある。

上記目的を達成するために、本開示の一態様としての車両用装置（１）は、周辺機器（３）へのアクセスが可能であり、車両を利用する際に提供される機能を実行可能な制御部（１０１）と、制御部と通信可能に接続され、当該制御部を介して周辺機器へのアクセスが可能な外部装置（２）が接続される接続部（５）と、外部装置が接続部に機能を実行可能な状態で接続されているか否かを判定する判定部（１２）とを備え、外部装置が機能を実行可能な状態で接続されていると判定した場合、外部装置を有効化して機能の実行を可能にする。

これにより、例えば車両出荷時には必要とされる性能を有していたものの、その後のＯＳのアップデートなどによって高性能化が必要になるような状況において、外部装置を接続することで機能を提供するための性能向上を容易に図ることができる。

そして、車両用装置は、自身が実行可能な機能のうち少なくとも１つの機能の実行を外部装置に移管することによって、他の機能を実行するための自身のリソースを確保するリソース管理部（１３）を備えている。これにより、例えばリアルタイム性が必要とされる機能、周辺機器へのアクセス頻度が高い機能、あるいは、車両用装置と外部装置との間の通信経路にかかる負荷が高い機能などを車両用装置で実行することが可能となる。

したがって、例えば出荷後に新たに追加された機能や新たに追加された周辺機器を利用する機能などを、車両用装置のハードウェア構成自体は変更することなく提供することが可能となり、車両用装置の出荷後においても性能向上を図ることができる。

また、上記した車両用装置（１）と外部装置（２）とを備える車両用システム（４）によっても、出荷後に新たに追加された機能や新たに追加された周辺機器を利用する機能を車両用装置のハードウェア構成自体は変更することなく提供することが可能となり、車両用装置の出荷後においても全体として性能向上を図ることができる。

第１実施形態での車両用装置、外部装置の電気的構成例を模式的に示す図 車両用装置、外部装置のソフトウェア構成例を模式的に示す図 車両用装置、外部装置の起動時の処理の流れを示す図 外部装置を有効化する有効化処理の流れを示す図 簡略化したソフトウェア構成例を模式的に示す図 第２実施形態での簡略化したソフトウェア構成例を模式的に示す図その１ 簡略化したソフトウェア構成例を模式的に示す図その２ 簡略化したソフトウェア構成例を模式的に示す図その３

以下、複数の実施形態について説明する。また、各実施形態において実質的に共通する部位には同一符号を付すものとする。

（第１実施形態）
以下、第１実施形態について説明する。図１に示すように、車両用装置１は、例えばＳｏＣで構成された半導体集積回路として実現されており、外部装置２に接続可能となっているとともに周辺機器３へのアクセスが可能となっている。これら車両用装置１、外部装置２は、互いに連携して作動することにより車両用システム４を構成している。

具体的には、車両用装置１は、車両を利用する際に提供される機能を実行可能な制御部１０１、周辺機器３との間で各種の信号を入出力するための外部入出力回路１０２、制御部１０１と通信可能であって車両を利用する際に提供される機能を実行可能な外部装置２が接続されるＵＳＢコネクタ１０３などを備えている。なお、ＳｏＣはSystem on a Chipの略であり、ＵＳＢは、Universal Serial Busの略である。また、図１では説明の簡略化のために外部入出力回路１０２を１つのブロックとして示しているが、周辺機器３に対応した複数の回路で構成することができる。

制御部１０１は、ＣＰＵ１０４、ＲＯＭ１０５、ＲＡＭ１０６、入出力ポート１０７、および通信回路１０８などを備えており、それらがバス１０９によって接続されている。ＣＰＵ１０４は、ＲＯＭ１０５に記憶されているプログラムを実行することにより、車両用装置１を制御するための各種の処理と、車両を利用する際に提供される各種の機能を実行する。また、ＣＰＵ１０４が実行する機能の一部または全部を１つあるいは複数のＩＣによりハードウェアで構成することができる。

本実施形態では、車両を利用する際に提供される機能とは、車両を利用するユーザに対して提供される機能、および、ユーザが直接的には把握していなくても車両を利用するために必要とされる車載機器を含む周辺機器３を制御するための機能を想定している。つまり、車両を利用する際に提供される機能とは、車両用装置１が提供可能な機能、および、車両用装置１を介して外部装置２が提供可能な機能を意味している。

ＲＯＭ１０５は、例えばｅＭＭＣで構成された不揮発性のメモリである。なお、ｅＭＭＣは、embedded Multi Media Cardの略である。このＲＯＭ１０５には、ＣＰＵ１０４が実行する各種のプログラム、プログラムを実行する際に参照されるデータ、エアコンディショナの設定温度、シートやハドルの位置や角度のような主として車両設備に利用されるデータ、ナビゲーションに利用する自宅の位置や電話番号、楽曲などのような主として提供する機能に利用されるデータなどが記憶されている。以下、これらのデータのうち、シートポジションや電話番号などのようなユーザとって固有のデータをユーザ情報とも称する。

また、ＲＯＭ１０５は、不揮発性のメモリで構成されており、読み出し専用の領域と書き込み可能な領域とが設けられている。例えばＯＳイメージのように基本的には書き換えないデータは読み出し専用の領域に記憶されている一方、車両用装置１の電源がオフされた場合でも記憶しておくデータは書き込み可能な領域に記憶される。このＲＯＭ１０５は、記憶部１１０を構成している。

ＲＡＭ１０６は、揮発性のメモリで構成されており、演算結果等のデータを一時的に記憶する。なお、ＲＡＭ１０６に記憶されるデータは、必要であれば例えば車両用装置１の動作終了時にＲＯＭ１０５の書き込み可能な領域に記憶される。

入出力ポート１０７は、制御部１０１と周辺機器３や外部装置２との間で信号の入出力を行わせるための回路である。通信回路１０８は、本実施形態ではＵＳＢ規格に準拠したものであり、物理的な接続手段であるＵＳＢコネクタ１０３を介して、外部装置２との間でデータの送受信を行う。これらＵＳＢコネクタ１０３と通信回路１０８は、本実施形態における接続部５を構成している。また、このＵＳＢ通信が行われる経路が通信経路に相当する。

外部装置２は、例えばＳｏＣで構成された半導体集積回路として実現されており、本実施形態では、車両用装置１とＵＳＢ接続されるＵＳＢモジュールとして構成されている。この外部装置２は、ケーブル６を介して車両用装置１の制御部１０１と通信可能にＵＳＢ接続されることで、車両用装置１を介して周辺機器３にアクセス可能になっている。また、外部装置２は、動作時にはＵＳＢコネクタ１０３を介して車両用装置１から電源が供給される。

外部装置２は、車両を利用する際に提供される機能を実行可能な外部制御部２０１と、周辺機器３や無線通信装置２０３との間で各種の信号を入出力するための外部入出力回路２０２とを備えている。つまり、外部装置２は、車両用装置１と通信可能に接続され、車両用装置１を介して周辺機器３にアクセス可能であって、車両を利用する際に提供される機能を実行可能な外部制御部２０１を有している。また、外部装置２は、後述するように、車両用装置１からの機能の移管を受付可能であるとともに、移管された機能を実行することによって車両用装置１のリソースを節約する。

外部制御部２０１は、ＣＰＵ２０４、ＲＯＭ２０５、ＲＡＭ２０６、入出力ポート２０７、および通信回路２０８などを備えており、それらがバス２０９によって接続されている。なお、図１では説明の簡略化のために外部入出力回路２０２を１つのブロックとして示しているが、無線通信装置２０３のような外部装置２に接続されることが想定される装置に対応した複数の回路で構成することができる。

ＣＰＵ２０４は、ＲＯＭ２０５に記憶されているプログラムを実行することにより、車両用装置１との間の通信や車両を利用する際に提供される各種の機能を実行する。ＲＯＭ２０５は、ＣＰＵ２０４が実行するプログラムやプログラムを実行する際に参照されるデータなどを記憶する外部側記憶部２１０を構成している。また、外部装置２の外部側記憶部２１０は、車両用装置１から送信される例えばユーザ情報などのデータを記憶することもできる。

本実施形態では、外部制御部２０１は、車両用装置１の制御部１０１よりも高い処理性能を有する構成となっている。そのため、同一処理を実行する場合には、車両用装置１よりも外部装置２の方がより短時間で処理を完了することができる。また、ＣＰＵ２０４が実行する機能の一部または全部を１つあるいは複数のＩＣによりハードウェアで構成することができる。

入出力ポート２０７は、外部制御部２０１と他の装置との間で信号の入出力を行わせるための回路である。本実施形態では、他の装置として、車両用装置１、車両用装置１を介して制御する周辺機器３、例えばユーザが所有する携帯端末７との間で通信を行う無線通信装置２０３などを想定している。

通信回路２０８は、本実施形態では車両用装置１と通信するためのＵＳＢ規格に準拠したものである。無線通信装置２０３は、例えばＷｉ－Ｆｉ（登録商標）やＢｌｕｅｔｏｏｔｈ（登録商標）に対応した無線通信部を備えており、携帯端末７との間で無線通信を行う。なお、無線通信装置２０３は、携帯端末７との間を有線接続方式で通信する機能を備えていてもよい。

車両用装置１に接続される周辺機器３としては、例えばセンタディスプレイ３０１、メータディスプレイ３０２、ヘッドアップディスプレイ３０３、エアコンディスプレイ３０４、スピーカ３０５、カメラ３０６、マイク３０７、位置検出装置３０８、チューナ３０９、ＤＳＭ３１０、ＬＩＤＡＲ３１１、レーダ３１２、ＥＣＵ３１３などが想定される。ただし、図１に示した周辺機器３の種類や数は一例であり、車両用装置１は必ずしもこれら全てと接続されている必要は無く、また、例示していない他の周辺機器３を接続することもできる。

センタディスプレイ３０１は、例えば運転席と助手席との間の前方に配置される。このセンタディスプレイ３０１は、例えばナビゲーション機能などを実行する際の表示画面や、表示領域に対応して設けられている図示しないタッチパネルを利用する際の操作画面として使用される。つまり、センタディスプレイ３０１は、ユーザの操作を入力する入力部１０として機能する。

ただし、入力部１０としては、タッチパネル以外にも例えば画面の周囲に図示しない機械式の操作スイッチを配置して操作を入力する構成とすることができる。また、入力部１０としては、他のディスプレイや図示しないステアリングスイッチなどを採用したり、それらをタッチパネルや操作スイッチとを共用したりすることができる。

メータディスプレイ３０２は、ステアリングの前方に配置されて、速度や回転数などのメータ表示、警告灯などの表示を行う。ヘッドアップディスプレイ３０３は、運転者の前方に配置されているウィンドシールドやダッシュボードに配置された表示板に各種の情報を表示する。エアコンディスプレイ３０４は、例えば現在の設定温度や外気温などのエアコンディショナの制御に関する情報を表示する。ただし、エアコンディスプレイ３０４は、専用で設けることもできるし、他のディスプレイの一部を利用する構成とすることもできる。

スピーカ３０５は、車室内に設置され、車両用装置１あるいは外部装置２から出力される音声データに基づいた音声を出力する。スピーカ３０５は、例えば車両用装置１や外部装置２からの警告や操作案内あるいは楽曲の再生などに用いられる。マイク３０７は、車室内に設置され、車両の乗員が発話した音声を音声データとして車両用装置１や外部装置２に出力する。このマイク３０７は、車両用装置１や外部装置２を操作する音声コマンドの入力などに用いられる。また、マイク３０７およびスピーカ３０５は、携帯端末７を利用したハンズフリー通話時の音声入力や音声出力に利用することができる。

位置検出装置３０８は、図示しないＧＰＳ受信機やジャイロセンサなどによって構成されており、車両の現在位置や向きを取得する。なお、ＧＰＳは、Global Positioning Systemの略である。また、ＧＰＳ受信機は、ＧＰＳ衛星から送信されるＧＰＳ測位信号を受信して、受信したＧＰＳ測位信号を出力するものであり、ジャイロセンサは、互いに直交するＸ軸、Ｙ軸およびＺ軸を中心とした回転の角速度を検出するものである。

カメラ３０６は、例えば、車両の後側に取り付けられており、車両の後方の状況を連続して撮影する。このカメラ３０６で撮像された画像は、例えば画像内に存在する物体の検出結果や車両を誘導するための誘導ラインなどとともにセンタディスプレイ３０１や他のディスプレイに表示される。チューナ３０９は、ＡＭ放送およびＦＭ放送のラジオ放送信号を受信する。また、チューナ３０９としてテレビ放送を受信するものを備えることもできる。

ＤＳＭ３１０は、撮像装置などで構成されており、運転者の顔を撮影した顔画像を画像解析することにより運転者の状態を検出するドライバステータスモニタである。なお、ＤＳＭ３１０は、Driver Status Monitorの略である。ＬＩＤＡＲ３１１は、レーザ光を送受信することで、車両の周囲に存在する物体の位置を検出する。なお、ＬＩＤＡＲ３１１は、Light Detection and Rangingの略である。

レーダ３１２は、ミリ波帯のレーダ３１２波を送受信することで、車両の周囲に存在する物体の位置を検出する。これらＤＳＭ３１０、ＬＩＤＡＲ３１１あるいはレーダ３１２による検出結果は、例えばディスプレイへの注意表示や警告表示あるいはスピーカ３０５からの音声出力によって運転者に報知される。

ＥＣＵ３１３は、車両に搭載されている電子機器である。一般的に、車両には複数のＥＣＵ３１３が搭載されており、車両用装置１は、これらのＥＣＵ３１３からエンジンやモータのような駆動部の駆動状態やドアの開閉状態などの車両に関する各種の情報を取得する。なお、ＥＣＵ３１３は、Electronic Control Unitの略である。

なお、図１では説明の簡略化のために１つのＥＣＵ３１３を示しているが、車両には複数のＥＣＵ３１３が搭載されており、車両用装置１は、例えばＣＡＮのような車載ネットワークを介して複数のＥＣＵ３１３と通信可能に接続されている。なお、ＣＡＮは、Controller Area Networkの略である。

次に、車両用装置１の基本的なソフトウェア構成について説明する。図２に示すように、車両用装置１は、複数のオペレーティングシステムが動作可能な仮想化環境が構築されている。以下、オペレーティングシステムをＯＳ８と称する。なお、ＯＳはOperating Systemの略である。

ただし、図２では、説明の簡略化のために幾つかの周辺機器３の図示を省略するとともに、各ＯＳ８で実行される機能のうち幾つかを抜粋した状態を例示している。そのため、車両用装置１および外部装置２は、必ずしも図２に示した全てのアプリケーション９が実行可能である必要はなく、仕様に応じて必要になるアプリケーション９が実行できればよい。

また、図２では、詳細は後述するが、外部装置２への機能の移管と外部装置２側からの機能の取得とが完了した状態におけるソフトウェア構成の一例を示している。例えば、図１では、外部装置２に設けられているメータアプリ９０１が車両用装置１によって取得されたことが破線にて模式的に示されているとともに、そのメータアプリ９０１が車両用装置１で実行されることが実線にて模式的に示されている。

車両用装置１は、制御部１０１上に、ハイパーバイザ１１１、サービスバス１１２、ファイアウォール１１３、ＲＴＯＳ８１、ＭＭＯＳ８２Ａが実装されている。なお、ＲＴＯＳ８１はReal Time ＯＳの略であり、ＭＭＯＳ８２はMulti Media ＯＳの略である。また、本実施形態では車両用装置１と外部装置２にそれぞれＭＭＯＳ８２を実装していることから、両者を区別し易くするために、車両用装置１に実装されているＭＭＯＳ８２にはＡを付し、外部装置２に実装されているＭＭＯＳ８２にはＢを付している。

また、本実施形態では、ＭＭＯＳ８２としてＡｎｄｒｏｉｄ（登録商標）を採用している。以下、ＲＴＯＳ８１やＭＭＯＳ８２に共通する事項を説明する場合には単にＯＳ８と称することがある。また、ＭＭＯＳ８２ＡとＭＭＯＳ８２Ｂとに共通する事項を説明する場合には単にＭＭＯＳ８２と称することがある。また、ＭＭＯＳ８２Ａ２とＭＭＯＳ８２Ｂは、同一のバージョンあるいは十分な互換性を有するバージョンであるものとする。

ハイパーバイザ１１１は、一般的な技術であるため詳細な説明は省略するが、ＲＴＯＳ８１とＭＭＯＳ８２Ａのような複数のＯＳ８を制御部１０１上で並列に実行可能とするためのプログラムであり、各ＯＳ８を管理する機能や各ＯＳ８間の通信を補助する機能などを有している。ただし、ハイパーバイザ１１１は、例えばＲＴＯＳ８１が備える機能の一部として実装することもできる。

サービスバス１１２は、各ＯＳ８のアプリケーション層と、それよりも下位の任意の層を示す下位層との間のデータのやり取りを行うためのプログラムである。このサービスバス１１２は、車両用装置１と外部装置２とがあたかも１つの装置であるかのようにデータをやり取りすることを可能とするために、下位層で用いるデータとアプリケーション層で用いるデータとの対応付けを行うためのデータベースを備えている。

また、サービスバス１１２は、データベースを参照することによってアプリケーション層と下位層との間でデータの形式を変換し、車両用装置１内におけるＲＴＯＳ８１とＭＭＯＳ８２Ａとの間、および、車両用装置１と外部装置２との間におけるデータのやり取りを可能にする。

ファイアウォール１１３は、各ＯＳ８間の不正なアクセスや、外部からのＲＴＯＳ８１やＭＭＯＳ８２Ａに対する不正なアクセスなどを制限する機能を備えている。なお、ファイアウォール１１３を実装するか否かは適宜選択することができ、他の手法でセキュリティを確保できる場合にはファイアウォール１１３を実装しない構成とすることもできる。

ＲＴＯＳ８１は、リアルタイム性が求められる処理の実行に適したものであり、車両の制御や安全性に関わる処理などを主として実行する。このＲＴＯＳ８１には、機能部としてのＨＭＩ処理部１１、判定部１２、およびリソース管理部１３などが実装されている。なお、ＨＭＩは、Human Machine Interfaceの略である。

これらの機能部は、本実施形態ではソフトウェアで実現されている。ただし、各機能部の一部あるいは全部をハードウェアで実現する構成とすることができるし、処理能力に問題が無ければ各機能部の一部あるいは全部をＭＭＯＳ８２Ａに実装することもできる。

ＨＭＩ処理部１１は、周辺機器３や他のアプリケーション９から入力されるデータに基づいて、センタディスプレイ３０１、メータディスプレイ３０２、ヘッドアップディスプレイ３０３およびエアコンディスプレイ３０４への表示を制御する処理などを実行する。また、ＨＭＩ処理部１１は、アプリケーション９から指示や画像作成の命令等に従って、図示しないＧＰＵを利用した画像データの作成等の処理も実行する。なお、ＧＰＵは、Graphics Processing Unitの略である。

判定部１２は、外部装置２が機能を実行可能な状態で接続されているか否かを判定する。この判定部１２は、外部装置２との間で通信を行い、外部装置２の接続状態や動作状態を把握することにより、機能を実行可能な状態で接続されているか否かを判定する。

リソース管理部１３は、外部装置２への機能の移管、および、外部装置２側からの新たな機能の取得に関する処理を実行する。具体的には、リソース管理部１３は、制御部１０１で実行可能な機能のうち少なくとも１つの機能の実行を外部装置２に移管することにより、制御部１０１が他の機能を実行するためのリソースを確保する。

また、リソース管理部１３は、外部装置２側との間でプログラムの実行ファイルや必要なデータを受け渡すなど、機能の実行を移管したり、新たな機能を取得したりするための処理を実行する。このとき、リソース管理部１３は、車両用装置１や外部装置２に予め実装されている機能を移管あるいは取得する以外にも、例えば携帯端末７を介してＯＴＡにより更新された機能を取得したりすることができる。なお、ＯＴＡは、Over The Airの略である。

以下では、機能の実行を外部装置２に移管することを、便宜的に、アプリケーション９を外部装置２に実行させる、あるいは、アプリケーション９を外部装置２に移管するなどとも称する。また、機能の実行を外部装置２に移管するとは、その機能を外部装置２が提供することを意味する。

ＭＭＯＳ８２Ａは、例えば一般的な携帯端末７などに利用されている汎用的なものであって、マルチメディア系の処理の実行に適したものである。本実施形態では、ＭＭＯＳ８２上では、例えば画面への表示処理や音声出力などの処理が実行される。以下、アプリケーション９を単にアプリとも称する。

このＭＭＯＳ８２Ａには、アプリケーション９として、例えばメータアプリ９０１、ＨＵＤアプリ９０２、カメラアプリ９０３、音声出力アプリ９０４、エアコンアプリ９０５、ナビゲーションアプリ９０６などが実行可能になっている。なお、ＨＵＤはHead Up Displayの略である。

メータアプリ９０１は、メータディスプレイ３０２に表示する例えば速度計や警告灯などの画像を生成するための指示や必要になる画像を生成するための演算を行う。つまり、本実施形態のメータアプリ９０１は、メータディスプレイ３０２へのアクセスを直接的に行うのではなく、メータディスプレイ３０２への画像の表示はＨＭＩ処理部１１に行わせる構成となっている。

ＨＵＤアプリ９０２は、ヘッドアップディスプレイ３０３への表示を制御するための機能を実現するものである。このＨＵＤアプリ９０２は、画像を生成するための指示や必要になる画像を生成するための演算を行う構成となっており、実際のヘッドアップディスプレイ３０３への画像の表示はＨＭＩ処理部１１に行わせる構成となっている。

カメラアプリ９０３は、カメラ３０６による撮影画像の表示を制御する機能を実現するためのものであり、画像中に存在する物体を検出、車両がバックする際の誘導ラインの演算等の処理を行う。このカメラアプリ９０３は、画像を生成するための指示や必要になる画像を生成するための演算を行うものであり、センタディスプレイ３０１への画像の表示や撮影画像と誘導ラインとの合成などはＨＭＩ処理部１１に行わせる構成となっている。

音声出力アプリ９０４は、スピーカ３０５に音声を出力する。なお、音声出力アプリ９０４は、例えばチューナ３０９が受信したラジオ放送信号やテレビ放送信号に基づいた音声の出力も行う。エアコンアプリ９０５は、車両に搭載されているエアコンディショナの制御を行う。

ナビゲーションアプリ９０６は、位置検出装置３０８が検出した位置情報などに基づいて、車両の現在地の表示、現在地から目的地までの経路の案内のための演算等を行うことでいわゆるナビゲーション機能を実現する。このナビゲーションアプリ９０６は、画像を生成するための指示や必要になる画像を生成するための演算を行うものであり、センタディスプレイ３０１への画像の表示はＨＭＩ処理部１１に行わせ、音声の出力は音声出力アプリ９０４に行わせる構成となっている。

ただし、図１では、車両用装置１に設けられているナビゲーションアプリ９０６が外部装置２に移管されたことを破線にて模式的に示すとともに、ナビゲーションアプリ９０６が外部装置２で実行されることを実線にて模式的に示している。また、ナビゲーションアプリ９０６は、マイク３０７で検出した音声を認識する音声認識を行う。

また、外部装置２のＭＭＯＳ８２Ｂには、メータアプリ９０１や外部機器通信アプリ９０７が実装されている。メータアプリ９０１は、外部装置２が車両用装置１に接続されると、上記したように車両用装置１に移管されて車両用装置１で実行される。

外部機器通信アプリ９０７は、無線通信装置２０３を用いた無線通信により携帯端末７との間でデータを送受信したり、受信したデータを車両用装置１へ送信したり、車両用装置１からのデータを携帯端末７に送信したりする機能を実現する。つまり、外部装置２は車両用装置１に接続されて利用されることが前提となっており、実装されているＯＳ８やアプリケーション９も車両用装置１と連携して動作する構成となっている。

この外部装置２は、車両用装置１を介してディスプレイへの表示やスピーカ３０５からの音声出力を行うとともに、機能の実行や停止といったユーザの操作も車両用装置１を介して入力される。そのため、外部装置２が機能を実行した状態で接続されている場合には、ユーザからはあたかも車両用装置１に機能が追加されたように見える。つまり、外部装置２は、車両用装置１に接続された際、車両用装置１からの機能の移管を受付可能であるとともに、当該移管された機能を実行可能に構成されている。

次に、上記した構成の作用について説明する。
前述のように、車両用装置１に複数のＯＳ８を実装する際、リアルタイム性が求められる処理に適したＲＴＯＳ８１と、マルチメディア系の処理に適しているＭＭＯＳ８２とを実装することがある。このとき、ＭＭＯＳ８２としては、一般的な携帯端末７等で利用されるＯＳ８が利用されることがある。

このようなＭＭＯＳ８２は、更新頻度が比較的高く、その更新によって搭載される機能も拡充されていく一方、要求されるハードウェアの性能も高くなっていくことが想定される。しかし、車両に搭載される車両用装置１は、出荷後に例えば１年ごとや数年ごとにハードウェアを更新する対応を取ることが困難であり、ＭＭＯＳ８２の更新や機能の拡充への対応が難しくなることが想定される。

これは、数年先に必要になることを見越して予め拡張性や将来性に余裕を持たせたハードウェア設計とすることは、現時点においては過剰な性能となることから、コストの観点から採用することが困難であるためである。なお、ここで言うハードウェアの更新とは、車両用装置１自体を取り換えることではなく、実装されているＣＰＵやメモリなどの部品を交換することにより性能を向上させることを意味している。

また、仮に例えば後からメモリを追加する等の部品の追加や交換をすることは、車両用装置１の品質確保という観点からすると、セキュリティ面や信号品質あるいは信頼性の確保が困難になることが予想される。以下、性能向上のためにハードウェアを更新することを、便宜的にバージョンアップと称する。

そこで、本実施形態の車両用装置１は、出荷された後であっても、新たな機能の追加や既存機能の処理速度向上を可能とすることにより、車両用装置１を介して提供される機能の拡充といった性能向上をハードウェア面、ソフトウェア面から図ることが容易にできる構成となっている。

まず、本実施形態の全体像について、車両用装置１、外部装置２および車両用システム４による概略の作用効果を述べながら説明する。車両用システム４を構成する車両用装置１は、外部装置２が接続される接続部５と、外部装置２が機能を実行可能な状態で接続されているか否かを判定する判定部１２とを備えている。また、外部装置２は、車両を利用する際に提供される機能を実行可能な外部制御部２０１を備えている。

そのため、車両用装置１は、機能を提供する際、自身が備える制御部１０１に加えて、接続部５に接続される外部装置２を利用することが可能となる。このとき、車両用装置１と外部装置２とは接続部５を介して通信可能に接続されるため、車両用装置１を車両に取り付けた後であっても、車両用装置１と外部装置２とを容易に接続することができる。

つまり、車両用装置１は、実質的に、機能を提供する際に利用可能な新たなハードウェア面でのリソースを確保することができる構成となっている。これにより、例えば出荷後に外部装置２を容易に接続することが可能となり、車両用装置１の性能向上を図ることが容易に行えるようになる。このとき、本実施形態のように車両用装置１と外部装置２とをＵＳＢ接続する構成とすれば、接続自体も容易に行うことができる。

そして、例えば外部装置２側でナビゲーションアプリ９０６を実行させることにより、つまりは、ナビゲーション機能を外部装置２に移管することにより、車両用装置１側に余剰のリソースが発生する。換言すると、機能の実行を外部装置２に移管することにより、車両用装置１は、他の機能を実行するためのリソースを確保することができる。

そのため、車両用装置１は、自身が備えていなかった例えばメータアプリ９０１を実行することにより、メータディスプレイ３０２への表示機能を得ることができる。つまり、車両用装置１は、新たに追加された周辺機器３を利用する機能、および、新たに取得したプログラムにより提供される機能、るまりは、アプリケーション９を実行することにより実現される機能を実行することができる。この場合、移管されたナビゲーションアプリ９０６は外部装置２で実行されることから、ナビゲーション機能が損なわれることもない。

このように、車両用装置１と外部装置２とを接続することにより、例えば車両用装置１に新たな機能を追加できるなど実質的な性能向上を図ることができる。そして、車両用装置１自身は、機能を移管したことにより自身のリソースが空くため、そのリソースを用いて他の機能を実行することができる。

次に、具体的な作用効果について、起動時から通常の動作が行われる定常状態までの処理の流れの概略とともに説明する。以下、車両用装置１および外部装置２を処理の主体とするとともに、各装置での処理の流れを対比させながら説明する。また、以下では主に車両用装置１を例にして説明しているが、その作用効果は、車両用システム４および車両用装置１に接続される外部装置２を利用することによっても同様に得ることができるものである。

さて、図３に示すように、車両用装置１は、電源がオンされると、ステップＳ１０１においてＣＰＵ１０４が起動し、その後、ステップＳ１０２においてＢＳＰをロードする。ＢＳＰは、Board Support Packageの略であり、例えばハードウェアを初期化するためのプログラムや、制御部１０１上でＯＳ８を実行させるために必要なプログラムを含んでいる。

ＢＳＰをロードすると、車両用装置１は、ステップＳ１０３においてハイパーバイザ１１１を起動した後、ステップＳ１０４においてＯＳ８を起動する。このステップＳ１０４では、ＲＴＯＳ８１とＭＭＯＳ８２Ａとを起動するが、本実施形態ではＲＴＯＳ８１を起動した後にＭＭＯＳ８２Ａを起動させる順序で各ＯＳ８を起動させている。

同様に、外部装置２は、電源がオンされると、ステップＳ２０１においてＣＰＵ２０４が起動し、ステップＳ２０２においてＢＳＰをロードし、ステップＳ２０３においてＭＭＯＳ８２Ｂを起動する。このとき、本実施形態では車両用装置１よりも外部装置２のほうが高性能であり、また、ソフトウェア構成もシンプルになっている。

そのため、基本的には車両用装置１よりも外部装置２のほうが早くＯＳ８が起動して車両用装置１からの指示を待機する待機状態になると考えられるそして、外部装置２は、車両用装置１からの接続を確認するための通信があると、ステップＳ２０４においてそれに応答する接続応答処理を実行しつつ次の指示を待機することになる。

さて、車両用装置１は、ＲＴＯＳ８１およびＭＭＯＳ８２Ａが起動すると、ステップＳ１０５においてサービスバス１１２を起動した後、ステップＳ１０６において外部装置２との接続を確認する。このステップＳ１０６は、判定部１２によって実行される処理であり、外部装置２が機能を実行可能な状態で接続されているか否かの判定が行われる。以下、外部装置２が機能を実行可能に接続されている状態を接続状態と称し、外部装置２が接続部５に接続されていない状態、あるいは、接続部５には接続されていても動作可能ではない状態を解除状態と称する。

車両用装置１は、外部装置２との間で接続確認用のデータをやり取りし、外部装置２から応答があった場合に接続状態であると判定する一方、車両用装置１は、所定時間内に外部装置２からの応答がなかった場合に解除状態であると判定する。このときやり取りするデータは、ＭＭＯＳ８２Ｂのバージョン情報やＭＭＯＳ８２Ｂに実装されているアプリケーション９の機能やバージョン情報を特定可能するためのデータなどを含めて適宜設定することができる。

これにより、接続状態の確認以外にも、外部装置２の性能の確認、外部装置２で実行可能な機能の確認、接続された外部装置２が車両用装置１に対応したものであるか否かの判定、外部装置２に実装されていて車両用装置１が取得可能なアプリケーション９の確認、外部装置２に移管することができるアプリケーション９の確認などを併せて行うことができる。

車両用装置１は、外部装置２からの応答がなかった場合には、外部装置２による機能の実行が可能ではない解除状態であると判定し、ステップＳ１０７においてＮＯとなることから、ステップＳ１０８を省略する。これに対して、車両用装置１は、外部装置２からの応答があった場合には、外部装置２による機能の実行が可能な接続状態であると判定し、ステップＳ１０７においてＹＥＳとなることから、ステップＳ１０８において有効化処理を実行する。

この有効化処理は、接続状態にある外部装置２に機能を移管および実行させる処理である。車両用装置１は、図４に示すように、ステップＳ３０１においてＭＭＯＳ８２Ｂとの同期を取る処理を実行し、ステップＳ３０２においてＭＭＯＳ８２Ｂへリソースを割り付ける。このステップＳ３０１ではＲＴＯＳ８１、ＭＭＯＳ８２ＡおよびＭＭＯＳ８２Ｂで利用する時刻を一致させる処理などが行われ、ステップＳ３０２ではＭＭＯＳ８２Ｂから周辺機器３へのアクセスを可能にするための処理などが行われる。

ここで、機能を移管および取得する際の基本的な考え方について説明する。図５にバージョンアップ前として一例を示すように、車両用装置１は、その製造時点においては、つまりは、バージョンアップ前の時点においては、メータディスプレイ３０２が搭載されていない車両に搭載されることを想定した仕様であったとする。なお、図５は、説明の簡略化のために図１および図２を簡略化して一部の周辺機器３と一部のアプリケーション９を示している。

バージョンアップ前の車両用装置１は、メータディスプレイ３０２に関する機能を実行する必要がないことから、メータアプリ９０１の実行を考慮していないハードウェア構成になっていると考えられる。換言すると、車両用装置１は、仕様に含まれている他の機能を実行するには十分であるものの、メータアプリ９０１を実行するにはリソースが不足する、あるいは、リソースが不足する可能性があるハードウェア設計になっていると考えられる。

そして、この車両用装置１を、図５にバージョンアップ後として示すように、メータディスプレイ３０２が搭載された車両に搭載することを想定する。この場合、車両用装置１単体ではリソースが不足する可能性があると考えられるものの、外部装置２を接続することにより、車両用システム４全体としてはリソースを確保することができると考えられる。すなわち、車両用装置１と通信可能な外部装置２を接続する構成としたことにより、車両用装置１自体を変更しなくても実質的にハードウェア性能を向上させることが可能になると考えられる。

ところで、車両用システム４全体としてのリソースが確保できるのであれば、車両用装置１の当初の仕様では想定されていなかった新しい機能については、外部装置２で実行するという選択肢も当然のことながら考えられる。しかし、本実施形態では、以下の理由により、車両用装置１側のリソースを確保する構成を敢えて採用している。

まず、提供する機能の中には、アプリケーション９が動作するＯＳ８や必要となる処理能力にもよるものの、車両用装置１で実行するほうが望ましい機能が存在する。例えばメータアプリ９０１は、速度や回転数などの速度メータといったリアルタイム性が要求される表示や警告灯といった安全性に関する処理を実行する。

その場合、メータアプリ９０１が実現するメータ画像の表示機能は、例えば１／３０秒といった短期間に更新する必要があることから、ＨＭＩ処理部１１との間でのデータのやり取りが頻繁に行われることが想定される。また、センタディスプレイ３０１への表示を行うために、ＨＭＩ処理部１１からメータディスプレイ３０２へのアクセス頻度が高くなることが想定される。また、メータアプリ９０１が実現する警告灯などの表示機能は、迅速かつ確実にユーザに通知するための即応性が求められることが想定される。

このように、データのやり取りや周辺機器３へのアクセスが頻繁に行われる機能については、外部装置２でその機能を実行すると、車両用装置１との間の通信や、その機能を実現するための連携しているアプリケーション９間の通信が頻繁に行われることになる。その結果、帯域が不足するといった通信経路にかかる負荷が高くなったり、本実施形態のようにＵＳＢ接続している場合には車両用装置１の通信処理にかかる負荷が高くなったりするおそれがある。

すなわち、提供する機能によっては、外部装置２との通信にかかる負荷が他の機能よりも相対的に高くなる機能が存在することがある。そして、外部装置２との通信にかかる負荷が相対的に高い機能については、車両用装置１で実行するほうが望ましい場合がある。

その一方で、外部装置２で実行するほうが望ましい場合も想定される。例えば純粋な演算処理については、演算元のデータと演算結果のデータとの通信を行えばよいことから通信にかかる負荷が比較的少ないと考えられる。その場合、演算処理については外部装置２で実行することにより、車両用装置１が確保可能なリソースが相対的に増加すると考えられる。

また、本実施形態の場合、外部装置２のほうが車両用装置１よりも処理能力が高くなっていることから、確保できるリソースがさらに増加すると考えられる。また、ある機能を実現するため必要な処理のうち例えば演算処理を外部装置２で実行させる構成、つまりは、機能の一部を移管して車両用装置１と外部装置２とにより機能を分業する構成においても同様に、確保できるリソースを増加させることができると考えられる。

このように、提供する機能によっては、車両用装置１で実行するほうが望ましいものと、外部装置２で実行するほうが望ましいものとが存在する。そして、いずれで実行するのかを適切に振り分けることができれば、全体としての性能向上を図ることができると考えられる。

そのため、本実施形態では、提供する機能のうち周辺機器３へのアクセス頻度が相対的に低い機能、または、外部装置２との通信にかかる負荷が相対的に低い機能については、外部装置２に移管することで、車両用装置１側のリソースを確保している。なお、周辺機器３へのアクセス頻度が相対的に低く、且つ、外部装置２との通信にかかる負荷が相対的に低い機能も移管の対象となる。

換言すると、本実施形態では、周辺機器３へのアクセス頻度が相対的に高い機能、または、外部装置２との通信にかかる負荷が相対的に高い機能については、車両用装置１側で実行している。なお、周辺機器３へのアクセス頻度が相対的に高く、且つ、外部装置２との通信にかかる負荷が相対的に高い機能も車両用装置１側で実行する対象となる。

具体的には、車両用装置１は、図４に示すステップＳ３０３において、外部装置２に機能を移管する。この場合、外部装置２が接続状態にあれば、外部装置２で機能を実行することができるため、車両用装置１は、自身が実行可能な機能のうち、外部装置２に実行させることができる機能を移管する。

例えば、図５にバージョンアップ後として示すように、車両用装置１は、ナビゲーションアプリ９０６の実行を矢印Ｆ１にて示すように外部装置２に移管する。これにより、ＭＭＯＳ８２Ａに実装されていたアプリケーション９で実現される例えばナビゲーション機能が、同系統のＭＭＯＳ８２Ｂが実装されていて実行可能な環境が構築されている外部装置２に移管される。

ナビゲーション機能は、画面の更新頻度がメータ表示に比べれば低いことから、通信にかかる負荷も相対的に低いと考えられる。そのため、外部装置２に機能を移管しても、他の機能に与える影響は少ないと考えられる。そして、機能を移管することにより、車両用装置１のリソースには余裕ができることになる。なお、ナビゲーション機能を実現するための演算処理を外部装置２に移管する構成、つまりは、機能の一部を移管する構成とすることもできる。

さて、機能を移管すると、車両用装置１は、ステップＳ３０４において取得可能な機能があるか否かを判定する。ここで、取得可能とは、物理的に取得できるものであること、および、外部装置２に機能を移管することにより確保できるリソースによって自身で実行可能であること意味している。例えば外部装置２にメータアプリ９０１が記憶されており、そのメータアプリ９０１を自身で実行可能であると判定した場合には、車両用装置１は、取得可能な機能があると判定する。

このとき、メータディスプレイ３０２が存在しているか否かについてはＥＣＵ３１３から車両情報を取得することなどにより判定することができ、メータアプリ９０１を自身で実行可能であるか否かはアプリケーション９内に記述しておく、あるいは、アプリケーション９に付帯するデータとして外部装置２に記憶しておくことにより把握できる。

そして、車両用装置１は、取得可能な機能があると判定した場合には、ステップＳ３０４においてＹＥＳとなることから、ステップＳ３０５においてその機能を取得する。この場合、車両用装置１は、例えば図５に矢印Ｆ２にて示すように、外部装置２に記憶されているメータアプリ９０１を自身にコピーすることにより機能を取得する。

機能を取得すると、車両用装置１は、ステップＳ３０６において取得した機能を実行し、ステップS３０７において外部装置２に移管した機能の実行を指示した後にリターンする。つまり、車両用装置１は、新たに追加された周辺機器３を利用する機能、および、新たにインストールされたプログラムによって実現される機能を実行する。

なお、車両用装置１は、取得可能な機能がないと判定した場合には、ステップＳ３０４においてＮＯとなることからステップＳ３０７に移行して機能の実行を指示した後にリターンする。なお、車両用装置１は、既に外部装置２と接続されたことがあり、その際に機能を取得済みである場合も取得可能な機能がないと判定する。

機能の取得や移管が完了すると、車両用装置１は、ステップＳ３０６において取得した機能を実行し、ステップＳ３０７において外部装置２に移管した機能の実行を指示した後、リターンする。そして、車両用装置１および外部装置２は、図２に示すように、通常の動作状態、つまりは、必要に応じて各種の機能を提供する定常状態に移行する。このとき、機能の取得結果や移管結果を記憶しておき、次回の起動時には各判定や取得あるいは移管の処理を省略する流れとすることもできる。

このように、車両用装置１は、外部装置２が機能を実行可能な状態で接続部５に接続されているか否かを判定し、外部装置２が機能を実行可能な状態で接続されていると判定された場合には、外部装置２に機能を移管することによって、他の機能を実行するための自身のリソースを確保している。

以上説明した構成によれば、次のような効果を得ることができる。
車両用装置１は、制御部１０１と、外部装置２が接続される接続部５と、判定部１２とを備えており、外部装置２が機能を実行可能な状態で接続されていると判定した場合、外部装置２を有効化して機能の実行を可能にする。

これにより、例えば車両出荷時には必要とされる性能を有していたものの、その後のＯＳ８のアップデートなどによって高性能化が必要になるような状況において、外部装置２を接続することで機能を提供するための性能向上を容易に図ることができる。

そして、車両用装置１は、リソース管理部１３により、自身が実行可能な機能のうち少なくとも１つの機能の実行を外部装置２に移管することによって、他の機能を実行するための自身のリソースを確保する。これにより、例えばリアルタイム性が必要とされる機能、周辺機器３へのアクセス頻度が高い機能、あるいは車両用装置１と外部装置２との間の通信経路にかかる負荷が高い機能などを車両用装置１で実行することが可能となる。

したがって、例えば出荷後に新たに追加された機能や新たに追加された周辺機器３を利用する機能などを、車両用装置１のハードウェア構成自体は変更することなく提供することができ、出荷後においても性能向上を図ることができる。

また、車両用装置１は、確保したリソースを利用して、新たに追加された周辺機器３を利用する機能を実行する。これにより、例えば出荷後に新たに追加された機能や新たに追加された周辺機器３を利用する機能を、車両用装置１のハードウェア構成自体は変更することなく提供することができる。

また、車両用装置１は、確保したリソースを利用して、新たにインストールされたプログラムによって実現される機能を実行する。これにより、例えば出荷後に新たに追加された機能や新たに追加された周辺機器３を利用する機能を、車両用装置１のハードウェア構成自体は変更することなく提供することができる。

また、車両用装置１は、確保したリソースで実行する機能を、外部装置２側から取得する。例えば、車両用装置１は、外部装置２に記憶されているプログラムを自身にコピーすることにより、機能を取得する。これにより、例えば出荷後に新たに追加された機能や新たに追加された周辺機器３を利用する機能を、車両用装置１のハードウェア構成自体は変更することなく提供することができる。

また、車両用装置１は、自身に実装されているプログラムを外部装置２に渡すことにより、外部装置２に機能の実行を移管する。これにより、例えば外部装置２にＯＳ８が実装されているもののアプリケーション９が実装されていない構成である場合、換言すると、外部装置２がリソースを確保するためのいわゆる拡張モジュールのような位置づけの構成である場合であっても、外部装置２に機能を実行させることができ、自身のリソースを確保することができる。

また、車両用装置１は、外部装置２に機能の実行を移管する際、当該機能を実現する処理の一部を外部装置２で実行させ、残りの処理を自身で実行する。例えば、車両用装置１は、ナビゲーション機能に関する処理のうち、演算処理を外部装置２で実行させ、表示処理を自身で実行する。このように機能の一部の実行を移管する構成によっても、演算の負荷が低減されることにより、他の機能を実行するための自身のリソースを確保することができる。

また、車両用装置１は、提供する機能のうち周辺機器３へのアクセス頻度が相対的に低い機能、または、外部装置２との通信にかかる負荷が相対的に低い機能を外部装置２に移管する。なお、周辺機器３へのアクセス頻度が相対的に低く、且つ、外部装置２との通信にかかる負荷が相対的に低い機能も移管の対象となる。これにより、通信経路の帯域が不足したり通信するための処理に時間がとられたりして機能を所望の応答時間内に提供できなくなるおそれを低減することができる。

また、車両用システム４は、周辺機器３へのアクセスが可能な車両用装置１と、車両用装置１と通信可能に接続され、車両用装置１を介して周辺機器３へのアクセスが可能な外部装置２とを備えている。

このような車両用システム４によっても、出荷後のＯＳ８のアップデートなどによって高性能化が必要になるような状況において、外部装置２を接続することで機能を提供するための性能向上を容易に図ることができるとともに、新たに追加された機能や新たに追加された周辺機器３を利用する機能などを、車両用装置１のハードウェア構成自体は変更することなく提供することができるなど、車両用装置１と同様の効果を得ることができる。

また、外部装置２は、車両を利用する際に提供される機能を実行可能であり、車両用装置１に接続された際、車両用装置１からの機能の移管を受付可能であるとともに、移管された機能を実行することによって車両用装置１のリソースを節約する外部制御部２０１を有している。

このような外部装置２を利用することによっても、出荷後のＯＳ８のアップデートなどによって高性能化が必要になるような状況において、外部装置２を接続することで機能を提供するための性能向上を容易に図ることができるとともに、新たに追加された機能や新たに追加された周辺機器３を利用する機能などを車両用装置１のハードウェア構成自体は変更することなく提供することができるなど、車両用装置１と同様の効果を得ることができる。

（第２実施形態）
以下、第２実施形態について説明する。第１実施形態ではプログラムそのものをコピーすることにより機能の移管や取得を行う構成例を示したが、第２実施形態では、第１実施形態とは異なる機能の移管や取得の幾つかの手法について説明する。なお、以下では主に車両用装置１について作用効果を説明するが、車両用装置１と外部装置２とを備える車両用システム４、および、車両用装置１に接続される外部装置２を利用することによっても、同様の作用効果を得ることができる。

車両用装置１が機能を移管する場合、外部装置２で実行される機能と重複する自身の機能を停止することにより外部装置２に機能を移管する構成とすることができる。例えば図６に示すように車両用装置１と外部装置２にそれぞれナビゲーションアプリ９０６が実装され、それぞれがナビゲーション機能を提供可能であったとする。

なお、各ナビゲーションアプリ９０６は互換性があるものとし、車両用装置１は、図３に示すステップＳ１０６の接続確認時に外部装置２に実装されている機能を取得することにより、移管しようとしている機能が外部装置２に既に実装されているか否かを判定する。

図６の場合、外部装置２にはナビゲーションアプリ９０６が実装されていることから、車両用装置１は、移管しようとしているナビゲーション機能が既に外部装置２に実装されていることを把握できる。なお、ナビゲーション機能のための演算処理といった機能の一部を外部装置２で代行可能な状態であることを把握する構成であってもよい。

その場合、車両用装置１は、図４のステップＳ３０３において機能を移管する際、外部装置２に実装されているナビゲーション機能の実行を許可するとともに、ハッチングにて模式的に示しているように自身に実装されているナビゲーション機能は実行しないことにより、実質的に外部装置２に機能を移管することができる。

このような構成によっても、車両用装置１は、外部装置２への機能の移管と自身のリソースの確保とを行うことが可能となり、外部装置２を接続することで機能を提供するための性能向上を容易に図ることができるとともに、新たに追加された機能や新たに追加された周辺機器３を利用する機能などを車両用装置１のハードウェア構成自体は変更することなく提供することができるなど、第１実施形態で説明したのと同様の効果を得ることができる。

また、車両用装置１が機能を取得する場合には、例えば図６に示すように外部装置２にエージェントインストーラ９１０を実装し、車両用装置１と接続された際、プログラムを単純にコピーするのではなく、エージェントアプリ９１１をインストールする構成とすることができる。

なお、エージェントアプリ９１１は、各種のものが想定されるが、例えばユーザの音声指示に基づいて対応する操作を代行したり、目的地を予想して経路案内を行ったり、ガソリンの残量をモニターして給油所を案内するなど、ユーザの利便性や快適性を向上させる機能を実現するプログラムを想定している。

この場合、車両用装置１と外部装置２とが接続されると、例えば車両用装置１からエージェントインストーラ９１０の実行を指示することにより、エージェントアプリ９１１が車両用装置１にインストールされる。これにより、外部装置２のＯＳ８のほうが新しく、単純にコピーすると不具合が生じるおそれがある場合であっても、予め車両用装置１のＯＳ８に対応したバージョンのものを用意しておくことで、適切に動作するアプリケーション９を取得することができる。

あるいは、車両用装置１が機能を取得する場合には、例えば図７に示すように外部装置２を経由して外部のサーバ２０にアクセスし、サーバ２０に記憶されている例えばエージェントアプリ９１１を矢印Ｆ４にて示すようにＯＴＡで取得する構成とすることができる。この場合、車両用装置１は、自身のバージョンを通知することにより、自身に適したバージョンのエージェントアプリ９１１を取得することができる。なお、図７では、ナビゲーション機能の一部を矢印Ｆ１にて示すように外部装置２に移管した状態を、ハッチングにて模式的に示している。

このように、確保したリソースで実行する機能を、外部装置２または外部装置２を経由する外部から取得する構成とすることができる。すなわち、外部装置２側から機能を取得する構成とすることができる。また、エージェントアプリ９１１以外のものを対象として同様に取得することもできる。

このような構成によっても、外部装置２を接続することで機能を提供するための性能向上を容易に図ることができるとともに、新たに追加された機能や新たに追加された周辺機器３を利用する機能などを車両用装置１のハードウェア構成自体は変更することなく提供することができるなど、第１実施形態で説明したのと同様の効果を得ることができる。

さて、ここまでは１つの機能を取得したり１つの機能を移管したりする例を示したが、複数の機能を取得したり、複数の機能を移管したりする構成とすることができる。また、その場合には、取得する機能に必要な処理能力等のリソースを求めて、必要となるリソースを確保できるように複数の機能を移管することができる。なお、必要となるリソースは、例えば取得する機能を実現するアプリケーション９内に記述したり、そのアプリケーション９に付帯するデータとして準備したりすることにより把握することができる。

例えば図８に示すように、サーバ２０からＡＲ／ＶＲアプリ９２０が取得する可能であったとする。なお、ＡＲ／ＶＲは、Augmented Reality／Virtual Realityの略である。このＡＲ／ＶＲアプリ９２０は、ユーザが見ている現実の風景に対し、図示しない投影装置を用いて例えばウィンドシールドに画像を表示することなどによって情報を付加することにより、現実世界を仮想的に拡張する拡張現実の機能を実現する。

また、ＡＲ／ＶＲアプリ９２０は、ディスプレイに仮想的な映像を表示することなどにより仮想世界を現実のように体験させる仮想現実の機能を提供する。なお、拡張現実と仮想現実の双方を実現するものであってもよいし、いずれか一方を実現するものであってもよい。

このようなＡＲ／ＶＲアプリ９２０は、車両の速度や向きが変化することに伴って変化する現実世界の風景に追従させる形で、表示する画像、画像の大きさ、画像の向きなどを変更すると考えられる。なお、車両の速度や向きの変化は、車載ネットワークを介してＥＣＵ３１３から取得することができる。

そのため、ＡＲ／ＶＲアプリ９２０を実行する場合には、扱うデータ量が比較的大きくなるとともに、処理に要する負荷も高くなることが想定される。つまり、ＡＲ／ＶＲアプリ９２０は、比較的多くのリソースを必要とすることが想定される。また、周辺機器３へのアクセス頻度も高くなることが想定される。

つまり、ＡＲ／ＶＲアプリ９２０は、通信にかかる負荷やアプリケーション９間の通信頻度などを考慮すると、車両用装置１で実行することが望ましいと考えられる。そのため、車両用装置１は、矢印Ｆ２および矢印Ｆ３で示すように、自身で実行するほうが望ましいメータアプリ９０１とＡＲ／ＶＲアプリ９２０とを外部装置２側から取得する。なお、図８では、移管されたアプリを破線にて示し、実行されるアプリを実線にて示している。

そして、車両用装置１は、自身で実行するメータアプリ９０１とＡＲ／ＶＲアプリ９２０の実行に必要となるリソースをアプリケーション９内の記述や付帯するデータに基づいて求め、求めたリソースを確保できるように、図８に破線にて示すＨＵＤアプリ９０２、音声出力アプリ９０４、エアコンアプリ９０５、ナビゲーションアプリ９０６などの複数の機能を、矢印Ｆ１にて示すように外部装置２にまとめて移管する。

このように、車両用装置１は、外部装置２側から機能を取得可能であり、取得する機能を実行する際に必要となるリソースを求め、求めたリソースを確保可能な数の機能を外部装置２に移管することで、自身に必要となるリソースを確保している。

このような構成によっても、外部装置２を接続することで機能を提供するための性能向上を容易に図ることができるとともに、新たに追加された機能や新たに追加された周辺機器３を利用する機能などを車両用装置１のハードウェア構成自体は変更することなく提供することができるなど、第１実施形態で説明したのと同様の効果を得ることができる。

上記した各具体例は、その構成の全部あるいは一部を他の具体例の全部あるいは一部と適宜組み合わせることができる。例えば、インストーラを用いる構成とＯＴＡにより取得する構成とを組み合わせたり、機能によっていずれの手法で取得あるいは移管するかを選択可能な構成としたりすることができる。すなわち、各実施形態で説明した機能を移管または取得する手法は、適宜組み合わせて利用することができる。

実施形態ではサービスバス１１２として車両用装置１と外部装置２をＵＳＢ接続により物理的に通信可能に接続する例を示したが、サービスバス１１２は、ＵＳＢ接続による通信に限らず、車両用装置１と外部装置２とを通信可能に接続するものであればよい。例えば接続部５として無線通信回路を採用することにより、物理的な接続をすることなく車両用装置１と外部装置２とを通信可能に接続する構成とすることができる。また、映像を伝送するための映像ラインを含める構成とすることもできる。

実施形態では通信により外部装置２の接続状態を判定する例を示したが、外部装置２と接続されたのか、あるいは、類似するＭＭＯＳ８２が搭載されている携帯端末７が接続されたのかを判定するために、外部装置２の認証機能を車両用装置１に設ける構成とすることができる。これにより、類似するＭＭＯＳ８２が搭載されている携帯端末７を誤って外部装置２と認識してしまうおそれを低減することができる。

実施形態ではハイパーバイザ１１１を各ＯＳ８から独立した形で実装し、そのハイパーバイザ１１１上で各ＯＳ８をそれぞれ動作させる例を示したが、他の構成とすることができる。例えばＲＴＯＳ８１がハイパーバイザ１１１機能を備えている場合には、まずＲＴＯＳ８１を起動してハイパーバイザ１１１機能を有効化した後、そのＲＴＯＳ８１上でＭＭＯＳ８２Ａを実行させる構成とすることもできる。

実施形態では車両用装置１に複数のＯＳ８を実装し、外部装置２に１つのＯＳ８を実装するソフトウェア構成例を示したが、他のソフトウェア構成とすることができる。例えば、車両用装置１に１つのＲＴＯＳ８１を実装し、外部装置２にＭＭＯＳ８２Ｂ１、ＭＭＯＳ８２Ｂ２のような複数のＯＳ８を実装する構成とすることができる。

実施形態ではアプリケーション９の実行ファイルをコピーすることにより機能を移管する例を示したが、アプリケーション９を実行する実行環境ごと、例えばＯＳ８ごとコピーすることにより、外部装置２に機能を移管する構成とすることができる。

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

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

図面中、１は車両用装置、２は外部装置、３は周辺機器、４は車両用システム、５は接続部、８はＯＳ、９はアプリケーション（機能、プログラム）、１２は判定部、１３はリソース管理部、８１～８２はＯＳ、１０１は制御部、２０１は外部制御部、３０１～３１３は周辺機器、９０１～９０７、９１０～９１１、９２０はアプリケーション（機能、プログラム）を示す。

Claims (9)

1. 周辺機器（３）へのアクセスが可能であり、車両を利用する際に提供される機能を実行可能な制御部（１０１）と、
   前記制御部と通信可能に接続され、当該制御部を介して前記周辺機器へのアクセスが可能な外部装置（２）が接続される接続部（５）と、
   前記外部装置が前記接続部に機能を実行可能な状態で接続されているか否かを判定する判定部（１２）と、
   前記外部装置が機能を実行可能な状態で接続されていると判定された場合、前記制御部で実行可能な機能のうち少なくとも１つの機能の実行を前記外部装置に移管することにより、前記制御部が他の機能を実行するためのリソースを確保するリソース管理部（１３）と、を備え、
   前記制御部は、提供する機能のうち周辺機器へのアクセス頻度が相対的に低い機能、または、前記外部装置との通信にかかる負荷が相対的に低い機能を、前記外部装置に移管する車両用装置。
2. 前記制御部は、確保したリソースを利用して、新たに追加された周辺機器を利用する機能を実行する請求項１記載の車両用装置。
3. 前記制御部は、確保したリソースを利用して、新たに取得したプログラムにより提供される機能を実行する請求項１記載の車両用装置。
4. 前記制御部は、確保したリソースで実行する機能を、前記外部装置側から取得する請求項１から３のいずれか一項記載の車両用装置。
5. 前記制御部は、前記外部装置側から機能を取得可能であり、取得する機能を実行する際に必要となるリソースを求め、求めたリソースを確保可能な数の機能を前記外部装置に移管する請求項１から４のいずれか一項記載の車両用装置。
6. 前記制御部は、実装されているプログラムを前記外部装置にコピーすることにより、前記外部装置に機能の実行を移管する請求項１から５のいずれか一項記載の車両用装置。
7. 前記制御部は、自身で実行可能な機能が前記外部装置に実装されている場合、前記外部装置による機能の実行を有効化するとともに、当該機能を自身では実行しないことにより、前記外部装置に機能の実行を移管する請求項１から６のいずれか一項記載の車両用装置
   。
8. 前記制御部は、前記外部装置に機能の実行を移管する際、当該機能を実現する処理の一部を前記外部装置で実行させ、残りの処理を自身で実行する請求項１から７のいずれか一項記載の車両用装置。
9. 周辺機器（３）へのアクセスが可能な車両用装置（１）と、
   前記車両用装置と通信可能に接続され、前記車両用装置を介して前記周辺機器へのアクセスが可能な外部装置（２）と、を備え、
   前記車両用装置は、
   周辺機器へのアクセスが可能であり、車両を利用する際に提供される機能を実行可能な制御部（２０１）と、
   前記制御部と通信可能に接続され、当該制御部を介して前記周辺機器へのアクセスが可能な外部装置が接続される接続部（５）と、
   前記外部装置が前記接続部に機能を実行可能な状態で接続されているか否かを判定する判定部（１２）と、
   前記外部装置が機能を実行可能な状態で接続されていると判定された場合、前記制御部で実行可能な機能のうち少なくとも１つの機能の実行を前記外部装置に移管することにより、前記制御部が他の機能を実行するためのリソースを確保するリソース管理部（１３）と、を有し、
   前記制御部は、提供する機能のうち周辺機器へのアクセス頻度が相対的に低い機能、または、前記外部装置との通信にかかる負荷が相対的に低い機能を、前記外部装置に移管する車両用システム。

Images