JP2020197837A - 車両用装置 - Google Patents

Abstract

【課題】複数の機能が動作する環境において不具合が生じた場合、正常に動作している機能への影響を抑制しつつ、不具合を解消することができる車両用装置を提供する。【解決手段】実施形態の車両用装置（１）は、複数のオペレーティングシステム（１１Ａ、１１Ｂ）が動作するシステムが構築されている制御部（１０）と、システムの不具合を監視する複数の監視部（２１、２２、２３）と、を備え、複数の監視部は、システムを複数の階層に区分けした各階層に対してそれぞれ監視を行い、不具合が生じた場合、階層単位で不具合を解消する。【選択図】図１

Description

本発明は、車両用装置に関する。

従来、車両用装置は、不具合が生じた場合の復帰手段が設けられている。例えば、特許文献１には、メイン制御部とサブ制御部とを設け、不具合が生じた制御部を再起動することによって不具合を解消することが開示されている。

特許第３３４３８１６号

さて、近年では、例えば速度などの車両に関する情報を提示する機能部に加えて、例えばナビゲーション画面などのいわゆるマルチメディア系の情報を提供する機能部を備えた車両用装置がある。このような車両用装置では、複数の機能部を実現するために、複数のオペレーティングシステムが動作している。以下、オペレーティングシステムをＯＳと称する。

しかしながら、例えば複数のＯＳを動作させることで複数の機能を実現している場合、従来のように全体を再起動する構成では、１つの機能について不具合が生じた場合であっても車両用装置全体が再起動されてしまう。その結果、正常に動作している他の機能の動作を継続することができなくなる。これは、各ＯＳ上で動作するアプリケーションプログラムに不具合が生じた場合も同様である。

本発明の目的は、複数の機能が動作する環境において不具合が生じた場合、正常に動作している機能への影響を抑制しつつ、不具合を解消することができる車両用装置を提供することにある。

上記目的を達成するために、本発明では、車両用装置（１）は、複数のオペレーティングシステム（１１Ａ、１１Ｂ）が動作するシステムが構築されている制御部（１０）と、システムの不具合を監視する複数の監視部（２１、２２、２３）と、を備え、複数の監視部は、システムを複数の階層に区分けした各階層に対してそれぞれ監視を行い、不具合が生じた場合、階層単位で不具合を解消する。

このような構成により、不具合を解消する対象となる範囲が各階層内に限定され、複数の機能が動作する環境において不具合が生じた場合、正常に動作している機能への影響を抑制しつつ、不具合を解消することができる。

実施形態による車両用装置の構成を模式的に示す図 第１監視部による監視処理の流れを示す図 第２監視部による監視処理の流れを示す図 第３監視部による監視処理の流れを示す図 車両用装置の他の構成を模式的に示す図

以下、実施形態について説明する。図１に示すように、車両用装置１は、例えばメータディスプレイ２やセンターディスプレイ３などの複数の表示器、ユーザが所有する携帯端末などの外部装置４、車両に搭載されている他のＥＣＵ５、および車両用装置１電源を供給する第１電源回路６および第２電源回路７を制御する電源制御部８などに接続されている。

この車両用装置１は、後述するように車両に関する情報の提示とマルチメディア系の情報の提示とを行うことができるいわゆる車両インフォテイメント装置である。なお、図１に示す構成は一例であり、これに限定されない。例えば、車両には多数のＥＣＵ５が設けられており、車両用装置１は、それら多数のＥＣＵ５と各種の情報を通信可能に接続されている。

メータディスプレイ２は、例えば液晶ディスプレイや有機ＥＬディスプレイで構成されており、運転者の正面付近に位置するメータパネルに設けられている。このメータディスプレイ２には、例えば速度、警告、法規により定められている情報、燃料の残量やシートベルト装着の有無など、主として車両の状態に関する情報や車両の走行あるいは安全に関する情報がフルグラフィックで示される。以下、これらの情報を便宜的に車両情報と称する。なお、メータパネルの例えば中央部分にメータディスプレイ２を設け、速度計や回転数計あるいは警告灯などはいわゆるアナログ式のものを設ける構成とすることもできる。

センターディスプレイ３は、例えば液晶ディスプレイや有機ＥＬディスプレイで構成されており、いわゆるセンターコンソール付近に設けられている。このセンターディスプレイ３には、例えばナビゲーション画面やメニュー画面などが表示される。また、センターディスプレイ３は、テレビ放送や再生している楽曲の情報などを表示することもできる。

