JP2023045278A - 車載システム - Google Patents

Abstract

【課題】主電源の電力を消費することなく安定的にデータ更新可能な車載システムを提供することを目的とする。【解決手段】ＤＣＭ２０は、ＯＴＡセンタ１２から受信したアップデートデータを指示ＥＣＵ２４ａのストレージ２４Ｄに一時的に格納する。ＩＧがオフされた場合、バックアップ電源２８が指示ＥＣＵ２４ａ及びターゲットＥＣＵ２４ｂに対して電力を供給し、指示ＥＣＵ２４ａは、ターゲットＥＣＵ２４ｂに対してストレージ２４Ｄに一時格納したアップデートデータを送信する。そして、アップデートデータを受信したターゲットＥＣＵ２４ｂは、受信した情報に基づいてアップデートを実施する。【選択図】図４

Description

本発明は、車両に搭載された車載システムに関する。

特許文献１には、車両に搭載され、無線通信にて受信した更新プログラムにより記憶データを更新可能な複数の車載機器に対する電力供給を制御するソフトウエア更新装置が提案されている。当該ソフトウエア更新装置は、無線通信によって取得した情報に基づいて、複数の車載機器のうち更新対象となる更新対象機器を判断する更新対象判断部と、更新対象判断部により更新対象機器であると判断された車載機器に対する電力供給が断たれている場合に、その車載機器に対して電力供給を行う電力供給制御部とを備えている。

特開２０１７－０２７５４９号公報

車両が走行している際には、更新の対象機器が制御中の場合、更新できないので、駐車中等の車両が停車している場合に、更新する必要があるが、この場合、電力供給が絶たれているため、特許文献１の技術を利用して更新を行うことができる。しかしながら、特許文献１の技術では、更新対象とする車載機器への電力の供給状態を検出する必要があり、また、電力が未供給の場合には、バッテリから電力を供給するため、駐車中に主電源であるバッテリの電力が消費されてしまい、安定的にソフトウエアを更新するためには、改善の余地がある。

本発明は、上記事実を考慮して成されたもので、主電源の電力を消費することなく安定的にデータ更新可能な車載システムを提供することを目的とする。

上記目的を達成するために請求項１に記載の車載システムは、車両の主電源が失陥した場合に、前記車両内に電力供給可能な補助電源と、車外からデータを受信する受信部と、前記車両の電源スイッチがオフ時に、前記補助電源からの電力を利用して、前記受信部によって受信したデータを対象の車載器に送信してデータを更新する更新部と、を含む。

請求項１に記載の車載システムによれば、補助電源は、車両の主電源が失陥した場合に、車両内に電力供給が可能とされている。受信部は、車外からデータを受信する。

そして、更新部では、車両のイグニッションスイッチ等の電源スイッチがオフ時に、補助電源からの電力を利用して、受信部によって受信したデータを対象の車載器に送信してデータが更新される。これにより、車両の電源スイッチがオフ時に補助電源の電力を利用して車外から受信したデータによる車載器のデータ更新が可能となるため、主電源の電力を消費することなく安定的にソフトウエアの更新が可能となる。

以上説明したように本発明によれば、主電源の電力を消費することなく安定的にデータ更新可能な車載システムを提供できる。

本実施形態に係る車載システムの概略構成を示す図である。 本実施形態に係る車載システムにおける車両内の構成例を示すブロック図である。 本実施形態に係る車載システムにおけるＤＣＭ及び複数のＥＣＵの電気系の要部構成を示すブロック図である。 本実施形態に係る車載システムにおけるデータ更新の流れを説明するための図である。 本実施形態に係る車載システムにおいて、ＩＧがオンされた場合にＤＣＭで行われる処理の流れの一例を示すフローチャートである。 本実施形態に係る車載システムにおいて、ＩＧがオンされた場合に指示ＥＣＵで行われる処理の流れの一例を示すフローチャートである。 本実施形態に係る車載システムにおいて、ＩＧがオフされてバックアップ電源から電力供給を受けた場合に指示ＥＣＵで行われる処理の流れの一例を示すフローチャートである。 本実施形態に係る車載システムにおいて、ＩＧがオフされてバックアップ電源から電力供給を受けて指示ＥＣＵからアップデートデータが送信された場合にターゲットＥＣＵで行われる処理の流れの一例を示すフローチャートである。

