JP6237543B2

JP6237543B2 - 車載装置

Info

Publication number: JP6237543B2
Application number: JP2014177087A
Authority: JP
Inventors: 下谷　隆史; 隆史下谷
Original assignee: Denso Corp
Current assignee: Denso Corp
Priority date: 2014-09-01
Filing date: 2014-09-01
Publication date: 2017-11-29
Anticipated expiration: 2034-09-01
Also published as: JP2016051374A; WO2016035244A1; US20170255461A1; US10331433B2

Description

本発明は、装置本体に予め搭載されている固有アプリケーションを実行するための第１のＯＳと、外部の機器から取得される配信アプリケーションを実行するための第２のＯＳとを含むハイブリッドＯＳ構造を備える車載装置に関する。

近年、コンピュータ装置においては、１つのＣＰＵ上で２つのＯＳが動作するハイブリッドＯＳ構造を設けることが行われてきており、車載端末装置においても、単一のＣＰＵで複数のＯＳを動作させて、ナビゲーション等の周辺デバイス（車載システム）を制御するものが考えられてきている（例えば特許文献１参照）。

例えばナビゲーション機能、オーディオ機能、電話機能等を搭載した車載装置（車載システム）において、例えばＬｉｎｕｘ（登録商標）とＡｎｄｒｏｉｄ（登録商標）との２つのＯＳの動作が可能なハイブリッドＯＳ構造を設けることが行われる。この車載システムでは、予め搭載されているナビゲーションアプリ等の固有アプリケーションに加えて、外部の機器から取得された各種の配信アプリケーションといった、複数のアプリケーションを共存（連携）して実行させることが可能となる。

特開２００３−３６１７４号公報

しかしながら、このようなハイブリッドＯＳ構造を有するシステムでは、各アプリケーションが独自に動作するため、Ａｎｄｒｏｉｄ上で動作する外部から配信された配信アプリケーションが、車載装置に搭載されている固有アプリケーションの機能に対し、予期しない様々な影響を及ぼす懸念がある。特にソフトウエアの更新時には、配信アプリケーションの動作によって、ソフトウエア更新のための書込み速度や処理能力に悪影響を与え、更新に要する時間が異常に長くなったり、安定性が大幅に低下したりする虞がある。

本発明は上記事情に鑑みてなされたものであり、その目的は、固有アプリケーション及び配信アプリケーションの実行が可能なハイブリッドＯＳ構造を備えるものにおいて、ソフトウエアの更新動作中に配信アプリケーションが実行されることに伴う予期せぬ不具合の発生を未然に防止することができる車載装置を提供するにある。

上記目的を達成するために、本発明の車載装置（１）は、固有アプリケーション及び配信アプリケーションの実行が可能なハイブリッドＯＳ構造を備えるものにあって、前記複数のＯＳ及びアプリケーションを記憶する記憶装置（１１）と、前記記憶装置（１１）の各ソフトウエアを更新する更新手段（１０ａ）と、前記更新手段（１０ａ）によるソフトウエアの更新動作中に前記第２のＯＳの機能を一時停止させる停止手段（１０ｂ）とを設けたところに特徴を有する（請求項１の発明）。

本発明の車載装置（１）においては、ハイブリッドＯＳ構造を備えることによって、第１のＯＳによる予め搭載された固有アプリケーションの実行に加えて、第２のＯＳによる外部から取得された配信アプリケーションの実行が可能となる。また、更新手段（１０ａ）により、記憶装置（１１）に記憶された複数のＯＳ及びアプリケーションのソフトウエアの更新が実行される。

このとき、予め予測できない配信アプリケーションが取得される（開発される）ケースがあり、そのような配信アプリケーションが固有アプリケーションによる機能に意図しない影響を与える虞が考えられ、特にソフトウエアの更新時に、書込み速度や処理能力に悪影響を及ぼすことが考えられる。ところが、前記更新手段（１０ａ）によるソフトウエアの更新動作中には、停止手段（１０ｂ）により、第２のＯＳの機能が一時停止される。従って、ソフトウエアの更新動作中に配信アプリケーションが実行されることに伴う予期せぬ不具合の発生を未然に防止することができる。