これらメータディスプレイ２やセンターディスプレイ３は、互いにシームレスに連係した表示が可能となっている。そのため、例えばナビゲーション画面をメータディスプレイ２に表示したり、速度をセンターディスプレイ３に表示したりすることができる。

つまり、車両用装置１は、車両情報を表示する機能とマルチメディア系の情報を表示する機能とを含む複数の機能部が統合され、各種の情報を運転者に対して視覚的あるいは聴覚的に提示可能な統合型の構成となっている。

この車両用装置１は、１つの制御部１０によって制御されている。制御部１０は、いわゆるマイクロコンピュータで構成されており、図示しない記憶部に記憶されているコンピュータプログラムをＣＰＵ１２上で実行することにより、車両用装置１を制御している。そして、制御部１０上には、複数のオペレーティングシステム１１が動作可能なシステムが構築されている。以下、オペレーティングシステム１１をＯＳ１１と称する。

本実施形態の場合、制御部１０上ではＯＳ１１ＡとＯＳ１１Ｂの２つが動作しており、それぞれ処理を分担している。これらのＯＳ１１は、ＣＰＵ１２が備える複数のコアに割り当てられている。

具体的には、各ＯＳ１１は、ハイパーバイザ１３上で動作している。本実施形態の場合、ハイパーバイザ１３は、ＯＳ１１Ａが備える機能として提供されている。なお、ハイパーバイザ１３を専用に設け、そのハイパーバイザ１３上でＯＳ１１ＡおよびＯＳ１１Ｂの双方を動作させる構成とすることもできる。これらＯＳ１１ＡとＯＳ１１Ｂとの間は、通信可能に接続されている。

ＯＳ１１Ａは、いわゆるリアルタイムＯＳであり、ＯＳ１１Ｂに比べてリアルタイム性が要求される処理、例えば、車両の走行あるいは安全に関係する処理などを主に実行する機能部が設けられている。このようなリアルタイムＯＳは、一般的に、ＯＳ１１Ａ自体に不具合が起きにくく、また、アプリケーションプログラムの実行時間などを予測あるいは制限できる等、汎用ＯＳに比べて相対的に安定性が高い設計となっている。以下、アプリケーションプログラムをアプリと称する。このＯＳ１１Ａは、第１のオペレーティングシステムに相当する。

ＯＳ１１Ｂは、いわゆる汎用ＯＳであり、ＯＳ１１Ａに比べるとリアルタイム性能や安定性は相対的に低いことが多いものの、マルチメディア機能のような汎用的な処理を容易に実行できるというメリットがある。このＯＳ１１Ｂは、第２のオペレーティングシステムに相当する。

各ＯＳ１１は、それぞれアプリを実行することにより、各種の機能部をソフトウェアで実現している。制御部１０が備える機能部としては、例えばメータ表示アプリ１４、ナビアプリ１５、通信アプリ１６などがある。なお、図１に示す機能部の数や種類あるいは機能部を実装するＯＳ１１は一例であり、これらに限定されない。

メータ表示アプリ１４は、主としてメータディスプレイ２への表示を行う機能部として設けられている。このメータ表示アプリ１４は、速度計のように車両の走行に必要な情報を表示するものであるとともに、例えば１／６０秒程度の比較的短い周期で表示を更新する。そのため、メータ表示アプリ１４は、ＯＳ１１Ａに設けられている。このメータ表示アプリ１４が表示する画像は、例えばＬＶＤＳ形式の描画データとしてメータディスプレイ２に送信される。

ナビアプリ１５は、主としてセンターディスプレイ３への表示を行う機能部として設けられている。このナビアプリ１５は、例えばナビゲーション画面の生成および表示や経路案内の音声出力などのマルチメディア系の処理を行っている。そのため、ナビアプリ１５は、ＯＳ１１Ｂに設けられている。このナビアプリ１５が表示する画像は、例えばＬＶＤＳ形式の描画データとしてセンターディスプレイ３に送信される。

通信アプリ１６は、車両用装置１に接続されている外部装置４との間で通信を行う機能部として設けられている。通信アプリ１６は、例えばＵＳＢ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｗｉ−Ｆｉなどの既知の通信方式を利用して外部装置４と通信を行う。外部装置４は、上記した携帯端末以外にも、タブレット、ＵＳＢメモリ、あるいはインターネット上のサーバなどを対象とすることができる。

