JP6032176B2 - 車両用表示制御装置 - Google Patents

Description

本発明は、車載機器で動作するアプリケーションによる表示出力を制御する車両用表示制御装置に関する。

従来、無線通信により外部から特定のアプリケーションを取込み、そのアプリケーションによる情報提供をする車両用装置（例えば、ナビゲーション装置や多機能ディスプレイ）の車両用装置が開発されている（非特許文献１参照）。

"Ｇ−ＢＯＯＫ．ｃｏｍ"、［online］、トヨタメディアサービス株式会社、［平成２４年１０月２９日検索］、インターネット＜ＵＲＬ：http://g-book.com/pc/default.asp＞

しかし、従来の車両用装置においては、外部からアプリケーションを取込んで動作させるために、その車両用装置における動作要件に適合する専用のアプリケーションを個別に開発する必要があった。例えば、スマートフォンやタブレットＰＣ等の携帯情報端末向けに、Android（登録商標）やｉＯＳ（登録商標）等の汎用プラットフォームに対応した汎用アプリケーションが開発されているが、それらの汎用アプリケーションは、そのままでは車両用装置に取込み、動作させることはできなかった。

一方、スマートフォンやタブレットＰＣ等の携帯情報端末で流行の機能を車両用装置で実現するために、携帯情報端末向けに開発された汎用アプリケーションに対応した汎用プラットフォームを車載用装置に搭載する手段が考えられる。このような手段では、車両用装置の組込み機能として予め実装されている、車両用のネイティブアプリケーションと、外部から取込んだ汎用アプリケーションとが共存動作する上で、次のような問題がある。

それは、汎用アプリケーションが車両用装置の仕様に基づき設計・制作されていないことが原因で、ネイティブアプリケーションと相容れない動作をする可能性があることである。例えば、ネイティブアプリケーションによる出力画面がディスプレイに表示されるべきタイミングで、外部から取得された汎用アプリケーションによる出力画面が表示されたために、本来のネイティブアプリケーションの出力画面が表示されない可能性がある。

このような事態を回避するために、ネイティブアプリケーションが行う表示出力と、外部から取込まれた汎用アプリケーションが行う表示出力とが競合しないように調整しなければならない。そのような事情により、従来の車両用装置においては、外部から取込まれる汎用アプリケーションに、取込み先の車両用装置での動作要件を考慮した個別の仕組みを設ける必要があった。しかしながら、車両用装置の要件に合った汎用アプリケーションを個別に開発するのには多大な開発資源を必要とし、また、それが情報鮮度や汎用性の高いアプリケーションの普及を妨げる要因にもなる。

本発明は、上記問題に鑑みなされたものである。本発明は、車両用の組込みシステムにおいて汎用プラットフォームを共存動作させる上で、ネイティブアプリケーションによる出力画面と汎用アプリケーションによる出力画面との同時表示や連携表示が可能な仕組みを提供することを目的とする。

上記目的を達成するためになされた本発明の車両用表示制御装置は、ネイティブプラットフォームと、汎用プラットフォームと、共有メモリ領域とを備える。ネイティブプラットフォームは、車両用の組込み機能として予め実装されたネイティブアプリケーションを動作させるための基本ソフトウェアである。汎用プラットフォームは、ネイティブプラットフォーム上に仮想化して実装された基本ソフトウェアであって、外部との情報通信を通じて導入される汎用アプリケーションを動作させるためのものである。共有メモリ領域は、汎用プラットフォームと、ネイティブプラットフォームと汎用プラットフォームとの間で、データを共有するためのメモリ領域である。

このうち、汎用プラットフォームは、動作中の汎用アプリケーションによって描画された画像である汎用アプリ画像を共有メモリ領域に格納する格納手段を備える。一方、ネイティブプラットフォームは、格納手段によって共有メモリ領域に格納された汎用アプリ画像を取得する取得手段と、生成手段と、表示制御手段とを備える。生成手段は、取得手段により取得された汎用アプリ画像と、動作中のネイティブアプリケーションによって描画された画像であるネイティブアプリ画像とを、ネイティブプラットフォームにおいて規定された所定の表示要件に応じてレイアウトした表示用画像を生成する。表示制御手段は、生成手段により生成された表示用画像を、所定の表示手段に表示させる。また、生成手段は、複数の画面に別々に表示される表示用画像として、取得手段により取得された汎用アプリ画像に関する表示用画像と、動作中のネイティブアプリケーションによって描画された画像であるネイティブアプリ画像に関する表示用画像とを生成する。表示制御手段は、生成手段により生成された汎用アプリ画像に関する表示用画像と、ネイティブアプリ画像に関する表示用画像とを、複数の表示手段に別々に分配して表示させる。