以下、図面を参照して本発明の実施の形態の一例を詳細に説明する。図１は、本実施形態に係る車載システムの概略構成を示す図である。

本実施形態に係る車載システム１０は、図１に示すように、車両１４と、ＯＴＡ（Over The Air）センタ１２とが通信ネットワーク１８を介して接続されている。通信ネットワークは、５Ｇ、ＬＴＥ、Ｗｉ－Ｆｉ（登録商標）等の無線通信網が適用される。

本実施形態に係る車載システム１０は、ＯＴＡセンタ１２と車両１４との間で無線通信を行うことで、車両１４に搭載された各種ＥＣＵ（Electronic Control Unit）のアップデートデータをＯＴＡセンタ１２から取得してプログラム等のソフトウエアを更新する。

図２は、本実施形態に係る車載システム１０における車両１４内の構成例を示すブロック図である。

車両１４には、受信部としてのＤＣＭ（Data Communication Module）２０、複数のＥＣＵ２４、ヒューマンＩＦ（インタフェース）２６、及び補助電源としてのバックアップ電源２８を備えている。ＤＣＭ２０及び複数のＥＣＵ２４は、各々ＣＡＮ（Controller Area Network）等の車載ネットワーク３０に接続されている。

ＤＣＭ２０は、アンテナ２２を備え、通信ネットワーク１８を介してＯＴＡセンタ１２と通信を行うための車載用の通信ユニットであり、通信ネットワーク１８に接続することで、ＯＴＡセンタ１２と車両１４との間の通信を行う。

複数のＥＣＵ２４は、車両１４の各部を制御する種々の制御機器であり、データの書き換えを指示するＥＣＵ２４ａと、書き換え対象となるＥＣＵ２４ｂを含む。データの書き換えを指示するＥＣＵ２４ａとしては、複数のＥＣＵ２４を一体化して制御するセントラルＥＣＵ、ＡＤ（Autonomous Driving）コントローラ、又はＡＤＡＳ（Advanced driver-assistance systems）ドメインコントローラが適用される。なお、以下では、データの書き換えを指示するＥＣＵ２４ａは指示ＥＣＵ２４ａと称し、書き換え対象のＥＣＵ２４ｂはターゲットＥＣＵ２４ｂと称する場合がある。また、指示ＥＣＵ２４ａ及びターゲットＥＣＵ２４ｂは同一のＥＣＵでもよい。また、指示ＥＣＵ２４ａは更新部の一例に対応し、ターゲットＥＣＵ２４ｂは車載器の一例に対応する。

ヒューマンＩＦ２６は、人への表示や、意思確認操作入力を可能とするインタフェースであり、例えば、ナビゲーションやメータ等を表示する。

バックアップ電源２８は、主電源としてのバッテリが失陥した場合のバックアップとして機能し、バッテリからの電力が未供給の場合に、複数のＥＣＵ２４に電力を供給可能とされている。例えば、ブレーキやシフトバイワイヤ、ステアバイワイヤ、自動運転システム等のバックアップとして電力を供給する。なお、バックアップ電源２８としては、例えば、キャパシタやリチウム電池等を用いることにより、鉛電池よりもＳＯＣを管理し易い。

続いて、本実施形態に係る車載システム１０におけるＤＣＭ２０及び複数のＥＣＵ２４の電気系の要部構成について説明する。

図３は、本実施形態に係る車載システム１０におけるＤＣＭ２０及び複数のＥＣＵ２４の電気系の要部構成を示すブロック図である。なお、ＤＣＭ２０及び複数のＥＣＵ２４は基本的には一般的なコンピュータの構成とされているので、ここではＤＣＭ２０を代表して説明する。