この車両用装置１は、第１電源回路６および第２電源回路７から電源供給が行われている。第１電源回路６は、制御部１０やメータ表示回路１７など、主として制御系の情報を処理あるいは表示するためのデバイスに電源を供給する。この第１電源回路６は、図示しないバッテリから電源供給を受けており、バッテリの電圧が比較的低くなっても制御部１０等への電源供給が可能なように、低電圧対応の回路構成となっている。具体的には、第１電源回路６は、エンジン始動時のクランキング中にバッテリからの電圧が低下した場合であっても電源供給ができるように、電源供給が可能な最低動作電圧が、クランキング時に想定されるバッテリの電圧の最低値よりも低く設定されている。

第２電源回路７は、主としてセンター表示回路１８や通信回路１９など、マルチメディア系の情報を処理あるいは表示するためのデバイスに電源を供給する。この第２電源回路７もバッテリから電源供給を受けているものの、第１電源回路６とは異なり、低電圧対応の回路構成とはなっていない。具体的には、第２電源回路７は、電源供給が可能な最低動作電圧が第１電源回路６よりも高く設定されており、クランキング時にバッテリの電圧が低下した際には電源供給が停止されることがある。

電源制御部８は、制御部１０とは異なるマイクロコンピュータにより構成されている。この電源制御部８は、ＥＣＵ５から車両用装置１を始動すべき信号が入力されると、第１電源回路６および第２電源回路７からの電源供給を開始する。また、電源制御部８は、ＥＣＵ５から車両用装置１を停止すべき信号が入力された場合、第１電源回路６および第２電源回路７からの電源供給を停止する。

なお、車両用装置１の始動や停止は、操作入力回路２０を介して入力されるユーザの操作により行うこともできる。この操作入力回路２０は、メータディスプレイ２やセンターディスプレイ３の画面に対応して設けられているタッチパネルや、図示しない操作スイッチなどにより操作部を構成している。

また、車両用装置１には、本実施形態に関連して、第１監視部２１、第２監視部２２および第３監視部２３が設けられている。第１監視部２１は、電源制御部８上で実行されるコンピュータプログラムによってソフトウェアで実現された機能部である。

第１監視部２１は、後述するように、車両用装置１のシステムを複数の階層に区分けした構造における最上位の階層であって、制御部１０を監視対象とする第１階層での監視を行っている。この第１監視部２１は、矢印Ｆ１にて示すように制御部１０を監視しており、制御部１０に不具合が生じた場合、制御部１０の全体を再起動することにより不具合を解消する。

第２監視部２２は、後述するように、車両用装置１のシステムを複数の階層に区分けした構造における最上位から２番目となる階層であって、ＯＳ１１を監視対象とする第２階層での監視を行っている。本実施形態の場合、第２監視部２２は、ＯＳ１１Ａに設けられている。この第２監視部２２は、矢印Ｆ２にて示すようにＯＳ１１Ｂを監視しており、ＯＳ１１Ｂに不具合が生じた場合、ＯＳ１１Ｂを再起動することにより不具合を解消する。

第３監視部２３は、後述するように、車両用装置１のシステムを複数の階層に区分けした構造における最下位の階層であって、ＯＳ１１内で動作するアプリを監視対象とする第２階層での監視を行っている。本実施形態では、第３監視部２３は、各ＳＯ１１にそれぞれ設けられている。

この第３監視部２３は、矢印Ｆ３にて示すように各アプリを監視しており、アプリに不具合が生じた場合、アプリを再起動することにより不具合を解消する。このとき、第３監視部２３は、基本的には、不具合が生じたアプリを再起動する一方、不具合が生じていないアプリは再起動しない。

つまり車両用装置１では、プログラムレベルでシステムを複数の階層に区分けしており、階層ごとに監視を行うとともに、階層の上位になるほど、監視する範囲つまりは不具合が起きたときに再起動する範囲が広くなっている。

次に、上記した構成の車両用装置１の作用について説明する。
車両用装置１は、複数のＯＳ１１が動作しており、そのうちＯＳ１１Ａは、相対的に且つ一般的に安定性が高く不具合が生じにくいと考えられる。これは、ＯＳ１１Ａ側の処理は基本的に車両用装置１の内部に関するものであるため、十分な開発やデバッグが行われることにも起因する。

