特許 7180516 車両用装置、車両用装置の制御方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-11-21

(45)【発行日】2022-11-30

(54)【発明の名称】車両用装置、車両用装置の制御方法

(51)【国際特許分類】

   G09G 5/00 20060101AFI20221122BHJP

   G09G 5/36 20060101ALI20221122BHJP

   B60K 35/00 20060101ALI20221122BHJP

   B60R 16/02 20060101ALI20221122BHJP

【ＦＩ】

G09G5/00 555P

G09G5/36 530C

G09G5/00 555S

G09G5/36 510A

B60K35/00 A

B60K35/00 Z

B60R16/02 640K

【請求項の数】 11

(21)【出願番号】P 2019077778

(22)【出願日】2019-04-16

(65)【公開番号】P2020177075

(43)【公開日】2020-10-29

【審査請求日】2021-03-03

(73)【特許権者】

【識別番号】000004260

【氏名又は名称】株式会社デンソー

(74)【代理人】

【識別番号】110000567

【氏名又は名称】弁理士法人サトー

(72)【発明者】

【氏名】谷端 伸彦

【審査官】橋本 直明

(56)【参考文献】

【文献】特開平０７－２４４５７２（ＪＰ，Ａ）

【文献】国際公開第２０１７／０３３２８９（ＷＯ，Ａ１）

【文献】特開２０１４－０２１８３３（ＪＰ，Ａ）

【文献】特開２００８－２８９０３０（ＪＰ，Ａ）

【文献】特開２０１５－０４１１９９（ＪＰ，Ａ）

【文献】特開２００８－０１５６３８（ＪＰ，Ａ）

【文献】特開２００９－１７９２４０（ＪＰ，Ａ）

【文献】特開２０１７－０６８３１２（ＪＰ，Ａ）

【文献】特開２０００－０５６９９２（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０９Ｇ ５／００

Ｇ０９Ｇ ５／３６

Ｂ６０Ｋ ３５／００

Ｂ６０Ｒ １６／０２

(57)【特許請求の範囲】

【請求項1】

複数のアプリケーションプログラム（２１）から描画が行われる車両用装置（１）であって、
複数の前記アプリケーションプログラムからの描画依頼に基づいて、表示器（２、３、４）にコンテンツとして表示される画像データであるサーフェスを、メモリ上に確保されるデータの格納領域のうち複数の前記アプリケーションプログラムに個別に割り当てられている格納領域である物理面に描画するグラフィック処理ユニット（１３）と、
前記グラフィック処理ユニットに対する描画依頼が入力される通常キュー（１３ａ）と、
前記通常キューよりも優先的に処理する描画依頼が入力される優先キュー（１３ｂ）と、を備え、
前記グラフィック処理ユニットは、前記優先キューに入力された描画依頼を優先しつつ、前記通常キューに入力された描画依頼をラウンドロビン形式で処理する車両用装置。

【請求項2】

複数の前記アプリケーションプログラムのうち少なくとも１つは、周期的な更新が必要とされる画像（Ｍ１～Ｍ８）の描画依頼を、前記優先キューに入力する請求項１記載の車両用装置。

【請求項3】

複数の前記アプリケーションプログラムのうち少なくとも１つは、警告表示用の画像（Ｍ３）の描画依頼を、前記優先キューに入力する請求項１または２記載の車両用装置。

【請求項4】

複数の前記アプリケーションプログラムのうち少なくとも１つは、描画を依頼する画像のうち優先的に処理すべき優先部位（Ｍ１ａ、Ｍ２ａ、Ｍ３、Ｍ８）を特定し、前記優先部位に対する描画依頼を前記優先キューに入力する一方、前記優先部位以外に対する描画依頼を前記通常キューに入力する請求項１から３のいずれか一項記載の車両用装置。

【請求項5】

複数の前記アプリケーションプログラムのうち少なくとも１つは、フルグラフィック表示が可能なメータディスプレイに表示する画像の描画依頼を入力するものであり、前記優先部位として、メータの針に対応する部位（Ｍ１ａ、Ｍ２ａ）、および、メータの警告灯に対応する部位（Ｍ３）の描画依頼のうち少なくとも一方を、前記優先キューに入力する請求項４記載の車両用装置。

【請求項6】

複数の前記アプリケーションプログラムのうち少なくとも１つは、フルグラフィック表示が可能なメータディスプレイに表示する画像の描画依頼を入力するものであり、前回描画した前記優先部位を消去するための描画依頼を、前記優先キューに入力する請求項４または５記載の車両用装置。

【請求項7】

複数の前記アプリケーションプログラムに優先順位を付け、相対的に優先順位が高い前記アプリケーションプログラムからの描画依頼を前記優先キューに入力し、相対的に優先順位が低い前記アプリケーションプログラムからの描画依頼を前記通常キューに入力する
請求項１から６のいずれか一項記載の車両用装置。

【請求項8】

車両用装置は、複数のオペレーティングシステム（２０）が実装されており、
複数の前記オペレーティングシステムに優先順位を付け、相対的に優先順位が高い前記オペレーティングシステムからの描画依頼を前記優先キューに入力し、相対的に優先順位が低い前記オペレーティングシステムからの描画依頼を前記通常キューに入力する請求項１から７のいずれか一項記載の車両用装置。

【請求項9】

車両用装置は、複数のＣＰＵモジュール（１６）を備えており、
複数の前記ＣＰＵモジュールに優先順位を付け、相対的に優先順位が高い前記ＣＰＵモジュールからの描画依頼を前記優先キューに入力し、相対的に優先順位が低い前記ＣＰＵモジュールからの描画依頼を前記通常キューに入力する請求項１から８のいずれか一項記載の車両用装置。

【請求項10】

車両用装置は、複数の表示器（２、３、４）に画面を出力するものであり、
複数の前記表示器に優先順位を付け、相対的に優先順位が高い前記表示器に対応する描画依頼を前記優先キューに入力し、相対的に優先順位が低い前記表示器に対応する描画依頼を前記通常キューに入力する請求項１から９のいずれか一項記載の車両用装置。

【請求項11】

複数のアプリケーションプログラム（２１）から描画が行われる車両用装置（１）の制御方法であって、
複数の前記アプリケーションプログラムからの描画依頼に基づいて、表示器（２、３、４）にコンテンツとして表示される画像データであるサーフェスを、メモリ上に確保されるデータの格納領域のうち複数の前記アプリケーションプログラムに個別に割り当てられている格納領域である物理面に描画する際、通常キュー（１３ａ）に入力された描画依頼と前記通常キューよりも優先的に処理される優先キュー（１３ｂ）に入力された描画依頼とを、前記優先キューに入力された描画依頼を優先しつつ、前記通常キューに入力された描画依頼をラウンドロビン形式で処理する車両用装置の制御方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、車両用装置、車両用装置の制御方法に関する。