ＤＣＭ２０は、ＣＰＵ（Central Processing Unit）２０Ａ、ＲＯＭ（Read Only Memory）２０Ｂ、ＲＡＭ（Random Access Memory）２０Ｃ、ストレージ２０Ｄ、インタフェース（Ｉ／Ｆ）２０Ｅ、及びバス２０Ｆ等を含む一般的なマイクロコンピュータで構成されている。

ＣＰＵ２０Ａは、中央演算処理ユニットであり、各種プログラムを実行することにより、装置の全体の動作を司る。ＲＯＭ２０Ｂは、各種制御プログラムや各種パラメータ等が予め記憶される。ＲＡＭ２０Ｃは、ＣＰＵ２０Ａによる各種プログラムの実行時のワークエリア等として用いられる。ストレージ２０Ｄは、ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）、フラッシュメモリ等の各種記憶部により構成され、各種データやアプリケーションプログラム等が記憶される。Ｉ／Ｆ２０Ｅは、車載ネットワーク３０に接続可能とされ、当該車載ネットワーク３０に接続された他のＥＣＵ２４と各種データの送受信を行う。以上のＤＣＭ２０の各部はバス２０Ｆにより電気的に相互に接続されている。

なお、指示ＥＣＵ２４ａのストレージ２４Ｄは、他のＥＣＵ２４よりも大容量とされ、本実施形態ではアップデートデータをＯＴＡセンタ１２から受信して一時的に指示ＥＣＵ２４ａのストレージ２４Ｄに格納する。アップデートデータの一例としては、更新プログラムの他に、制御用の定数などのデータのみの場合もある。

ここで、上述のように構成された本実施形態に係る車載システム１０におけるデータ更新の流れを、図４を参照して説明する。図４は、本実施形態に係る車載システム１０におけるデータ更新の流れを説明するための図である。

ＯＴＡセンタ１２は、アップデート対象のプログラム等がある場合、通信ネットワーク１８を介して、イグニッションスイッチがオン中にＤＣＭ２０に対して送信する。なお、イグニッションスイッチは車両の電源スイッチであり、以下では、イグニッションスイッチを単にＩＧと称す場合がある。

ＤＣＭ２０は、ＯＴＡセンタ１２から受信したアップデートデータを指示ＥＣＵ２４ａのストレージ２４Ｄに一時的に格納する。アップデートデータの一時的な格納は、ＩＧオン時に行い、走行中でもよい。

指示ＥＣＵ２４ａは、ＤＣＭ２０を介したアップデートデータのダウンロードが全て完了すると、アップデート可能状態となる。そして、指示ＥＣＵ２４ａは、運転者等の乗員に対して、次回のＩＧオフ時にアップデート対象であるターゲットＥＣＵ２４ｂをアップデートして良いかの許諾確認をヒューマンＩＦ２６により実施する。

許諾確認の結果、乗員からアップデートの許諾があった場合、バックアップ電源２８及びターゲットＥＣＵ２４ｂに次回ＩＧオフ時にアップデートを実施することを通知する。

ここで、ＩＧがオフされた場合、バックアップ電源２８が指示ＥＣＵ２４ａ及びターゲットＥＣＵ２４ｂに対して電力を供給する。指示ＥＣＵ２４ａは、バックアップ電源２８のＳＯＣ（State Of Charge）を確認し、十分に書き換えできる電力があることを確認する。

バックアップ電源２８の電力の確認後に、指示ＥＣＵ２４ａは、ターゲットＥＣＵ２４ｂに対してストレージ２４Ｄに一時格納したアップデートデータを送信する。

アップデートデータを受信したターゲットＥＣＵ２４ｂは、受信した情報に基づいてアップデートを実施する。

指示ＥＣＵ２４ａは、アップデートの送信が完了したところで、ターゲットＥＣＵ２４ｂのアップデートが完了するまで待機する。

ターゲットＥＣＵ２４ｂは、アップデートの受信が完了したところで、チェックサム等によりアップデートデータが正しいか否かを検証し、問題無い場合は指示ＥＣＵ２４ａに問題ないことを返信する。