本発明は、汎用アプリケーションにより出力された画像を汎用プラットフォームから、表示ドライバに直接アクセスして表示を行うのではなく、共有メモリ領域の仕組みを用いて、ネイティブプラットフォーム側で汎用アプリ画像とネイティブアプリ画像との表示調整を行った上で表示することを特徴とする。具体的には、汎用プラットフォーム側で用意した表示用画像（共有メモリ領域）に対して、ネイティブプラットフォームからアクセスを行い、それをネイティブプラットフォーム側の表示の仕組みを用いて、実際の表示手段に表示させる。

このように、ネイティブプラットフォーム側と汎用プラットフォーム側との窓口となる共有メモリ領域や、共有メモリ領域を介して画像をやり取りする仕組みにより、汎用アプリ画像の表示可否や表示位置等を、ネイティブプラットフォーム側で制御できる。これにより、車両用表示制御装置に導入された汎用アプリケーションが、車載機器の仕様に基づいて制作されていない場合でも、車載機器の要件に適合した表示の制御を実現できる。よって、車両用の組込みシステムにおいて汎用プラットフォームを共存動作させる上で、ネイティブアプリケーションによる出力画面と汎用アプリケーションによる出力画面との同時表示や連携表示が可能となる。

制御装置１のソフトウェア構成を示すブロック図。 制御装置１のハードウェア構成を示すブロック図。 画像表示の仕組みを示す説明図。 画像表示例を示す説明図。 汎用プラットフォームで実行される処理を表すフローチャート。 ネイティブプラットフォームで実行される処理を表すフローチャート。 応用例においてネイティブプラットフォームで実行される処理を表すフローチャート。 応用例において汎用プラットフォームで実行される処理を表すフローチャート。

以下、本発明の一実施形態を図面に基づいて説明する。なお、本発明は下記の実施形態に限定されるものではなく様々な態様にて実施することが可能である。
［制御装置１の構成の説明］
図１に示すように、制御装置１は、２つのディスプレイ２ａ，２ｂ、外部記憶装置３、ナビゲーションユニット４等の車載機器と接続され、車両用表示システムを構成している。制御装置１は、車両用の組込み機能として予め実装されているネイティブアプリケーションや、外部との通信を通じて導入される汎用アプリケーションによる画像表示を行うための車両用表示制御装置である。制御装置１は、ソフトウェア構成として、ネイティブプラットフォーム１１、アプリケーションコア部１２、汎用プラットフォーム１３、汎用アプリケーション１４、アプリケーションＨＭＩ部１５、入出力管理部１６等の機能を備える。

ネイティブプラットフォーム１１は、制御装置１の基本動作に必要な機能を提供する基本ソフトウェア（オペレーティングシステム（ＯＳ）ともいう。）である。このネイティブプラットフォーム１１上では、アプリケーションコア部１２として、車両用の組込み機能として予め実装されている様々なネイティブアプリケーションが動作する。ネイティブアプリケーションのとしては、エアコンアプリ１２ａ、電話アプリ１２ｂ、オーディオアプリ１２ｃ、描画システム１２ｄ等が例示される。なお、ここで例示したネイティブアプリケーションは、ほんの一例であり、その他の車両用のソフトウェアがネイティブアプリケーションとして実装されていてもよい。

エアコンアプリ１２ａは、カーエアコンに関する各種操作を行うためのグラフィカルユーザインタフェースを表示するアプリケーションである。電話アプリ１２ｂは、移動電話による車内でのハンズフリー通話機能を提供するアプリケーションである。この電話アプリ１２ｂは、外部からの電話の着信があったときに、着信を運転者に知らせるための画像を表示する。オーディオアプリ１２ｃは、例えば、テレビや、ビデオ、オーディオプレーヤ、ラジオ等の各種映像・音声ソースに基づいて各種映像や音声の出力を行うアプリケーションである。描画システム１２ｄは、ネイティブアプリケーションや汎用アプリケーション等の各種のアプリケーションから出力される画像に対して、車両用表示システムにおいて規定されている動作要件に則って表示出力調停を行うアプリケーションである。他にも、ネイティブアプリケーションとして、ナビゲーションユニット４において実行されるナビゲーション機能がある。

ネイティブプラットフォーム１１上には、更に汎用プラットフォーム１３が実装されている。汎用プラットフォーム１３は、外部のサーバ装置等から通信を介して導入された汎用アプリケーション１４を動作させるための基本ソフトウェア（ＯＳ）である。汎用プラットフォーム１３は、ネイティブプラットフォーム１１のカーネル上に、”Chroot”等の公知の仮想化実装技術を用いて実装されているものとする。これにより、汎用プラットフォーム１３は、ネイティブプラットフォーム１１上で隔離された状態で動作できる。なお、本実施形態の制御装置１では、汎用プラットフォーム１３として、オープンソース・オペレーティングシステムとして広く普及しているAndroid（登録商標）が実装されているものとする。