本発明の一実施形態を示すもので、車載システムの電気的構成を概略的に示す図制御部のソフトウエア構成を模式的に示す図制御部のハードウエア構成を概略的に示すブロック図記憶装置の記憶領域の割り当て態様を模式的に示す図制御部が実行するソフトウエア更新の処理手順を示すフローチャート

以下、本発明を具体化した一実施形態について、図面を参照しながら説明する。図１は、本実施形態に係る車載装置（装置本体）１の電気的構成、及び車載装置１を含むシステム構成を概略的に示している。本実施形態に係る車載装置１は、例えばユーザ（自動車の運転者）が所持するスマートフォン等の携帯端末２との間で、Bluetooth（登録商標）方式の無線通信により接続が可能に構成され、それらの連係動作が可能とされている。

前記携帯端末２は、例えばインターネット３を介して複数のサーバ４、５、６（ここでは、便宜上３つのみ図示）との間で通信可能に接続される。そのうちサーバ４は、スマートフォン２（車載装置１）に対し、例えばＰＯＩ（Point Of interest）に関する情報や検索サービスを提供する。サーバ５は、スマートフォン２（車載装置１）に対し、例えば配信アプリケーション（以下、配信アプリと略す）を配信する。サーバ６は、スマートフォン２（車載装置１）に対し、例えば特定のアプリケーション（配信アプリに含まれる）に応じたサービスを提供する。尚、図１に示すサーバの構成は一例であり、その数や提供するサービスの種類等はこれに限定されるものではない。

前記車載装置１は、制御部１０、記憶装置１１、表示部１２、操作部１３、通信部１４、外部インターフェース１５等を備えている。前記外部インターフェース１５には、ＵＳＢコネクタ（ＵＳＢポート）１５ａ（図３参照）が含まれており、このＵＳＢコネクタ１５ａは、例えば車室内のアームレスト部分に設けられている。

また、車載装置１は、ナビゲーション機能を提供するためのナビＥＣＵ１６（Electronic Control Unit）、及び、オーディオ機能を提供するためのオーディオＥＣＵ１７を備えている。オーディオＥＣＵ１７には、スピーカ１８及びマイク１９が接続されている。この車載装置１は、いわゆるナビゲーションシステムとして機能する。尚、車載装置１は、ナビゲーション機能やオーディオ機能を制御部１０にて実現する構成としても良いし、ナビゲーション機能やオーディオ機能を備えていない構成であっても良い。

詳しく図示はしないが、前記制御部１０は、ＣＰＵ、ＲＯＭ及びＲＡＭ等を有するコンピュータを主体として構成されている。この制御部１０は、前記表示部１２の表示を制御する機能を備えている。詳しくは後述するが、この制御部１０には、主としてそのソフトウエア的構成により、前記記憶装置１１の各ソフトウエアを更新する更新手段としてのソフト更新部１０ａと、このソフト更新部１０ａによるソフトウエアの更新動作中に後述する第２のＯＳ（後述するＡｎｄｒｏｉｄ（登録商標））の機能を一時停止させる停止手段としての停止処理部１０ｂとが設けられている。

このとき、本実施形態では、前記制御部１０（車載装置１）は、ハイブリッドＯＳ構造により複数のアプリケーション（以下、アプリと略す）の実行が可能な動作環境を備えている。つまり、１つのＣＰＵ上で２つのＯＳが並行（連携）して動作可能な構造を備え、具体的には、予め搭載されている固有（Ｎａｔｉｖｅ）アプリを実行（制御）可能な第１のＯＳとしてのＬｉｎｕｘ（登録商標）、及び、通信部１４を介して例えば外部サーバ５等からダウンロードした配信アプリを実行（制御）可能な第２のＯＳとしてのＡｎｄｒｏｉｄ（登録商標）の動作環境を備えている。