指示ＥＣＵ２４ａは、ターゲットＥＣＵ２４ｂの書き換えが問題なく終了したことを確認したところで、バックアップ電源２８にアップデート終了を通知する。

バックアップ電源２８は、アップデート終了を確認したところで、指示ＥＣＵ２４ａ及びターゲットＥＣＵ２４ｂへの電力の供給を終了する。

これにより、次回ＩＧオン時にターゲットＥＣＵ２４ｂでは、アップデートしたプログラム等で制御及び動作が実施される。

続いて、上述のように構成された本実施形態に係る車載システム１０の各部で行われる具体的な処理について説明する。

まず、ＩＧがオンされた場合にＤＣＭ２０で行われる具体的な処理について説明する。図５は、本実施形態に係る車載システム１０において、ＩＧがオンされた場合にＤＣＭ２０で行われる処理の流れの一例を示すフローチャートである。

ステップ１００では、ＣＰＵ２０Ａが、アップデートの問い合わせをＯＴＡセンタ１２に行ってステップ１０２へ移行する。

ステップ１０２では、ＣＰＵ２０Ａが、アップデートがあるか否かを判定する。該判定が否定された場合には、ＩＧオン時の処理を終了し、肯定された場合にはステップ１０４へ移行する。

ステップ１０４では、ＣＰＵ２０Ａが、アップデートデータをＯＴＡセンタ１２から受信してステップ１０６へ移行する。

ステップ１０６では、ＣＰＵ２０Ａが、指示ＥＣＵ２４ａにアップデートデータを転送してステップ１０８へ移行する。

ステップ１０８では、ＣＰＵ２０Ａが、ＯＴＡセンタ１２からのアップデートデータの受信が終了したか否かを判定する。該判定が否定された場合にはステップ１０４に戻って上述の処理を繰り返し、判定が肯定されたところで一連のＩＧオン時の処理を終了する。

次に、ＩＧがオンされた場合に指示ＥＣＵ２４ａで行われる具体的な処理について説明する。図６は、本実施形態に係る車載システム１０において、ＩＧがオンされた場合に指示ＥＣＵ２４ａで行われる処理の流れの一例を示すフローチャートである。

ステップ２００では、ＣＰＵ２４Ａが、アップデートデータの受信であるか否かを判定する。該判定は、ＤＣＭ２０からアップデートデータの送信があるか否かを判定する。該判定が否定された場合にはＩＧオン時の処理を終了し、肯定された場合にはステップ２０２へ移行する。

ステップ２０２では、ＣＰＵ２４Ａが、アップデートデータをＤＣＭ２０から受信し、ストレージ２４Ｄにアップデートデータを格納してステップ２０４へ移行する。

ステップ２０４では、ＣＰＵ２４Ａが、予め定めたアップデート可否許諾画面をヒューマンＩＦ２６に表示してステップ２０６へ移行する。なお、アップデート可否許諾画面は、受信したアップデートを行うか否かを確認するための画面である。

ステップ２０６では、ＣＰＵ２４Ａが、許諾されたか否かを判定する。該判定は、ヒューマンＩＦ２６が操作されて、アップデートの許諾が指示されたか否かを判定する。該判定が否定された場合にはＩＧオン時の処理を終了し、肯定された場合にはステップ２０８へ移行する。

ステップ２０８では、ＣＰＵ２４Ａが、ＩＧオフ時にアップデート実施をバックアップ電源２８及びターゲットＥＣＵ２４ｂに通知してステップ２１０へ移行する。

ステップ２１０では、ＣＰＵ２４Ａが、未許諾アップデートデータが他にあるか否かを判定する。該判定は、既に受信したアップデートデータに対してアップデートの許諾がされていないものが他にあるか否かを判定する。該判定が肯定された場合にはステップ２０４に戻って、許諾されていないアップデートデータに対して上述の処理を繰り返す。一方、判定が否定された場合には一連のＩＧオン時の処理を終了する。