汎用アプリケーション１４は、汎用プラットフォーム１３の機能に依存して動作するアプリケーションソフトウェアである。汎用アプリケーション１４は、制御装置１に元々実装されておらず、ユーザの任意によりインターネットを中心とするクラウドコンピューティングを構成するサーバ群からデータ通信を介して導入される汎用的なアプリケーションである。このような汎用アプリケーションにより、クラウドコンピューティングや、スマートフォン等の高機能携帯端末との連携により、広い分野での情報やユーザインタフェースの相互利用が可能となる。様々な汎用アプリケーションによって、車両の走行に関するものに限らず、多様性に富む画像情報が提供される。

アプリケーションＨＭＩ部１５は、ディスプレイや操作パネル等の入出力デバイスを制御し、アプリケーションに対して抽象化したインタフェースを提供するソフトウェアである。入出力管理部１６は、ディスプレイ２ａ，２ｂや、外部記憶装置３、ナビゲーションユニット４等の周辺装置と、制御装置１との間のデータの入出力を制御するソフトウェアである。

ディスプレイ２ａ，２ｂは、液晶表示パネル等の表示面を有するカラー表示装置であり、何れも運転者の視界内において運転席から手の届く範囲に設置されているものとする。これらのディスプレイ２ａ，２ｂは、それぞれ異なる画像を表示可能であり、制御装置１において実行される各種アプリケーションによる表示出力に基づく画像が表示される。外部記憶装置３は、ハードディスクドライブや書換え可能な不揮発性半導体メモリ等で具現化される記憶装置である。この外部記憶装置３には、制御装置１が動作するためのプログラムやデータが記憶されている。上述のネイティブプラットフォームや汎用プラットフォーム、ネイティブアプリケーション、汎用アプリケーションのプログラムもここに記憶されている。

ナビゲーションユニット４は、車両向けの経路案内を行う装置であり、地図表示や経路探索、経路案内等が実行される。地図表示は、現在地付近の地図や車両の現在地を示すマーク等を表示する機能である。また、経路探索は、現在地（出発地）から目的地までの最適な経路を自動的に算出する機能である。経路案内は、前述の経路探索によって求められた経路に沿った走行案内を行う機能である。ナビゲーションユニット４による出力画像は、制御装置１の描画システム１２ｄによる表示出力調停を経て、ディスプレイ２ａ，２ｂの何れかに割振られて表示される。

つぎに、図２に示すように、制御装置１は、ハードウェア構成として、ＣＰＵ２１、ＧＰＵ（グラフィックチップ）２２、メモリ２３、メモリコントローラ２４、表示コントローラ２５を備える。ＣＰＵ２１は、制御装置１における中心的な演算処理装置である。ＣＰＵ２１は、プログラムによって様々な数値計算や情報処理を行い、制御装置１における上記各ソフトウェア構成１１〜１６の機能を実現する。

ＧＰＵ２２は、画像の表示に必要な計算処理をＣＰＵ２１に代わって行う演算処理装置である。このＧＰＵ２２は、画像の内容を示すデータから具体的な画像を描画する処理や、アプリケーションからの出力画像を所定形式の画像に変換する処理をＣＰＵ２１に代わって行う。

メモリ２３は、ＣＰＵ２１やＧＰＵ２２、表示コントローラ２５がメインメモリとして直接アクセスできる読み書き自由な半導体メモリ（ＲＡＭ）である。メモリコントローラ２４は、ＣＰＵ２１、ＧＰＵ２２、及び、表示コントローラ２５によるメモリ２３に対するデータの読出しや書込みを媒介する。ＣＰＵ２１で実行される各種アプリケーションにより出力された画像に基づいて生成された表示用画像は、メモリ２３における所定の記憶領域に設けられたフレームバッファに書込まれる。フレームバッファに書込まれた表示用画像は、表示コントローラ２５を介してディスプレイ２ａ，２ｂに出力され、各ディスプレイ２ａ，２ｂにおいて表示される。

［画像表示の仕組みに関する説明］
制御装置１が、ネイティブアプリケーションや汎用アプリケーションによる出力画像に基づいてディスプレイ２ａ，２ｂに画像表示を行うための仕組み及び手順について、図３を参照しながら説明する。

ネイティブプラットフォームは、仮想アドレス空間をユーザ空間とカーネル空間とに分けて動作する。ユーザ空間は、アプリケーションコア部や汎用プラットフォーム等のユーザプロセスが動作する仮想メモリ領域である。カーネル空間は、ネイティブプラットフォームのカーネルが存在する仮想メモリ領域である。

ユーザ空間には、仮想化実装された汎用プラットフォーム（Android OS）が動作する仮想Android空間が設けられている。そして、ネイティブプラットフォームと汎用プラットフォームとの間には、ソケット通信等のプロセス間通信（ＩＰＣ：Inter process Communication）を行うプロセス間通信部３４，３６が実装されている。このプロセス間通信では、ネイティブプラットフォームのドメインソケット３７がインタフェースとして用いられる。また、カーネル空間には、ネイティブプラットフォームと汎用プラットフォームとの間でデータを共有するための記憶領域である共有メモリ３５（ashmem）が実装されている。