一方、ＯＳ１１Ｂ側は、汎用的な処理を行うものであり、また、車両用装置１の外部から取得したデータを利用して動作することがある。そのため、ＯＳ１１ＡとＯＳ１１Ｂとでは、品質レベルに差が生じることになる。換言すると、不具合が生じるリスクはＯＳ１１Ｂのほうが高いと考えられる。

そして、ＯＳ１１Ｂ側に仮に不具合が生じたとしても、基本的には独立して動作しているＯＳ１１Ａ側は、その不具合の影響を受けずに動作を継続できると考えられる。しかし、従来のような不具合が生じた際に制御部１０の全体を再起動する構成では、ごく一部のアプリに不具合が生じたとしても全体が再起動されてしまう。換言すると、複数の機能の一部に不具合が生じた場合、不具合を解消すべき範囲の大小に関わらず全体が再起動されてしまうことから、不具合が生じていない例えばＯＳ１１Ａの動作を継続させることもできなくなる。

そこで、車両用装置１は、以下のようにして、複数の機能が動作する環境において不具合が生じた場合、正常に動作している機能への影響を抑制しつつ、不具合を解消している。なお、以下の処理は各監視部によって行われるものの、説明の簡略化のために、車両用装置１を主体にして説明する。

車両用装置１は、図２から図４に示す処理を実行している。このうち、図２に示す処理は、第１監視部２１によって実行されるＣＰＵ間での監視処理である。また、図３に示す処理は、第２監視部２２によって実行されるＯＳ１１間での監視処理である。また、図４に示す処理は、第３監視部２３によって実行されるＯＳ１１とアプリ間での監視処理である。以下、各処理を個別に説明する。

まず、第１階層における不具合の監視とその解消の態様について説明する。車両用装置１は、図２に示す処理を実行しており、ステップＳ１において、制御部１０の監視を開始する。このとき、車両用装置１は、例えばロック監視、無限ループ、リセット監視、通信途絶監視、起動時間監視などを行っている。これらの監視内容は一般的なものであるため詳細な説明は省略するが、ロック監視では、プログラムが実行されない状態となる不具合が生じていないかを監視している。また、無限ループでは、プログラムがループする状態になる不具合が生じていないかを監視している。また、リセット監視では、制御部１０がリセット状態となる不具合が生じていないかを監視している。また、通信途絶監視では、制御部１０との間の通信が途絶する状態となる不具合が生じていないかを監視する。また、起動時間監視では、予め設定された時間内にモジュールが起動したかを監視する。

なお、これらの監視内容は、対象が異なるものの、後述する図３に示すＯＳ１１間での監視処理、および図４に示すＯＳ１１とアプリ間での監視処理にも共通する。ただし、監視内容は、上記した例に限定されず、他の内容を監視することができる。

監視を開始すると、車両用装置１は、ステップＳ２において、不具合を検知したかを判定する。車両用装置１は、不具合を検知していないと判定した場合には、ステップＳ２においてＮＯとなることから、ステップＳ１に移行して監視を継続する。一方、車両用装置１は、不具合を検知したと判定した場合には、ステップＳ２においてＹＥＳとなることから、ステップＳ３において、制御部１０を再起動する。これにより、制御部１０に生じた不具合、換言すると、車両用装置１のシステムの広範囲に影響を与える不具合が解消される。

その後、車両用装置１は、ステップＳ４において、再起動が完了したかを判定し、再起動が完了していないと判定した場合には、ステップＳ４においてＮＯとなるため、再起動が完了するのを待機する。一方、車両用装置１は、再起動が完了したと判定した場合には、ステップＳ４においてＹＥＳとなるため、ステップＳ１に移行して制御部１０の監視を開始する。なお、この図２に示す処理は、車両用装置１の停止時に終了する。
このように、車両用装置１は、車両用装置１のシステム全体に影響がある不具合については、制御部１０を再起動することにより解消している。

次に、第２階層における不具合の監視とその解消の態様について説明する。車両用装置１は、図３に示す処理を実行しており、ステップＳ１１において、ＯＳ１１Ｂの監視を開始する。このとき、車両用装置１は、上記したロック監視、無限ループ、リセット監視、通信途絶監視などを行っている。