図２は、制御部１０が備えるソフトウエア構成を模式的に示している。ここで、ハードウエアは、第１のＯＳとしてのＬｉｎｕｘのＯＳ（カーネル）により管理され、このＬｉｎｕｘのＯＳ上に、固有（Ｎａｔｉｖｅ）アプリが設けられる。これと共に、ＬｉｎｕｘのＯＳ上に、第２のＯＳとしてのＡｎｄｒｏｉｄのＯＳが設けられ、ＡｎｄｒｏｉｄのＯＳ上に、外部（サーバ４，５，６）から配信された配信アプリが設けられる。

前記固有（Ｎａｔｉｖｅ）アプリには、例えば表示部１２への表示を行うアプリ、操作部１３からの操作を受け付けるアプリ、ナビＥＣＵ１６やオーディオＥＣＵ１７との間の通信を行うアプリ、スピーカ１８へ音声出力を行うアプリ、マイク１９から入力された音声に例えば音声認識を行うアプリ等が含まれている。また、例えば燃料の残量の監視、ＥＴＣ車載器の管理、車両の走行に関する各種の監視・警告などを行うアプリも含まれている。

これらのソフトウエア群は、フラッシュメモリ等の電気的に書き替え可能な半導体記憶素子で構成された記憶装置１１に記憶されている。本実施形態の場合、記憶装置１１としては、ＳＤメモリカードを採用している。また、本実施形態では、ＳＤメモリカードは、車載装置１に内蔵された状態、つまり、車載装置１から着脱不可となっている。尚、記憶装置１１としては、ｍｉｎｉＳＤカードやｍｉｃｒｏＳＤカードのように異なる大きさのものを採用してよいし、ＳＨＤＣメモリカードのように転送速度や最大容量が異なるものを採用してもよい。また、記憶装置１１としては、いわゆるＳＳＤ（Solid State Disk）のようなものを採用してもよいし、他の規格のメモリカードを採用してもよい。さらに、記憶装置１１としては、メモリカードのような規格化されたものでは無く、例えばＮＡＮＤ型フラッシュメモリを直接的に接続した構成を採用してもよい。

この記憶装置１１は、図４に示すような記憶領域（パーティション構成）が設けられている。記憶領域としては、車載装置１の起動管理を行うためのプログラム等を記憶するＢｏｏｔ用記憶領域Ｒ１、ＬｉｎｕｘのＯＳを記憶するＬｉｎｕｘ本体用記憶領域Ｒ２、ＡｎｄｒｏｉｄのＯＳを記憶するＡｎｄｒｏｉｄ本体用記憶領域Ｒ３、固有（Ｎａｔｉｖｅ）アプリを記憶する固有アプリ用記憶領域Ｒ４、配信アプリを記憶する配信アプリ用記憶領域Ｒ５等が設けられる。つまり、車載装置１を動作させるためのソフトウエア群は、１つの記憶装置１１に纏めて記憶されている。

さて、前記制御部１０は、通常時には、ナビＥＣＵ１６によるナビゲーションに関連する処理、例えば表示部１２の地図画面の表示処理などを行うのであるが、このとき、ハイブリッドＯＳ構造により、固有アプリ、配信アプリの複数のアプリケーションを同時に並行して実行することが可能とされている。また、上記したように、制御部１０のソフト更新部１０ａは、前記記憶装置１１の各ソフトウエアの更新の処理を行う更新手段として機能する。

この場合、本実施形態では、図３に示すように、更新すべきソフトウエアは、メディアとしてのＵＳＢメモリ２０に記憶された状態とされ、このＵＳＢメモリ２０が、ＵＳＢコネクタ１５ａを介して車載装置１に接続されることに基づいて、更新処理が実行されるようになっている。また本実施形態では、基本的には、記憶装置１１に記憶されているソフトウエア（記憶領域）のうち、ＬｉｎｕｘのＯＳ（Ｌｉｎｕｘ本体用記憶領域Ｒ２）、ＡｎｄｒｏｉｄのＯＳ（Ａｎｄｒｏｉｄ本体用記憶領域Ｒ３）、固有（Ｎａｔｉｖｅ）アプリ（固有アプリ用記憶領域Ｒ４（更新が必要なもの））を一括して更新するようになっている。