仮想Android空間で動作している各汎用アプリケーション１４は、自身のアプリケーションによる出力画像（以下、汎用アプリ画像とも称する）を描画するための描画領域３１（Surface）を、Androidミドルウェアに備えられた領域割当部３２（Surface flinger）を介して確保する。各汎用アプリケーション１４に割当てられる描画領域３１は、Androidミドルウェアに備えられた領域確保部３３によって共有メモリ３５から確保される。そして、汎用アプリケーション１４は、領域割当部３２によって割当てられた各描画領域３１に対して、汎用アプリ画像の描画処理を行う（図３の矢印Ａで示される手順に相当）。各描画領域３１に対する描画結果は、領域割当部３２によって合成処理が行われ、共有メモリ３５に格納される（図３の矢印Ｂで示される手順に相当）。

ちなみに、従来技術では、領域確保部３３が、汎用アプリ画像を描画する描画領域をAndroid OS用の仕組みとして備えられたフレームバッファドライブ（Uvesafb Driver）から確保して描画処理を行う点で、共有メモリ３５を採用した本発明と相違する。

共有メモリ３５への汎用アプリ画像の書込みは、汎用プラットフォーム側で汎用アプリ画像が更新される度に行われる。共有メモリ３５における汎用アプリ画像の更新が行われたことは、プロセス間通信部３４，３６を介して、汎用プラットフォーム側からネイティブプラットフォーム側のバーチャルAndroid部３８に対して、”fb＿post”というイベントとして通知される。

バーチャルAndroid部３８は、ネイティブアプリケーションである描画システム１２ｄの機能として提供されるモジュールである。fb＿postの通知を受信したバーチャルAndroid部３８は、共有メモリ３５に格納されている汎用アプリ画像を取得する。そして、バーチャルAndroid部３８は、取得した汎用アプリ画像をネイティブプラットフォーム側のユーザ空間に確保されたピクセルマップ４３に格納する（図３の矢印Ｃで示される手順に相当）。

このとき、汎用プラットフォームとネイティブプラットフォームとの間でサポートするピクセルフォーマットとが異なる場合は、バーチャルAndroid部３８においてピクセルフォーマットの変換処理を行ってから画像をピクセルマップ４３に格納する。一例として、汎用プラットフォーム側から出力された汎用アプリ画像がＲＧＢ５６５形式であったとした場合、これをネイティブプラットフォーム側でサポートしているＡＲＧＢ８８８８形式の画像に変換するといった画像変換を行うことが挙げられる。また、画像のサイズ調整や色変換等の画像変換も必要があれば行う。

なお、上記のような画像変換は、一般的に処理負荷が高く、ＣＰＵ２１に画像処理を行わせる場合、高度な処理性能が求められる。そこで、共有メモリ３５をＧＰＵ２２からもアクセスできる記憶領域とし、共有メモリ３５に格納された汎用アプリ画像に対して、ＣＰＵ２１の代わりにＧＰＵ２２が所定のグラフィック・インタフェースを用いて画像変換を行うようにしてもよい。このようにすることで、ＣＰＵ２１の負荷の低減や表示の高速化を実現できる。

つぎに、ピクセルマップ４３に格納された汎用アプリ画像と、汎用アプリケーションとは別に動作中のネイティブアプリケーションから出力されたネイティブアプリ画像とを合成した表示用画像が生成され、カーネル空間のフレームバッファ４４に格納される（図３の矢印Ｄで示される手順に相当）。そして、フレームバッファ４４に格納された表示用画像は、表示コントローラ２５によってディスプレイ２ａ，２ｂにそれぞれ表示される。ここでは、ＨＭＩコントローラ３９が、ネイティブプラットフォームにおいて規定された所定の表示要件に応じて、汎用アプリ画像とネイティブアプリ画像とを何処に表示するか決めて、表示用画像をレイアウトする。レイアウトした表示画像の描画は、描画モジュール４０及び描画ドライバインタフェース４１を介して、カーネル空間の描画ドライバ４２によって行われる。

なお、表示用画像をレイアウトするルールの一例として、次のような方法が挙げられる。例えば、汎用アプリ画像とネイティブアプリ画像とを、車両に備えられたディスプレイ数に応じて分配し、別々の画面にレイアウトする。その具体例を図４の表示例１に示す。表示例１では、２つのディスプレイ２ａ，２ｂのうち、ディスプレイ２ａにネイティブアプリケーションによる画像を表示し、ディスプレイ２ｂに汎用アプリケーションによる画像を表示している。このように、ネイティブプラットフォーム側で表示場所を調整することで、ネイティブアプリケーションによる画像と、汎用アプリケーションによる画像との排他を行うことなく、同時に表示させることができる。あるいは、１つのディスプレイの表示領域を分割して、そこに汎用アプリ画像とネイティブアプリ画像とを別々にレイアウトしてもよい。