監視を開始すると、車両用装置１は、ステップＳ１２において、不具合を検知したかを判定する。車両用装置１は、不具合を検知していないと判定した場合には、ステップＳ１２においてＮＯとなることから、ステップＳ１１に移行して監視を継続する。一方、車両用装置１は、不具合を検知したと判定した場合には、ステップＳ１２においてＹＥＳとなることから、ステップＳ１３において、ＯＳ１１Ｂを再起動する。

その後、車両用装置１は、ステップＳ１４において、再起動後に不具合が解消されたかを判定する。なお、このステップＳ１４は、ＯＳ１１Ｂの再起動後に実行されることになる。車両用装置１は、再起動によりＯＳ１１Ｂの不具合が解消されたと判定した場合には、ステップＳ１４においてＹＥＳとなることから、ステップＳ１１に移行して監視を継続する。

これにより、ＯＳ１１Ｂに影響を与える不具合が解消される。このとき、不具合が検知されていないＯＳ１１Ａについては、基本的にその動作が継続されることになる。つまり、不具合が影響する範囲をＯＳ１１Ｂ単位に限定した状態で、不具合を解消することができる。

これに対して、車両用装置１は、不具合が解消されていないと判定した場合には、ステップＳ１４においてＮＯとなるため、ステップＳ１５において、再起動回数が所定のＭ回以上であるかを判定する。本実施形態ではＭ＝２に設定しているが、Ｍは、１や３以上などの適宜の値に設定することができる。車両用装置１は、再起動回数がＭ回以上ではないと判定した場合には、ステップＳ１５においてＮＯとなることから、ステップＳ１３に移行して再起動を繰り返す。

一方、車両用装置１は、再起動を繰り返して実行し、再起動回数がＭ以上になったと判定した場合には、ステップＳ１５においてＹＥＳとなることから、第１監視部２１に通知する。このとき、車両用装置１は、第２階層では不具合を解消できなかったことを第１監視部２１に通知する。なお、このステップＳ１５では、不具合を通知する代わりに、制御部１０を再起動する指示を直接的に通知する構成とすることもできる。

そして、通知を受けた第１監視部２１は、図２に示したように不具合を検知したと判定することになり、不具合を解消するために制御部１０を再起動する。これにより、ＯＳ１１Ｂを再起動しても解消できなかった不具合、つまりは、第２階層では納まらなかった不具合が、第１階層を監視する第１監視部２１によって解消される。

このように、車両用装置１は、ＯＳ１１単位の再起動で解消できる不具合については第２階層内で解消する一方、第２階層では解消できない不具合が生じた場合には、より広い範囲で不具合を解消することが可能な上位の第１監視部２１に通知することで不具合を解消する。

次に、第３階層における不具合の監視とその解消の態様について説明する。車両用装置１は、図４に示す処理を実行しており、ステップＳ２１において、ＯＳ１１上で動作するアプリの監視を開始する。このとき、車両用装置１は、上記したロック監視、無限ループ、リセット監視、通信途絶監視などを行っている。なお、この第３階層の監視は、ＯＳ１１ＡとＯＳ１１Ｂの双方で行われる。

監視を開始すると、車両用装置１は、ステップＳ２２において、不具合を検知したかを判定する。車両用装置１は、不具合を検知していないと判定した場合には、ステップＳ２２においてＮＯとなることから、ステップＳ２１に移行して監視を継続する。一方、車両用装置１は、不具合を検知したと判定した場合には、ステップＳ２２においてＹＥＳとなることから、ステップＳ２３において、不具合が検知されたアプリを再起動する。

その後、車両用装置１は、ステップＳ２４において、再起動後に不具合が解消されたかを判定する。なお、このステップＳ２４は、アプリの再起動後に実行されることになる。車両用装置１は、再起動によりアプリの不具合が解消されたと判定した場合には、ステップＳ２４においてＹＥＳとなることから、ステップＳ２１に移行して監視を継続する。

これにより、アプリに生じた不具合を、そのアプリ単体を再起動することによって解消することができる。このとき、不具合が検知されていないアプリについては、基本的にその動作が継続されることになる。つまり、不具合が影響する範囲をアプリ単位に限定した状態で、不具合を解消することができる。

これに対して、車両用装置１は、不具合が解消されていないと判定した場合には、ステップＳ２４においてＮＯとなるため、ステップＳ２５において、再起動回数が所定のＮ回以上であるかを判定する。本実施形態ではＮ＝２に設定しているが、Ｎは、１や３以上などの適宜の値に設定することができる。車両用装置１は、再起動回数がＮ回以上ではないと判定した場合には、ステップＳ２５においてＮＯとなることから、ステップＳ２３に移行して再起動を繰り返す。