そして、本実施形態では、次の作用説明（フローチャート説明）で述べるように、ソフト更新部１０ａによるソフトウエアの更新動作中には、前記停止処理部１０ｂにより、Ａｎｄｒｏｉｄの機能を一時停止させる停止処理が実行される。従って、ソフトウエアの更新動作中は、全ての配信アプリの実行が停止される。尚、ＬｉｎｕｘのＯＳ、ＡｎｄｒｏｉｄのＯＳ、固有アプリの全体を一括して更新する場合に限らず、それらのいずれかのみを更新する場合にあっても、停止処理部１０ｂによる停止処理を行うことができる。また、ＡｎｄｒｏｉｄのＯＳのみの更新時には、配信アプリ（配信アプリ用記憶領域Ｒ５）に関しても併せて更新することができる。

次に、上記構成の作用について、図５も参照して述べる。図５のフローチャートは、制御部１０が実行するソフトウエア更新の処理手順を示している。即ち、例えばイグニッションスイッチがオンされて車載装置１が起動されると、ステップＳ１にて、通常動作が行われる。今、ユーザがソフトウエアの更新処理を実行させたい場合には、更新するソフトウエアを記憶したＵＳＢメモリ２０を、ＵＳＢコネクタ１５ａに接続する。

ステップＳ２では、ソフトウエアの更新を行うかどうかが判断される。この判断は、更新ソフトウエアを記憶したＵＳＢメモリ２０がＵＳＢコネクタ１５ａに接続されているかどうかによりなされ、ソフト更新用のＵＳＢメモリ２０を認識しない場合には（ステップＳ２にてＮｏ）、ステップＳ１に戻り、通常動作が行われる。ソフト更新用のＵＳＢメモリ２０を認識した場合には（ステップＳ２にてＹｅｓ）、ステップＳ３にて、Ａｎｄｒｏｉｄの機能を一時停止させる停止処理が実行される。このときには、表示部１２にソフト更新処理の画面が表示される。

そして、ステップＳ４にて、ソフトウエアの更新処理が実行される。このソフトウエア更新処理では、ＵＳＢメモリ２０から記憶装置１１に対するソフトウエアのコピーやインストールの処理が実行される。この処理中には、Ａｎｄｒｏｉｄの機能が停止されているので、配信アプリが実行されることはない。ステップＳ５にて、ソフトウエアの更新処理が完了すると、ステップＳ６にて、装置が再起動される。再起動後は、通常動作に戻り、全てのソフトウエア（アプリ）の実行が可能となる。

ここで、ハイブリッドＯＳ構造を有するシステムでは、Ａｎｄｒｏｉｄ上で動作する外部から配信された配信アプリとして、予め予測できない配信アプリが取得される（開発される）ケースがある。そのような配信アプリが、車載装置１に予め搭載されている固有アプリの機能に対し、予期しない様々な影響を及ぼす懸念がある。特にソフトウエアの更新時には、配信アプリの動作によって、ソフトウエア更新のための書込み速度や処理能力に悪影響を与え、更新に要する時間が異常に長くなったり、安定性が大幅に低下したりする虞がある。

ところが、本実施形態では、ソフト更新部１０ａによるソフトウエアの更新動作中には、停止処理部１０ｂにより、Ａｎｄｒｏｉｄの機能が一時停止される。従って、本実施形態によれば、Ｌｉｎｕｘによる固有アプリ及びＡｎｄｒｏｉｄによる配信アプリの実行が可能なハイブリッドＯＳ構造を備えるものにおいて、ソフトウエアの更新動作中に配信アプリが実行されることに伴う予期せぬ不具合の発生を未然に防止することができるという優れた効果を得ることができる。