また、別の例として、特定の関連性のあるネイティブアプリケーションと汎用アプリケーションとの間で、それぞれの出力画像を１つの画面上に重ね合わせたレイアウトを作成する。例えば、ネイティブアプリケーションが描画・表示する画面に、汎用アプリ画像を重ね合わせて補足的に情報表示を行うことが考えられる。その具体例を図４の表示例２に示す。表示例２では、地図表示を行うネイティブアプリケーションと、地図上のＰＯＩ（Point Of Interest）情報を提供する汎用アプリケーションとの連携表示を行う。ここでは、ネイティブアプリケーションにより出力された地図画像上に、汎用アプリケーションにより出力されたＰＯＩを示すアイコンを地図上の位置に対応させて合成し、１つのディスプレイ２ａに表示している。また、ネイティブアプリ画像上に重ねて表示させる汎用アプリ画像に対して、所定の透過色を適用したり、各ピクセルに透過度を表すα値を掛け合わせることで、ネイティブアプリ画像上に汎用アプリ画像を透過合成することができる。

また、別の例として、アプリケーションごとに予め規定された表示の優先度に応じて、車両の走行や安全に関する優先度の高いネイティブアプリ画像を、他の汎用アプリ画像よりも優先的に表示されるようにレイアウトする。この場合、優先度が高い方の画像をメインディスプレイにレイアウトし、低い方の画像をサブディスプレイにレイアウトしたり、優先度が高い方の画像を他の画像に上書きしてもよい。

上述の一連の処理の仕組みにおいて、汎用プラットフォーム側で実行される処理の手順について、図５のフローチャートを参照しながら説明する。Ｓ１００では、汎用プラットフォームで動作している汎用アプリケーションにおいて、それぞれのタイミングで画像の描画や表示出力等の処理が行われる。Ｓ１０２では、汎用アプリケーションによって汎用アプリ画像が描画され、描画された汎用アプリ画像が領域割当部３２によって共有メモリ３５に格納される。Ｓ１０４では、領域割当部３２において表示を更新するか否かが判断される。ここでは、動作中の汎用アプリケーションから新たな汎用アプリ画像の表示要求があるか否かに応じて、表示を更新するか否かを判定する。表示を更新すると判定された場合（Ｓ１０４：ＹＥＳ）、Ｓ１０６に進む。一方、表示を更新しないと判定された場合（Ｓ１０４：ＮＯ）、Ｓ１００に戻る。Ｓ１０６では、領域割当部３２からプロセス間通信部３４を介して、fb＿postのイベントがネイティブプラットフォーム側に通知される。

一方、ネイティブプラットフォーム側で実行される処理の手順について、図６のフローチャートを参照しながら説明する。Ｓ２００では、バーチャルAndroid部３８が、プロセス間通信部３６を介してfb＿postの通知を受信する。fb＿postの通知を受信したときに進むＳ２０２では、バーチャルAndroid部３８において、受信したfb＿postに該当する汎用アプリ画像の表示が可能であるか否かが判定される。ここでは、予め定められたネイティブアプリ画像と汎用アプリ画像との表示調停に関するルールに基づいて、汎用アプリ画像の表示の可否が判定される。一例として、車両の走行や安全に関する優先度の高い特定のネイティブアプリ画像を表示している状況下において、優先度の低い汎用アプリ画像を表示させないといったルールを適用することが挙げられる。汎用アプリ画像の表示が可能であると判定された場合（Ｓ２０２：ＹＥＳ）、Ｓ２０４に進む。一方、汎用アプリ画像の表示が不可であると判定された場合、（Ｓ２０２：ＮＯ）、Ｓ２００に戻る。

Ｓ２０４では、バーチャルAndroid部３８において、自車両が走行中であるか否かが判定される。自車両が走行中でないと判定された場合（Ｓ２０４：ＮＯ）、Ｓ２０８に進む。一方、自車両が走行中であると判定された場合（Ｓ２０４：ＹＥＳ）、Ｓ２０６に進む。Ｓ２０６では、バーチャルAndroid部３８において、受信したfb＿postに該当する汎用アプリ画像が、走行中に表示可能なコンテンツであるか否かが判定される。具体的には、バーチャルAndroid部３８がプロセス間通信部３６を介して、当該汎用アプリケーションのコンテンツが走行中の表示に適合しているか否かを、汎用プラットフォームに対して問合せることで、表示の可否を判定する。受信したfb＿postに該当する汎用アプリ画像が、走行中に表示可能なコンテンツであると判定された場合（Ｓ２０６：ＹＥＳ）、Ｓ２０８に進む。一方、受信したfb＿postに該当する汎用アプリ画像が、走行中に表示不可能なコンテンツであると判定された場合（Ｓ２０６：ＮＯ）、Ｓ２００に戻る。

Ｓ２０８では、汎用アプリ画像を画面に表示するための表示処理が実行される。ここでは、既に説明したとおり、バーチャルAndroid部３８が、共有メモリ３５にアクセスして汎用アプリ画像を取得する。取得された汎用アプリ画像は、ネイティブプラットフォームにおいて規定された所定の表示要件に応じてディスプレイ２ａ，２ｂに対する表示画像にレイアウトされ、表示画像が描画される。そして、描画された表示画像が、ディスプレイ２ａ，２ｂにそれぞれ表示される。