一方、車両用装置１は、再起動を繰り返して実行し、再起動回数がＮ以上になったと判定した場合には、ステップＳ２５においてＹＥＳとなることから、第２監視部２２に通知する。このとき、車両用装置１は、第３階層では不具合を解消できなかったことを第２監視部２２に通知する。なお、このステップＳ２５では、不具合を通知する代わりに、不具合が検知されたアプリが動作しているＯＳ１１Ｂを再起動する指示を直接的に通知する構成とすることもできる。

そして、通知を受けた第２監視部２２は、図３に示したように不具合を検知したと判定することになり、不具合を解消するためにＯＳ１１を再起動する。このとき、第２階層でも不具合を解消できなかった場合には、さらに第１監視部２１に通知が行われ、制御部１０が再起動されることになる。

これにより、アプリを再起動しても解消できなかった不具合、つまりは、第３階層では納まらなかった不具合が、上位の第２階層を監視する第２監視部２２によって、あるいは、さらに上位の第１階層を監視する第１監視部２１によって解消される。

このように、車両用装置１は、アプリ単位の再起動で解消できる不具合については第３階層内で解消する一方、第３階層では解消できない不具合が生じた場合には、より広い範囲で不具合を解消することが可能な上位の第２監視部２２あるいは第１監視部２１に通知することで不具合を解消する。

このように、車両用装置１は、システムを複数の階層に区分けして各階層で監視を行うことにより、階層内で解消できる不具合については各階層の監視部で解消し、階層内で解消できない不具合については上位の階層の監視部で解消している。

以上説明した実施形態によれば、次のような効果を得ることができる。
車両用装置１は、複数のＯＳ１１ＡおよびＯＳ１１Ｂが動作するシステムが構築されている制御部１０と、システムの不具合を監視する第１監視部２１、第２監視部２２および第３監視部２３の複数の監視部と、を備え、複数の監視部は、システムを複数の階層に区分けした各階層に対してそれぞれ監視を行い、不具合が生じた場合、階層単位で不具合を解消する。

これにより、不具合を解消するために例えば再起動される範囲を、基本的に各階層内に限定することが可能になる。その結果、不具合が生じていない機能について動作を継続させることが可能になる。したがって、複数の機能が動作する環境において不具合が生じた場合、正常に動作している機能への影響を抑制しつつ、不具合を解消することができる。

また、車両用装置１では、複数の監視部は、制御部１０の外部に設けられ、制御部１０を監視対象とする第１階層において監視を行う第１監視部２１と、制御部１０上に設けられ、ＯＳ１１を監視対象とする第２階層において監視を行う第２監視部２２と、ＯＳ１１上に設けられ、アプリを監視対象とする第３階層において監視を行う第３監視部２３と、を備えている。

そして、第１監視部２１は、制御部１０に不具合が生じた場合、制御部１０の全体を再起動することにより不具合を解消し、第２監視部２２は、ＯＳ１１に不具合が生じた場合、不具合が生じたＯＳ１１を再起動することにより不具合を解消し、第３監視部２３は、アプリに不具合が生じた場合、不具合が生じたアプリを再起動することにより不具合を解消する。

これにより、車両用装置１は、自身のシステムをプログラムレベルで、換言すると、再起動がし易い単位で、階層に区分けすることが可能になる。したがって、階層単位での監視および再起動による不具合の解消を容易に実行することができる。

また、車両用装置１では、相対的に安定性が高いＯＳ１１Ａと、ＯＳ１１に比べると相対的に安定性が低いＯＳ１１Ｂとを含み、第２監視部２２は、ＯＳ１１Ａに設けられて、ＯＳ１１Ｂを監視する。これにより、不具合が生じるリスクが相対的に高いＯＳ１１Ｂを、安定性の高いＯＳ１１Ａ側から監視することができ、不具合の検知とその解消とをより確実に行うことができるようになる。

また、車両用装置１では、第３監視部２３は、アプリを再起動しても不具合を解消できない場合、第２監視部２２に対して不具合の解消を指示し、第２監視部２２は、ＯＳ１１を再起動しても不具合を解消できない場合、第１監視部２１に対して不具合の解消を指示する。