【背景技術】

【0002】

車両用装置では、速度計などをフルグラフィック表示が可能なメータディスプレイが採用されることがある。そして、例えば特許文献１では、メータディスプレイに表示される画像を短い更新周期が必要となる部位とその他の部位とに分け、更新周期が短い部位をＣＰＵにて処理させることにより、画像を更新する際の負荷を低減することが提案されている。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０１６－６１８３７号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

ところで、近年では、１つの表示器に異なるコンテンツを表示したり、複数の表示器を１つの車両用装置で制御したりすることがある。つまり、車両用装置では、複数のアプリケーションプログラムから描画が行われることがある。この場合、複数のアプリでＣＰＵやグラフィック処理ユニットのリソースを共有することになるものの、速度の表示や警告の表示などは、即応性が必要とされることから、いわゆるマルチメディア系の描画よりも優先して処理つまり描画する必要がある。

【0005】

しかしながら、速度や警告の描画を全てにおいて優先してしまうと、他のアプリケーションプログラムへのＧＰＵのリソースが不足してしまい、結果として、マルチメディア系のアプリケーションプログラムによる描画、例えばナビゲーション画面の表示やホーム画面の表示などに不具合が生じるおそれがある。

【0006】

本発明の目的は、即応性が必要とされる描画を優先的に処理することができるとともに、他の描画へのグラフィック処理ユニットのリソースが不足するおそれを低減することができる車両用装置、車両用装置の制御方法を提供することにある。

【課題を解決するための手段】

【0007】

上記目的を達成するために、本発明では、車両用装置（１）は、複数のアプリケーションプログラム（２１）から描画が行われるものであって、複数のアプリケーションプログラムからの描画依頼に基づいて描画を行うグラフィック処理ユニット（１３）と、グラフィック処理ユニットに対する描画依頼が入力される通常キュー（１３ａ）と、通常キューよりも優先的に処理する描画依頼が入力される優先キュー（１３ｂ）と、を備え、グラフィック処理ユニットは、優先キューに入力された描画依頼を優先しつつ、通常キューに入力された描画依頼をラウンドロビン形式で処理する。

【0008】

このように、グラフィック処理ユニットに通常キューと優先キューとを設け、グラフィック処理ユニットに対してプリエンプションを行うことにより、ＣＰＵ側の負荷が増加することを抑制できる。これにより、ＣＰＵ側であるアプリケーションプログラムの処理を優先した結果、他のアプリケーションプログラムの実行が妨げられるような状況を回避することができる。

【0009】

そして、グラフィック処理ユニットは、優先キューに入力された描画依頼を優先するため、優先して処理すべき描画については迅速に処理することができる。また、通常キューに入力された描画依頼については、ラウンドロビン形式で処理されることから、リソースを均等且つ適切に分配することができる。

【0010】

したがって、複数のアプリケーションプログラムから描画が行われる場合であっても、即応性が必要とされる描画を優先的に処理することができるとともに、他の描画へのグラフィック処理ユニットのリソースが不足するおそれを低減することができる。そして、１つの表示器あるいは各表示器において、滑らかな表示を実現することができる。

【図面の簡単な説明】

【0011】

【図1】第１実施形態におけるコックピットシステムの構成例を示す図

【図2】車両用装置の電気的構成例を示す図

【図3】車両用装置のソフトウェア構成例を示す図

【図4】メータディスプレイの表示態様の一例を示す図

【図5】センターディスプレイの表示態様の一例を示す図

【図6】ヘッドアップディスプレイの表示態様の一例を示す図

【図7】各アプリに割り当てられている物理面の一例を示す図

【図8】描画依頼を行う処理の流れを示す図

【図9】ＧＰＵの動作態様の一例を示す図

【図10】車両用装置の他の構成例を示す図その１

【図11】車両用装置の他の構成例を示す図その２

【図12】第２実施形態による、ＧＰＵへのプリエンプション時の課題を示す図

【図13】優先部位を特定する処理の流れを示す図

【図14】ＧＰＵへのプリエンプションの態様を示す図

【図15】表示の更新態様の一例を示す図

【図16】表示の他の更新態様の一例を示す図

【図17】第３実施形態によるアプリ別の優先順位の一例を示す図

【図18】ＯＳ別の優先順位の一例を示す図

【図19】ＣＰＵモジュール別、および、コア別の優先順位の一例を示す図

【図20】表示器別の優先順位の一例を示す図

【発明を実施するための形態】

【0012】

以下、複数の実施形態について図面を参照しながら説明する。なお、各実施形態において実質的に共通する部位には同一の符号を付して説明する。

【0013】

（第１実施形態）
以下、第１実施形態について説明する。図１に示すように、車両用装置１は、例えば、メータディスプレイ２、センターディスプレイ３およびヘッドアップディスプレイ４の３つの表示器を備えるコックピットシステム５を構成している。

【0014】

メータディスプレイ２は、例えば液晶ディスプレイや有機ＥＬディスプレイで構成されており、ダッシュボードの運転者の正面付近に設けられるものを想定している。センターディスプレイ３は、例えば液晶ディスプレイや有機ＥＬディスプレイで構成され、センターコンソール付近に設けられるものを想定している。このメータディスプレイは、後述するように、いわゆるフルグラフィック表示で速度や警告などを表示可能な構成となっている。

【0015】

ヘッドアップディスプレイ４は、例えば液晶ディスプレイや有機ＥＬディスプレイあるいはフロントウィンドに画像を投影する投影器で構成されており、ダッシュボード上の運転者の正面付近に設けられるものを想定している。ただし、表示器の数や配置あるいは構成は一例であり、これらに限定されない。

【0016】

なお、図１では車両用装置１が複数の表示器に接続されている例を示しているが、本実施形態の車両用装置１は、後述するように複数のアプリケーションプログラム（以下、アプリ）から描画が行われる際の課題を解決するものである。そのため、車両用装置１に接続される表示器は１つ以上であればよい。

【0017】

この車両用装置１は、車両に設けられている幾つかの電子制御装置６（以下、ＥＣＵ６）と通信可能に接続されている。なお、車両用装置１もＥＣＵ６の１つとして考えることはできるものの、理解し易くするために、本明細書では車両用装置１とＥＣＵ６とを分けている。

【0018】