［実施形態に関する付加説明］
本実施形態の制御装置１では、１つのシステム上に異なったプラットフォーム（ネイティブプラットフォーム及び汎用プラットフォーム）が実装されている。それぞれのプラットフォーム内のアプリケーションは、各々独立に動作し、お互いのプラットフォーム上に搭載されているアプリケーションソフトウェアに干渉されることなく動作することができる。

汎用プラットフォームは、ネイティブプラットフォームと同じカーネルを使用する。この汎用プラットフォーム内で生成されるアプリケーションプロセスやスレッドは、汎用プラットフォーム内のプロセス、スレッドマネージメント機構によって、生存期間や動作タイミング等が制御される。また、汎用プラットフォームにおけるメモリの確保、解放、アプリケーションに対するメモリの割当て等は、汎用プラットフォーム内に設けられたメモリマネージメント機構によって制御される。例えば、Android OS等であれば、それらの仕組みは標準的にAndroidミドルウェアとして提供されることになる。

しかしながら、汎用プラットフォームが一方的に動作することで、ＣＰＵリソースやメモリリソースの占有を招き、ネイティブプラットフォームに影響を及ぼす可能性がある。その場合、共通に使用しているカーネルの機能を用いて、汎用プラットフォームに対して制限をかける等の機構を用いても良い。例えば、Linux（登録商標）カーネルには、cgroup等のリソース分離を行う機構が標準的に入っている。このような機構によって汎用プラットフォームの動作に制限をかけることで、ネイティブプラットフォームおいて実行される車両の安全に関する車載機能の動作を保証することができる。

汎用プラットフォーム上で動作する汎用アプリケーションは、独立的に動作し、それぞれのアプリケーションのタイミングで画像の描画処理や表示出力処理を行う。これらの汎用アプリケーションは、ネイティブプラットフォーム上で動作するアプリケーションの動作を意識して動作することはない。また、汎用プラットフォームは、汎用アプリケーションによって描画された画像を、自ら表示デバイス（ディスプレイ２ａ，２ｂ）に表示させる表示処理を行わない。代わりに、汎用プラットフォームは、汎用アプリケーションによって描画された画像を共有メモリ３５に格納し、表示が更新されたことを表すイベント（fb＿post）をネイティブプラットフォームに通知するのみである。

共有メモリ３５に格納された汎用アプリ画像が実際に表示されるか否かは、ネイティブプラットフォーム側の動作に依存する。バーチャルAndroid部３８を始めとするネイティブプラットフォームの各種機能により、汎用アプリ画像とネイティブアプリ画像との間で表示の排他制御が行われる。例えば、ネイティブプラットフォームにおいて汎用アプリ画像が表示不可であると判断された場合、たとえ汎用アプリケーションが画像の表示出力を行ったとしても、共有メモリ３５に保存された映像はフレームバッファ４４に転送されることはない。このように、汎用アプリ画像については、ネイティブプラットフォーム側で表示可否を制御できるため、表示の必要がない場合、ネイティブプラットフォーム側のみの制御で表示を無効にすることができる。

このようにすることで、ネイティブアプリケーションによる車両の走行や安全に関する重要な機能に関する画像の表示を、汎用プラットフォームの動作によって阻害されることを防ぐ。また、走行中に不要な画像の表示を制限する規制に汎用アプリケーションが対応していなかったとしても、ネイティブプラットフォーム側で汎用プラットフォームの表示自体を抑止することで、走行時の表示規制への対応を行うことができる。

一方、外部のユニット（例えば、ナビゲーションユニット４）のアプリケーションからネイティブプラットフォームに取込まれた外部画像についても、ネイティブプラットフォームにおいて表示可否の制御やネイティブアプリ画像との重ね合わせ表示を実現できる。その場合、汎用アプリ画像に関する表示可否の制御や、汎用アプリ画像とネイティブアプリ画像との重ね合わせ表示と同様の仕組みによって、ネイティブプラットフォームが外部画像の表示の制御を行うことができる。

［応用例］
共有メモリ３５及びプロセス間通信部３４，３６の仕組みを使うことで、ネイティブプラットフォームがナビゲーションユニット４等の外部ユニットから取込んだ外部画像を、汎用プラットフォーム側で利用することが実現可能となる。これにより、ネイティブプラットフォームが取込んだ外部画像を、汎用プラットフォーム側の汎用アプリケーションが加工して表示したり、汎用アプリケーションが画像認識等に用いることができる。