これにより、各階層内で解消できない不具合が生じた場合には、直近の上位となる階層において不具合の解消を試みることが可能になるとともに、直近の上位となる階層において不具合を解消できない場合には、さらに上位の階層つまりは制御部１０全体を再起動することが可能になる。したがって、階層内で解消できない不具合であっても、最終的に解消することができる。

実施形態では第２監視部２２をＯＳ１１Ａに設ける構成を例示したが、ＯＳ１１Ｂにも設け、互いのＯＳ１１を監視する構成とすることができる。あるいは、図５に示すように、第２監視部２２をハイパーバイザ１３上に設け、ＯＳ１１ＡとＯＳ１１Ｂとを監視する構成とすることができる。この場合、３以上のＯＳ１１を実装する場合も同様に、ＯＳ１１Ａに第２監視部２２を設けたり、各ＯＳ１１にそれぞれ第２監視部２２を設けたり、ハイパーバイザ１３上に第２監視部２２を設けて各ＯＳ１１を監視する構成とすることができる。

実施形態ではプログラム側を再起動することで不具合を解消する例を示したが、車両用装置１は、複数のＥＣＵ５など多数の装置に接続されているため、プログラム側を再起動したとしても、周辺回路等のデバイスやＥＣＵ５などとの間で動作状態の不一致が発生する場合がある。そして、動作状態の不一致が発生した場合には、プログラム側を再起動しても正常に復帰できないおそれがある。換言すると、車両用装置１の場合には、プログラム側の再起動だけでなく、周辺回路等のデバイスやＥＣＵ５などとの連携のために、デバイスを正常に復帰させる仕組みが必要になる。

そこで、車両用装置１では、複数の監視部は、各階層で不具合を解消する際、当該階層で利用されているデバイスを初期化の対象に含める。これにより、例えばセンター表示回路１８の不具合に起因してナビアプリ１５に不具合が生じたような場合において、ナビアプリ１５を再起動しても不具合の根本的な原因が解消されないといった状況や、デバイスが中途半端に動作していることによってアプリとの連係や同期がとれずに再起動後に不具合がさらに生じるといった状況を回避することができる。これは、第１階層や第２階層の場合も同様である。

このとき、各監視部は、デバイスのうち、図５に示すように１つのＯＳ１１に占有される占有デバイス３０と、複数のＯＳ１１で共有される共有デバイス３１とで、不具合を解消した後の初期化シーケンスを変更する構成とすることができる。

例えば、占有デバイス３０についてはＯＳ１１の再起動時に初期化処理を行う構成とし、共有デバイス３１については、再起動させるＯＳ１１に対して一旦サービスを停止し、再起動するＯＳ１１にとっては通常の起動シーケンスにしたがって再度サービスを起動するようにする。これにより、再起動した側のＯＳ１１は、通常の通りデバイスを利用することができる。なお、サービスとしては、物理的なデバイスにアクセスするための仮想デバイスの提供や、その仮想デバイスの初期化などが考えられる。

この場合、対象となるデバイスとしては、車両用装置１が備えるメータ表示回路１７，センター表示回路１８、通信回路１９、操作入力回路２０、また、車両用装置１に接続されているメータディスプレイ２やセンターディスプレイ３などを対象とすることができる。すなわち、制御部１０の制御対象となるデバイスを対象とすることができる。

例えば占有デバイス３０がＯＳ１１Ａによって占有されており、共有デバイス３１がＯＳ１１ＡとＯＳ１１Ｂによって共有されているとする。そして、例えば第２階層においてＯＡ１１Ｂに不具合が生じて再起動する際、占有デバイス３０は再起動せずに、共有デバイス３１を再起動する構成とすることができる。

このような構成とすることにより、デバイスを不必要に初期化することが省略される。これにより、例えば第２階層においてＯＳ１１Ｂを再起動した際、正常に動作しているＯＳ１１Ａがデバイスの初期化によって動作しなくなると言った不具合が生じるおそれを抑制することができる。

あるいは、第１階層において制御部１０に不具合が生じて再起動する際には、占有デバイス３０と共有デバイス３１の双方を再起動する構成とすることができる。これにより、デバイスが中途半端に動作していることによって制御部１０を再起動した後の動作に影響を与えることを防止できる。