車両用装置１は、図２に示すように、ＣＰＵ１０、バスマスタ１１、メインメモリ１２、グラフィック処理ユニット１３(以下、ＧＰＵ１３）、画像処理ユニット１４（以下、ＩＰＵ１４）、通信部１５などを備えている。

【0019】

ＧＰＵ１３は、アプリから指示されたサーフェスを実際に描画する機能部である。つまり、アプリからＧＰＵ１３に対して後述する描画依頼が入力され、その描画依頼に基づいて、ＧＰＵ１３が実際のサーフェスを描画する。ここで、サーフェスとは、平易に言えば、ある瞬間に表示されているコンテンツ画像の元となる画像データである。また、ＧＰＵ１３には、後述する図９に示すように、描画依頼を入力する通常キュー１３ａと、優先的に処理すべき描画依頼が入力される優先キュー１３ｂとが設けられている。

【0020】

ＩＰＵ１４は、フレームバッファを読み出して表示器に例えば映像信号として出力する機能部である。つまり、ＩＰＵ１４によりフレームバッファ上に描画されたコンテンツを表示器に転送することにより、表示器にコンテンツが表示される。なお、ＩＰＵ１４は、必ずしもコンテンツを映像信号の形式で出力する必要はなく、データ形式で出力して表示器側でコンテンツに再生する構成とすることもできる。

【0021】

ＣＰＵ１０は、複数のコア１０ａを備えている。なお、ここでは、一例としてコア１０ａの数は８個としている。これら８個のコア１０ａは、４個ずつにとりまとめられ、２つのＣＰＵモジュール１６ＡとＣＰＵモジュール１６Ｂに割り振られている。つまり、車両用装置１内には、機能的に独立して動作可能な複数のＣＰＵモジュール１６が設けられている。

【0022】

また、ＣＰＵモジュール１６Ａは相対的にリアルタイム性が要求されるアプリケーション群２２Ａに割り当てられ、ＣＰＵモジュール１６Ｂは相対的にリアルタイム性が要求されないアプリケーション群２２Ｂに割り当てられている。以下、ＣＰＵモジュール１６に共通する説明をする際にはＡまたはＢを付さず、単にＣＰＵモジュール１６と称する。

【0023】

各ＣＰＵモジュール１６およびＧＰＵ１３にはそれぞれ専用のキャッシュメモリ１７が設けられている。以下、ＣＰＵモジュール１６Ａに設けられているものを便宜的にキャッシュ１７Ａと称し、ＣＰＵモジュール１６Ｂに設けられているものを便宜的にキャッシュ１７Ｂと称し、ＧＰＵ１３に設けられているものを便宜的にキャッシュ１７Ｇと称する。そして、各キャッシュメモリ１７は、バス１１ａおよびバスマスタ１１を介してメインメモリ１２とＩＰＵ１４に接続されており、相互にデータの送受信が可能に構成されている。

【0024】

通信部１５は、他のＥＣＵ６との間の通信を行う。この通信部１５は、例えばＣｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋインターフェースで構成されている。なお、ＥＣＵ６の種類によっては、例えばＷｉｆｉのような無線通信方式、あるいは、ＵＳＢのような有線通信方式を採用することもできる。

【0025】

車両用装置１は、図３に示すように、ＣＰＵ１０上でオペレーティングシステム２０（以下、ＯＳ２０）が実行され、そのＯＳ２０上で複数のアプリ２１が実行されている。ＯＳ２０上で実行されるアプリ２１としては、メータアプリ２１ａ、ナビアプリ２１ｂ、安全アプリ２１ｃ、映像アプリ２１ｄ、ＨＵＤアプリ２１ｅなどが設けられている。なお、ＨＵＤは、Ｈｅａｄ Ｕｐ Ｄｉｓｐｌａｙの略である。また、各アプリ２１は一例であり、ＯＳ２０上で実行されるアプリ２１はこれらに限定されない。

【0026】

メータアプリ２１ａは、車両の速度や回転数あるいは警告などをユーザに報知するものであるとともに、主にメータディスプレイ２に表示されるサーフェスを描画する。例えば、メータアプリ２１ａは、図４に通常表示モードとして示すユーザインターフェース２３のように、メータとしての速度計Ｍ１や回転数計Ｍ２、あるいは、テルテールとも称される警告灯Ｍ３などのコンテンツを表示するためのサーフェスを描画する。

【0027】

なお、上記したように、実際に描画を担当するのはＧＰＵ１３であり、メータアプリ２１ａなどは、ＧＰＵ１３に対して描画依頼を出力するものである。ただし、説明の簡略化のため、ここではメータアプリ２１ａが描画するといった表現をしている。これは、他のアプリ２１についても同様である。

【0028】

この、速度計Ｍ１は、車両の速度の変化を示すために周期的且つリアルタイムで表示を更新する必要がある針画像Ｍ１ａと、針画像Ｍ１ａに比べると表示の変化が少ないと想定される目盛り画像Ｍ１ｂとで構成されている。同様に、回転数計Ｍ２も、回転数の変化を示すために周期的且つリアルタイムで表示を更新する必要がある針画像Ｍ２ａと、針画像Ｍ２ａに比べると表示の変化が少ないと想定される目盛り画像Ｍ１ｂとで構成されている。また、メータディスプレイ２の場合、針画像Ｍ１ａや目盛り画像Ｍ１ｂなどとは異なるレイヤーに、背景画像ＭＢが描画されている。なお、これらの画像は一例である。

【0029】

ただし、メータアプリ２１ａが描画するサーフェスは、センターディスプレイ３やヘッドアップディスプレイ４にも表示可能である。また、メータアプリ２１ａによって描画されるサーフェスは、例示した他のアプリ２１によって描画されるサーフェスよりも、相対的にリアルタイム性が要求されるものとなっている。

【0030】

ナビアプリ２１ｂは、ナビゲーション機能を実現するものであるとともに、主にセンターディスプレイ３に表示されるサーフェスを描画する。例えば、ナビアプリ２１ｂは、図５に示すように、地図や車両の現在位置などを含むナビゲーション画面Ｍ４などのコンテンツを表示するためのサーフェスを描画する。ただし、ナビアプリ２１ｂが描画したサーフェスは、例えば図４にナビ表示モードとして示すようにメータディスプレイ２に表示することもできるし、ヘッドアップディスプレイ４にも表示することもできる。

【0031】

安全アプリ２１ｃは、メニューの表示や運転支援用の各種の機能を実現するものであるとともに、主にセンターディスプレイ３に表示されるサーフェスを描画する。例えば、安全アプリ２１ｃは、図５に示すように、対象となる機能やコンテンツを選択するために複数のアイコンを配置したホーム画面Ｍ５などのコンテンツを表示するためのサーフェスを描画する。ただし、安全アプリ２１ｃが描画したサーフェスは、例えば図４にメニュー表示モードとして示すようにメータディスプレイ２に表示することもできるし、ヘッドアップディスプレイ４にも表示することもできる。

【0032】

ＨＵＤアプリ２１ｅは、例えば速度や今後の進路などをユーザに報知するものであるとともに、主にヘッドアップディスプレイ４に表示されるサーフェスを描画する。例えば、ＨＵＤアプリ２１ｅは、図６に示すように、現在の速度情報Ｍ６や時刻情報Ｍ７あるいは曲がり角までの距離や曲がる方向などを示す進路情報Ｍ８を表示するためのサーフェスを描画する。ただし、ＨＵＤアプリ２１ｅが描画したサーフェスは、メータディスプレイ２やセンターディスプレイ３にも表示可能である。

【0033】

これらの各アプリ２１には、図７に示すように、サーフェスを描画するための物理面３０が個別に割り当てられている。つまり、各アプリ２１は、コンテンツの保持単位であるサーフェスを自身に割り当てられている物理面３０に描画する描画部として機能する。また、各アプリ２１は、コンテンツの保持単位であるサーフェスを自身に割り当てられている物理面３０に取り込んで同期させる同期部に相当する。

【0034】

これらの物理面３０は、キャッシュメモリ１７やメインメモリ１２上に、必要となるサーフェスを描画つまりは配置できる大きさで確保されている。なお、物理面３０の大きさは必ずしも表示器の画素数と一致させる必要はない。これは、物理面３０に描画されたサーフェスのうち必要なサーフェスが選択されて表示器に表示されるためである。

【0035】

本実施形態では、メータアプリ２１ａには物理面３０Ａが割り当てられており、ナビアプリ２１ｂには物理面３０Ｂが割り当てられており、安全アプリ２１ｃには物理面３０Ｃが割り当てられており、映像アプリ２１ｄには物理面３０Ｄが割り当てられており、ＨＵＤアプリ２１ｅには物理面３０Ｅが割り当てられている。そして、各物理面３０には、各アプリ２１によって１つ以上のサーフェスが描画される。

【0036】

例えば、物理面３０Ａには、メータアプリ２１ａによってサーフェスＳＡ１～ＳＡ３が描画される。同様に、物理面３０Ｂには、ナビアプリ２１ｂによってサーフェスＳＢ１が描画される。物理面３０Ｃには、安全アプリ２１ｃによってサーフェスＳＣ１、ＳＣ２が描画される。なお、図７では、説明の簡略化のために、安全アプリ２１ｃによって描画される複数のサーフェスをまとめてサーフェスＳＣ１としている。物理面３０Ｄには、映像アプリ２１ｄによってサーフェスＳＤ１が描画される。物理面３０Ｅには、ＨＵＤアプリ２１ｅによってサーフェスＳＥ１～ＳＥ３が描画される。なお、これらのサーフェスは一例である。

【0037】

また、各表示器に表示されるコンテンツは、少なくとも１つがアニメーション動作するものとなっている。ここで、アニメーション動作とは、コンテンツを示す画像の位置や大きさが徐々に変化したり、画像が回転したり、スワイプ操作にともなってユーザインターフェース２３が全体的に移動したり、画像が徐々にフェードインあるいはフェードアウトしたり、画像の色が変化したりするような表示態様である。

【0038】

例えば、図４に示したように、速度計Ｍ１や回転数計Ｍ２あるいは地図やメニューなどは、表示モードや表示先の表示器によってその大きさや位置が変化するコンテンツである。ただし、アニメーション動作はこれらに限定されず、ある時点から連続的あるは断続的に表示態様が変化するものであればアニメーション動作に含まれる。

【0039】

次に、上記した構成の作用について説明する。
上記した速度計Ｍ１や回転数計Ｍ２あるいは警告灯Ｍ３は、車両を利用する際に必須なものであるとともに、その表示に即応性が要求されるものである。例えば、速度計Ｍ１や回転数計Ｍ２は、例えば１秒間に６０回と言った周期的な表示の更新が必要であるとともに、車速の変化等に応じてリアルタイムな更新が必要になる画像である。これは、１／６０秒以内に表示が更新されなければ、針画像Ｍ１ａが固着して見えたり、滑らかに表示されなかったりするおそれがあるためである。

【0040】

また、警告灯Ｍ３は、例えばシートベルトが装着されていない状態や、ドアが閉まっていない状態を知らせるものであるため、それらが検知された場合には速やかに表示が更新される必要がある。つまり、警告灯Ｍ３は、車両の走行に必要とされるものであり、例えばナビゲーション画面Ｍ４のようないわゆるマルチメディア系の描画よりも優先して処理つまり描画する必要がある。なお、個々で示すものは一例であり、周期的な更新やリアルタイム性などの即応性が必要とされる描画はこれらに限定されない。

【0041】

その一方で、車両用装置１は、例えばメータディスプレイ２のような１つの表示器に異なるコンテンツを表示したり、本実施形態では複数の表示器を制御したりしている。つまり、車両用装置１は、異なるアプリ２１によって描画されたコンテンツを表示可能な構成となっている。そして、車両用装置１では、複数のアプリ２１がＣＰＵ１０やＧＰＵ１３のリソースを共有しているとともに、複数のＣＰＵモジュールがＧＰＵ１３のリソースを共有している。

【0042】

そのため、ＧＰＵ１３において例えばメータアプリ２１ａからの描画依頼を優先的に処理すると、他のアプリ２１がＧＰＵ１３を利用したいと思ってもリソースが不足して描画依頼を行えなくなるおそれがある。そして、速度計Ｍ１や警告灯Ｍ３などの表示と更新がスムーズに行われたとしても、ナビゲーション画面Ｍ４の表示や更新がスムーズに行われなければ、ユーザからみれば滑らかな表示が行われていないことになる。

【0043】

すなわち、複数のアプリ２１から描画が行われる車両用装置１の場合には、例えばメータアプリ２１ａからの描画依頼を優先するといった単純な構成では、他のアプリ２１で不具合が生じるおそれがある。

【0044】

そこで、本実施形態では、以下のようにして、複数のアプリ２１による描画が行われる場合において、即応性が必要とされる描画を優先的に処理することができるとともに、他の描画へのＧＰＵ１３のリソースが不足するおそれを低減している。なお、以下の処理は各アプリ２１やＧＰＵ１３で行われる処理であるが、説明の簡略化のため、ここでは車両用装置１を主体として説明する。

【0045】

車両用装置１は、描画を依頼する際、図８に示す処理を実行し、ステップＳ１において描画準備を行う。この描画準備は、平易に言えば、サーフェスを描画するための大きさや色などを用意する工程である。続いて、車両用装置１は、ステップＳ２において、優先すべき描画であるか否かを判定する。

【0046】

例えば、車両用装置１は、メータアプリ２１ａからの描画であれば、優先すべき描画であると判定する。なお、メータアプリ２１ａが自身で優先度を判定する構成とすることもできる。この場合、車両用装置１は、ステップＳ２においてＹＥＳとなるため、描画依頼を優先キュー１３ｂに対して出力する。つまり、優先すべき描画依頼は、優先キュー１３ｂに入力される。

【0047】

このとき、ＧＰＵ１３には、図９に示すように、通常キュー１３ａと優先キュー１３ｂとが設けられている。つまり、車両用装置１では、ＧＰＵ１３に対してプリエンプションを行う構成としている。これにより、ＣＰＵ１０側の負荷が増加することが抑制され、例えばあるアプリ２１の処理を優先した結果、他のアプリ２１の実行が妨げられるような状況を回避することができる。

【0048】

そして、ＧＰＵ１３は、図９にＲｅｑＡとして示すように、優先キュー１３ｂに入力された描画依頼を優先的に処理する。つまり、この場合であれば、メータアプリ２１ａから依頼されたサーフェスの描画を優先して行う。これにより、優先すべき描画依頼は、迅速に処理されてサーフェスが描画されることになる。

【0049】

一方、車両用装置１は、例えばＲｅｑＢとして示すナビアプリ２１ｂからのナビゲーション画面Ｍ４の描画依頼や、ＲｅｑＣとして示す安全アプリ２１ｃからのホーム画面Ｍ５の描画であれば、相対的に優先度が低いことから、優先すべき描画ではないと判定する。なお、ナビアプリ２１ｂや安全アプリ２１ｃが自身で優先度を判定する構成とすることもできる。この場合、車両用装置１は、ステップＳ２においてＮＯとなるため、描画依頼を通常キュー１３ａに対して出力する。つまり、相対的に優先度の低い描画依頼は、通常キュー１３ａに入力される。

【0050】

そして、ＧＰＵ１３は、図９に示すように、優先キュー１３ｂに入力された描画依頼を優先的に処理したのち、通常キュー１３ａに描画依頼があれば、その描画依頼をラウンドロビン形式で処理する。つまり、ＧＰＵ１３は、通常キュー１３ａに入力された描画依頼に対して、時系列でリソースを割り振りつつ順次処理を行っていく。これにより、通常キュー１３ａに入力された描画依頼は、均等にリソースが割り振られてサーフェスが描画されることになる。

【0051】

このように、車両用装置１は、１つのアプリ２１を優先する場合に他のアプリ２１に与える影響を考慮して、ＧＰＵ１３に対して通常キュー１３ａと優先キュー１３ｂとを設ける構成、換言すると、ＧＰＵ１３に対してプリエンプションを行う構成とすることにより、複数のアプリ２１から描画が行われる際の描画依頼を処理している。

【0052】

以上説明した実施形態によれば、次のような効果を得ることができる。
車両用装置１は、複数のアプリ２１から描画が行われるものであって、複数のアプリ２１からの描画依頼に基づいて描画を行うＧＰＵ１３と、ＧＰＵ１３に対する描画依頼が入力される通常キュー１３ａと、通常キュー１３ａよりも優先的に処理する描画依頼が入力される優先キュー１３ｂと、を備え、ＧＰＵ１３は、優先キュー１３ｂに入力された描画依頼を優先しつつ、通常キュー１３ａに入力された描画依頼をラウンドロビン形式で処理する。

【0053】

つまり、通常キュー１３ａおよび優先キュー１３ｂには、複数のアプリ２１からの描画依頼、複数のＯＳ２０からの描画依頼、複数のＣＰＵモジュール１６からの描画依頼、複数のＣＰＵ１０からの描画依頼、複数のコア１０ａからの描画依頼、および複数の表示器に対応した描画依頼のうち、少なくとも１つが入力される。

【0054】

このように、ＧＰＵ１３に対して通常キュー１３ａと優先キュー１３ｂとを設けてプリエンプションを行う構成としたことにより、複数のアプリ２１から描画が行われる際、１つのアプリ２１を優先した結果、他のアプリ２１の実行に対するＣＰＵ１０のリソースが足らなくなることを防止できる。

【0055】

そして、ＧＰＵ１３は、優先キュー１３ｂに入力された描画依頼を優先するため、優先して処理すべき描画については迅速に処理することができる。また、通常キュー１３ａに入力された描画依頼については、ラウンドロビン形式で処理されることから、リソースを均等且つ適切に分配することができる。

【0056】

したがって、複数のアプリケーションプログラムから描画が行われる場合であっても、即応性が必要とされる描画を優先的に処理することができるとともに、他の描画へのＧＰＵ１３のリソースが不足するおそれを低減することができる。その結果、１つの表示器あるいは各表示器において、滑らかな表示を実現することができる。

【0057】

また、複数のアプリ２１から描画が行われる車両用装置１において、複数のアプリ２１からの描画依頼に基づいて描画を行う際、通常キュー１３ａに入力された描画依頼と通常キュー１３ａよりも優先的に処理される優先キュー１３ｂに入力された描画依頼とを、優先キュー１３ｂに入力された描画依頼を優先しつつ、通常キュー１３ａに入力された描画依頼をラウンドロビン形式で処理する制御方法によっても、同様に、即応性が必要とされる描画を優先的に処理することができるようになるとともに、他の描画へのＧＰＵ１３のリソースが不足するおそれを低減することができる。

【0058】

また、車両用装置１の場合、複数のアプリ２１のうち少なくとも１つは、周期的な更新が必要とされる画像の描画依頼を、優先キュー１３ｂに入力する。これにより、例えばメータアプリ２１ａからの速度計Ｍ１や回転数計Ｍ２などの描画依頼を優先的に処理することができ、スムーズな表示を行うことができる。

【0059】

また、車両用装置１の場合、複数のアプリ２１のうち少なくとも１つは、警告表示用の画像の描画依頼を、優先キュー１３ｂに入力する。これにより、例えばメータアプリ２１ａからの警告灯Ｍ３などなどの描画依頼を優先的に処理することができ、即応性の高い表示を行うことができる。

【0060】

また、車両用装置１の場合、複数のアプリ２１に優先順位を付け、相対的に優先順位が高いメータアプリ２１ａなどからの描画依頼を優先キュー１３ｂに入力し、相対的に優先順位が低い例えばナビアプリ２１ｂなどからの描画依頼を通常キュー１３ａに入力する。これにより、優先度の高い描画依頼と相対的に優先度が低い描画依頼とを簡潔に管理することができる。

【0061】

さて、ここまでは車両用装置１に１つのＯＳ２０が実装されている構成例を示して説明したが、車両用装置１は、異なる構成とすることもできる。例えば、車両用装置１は、図１０に示すように、ＣＰＵ１０上でハイパーバイザ４０が実行され、そのハイパーバイザ４０上で複数、例えば２つのＯＳ２０ＡおよびＯＳ２０Ｂが実行される。

【0062】

このとき、ＯＳ２０ＡはＣＰＵモジュール１６Ａに割り当てられており、ＯＳ２０ＢはＣＰＵモジュール１６Ｂに割り当てられている。本実施形態では、ＯＳ２０Ａは相対的にリアルタイム性が高い処理を担当し、ＯＳ２０Ｂは相対的にリアルタイム性が低い処理を担当するものを想定している。

【0063】

例えば、ＯＳ２０Ａでは、リアルタイム性が要求される、例えばメータアプリ２１ａが実行され、ＯＳ２０Ｂでは、リアルタイム性がＯＳ２０Ａほど要求されないナビアプリ２１ｂや安全アプリ２１ｃ、映像アプリ２１ｄやＨＵＤアプリ２１ｅなどが実行される。なお、ＯＳ２０の種類や数あるいはアプリ２１ケーションの配置は一例であり、これらに限定されない。

【0064】

このような構成であっても、複数のアプリ２１による描画が行われる際、即応性が必要とされる描画を優先的に処理することができるとともに、他の描画へのリソースが不足するおそれを低減することができる。この場合、ハイパーバイザ４０は、ＯＳ２０Ａの機能として実行される構成とすることもできる。すなわち、ＣＰＵ１０上でＯＳ２０Ａを実行し、そのＯＳ２０の機能としてハイパーバイザ４０を動作させ、そのハイパーバイザ４０上でＯＳ２０Ｂを実行する構成とすることもできる。

【0065】

あるいは、車両用装置１は、図１１に示すように、複数のＣＰＵ１０を備え、各ＣＰＵ１０上でそれぞれＯＳ２０ＡおよびＯＳ２０Ｂが実行される構成とすることもできる。この場合も同様に、ＣＰＵ１０Ａでは、リアルタイム性が要求される例えばメータアプリ２１ａを実行し、ＣＰＵ１０Ｂでは、リアルタイム性がＣＰＵ１０Ａ側ほど要求されないナビアプリ２１ｂや安全アプリ２１ｃ、映像アプリ２１ｄやＨＵＤアプリ２１ｅなどを実行することができる。なお、ＣＰＵ１０の数あるいはアプリ２１ケーションの配置は一例であり、これらに限定されない。

【0066】

このような構成であっても、複数のアプリ２１による描画が行われる際、即応性が必要とされる描画を優先的に処理することができるとともに、他の描画へのリソースが不足するおそれを低減することができる。

【0067】

本実施形態では、周期的な更新が必要な画像として、主としてメータの針画像Ｍ１ａやＭ２ａあるいは警告灯Ｍ３を例にして説明したが、ナビゲーション画面Ｍ４、ホーム画面Ｍ５、速度情報Ｍ６、時刻情報Ｍ７あるいは進路情報Ｍ８なども、周期的な更新が必要な画像に含まれる。

【0068】

（第２実施形態）
次に、第２実施形態について説明する。第２実施形態では、ＧＰＵ１３に対してプリエンプションを行う際に生じる更なる課題とその解決手法について説明する。なお、説明の簡略化のために、車両用装置１やＯＳ２０あるいはアプリ２１には共通する符号を付して説明する。また、車両用装置１の構成は第１実施形態と共通するため、図２、図３、図１０あるいは図１１等も参照しながら説明する。また、描画依頼処理の流れについては、概ね第１実施形態と共通するため、図８も参照しながら説明する。

【0069】

まず、ＧＰＵ１３に対してプリエンプションを行う際に生じる更なる課題について説明する。前述のように、ＧＰＵ１３に対して通常キュー１３ａと優先キュー１３ｂとを設けてプリエンプションを可能とすることにより、複数のアプリ２１から描画が行われる際の描画依頼について、即応性が必要とされる描画を優先的に処理することができるようになるとともに、他の描画へのＧＰＵ１３のリソースが不足するおそれを低減することができる。

【0070】

ここで、例えばメータディスプレイ２への表示について検討してみる。メータディスプレイ２は、フルグラフィック表示可能なものであるため、画面全体を更新するのに要する期間が長くなりがちである。これは、メータディスプレイ２の高精細化や大型化が進むにつれて顕著になると考えられる。

【0071】

具体的には、図１２に比較例として示すように、優先キュー１３ｂにメータアプリ２１ａからの描画依頼が入力され、ほぼ同時期にナビアプリ２１ｂからの描画依頼と安全アプリ２１ｃからの描画依頼とが通常キュー１３ａに入力されたとする。この場合、ＧＰＵ１３は、優先キュー１３ｂに入力された描画依頼をまず処理し、その後、通常キュー１３ａに入力された描画依頼をラウンドロビン形式で処理する。

【0072】

しかし、メータアプリ２１ａからは、上記したように例えば１／６０秒といった周期で描画依頼が優先キュー１３ｂに入力されることになる。そのため、メータアプリ２１ａからの描画要求をＧＰＵ１３が処理し、続いてナビアプリ２１ｂからの描画依頼を処理したときに、再びメータアプリ２１ａからの描画要求が優先キュー１３ｂに入力されるといった状況が発生し得る。

【0073】

その場合、ＧＰＵ１３は、優先キュー１３ｂに入力された描画依頼を優先して処理するため、安全アプリ２１ｃからの描画依頼が言わば後回しにされることになる。このとき、ＧＰＵ１３がメータアプリ２１ａからの描画依頼を処理している最中に安全アプリ２１ｃから新たな描画依頼が出力されても、安全アプリ２１ｃからの前回の描画依頼が通常キュー１３ａに残っている。

【0074】

そのため、図１２に「×」の記号で示すように、新たな描画依頼は、通常キュー１３ａに入力されることなく保留される。そして、ＧＰＵ１３は、メータアプリ２１ａからの描画要求を処理した後、通常キュー１３ａに入力されている安全アプリ２１ｃからの描画依頼を処理する。

【0075】

このように、１つの車両用装置１において複数のアプリ２１から描画を行う場合や、１つの車両用装置１で複数の表示器を制御する場合には、ＧＰＵ１３へのプリエンプションを行ったとしても、通常キュー１３ａに入力された描画依頼を処理しきれなくなるおそれがある。

【0076】

そこで、本実施形態では、以下のようにして、各アプリ２１からの描画要求を処理できるようにしている。車両用装置１は、図１３に示す優先部位を特定する処理を実行する。なお、この処理はアプリ２１側で行われるが、説明の簡略化のため、ここでは車両用装置１を主体としている。続いて、車両用装置１は、ステップＳ２において、その描画が優先部位に対するものであるか否かを判定する。

【0077】

ここで、優先部位とは、更新される画面全体のうち、優先して更新する部位である。この優先部位は、例えば、画面を構成するパーツ単位の部位や、前回描画された画面との差分が生じる部位つまりは前回とは異なる描画が必要な部位が該当する。

【0078】

例えば、メータアプリ２１ａの場合であれば、速度計Ｍ１の針画像Ｍ１ａを優先部位とし、目盛り画像Ｍ１ｂは優先部位にしないといったことができる。同様に、回転数計Ｍ２の針画像Ｍ２ａを優先部位とし、目盛り画像Ｍ２ｂは優先部位にしないといったことができる。また、警告灯Ｍ３であれば、全てを優先部位とすることができる。

【0079】

針画像Ｍ１ａや目盛り画像Ｍ１ｂは、速度計Ｍ１を表示する際のパーツとして考えることができる部位である。そして、図１５に示すように、針画像Ｍ１ａは、更新される前と後とでその位置などが変化すると考えられる一方、目盛り画像Ｍ１ｂは、更新される前と後とで実質的には変化しないと考えられる。なお、これは、本実施形態での例であり、針画像Ｍ１ａが目盛り画像Ｍ１ｂに重なる表示態様の場合には、目盛り画像Ｍ１ｂも更新前後で変化することがある。

【0080】

この点、図４に示した通常表示モードを参照すると、更新前後で変化すると考えられる速度計Ｍ１の針画像Ｍ１ａ、回転数計Ｍ２の針画像Ｍ２ａ、および警告灯Ｍ３は、画面全体からみればごく一部であることが分かる。そのため、優先部位を更新するために要する期間は、画面全体を更新するために要する期間に比べて大幅に短縮可能であると期待できる。

【0081】

そのため、車両用装置１は、フルグラフィック表示が可能なメータディスプレイ２に表示する画像の描画依頼を入力するものであり、優先部位として、メータの針画像Ｍ１ａ、針画像Ｍ２ａ、および、警告灯Ｍ３の描画依頼のうち少なくとも一方、本実施形態では双方を、優先キュー１３ｂに入力する。

【0082】

より具体的には、車両用装置１は、図１３に示す処理において、準備した画像が優先部位である場合には、優先部位に対する描画依頼であると判定する。この場合、車両用装置１は、ステップＳ１２がＹＥＳとなることから、その描画依頼を優先キュー１３ｂに出力する。一方、車両用装置１は、優先部位に対する描画依頼ではないと判定した場合には、ステップＳ１２がＮＯとなることから、その描画依頼を通常キュー１３ａに出力する。

【0083】

このように、車両用装置１は、１つのアプリ２１から描画が行われる画面全体のうち、優先的に描画すべき優先部位を特定し、第１実施形態でＲｅｑＡとして説明した画面全体の描画依頼を、図１４にＲｅｑＡ１として示す優先部位に対する描画依頼と、ＲｅｑＡ２として示すその他の部位に対する描画依頼とに分ける。なお、図１４では便宜的に「針」と示しているが、優先部位に対する描画依頼には警告灯Ｍ３の描画要求も含まれている。

【0084】

そして、車両用装置１は、優先部位に対する描画依頼を優先キュー１３ｂに出力し、その他の部位に対する描画依頼を通常キュー１３ａに出力する。また、車両用装置１は、優先部位に対する描画依頼を優先キュー１３ｂに出力し、その他の部位に対する描画依頼を通常キュー１３ａに出力する処理を含む制御方法を採用している。

【0085】

これにより、ＧＰＵ１３は、優先キュー１３ｂに入力された描画要求に対する描画、つまりは、優先すべき描画を画面全体を更新する場合に比べて短期間で行うことができる。そして、優先すべき描画を短期間で行うことができることから、通常キュー１３ａに入力された描画要求をラウンドロビン形式で処理する際の余裕を確保でき、上記した図１２で説明した通常キュー１３ａに入力された描画要求を処理しきれなくなるおそれを低減することができる。

【0086】

以上説明した実施形態によれば、次のような効果を得ることができる。
まず、車両用装置１は、ＧＰＵ１３に対してプリエンプションを行っていることから、上記した第１実施形態と同様に、複数のアプリ２１から描画が行われる際の描画依頼について、即応性が必要とされる描画を優先的に処理することができるようになるとともに、他の描画へのＧＰＵ１３のリソースが不足するおそれを低減することができる。これは、本実施形態による制御方法によっても同様である。

【0087】

そして、車両用装置１では、複数のアプリ２１のうち少なくとも１つは、描画を依頼する画像のうち優先的に処理すべき優先部位を特定し、優先部位に対する描画依頼を優先キュー１３ｂに入力する一方、優先部位以外に対する描画依頼を通常キュー１３ａに入力する。

【0088】

これにより、優先すべき描画を短期間で行うことができるとともに、通常キュー１３ａに入力された描画要求をラウンドロビン形式で処理する際の余裕を確保でき、通常キュー１３ａに入力された描画要求を処理しきれなくなるおそれを低減することができる。すなわち、１つのアプリ２１を優先する場合に他のアプリ２１に与える影響を考慮して、優先度が高い描画と相対的に優先度が低い描画とを処理することができる。

【0089】

また、車両用装置１では、複数のアプリ２１のうち少なくとも１つは、フルグラフィック表示が可能なメータディスプレイ２に表示する画像の描画依頼を入力するものであり、優先部位として、メータの針画像Ｍ１ａおよび針画像Ｍ２ａに対応する部位の描画依頼を優先キュー１３ｂに入力する。また、車両用装置１では、複数のアプリ２１のうち少なくとも１つは、警告表示用の画像つまりは警告灯Ｍ３の描画依頼を、優先キュー１３ｂに入力する。これらにより、定期的な更新や即応性が必要とされる針画像Ｍ１ａや針画像Ｍ２ａおよび警告灯Ｍ３を、適切に表示つまりは更新することができる。

【0090】

ところで、優先部位を特定することにより、優先部位の更新を適切に行うことができるものの、懸念される点もある。例えば、速度計Ｍ１の針画像Ｍ１ａの描画要求を優先キュー１３ｂに入力し、それ以外の部位の描画を通常キュー１３ａに入力した場合であれば、タイミングによっては、図１６に比較例として示すように、更新後の画面に、更新前の位置で針画像Ｍ１ａが残像のように表示されてしまう可能性がある。これは、更新後の針画像Ｍ１ａが優先して描画され、それ以外の画像の更新が後に来るためである。

【0091】

そのため、車両用装置１は、複数のアプリ２１のうち少なくとも１つがフルグラフィック表示が可能なメータディスプレイ２に表示する画像の描画依頼を入力するものである場合、前回描画した優先部位を消去するための描画依頼を、優先キュー１３ｂに入力する構成とすることができる。このような構成とすれば、図１６に実施例として示すように、更新前の位置の針画像Ｍ１ａは、破線にて模式的に示すように消去され、残像のように表示されてしまうおそれを防止することができる。

【0092】

このとき、前回描画した優先部位は、上記したように画面のごく一部であり、消去するために他のアプリ２１へのリソースが不足する懸念は低いと考えられる。また、前回描画した優先部位は、既に描画されているものであり、再度の準備が必要ないため、ＣＰＵ１０の負荷が不要に増加することも抑制される。なお、描画依頼のあった画像を配置する部位の現状を一時的に記憶しておき、次に描画依頼があった際に、記憶した部位を描画することにより、前回描画した領域を消去する構成とすることもできる。

【0093】

本実施形態では、優先部位として、主に針画像Ｍ１ａ、針画像Ｍ２ａおよび警告灯Ｍ３を例にして説明したが、例えば進路情報Ｍ８は走行中に参照される情報であり、車両の移動に応じて随時更新する必要があるとともにリアルタイム性も要求されると考えられる。そのため、ＨＵＤアプリ２１ｅは、進路情報Ｍ８を優先部位として描画要求を優先キュー１３ｂに出力し、その他の部位については通常キュー１３ａに出力することなどができる。これは、他のアプリ２１についても同様である。

【0094】

（第３実施形態）
次に、第３実施形態について説明する。第３実施形態では、通常キュー１３ａと優先キュー１３ｂとに入力する描画要求の他の例について説明する。なお、車両用装置１の構成は第１実施形態や第２実施形態と共通する。

【0095】

例えば、車両用装置１は、図１７にアプリ別として示すように、複数のアプリ２１に例えば数値が低いほど優先度が高くなる態様で優先順位を付け、相対的に優先順位が高い例えばメータアプリ２１ａなどからの描画依頼を優先キュー１３ｂに入力し、相対的に優先順位が低い例えばナビアプリ２１ｂなどからの描画依頼を通常キュー１３ａに入力する構成とすることができる。

【0096】

このようにアプリ２１別に優先度を管理する構成によっても、優先度の高い描画依頼と相対的に優先度が低い描画依頼とを簡潔に管理することができる。勿論、複数のアプリ２１から描画が行われる際の描画依頼について、即応性が必要とされる描画を優先的に処理することができるようになるとともに、他の描画へのＧＰＵ１３のリソースが不足するおそれを低減することができるなど、第１実施形態と同様の効果を得ることができる。

【0097】

また、車両用装置１は、上記した図１０や図１１のように複数のＯＳ２０が実装されている場合、図１８にＯＳ別として示すように、複数のＯＳ２０に優先順位を付け、相対的に優先順位が高いＯＳ２０からの描画依頼を優先キュー１３ｂに入力し、相対的に優先順位が低いＯＳ２０からの描画依頼を通常キュー１３ａに入力する構成とすることができる。

【0098】

このようにＯＳ２０別に優先度を管理する構成によっても、優先度の高い描画依頼と相対的に優先度が低い描画依頼とを簡潔に管理することができる。勿論、複数のアプリ２１から描画が行われる際の描画依頼について、即応性が必要とされる描画を優先的に処理することができるようになるとともに、他の描画へのＧＰＵ１３のリソースが不足するおそれを低減することができるなど、第１実施形態と同様の効果を得ることができる。

【0099】

また、車両用装置１は、上記した図２や図１０あるいは図１１のように複数のＣＰＵモジュール１６を備えている場合、図１９にモジュール別として示すように、複数のＣＰＵモジュール１６に優先順位を付け、相対的に優先順位が高いＣＰＵモジュール１６からの描画依頼を優先キュー１３ｂに入力し、相対的に優先順位が低いＣＰＵモジュール１６からの描画依頼を通常キュー１３ａに入力する構成とすることができる。

【0100】

このようにＣＰＵモジュール１６別に優先度を管理する構成によっても、優先度の高い描画依頼と相対的に優先度が低い描画依頼とを簡潔に管理することができる。勿論、複数のアプリ２１から描画が行われる際の描画依頼について、即応性が必要とされる描画を優先的に処理することができるようになるとともに、他の描画へのＧＰＵ１３のリソースが不足するおそれを低減することができるなど、第１実施形態と同様の効果を得ることができる。

【0101】

また、車両用装置１は、上記した図２や図１０あるいは図１１のように複数のコア１０ａを備えている場合、図１９にコア別として示すように、複数のコア１０ａに優先順位を付け、相対的に優先順位が高いコア１０ａからの描画依頼を優先キュー１３ｂに入力し、相対的に優先順位が低いコア１０ａからの描画依頼を通常キュー１３ａに入力する構成とすることができる。また、車両用装置１は、上記した図１１のように複数のＣＰＵ１０を備えている場合には、図１９にＣＰＵ別として示すように、複数のＣＰＵ１０に優先順位を付ける構成とすることもできる。

【0102】

このようなコア１０ａ別またはＣＰＵ１０別に優先度を管理する構成によっても、優先度の高い描画依頼と相対的に優先度が低い描画依頼とを簡潔に管理することができる。勿論、複数のアプリ２１から描画が行われる際の描画依頼について、即応性が必要とされる描画を優先的に処理することができるようになるとともに、他の描画へのＧＰＵ１３のリソースが不足するおそれを低減することができるなど、第１実施形態と同様の効果を得ることができる。

【0103】

また、車両用装置１は、上記した図１、図２、図１０あるいは図１１のように複数の表示器に接続される場合、図２０に表示器別として示すように、複数の表示器に優先順位を付け、相対的に優先順位が高い表示器に対する描画依頼を優先キュー１３ｂに入力し、相対的に優先順位が低い表示器に対する描画依頼を通常キュー１３ａに入力する構成とすることができる。

【0104】

このような表示器別に優先度を管理する構成によっても、優先度の高い描画依頼と相対的に優先度が低い描画依頼とを簡潔に管理することができる。勿論、複数のアプリ２１から描画が行われる際の描画依頼について、即応性が必要とされる描画を優先的に処理することができるようになるとともに、他の描画へのＧＰＵ１３のリソースが不足するおそれを低減することができるなど、第１実施形態と同様の効果を得ることができる。

【0105】

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

【0106】

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

【符号の説明】

【0107】

図面中、１は車両用装置、２はメータディスプレイ（表示器）、３はセンターディスプレイ（表示器）、４はヘッドアップディスプレイ（表示器）、１３はＧＰＵ（グラフィック処理ユニット）、１６Ａ、１６ＢはＣＰＵモジュール、２０Ａ、２０Ｂはオペレーティングシステム、２１はアプリ（アプリケーションプログラム）、２１ａはメータアプリ（アプリケーションプログラム）、２１ｂはナビアプリ（アプリケーションプログラム）、２１ｃは安全アプリ（アプリケーションプログラム）、２１ｄは映像アプリ（アプリケーションプログラム）、２１ｅはＨＵＤアプリ（アプリケーションプログラム）、Ｍ１～Ｍ８は画像、Ｍ１ａは針画像（優先部位）、Ｍ２ａは針画像（優先部位）、Ｍ３は警告灯（優先部位）、Ｍ８は走行情報（優先部位）を示す。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】