具体的には、ネイティブプラットフォーム側に、汎用プラットフォームからのアクセスを受け付けるＡＰＩ（Application Programming Interface）を定義する。また、汎用プラットフォームからの要求（ＡＰＩコール）に対して、応答するソフトをネイティブプラットフォーム側に実装する。例えば、ネイティブプラットフォームが外部ユニットより取得した外部画像（ナビゲーションユニット４からのナビ映像）を汎用プラットフォームに渡すには、次のようにする。汎用プラットフォームは、プロセス間通信部３４，３６を介してネイティブプラットフォームに対して、外部画像を取得する意味のＡＰＩをコールする。ＡＰＩコールを受信したネイティブプラットフォームは、そのときに取得した外部画像を共有メモリ３５に格納する。そして、ネイティブプラットフォームは、プロセス間通信部３４，３６を介して汎用プラットフォームに対して、要求に対する応答を通知する。応答を受信した汎用は、共有メモリ３５にアクセスし、外部画像を取得する。汎用プラットフォームにより取得された外部画像は、動作中の汎用アプリケーションに供給され、汎用アプリケーションにおいて外部画像の加工や画像認識に利用される。

上述の一連の処理において、ネイティブプラットフォームにおいて実行される処理の手順について、図７のフローチャートを参照しながら説明する。Ｓ３００では、ネイティブプラットフォームは、プロセス間通信部３６を介して、外部画像を取得するイベントの通知を汎用プラットフォームから受信する。外部画像を取得するイベントの通知を受信したときに進むＳ３０２では、ネイティブプラットフォームは、フレームバッファ４４にアクセスし、外部ユニットのアプリケーションにより表示出力された外部画像を取得する。次のＳ３０４では、ネイティブプラットフォームは、Ｓ３０２で取得した外部画像を共有メモリ３５に格納する。次のＳ３０６では、ネイティブプラットフォームは、共有メモリ３５に外部画像が格納されたことを示す、ネイティブバッファアップデートのイベントを、プロセス間通信部３６を介して汎用プラットフォームに通知する。

なお、このイベントは非同期であるため、汎用プラットフォームの応答を待つことなく、ネイティブプラットフォーム側の動作を継続できるものとする。また、ネイティブプラットフォームが画像を共有メモリ３５に格納している最中に、汎用プラットフォーム側がその画像にアクセスしないように、共有メモリ３５に複数フレーム分のバッファを設け、排他制御する。

一方、汎用プラットフォームにおいて実行される処理の手順について、図８のフローチャートを参照しながら説明する。Ｓ４００では、汎用プラットフォームは、プロセス間通信部３４を介して、ネイティブバッファアップデートの通知をネイティブプラットフォームから受信する。ネイティブバッファアップデートの通知を受信したときに進むＳ４０２では、汎用プラットフォームは、共有メモリ３５にアクセスして、ネイティブバッファアップデートの通知を受信した時点での最新の外部画像を取得する。

例えば、ネイティブプラットフォーム側の動作が汎用プラットフォームに比べて速い場合、複数のネイティブバッファアップデートが汎用プラットフォーム側に通知される。これに対し、汎用プラットフォームは、全てのネイティブバッファアップデートのイベントを溜めておいて処理するのではなく、汎用プラットフォームが動けるタイミングで、そのときの最新の画像を取得することで、処理負荷を軽減させることができる。次のＳ４０４では、汎用プラットフォームは、共有メモリ３５から取得した外部画像を、外部画像の取得を要求した汎用アプリケーションに供給する。

［効果］
実施形態の制御装置１によれば、次のような効果を奏する。
ネイティブプラットフォーム側と汎用プラットフォーム側との窓口となる、共有メモリ３５、プロセス間通信部３４，３６、バーチャルAndroid部３８等の仕組みを制御装置１に実装した。これにより、汎用アプリケーションの出力画像に対して、ネイティブプラットフォーム側の規定に則って調整をかけた上で表示を行うことができる。このようにすることで、制御装置１に導入された汎用アプリケーションが、車載機器の仕様に基づいて制作されていない場合でも、車載機器の要件に適合した表示の制御を実現できる。よって、車両用の組込みシステムにおいて汎用プラットフォームを共存動作させる上で、ネイティブアプリケーションによる出力画面と汎用アプリケーションによる出力画面との同時表示や連携表示が可能となる。

また、共有メモリ３５に格納された汎用アプリ画像に対し、ネイティブアプリケーション側で所定の画像処理を行うことで、汎用アプリ画像をネイティブプラットフォームにおいてサポートされている形式に変換して表示できる。さらに、このような画像処理をＣＰＵ２１の代わりにＧＰＵ２２が実行することで、ＣＰＵ２１の処理負荷を軽減できる。

１…制御装置、２ａ，２ｂ…ディスプレイ、３…外部記憶装置、４…ナビゲーションユニット、１１…ネイティブプラットフォーム、１２…アプリケーションコア部、１２ａ…エアコンアプリ、１２ｂ…電話アプリ、１２ｃ…オーディオアプリ、１２ｄ…描画システム、１３…汎用プラットフォーム、１４…汎用アプリケーション、１５…アプリケーションＨＭＩ部、１６…入出力管理部、２１…ＣＰＵ、２２…ＧＰＵ、２３…メモリ、２４…メモリコントローラ、２５…表示コントローラ、３１…描画領域、３２…領域割当部、３３…領域確保部、３４…プロセス間通信部、３５…共有メモリ、３６…プロセス間通信部、３７…ドメインソケット、３８…バーチャルAndroid部、３９…ＨＭＩコントローラ、４０…描画モジュール、４１…描画ドライバインタフェース、４２…描画ドライバ、４３…ピクセルマップ、４４…フレームバッファ。