次に、ＩＧがオフされてバックアップ電源２８から電力供給を受けた場合に指示ＥＣＵ２４ａで行われる具体的な処理について説明する。図７は、本実施形態に係る車載システム１０において、ＩＧがオフされてバックアップ電源２８から電力供給を受けた場合に指示ＥＣＵ２４ａで行われる処理の流れの一例を示すフローチャートである。

ステップ２５０では、ＣＰＵ２４Ａが、アップデート許諾があるか否かを判定する。該判定は、上述のステップ２０６の判定が肯定されたアップデートの許諾が行われたか否かを判定する。該判定が否定された場合にはステップ２６４へ移行し、肯定された場合にはステップ２５２へ移行する。

ステップ２５２では、ＣＰＵ２４Ａが、バックアップ電源２８のＳＯＣを確認してステップ２５４へ移行する。

ステップ２５４では、ＣＰＵ２４Ａが、アップデート可能であるか否かを判定する。該判定は、ＳＯＣの確認結果からアップデートに必要な電力がバックアップ電源２８にあるか否かを判定する。該判定が否定された場合にはステップ２６４へ移行し、肯定された場合にはステップ２５６へ移行する。

ステップ２５６では、ＣＰＵ２４Ａが、ストレージ２４Ｄに一時格納したアップデートデータをターゲットＥＣＵ２４ｂに送信してステップ２５８へ移行する。

ステップ２５８では、ＣＰＵ２４Ａが、アップデートデータが問題ありか否かを判定する。該判定は、後述するターゲットＥＣＵ２４ｂで行われるアップデートデータの検証結果が問題ありか否かを判定する。該判定が肯定された場合にはステップ２６０へ移行し、否定された場合にはステップ２６２へ移行する。

ステップ２６０では、ＣＰＵ２４Ａが、アップデートデータの再取得要求を行ってステップ２６４へ移行する。例えば、次回ＩＧがオンされた際に、ＯＴＡセンタ１２に対してアップデートデータの再取得を要求する。

一方、ステップ２６２では、ＣＰＵ２４Ａが、アップデート完了か否かを判定する。該判定は、ターゲットＥＣＵ２４ｂからアップデート完了通知を受信したか否かを判定する。該判定が肯定されるまで待機してステップ２６４へ移行する。

ステップ２６４では、ＣＰＵ２４Ａが、バックアップ電源２８にアップデート終了を通知して一連のＩＧオフ時の処理を終了する。これにより、バックアップ電源２８からの電力供給がオフされる。

続いて、ＩＧがオフされてバックアップ電源２８から電力供給を受けた場合にターゲットＥＣＵ２４ｂで行われる具体的な処理について説明する。図８は、本実施形態に係る車載システム１０において、ＩＧがオフされてバックアップ電源２８から電力供給を受けて指示ＥＣＵ２４ａからアップデートデータが送信された場合にターゲットＥＣＵ２４ｂで行われる処理の流れの一例を示すフローチャートである。

ステップ３００では、ＣＰＵ２４Ａが、アップデートデータを指示ＥＣＵ２４ａから受信してステップ３０２へ移行する。すなわち、上述のステップ２５６で指示ＥＣＵ２４ａから送信されたアップデートデータを受信する。

ステップ３０２では、ＣＰＵ２４Ａが、アップデートデータの受信を完了したか否かを判定する。該判定が肯定されるまで待機してステップ３０４へ移行する。

ステップ３０４では、ＣＰＵ２４Ａが、アップデートデータを検証してステップ３０６へ移行する。例えば、チェックサムによりアップデートデータが正しいものであるかの検証を行う。

ステップ３０６では、ＣＰＵ２４Ａが、アップデートデータの検証結果を指示ＥＣＵ２４ａに通知してステップ３０８へ移行する。これにより、上述のステップ２５８の判定が行われる。

ステップ３０８では、ＣＰＵ２４Ａが、アップデートデータが問題なしか否かを判定する。該判定は、ステップ３０４のアップデートデータの検証結果が問題なしか否かを判定する。該判定が肯定された場合にはステップ３１０へ移行し、否定された場合にはそのままアップデートせずに一連のＩＧオフ時の処理を終了する。