また、特に本実施形態では、更新ソフトウエアを記録したＵＳＢメモリ２０が、ＵＳＢコネクタ１５ａに接続されることに基づいて、ソフト更新部１０ａが、更新処理を実行するように構成したので、簡易な操作で更新処理を実行させることができる。この場合、近年では、車載システムにおいて、車両のアームレスト等にＵＳＢコネクタ１５ａを設けることが一般的に行われているため、メディアとしてＵＳＢメモリ２０を採用することにより、構成の複雑化を招くことなく、安価に済ませることができる。

本実施形態では、ソフト更新部１０ａが実行する記憶装置１１のソフトウエアの更新においては、ＬｉｎｕｘのＯＳ、ＡｎｄｒｏｉｄのＯＳ、固有アプリ（必要なもの）の全体を一括して更新するケースだけでなく、ＬｉｎｕｘのＯＳのみの更新、固有アプリ（必要なもの）のみの更新、ＡｎｄｒｏｉｄのＯＳのみの更新についても、つまり、個別のソフトウエア更新時においても、停止処理部１０ｂによるＡｎｄｒｏｉｄの機能の一時停止の処理が行われる。これにより、個別のソフトウエアの更新時においても、ソフトウエアの更新動作中に配信アプリが実行されることに伴う予期せぬ不具合の発生を未然に防止することができる。

尚、上記実施形態では、メディアとしてＵＳＢメモリ２０を採用したが、例えば光ディスクや磁気ディスク等の他のメディアを採用しても良い。更には、メディアを介さずに、インターネット等を介した通信によりソフトウエアを更新する場合でも、本発明を適用することができる。第１のＯＳとしてＬｉｎｕｘを採用すると共に、第２のＯＳとしてＡｎｄｒｏｉｄを採用した場合を例示したが、これに限定されるものではなく、各種のＯＳを採用することができる。

また、上記実施形態では車載装置１としてナビゲーションシステムを例示したが、本発明は、ナビゲーション装置に限定されるものではなく、オーディオ装置、電話装置等、車両に搭載されている各種ＥＣＵ（Electronic Control Unit）全般を対象として適用することができる。その他、車載装置のハードウエア構成や、制御部のソフトウエア構成等についても種々の変更が可能である等、本発明は、上記した実施形態に限定されることなく、要旨を逸脱しない範囲で適宜変更して実施し得るものである。

図面中、１は車載装置、４，５，６はサーバ（外部機器）、１０は制御部、１０ａはソフト更新部（更新手段）、１０ｂは停止処理部（停止手段）、１１は記憶装置、１５ａはＵＳＢコネクタ、２０はＵＳＢメモリ（メディア）を示す。

Claims

装置本体に予め搭載されている固有アプリケーションを実行するための第１のＯＳと、外部の機器（４，５，６）から取得される配信アプリケーションを実行するための第２のＯＳとを含むハイブリッドＯＳ構造を備える車載装置（１）であって、
前記複数のＯＳ及びアプリケーションを記憶する記憶装置（１１）と、
前記記憶装置（１１）の各ソフトウエアを更新する更新手段（１０ａ）と、
前記更新手段（１０ａ）によるソフトウエアの更新動作中に前記第２のＯＳの機能を一時停止させる停止手段（１０ｂ）を設けたことを特徴とする車載装置。
前記更新手段（１０ａ）によるソフトウエアの更新は、前記第１のＯＳのみの更新、前記固有アプリケーションのみの更新、前記第２のＯＳの更新を含んでいることを特徴とする請求項１記載の車載装置。
前記更新手段（１０ａ）は、更新ソフトウエアを記録したメディア（２０）が、前記装置本体に接続されることに基づいて、更新処理を実行することを特徴とする請求項１又は２記載の車載装置。
前記第２のＯＳは、Ａｎｄｒｏｉｄ（登録商標）であることを特徴とする請求項１から３のいずれか一項に記載の車載装置。