Claims (6)

1. 車両用の組込み機能として予め実装されたネイティブアプリケーションを動作させるための基本ソフトウェアであるネイティブプラットフォーム（１１）と、
   前記ネイティブプラットフォーム上に仮想化して実装された基本ソフトウェアであって、外部との情報通信を通じて導入される汎用アプリケーションを動作させるための汎用プラットフォーム（１３）と、
   前記ネイティブプラットフォームと前記汎用プラットフォームとの間で、データを共有するためのメモリ領域である共有メモリ領域（３５）と、を備え、
   前記汎用プラットフォームは、
   動作中の汎用アプリケーションによって描画された画像である汎用アプリ画像を前記共有メモリ領域に格納する格納手段（３２）を備え、
   前記ネイティブプラットフォームは、
   前記格納手段によって前記共有メモリ領域に格納された汎用アプリ画像を取得する取得手段（３８）と、
   前記取得手段により取得された汎用アプリ画像と、動作中のネイティブアプリケーションによって描画された画像であるネイティブアプリ画像とを、前記ネイティブプラットフォームにおいて規定された所定の表示要件に応じてレイアウトした表示用画像を生成する生成手段（３９）と、
   前記生成手段により生成された表示用画像を、所定の表示手段（２ａ，２ｂ）に表示させる表示制御手段（２５）とを備え、
   前記生成手段は、複数の画面に別々に表示される表示用画像として、前記取得手段により取得された汎用アプリ画像に関する表示用画像と、動作中のネイティブアプリケーションによって描画された画像であるネイティブアプリ画像に関する表示用画像とを生成し、
   前記表示制御手段は、前記生成手段により生成された汎用アプリ画像に関する表示用画像と、ネイティブアプリ画像に関する表示用画像とを、複数の表示手段に別々に分配して表示させること
   を特徴とする車両用表示制御装置（１）。
2. 請求項１に記載の車両用表示制御装置において、
   前記ネイティブプラットフォームと、前記汎用プラットフォームとの間で通信を行う通信手段（３４，３６）を更に備え、
   前記汎用プラットフォームは、前記格納手段によって汎用アプリ画像が前記共有メモリ領域に格納されたことを、前記通信手段を介して前記ネイティブプラットフォーム側に通知し、
   前記ネイティブプラットフォームでは、
   汎用アプリ画像が前記共有メモリ領域に格納されたことを、前記通信手段を介して前記汎用プラットフォームから通知されたことを条件に、前記取得手段が、前記共有メモリ領域に格納された汎用アプリ画像を取得すること
   を特徴とする車両用表示制御装置。
3. 請求項１又は請求項２に記載の車両用表示制御装置において、
   前記汎用プラットフォームは、前記汎用アプリ画像を所定形式の画像に変換する変換手段（４２）を更に備え、
   前記生成手段は、前記変換手段によって前記汎用アプリ画像を所定形式の画像に変換した画像と、前記ネイティブアプリ画像とを前記表示要件に応じてレイアウトした表示用画像を生成すること
   を特徴とする車両用表示制御装置。
4. 請求項３に記載の車両用表示制御装置において、
   前記ネイティブプラットフォームを動作させる中央処理装置（２１）と、前記中央処理装置の代わりに画像の表示に必要な計算を行う画像処理装置（２２）とを備え、
   前記変換手段は、前記汎用アプリ画像の変換を前記画像処理装置を用いて行うこと
   を特徴とする車両用表示制御装置。
5. 請求項１ないし請求項４の何れか１項に記載の車両用表示制御装置において、
   前記生成手段は、前記取得手段により取得された汎用アプリ画像と、動作中のネイティブアプリケーションによって描画された画像であるネイティブアプリ画像とが、重ねて表示される表示用画像を生成すること
   を特徴とする車両用表示制御装置。
6. 請求項１ないし請求項５の何れか１項に記載の車両用表示制御装置において、
   前記ネイティブプラットフォームと、前記汎用プラットフォームとの間で通信を行う通信手段（３４，３６）を備え、
   前記ネイティブプラットフォームは、前記車両用表示制御装置に接続された外部装置のアプリケーションによって描画された画像である外部画像を前記共有メモリ領域に格納し、前記共有メモリ領域に外部画像が格納されたことを、前記通信手段を介して前記汎用プラットフォーム側に通知し、
   前記汎用プラットフォームは、前記共有メモリ領域に前記外部画像が格納されたことを、前記通信手段を介して通知されたことを条件に、前記共有メモリ領域に格納された外部画像を取得し、取得した外部画像を動作中の汎用アプリケーションに供給すること
   を特徴とする車両用表示制御装置。