ステップ３１０では、ＣＰＵ２４Ａが、アップデートデータに基づいて、アップデートを実行してステップ３１２へ移行する。

ステップ３１２では、ＣＰＵ２４Ａが、アップデートの完了を指示ＥＣＵ２４ａに通知して一連のＩＧオフ時の処理を終了する。これにより、上述のステップ２６２の判定が肯定される。

このように処理を行うことにより、本実施形態に係る車載システム１０では、走行中を含むＩＧオン時にアップデートデータを受信しておき、指示ＥＣＵ２４ａのストレージ２４Ｄに一時格納する。そして、ＩＧがオフされた際に、バックアップ電源２８を利用してターゲットＥＣＵ２４ｂにアップデートデータを転送してアップデートを行うので、主電源の電力を消費することなく安定的にデータ更新が可能となる。

バックアップ電源２８は、もともと車両１４の安全性を担保するために、電源失陥時のバックアップとして実装しており、電源失陥状態にならなければ、無駄に捨ててしまうことが多い。例えば、バックアップ電源２８がキャパシタの場合は、バックアップ電源２８の寿命のために熱変換して強制的に電力を放電して捨ててしまうことが多い。本実施形態では、バックアップ電源２８を用いてアップデートを行うので、無駄に捨ててしまう電力を有効利用することが可能となる。

従来のＥＣＵのアップデートでは、車両１４が停車しているＩＧオフ中に実施され、エンジンは作動していないため未発電状態であるため、主電源の電力は不安定な状態で、電源状態の管理が難しい。これに対して、本実施形態に係る車載システム１０では、バックアップ電源２８を用いるため、ＩＧオフ時のアップデートの際の電源管理が容易となる。

また、バックアップ電源２８は元々主電源のバックアップ用なので、コスト追加を最小限として、ＯＴＡによるアップデートが可能となる。

また、指示ＥＣＵ２４ａの一例として適用する、セントラルＥＣＵ、ＡＤコントローラ、又はＡＤＡＳドメインコントローラは、元々画像の大容量データ等を扱うため、大容量ストレージを搭載しており、ターゲットＥＣＵ２４ｂのソフトウエア等のアップデートデータを一時保存することに対して、メモリ容量的に問題にならない。

なお、上記の実施形態では、走行状態を含むＩＧオン時にアップデートデータをＤＣＭ２０がダウンロードする例を説明したが、これに限るものではない。バックアップ電源２８の電力がダウンロードとアップデートに必要な電力量がある場合には、ＩＧオフ時にアップデートデータのダウンロードも行う形態としてもよい。

また、上記の各実施形態における車載システム１０の各部で行われる処理は、プログラムを実行することにより行われるソフトウエア処理として説明したが、これに限るものではない。例えば、ＧＰＵ（Graphics Processing Unit）、ＡＳＩＣ（Application Specific Integrated Circuit）、及びＦＰＧＡ（Field-Programmable Gate Array）等のハードウエアで行う処理としてもよい。或いは、ソフトウエア及びハードウエアの双方を組み合わせた処理としてもよい。また、ソフトウエアの処理とした場合には、プログラムを各種記憶媒体に記憶して流通させるようにしてもよい。

さらに、本発明は、上記に限定されるものでなく、上記以外にも、その主旨を逸脱しない範囲内において種々変形して実施可能であることは勿論である。

１０ 車載システム
１２ ＯＴＡセンタ
１４ 車両
１８ 通信ネットワーク
２０ ＤＣＭ（受信部）
２４ ＥＣＵ
２４ａ 指示ＥＣＵ（更新部）
２４ｂ ターゲットＥＣＵ（車載器）
２６ ヒューマンＩＦ
２８ バックアップ電源（補助電源）

Claims (1)

1. 車両の主電源が失陥した場合に、前記車両内に電力供給可能な補助電源と、
   車外からデータを受信する受信部と、
   前記車両の電源スイッチがオフ時に、前記補助電源からの電力を利用して、前記受信部によって受信したデータを対象の車載器に送信してデータを更新する更新部と、
   を含む車載システム。
   
   
   

Images