なお、占有デバイス３０や共有デバイス３１としては、制御部１０のいわゆる周辺デバイスに限らず、制御部１０が内蔵するキャッシュメモリなども対象とすることができるし、仮想化環境において周辺デバイスにアクセスする際に利用する例えばＯＳ１１が仮想化された仮想占有デバイス３２や仮想共有デバイス３３なども対照することができる。また、上記した制御部１０の制御対象となるデバイスを対象とすることもできる。

また、実施形態では、車両用装置１の動作中に生じた不具合を解消する例を示したが、例えば操作入力回路２０を介して不具合を解消するための操作がユーザによって入力されたことに基づいて、例えば図２から図４に示す処理を実行する構成とすることができる。この場合、アプリの再起動する操作が入力されたとき、アプリの再起動では不具合を解消できない場合には、上位の階層で不具合の解消を試みる構成とすることができる。

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

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

図面中、１は車両用装置、２はメータディスプレイ（デバイス）、３はセンターディスプレイ（デバイス）、６は第１電源回路（デバイス）、７は第２電源回路（デバイス）、１０は制御部、１１、１１Ａ、１１ＢはＯＳ（オペレーティングシステム）、１４はメータ表示アプリ（アプリケーションプログラム）、１５はナビアプリ（アプリケーションプログラム）、１６は通信アプリ（アプリケーションプログラム）、１７はメータ表示回路(デバイス）、１８はセンター表示回路(デバイス）、１９は通信回路(デバイス）、２０は操作入力回路(デバイス）、２１は第１監視部、２２は第２監視部、２３は第３監視部、３０は占有デバイス（デバイス）、３１は共有デバイス（デバイス）、３２は仮想占有デバイス（デバイス、占有デバイス）、３３は仮想共有デバイス（デバイス、共有デバイス）を示す。

Claims (7)

1. 複数のオペレーティングシステム（１１Ａ、１１Ｂ）が動作するシステムが構築されている制御部（１０）と、
   前記システムの不具合を監視する複数の監視部（２１、２２、２３）と、を備え、
   複数の前記監視部は、前記システムを複数の階層に区分けした各階層に対してそれぞれ監視を行い、不具合が生じた場合、階層単位で不具合を解消する車両用装置。
2. 複数の前記監視部は、前記制御部の外部に設けられ、前記制御部を監視対象とする第１階層において監視を行う第１監視部（２１）と、前記制御部上に設けられ、オペレーティングシステムを監視対象とする第２階層において監視を行う第２監視部（２２）と、前記オペレーティングシステム上に設けられ、アプリケーションプログラムを監視対象とする第３階層において監視を行う第３監視部（２３）と、を備え、
   前記第１監視部は、前記制御部に不具合が生じた場合、前記制御部の全体を再起動することにより不具合を解消し、
   前記第２監視部は、オペレーティングシステムに不具合が生じた場合、不具合が生じたオペレーティングシステムを再起動することにより不具合を解消し、
   前記第３監視部は、アプリケーションプログラムに不具合が生じた場合、不具合が生じたアプリケーションプログラムを再起動することにより不具合を解消する請求項１記載の車両用装置。
3. 複数のオペレーティングシステムは、相対的に安定性が高い第１のオペレーティングシステム（１１Ａ）と、前記第１のオペレーティングシステムに比べると相対的に安定性が低い第２のオペレーティングシステム（１１Ｂ）と、を含み、
   前記第２監視部は、前記第１のオペレーティングシステムに設けられ、前記第２のオペレーティングシステムを監視する請求項２記載の車両用装置。
4. 前記第３監視部は、アプリケーションプログラムを再起動しても不具合を解消できない場合、前記第２監視部に対して不具合の解消を指示し、
   前記第２監視部は、オペレーティングシステムを再起動しても不具合を解消できない場合、前記第１監視部に対して不具合の解消を指示する請求項２または３記載の車両用装置。
5. 複数の前記監視部は、各階層で不具合を解消する際、当該階層で利用されているデバイスを初期化の対象に含める請求項１から４のいずれか一項記載の車両用装置。
6. 複数の前記監視部は、前記デバイスのうち、１つのオペレーティングシステムに占有される占有デバイスと、複数のオペレーティングシステムで共有される共有デバイスとで、不具合を解消した後の初期化シーケンスを変更する請求項５記載の車両用装置。
7. 複数の前記監視部は、不具合を解消するために入力された操作に基づいて、不具合を解消する請求項１から６のいずれか一項記載の車両用装置。

Images