2024-161998 車載機

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

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024161998

(43)【公開日】2024-11-21

(54)【発明の名称】車載機

(51)【国際特許分類】

   G06F 8/65 20180101AFI20241114BHJP

   B60R 16/02 20060101ALI20241114BHJP

【ＦＩ】

G06F8/65

B60R16/02 660U

【審査請求】未請求

【請求項の数】5

【出願形態】ＯＬ

(21)【出願番号】P 2023077115

(22)【出願日】2023-05-09

(71)【出願人】

【識別番号】000003207

【氏名又は名称】トヨタ自動車株式会社

(74)【代理人】

【識別番号】100105957

【弁理士】

【氏名又は名称】恩田 誠

(74)【代理人】

【識別番号】100068755

【弁理士】

【氏名又は名称】恩田 博宣

(72)【発明者】

【氏名】宮澤 知明

(72)【発明者】

【氏名】中林 良太

(72)【発明者】

【氏名】四方田 直輝

(72)【発明者】

【氏名】森 敦

(72)【発明者】

【氏名】井上 博司

(72)【発明者】

【氏名】北沢 つかさ

【テーマコード（参考）】

5B376

【Ｆターム（参考）】

5B376CA44

5B376GA07

(57)【要約】

【課題】ソフトウェア更新に際してのユーザへの問い合わせの頻度を低減する。
【解決手段】車両１０に搭載されたＯＴＡマスタ１１は、車両１０のソフトウェアの更新を管理する車載機として構成される。ＯＴＡマスタ１１は、ソフトウェアの種別に基づきユーザ許諾の要否を判定する。そして、ＯＴＡマスタ１１は、ユーザ許諾が必要であると判定した場合に、ソフトウェアの更新のための処理を実施するか否かのユーザへの問い合わせを実施する。
【選択図】図１

【特許請求の範囲】

【請求項1】

車両に搭載されて同車両のソフトウェアの更新を管理する車載機であって、
前記ソフトウェアの種別に基づきユーザ許諾の要否を判定する判定部と、
前記判定部により前記ユーザ許諾が必要であると判定された場合に、前記ソフトウェアの更新のための処理を実施するか否かのユーザへの問い合わせを実施する制御部と、
を備える車載機。

【請求項2】

前記ソフトウェアの更新は、更新データのダウンロード、更新対象となる車載機器への更新プログラムのインストール、及び更新プログラムのアクティベートの３つのフェイズを通じて行われ、
前記判定部は、前記３つのフェイズのそれぞれの実施についての前記ユーザ許諾の要否を個別に判定する請求項１に記載の車載機。

【請求項3】

前記ユーザ許諾が必要であると前記判定部が判定する前記ソフトウェアの種別、及び前記ユーザ許諾が不要であると前記判定部が判定する前記ソフトウェアの種別を前記ユーザが選択可能に構成されている請求項１に記載の車載機。

【請求項4】

前記制御部は、前記車両に搭載されたヒューマン・マシン・インターフェイスを通じて前記問い合わせを実施する請求項１に記載の車載機。

【請求項5】

前記制御部は、前記ユーザの携帯端末を通じて前記問い合わせを実施する請求項１に記載の車載機。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、車両に搭載される車載機に関する。

【背景技術】

【0002】

上記のような車載機として、特許文献１には、車両のソフトウェア更新の管理を行う車載機が記載されている。同車載機は、ソフトウェアを更新する際に、ユーザに対して、更新の要否、及び更新開始時期についての問い合わせを実施している。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２０２１－１０５９２３号公報

【発明の概要】

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

【0004】

ソフトウェアの更新が高頻度で行われると、ユーザへの問い合わせの回数も増加する。その結果、ユーザが、頻繁な問い合わせに対して煩わしさを感じることがある。

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

【0005】

上記課題を解決する車載機は、車両に搭載されて同車両のソフトウェアの更新を管理する車載機であって、前記ソフトウェアの種別に基づきユーザ許諾の要否を判定する判定部と、前記判定部により前記ユーザ許諾が要であると判定された場合に、前記ソフトウェアの更新のための処理を実施するか否かのユーザへの問い合わせを実施する制御部と、を備えている。

【発明の効果】

【0006】

上記車載機には、ソフトウェア更新に際してのユーザへの問い合わせの頻度を低減する効果がある。

【図面の簡単な説明】

【0007】

【図1】車載機の一実施形態の構成を模式的に示す図である。

【図2】ソフトウェアの更新処理の流れを示すシーケンス図である。

【図3】ソフトウェアの種別毎のユーザ承認要否の設定例を示す表である。

【図4】承諾画面の一例を示す図である。

【図5】選択画面の一例を示す図である。

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

【0008】

以下、車載機の一実施形態を、図１～図４を参照して詳細に説明する。
＜車載機の構成＞
まず、図１を参照して、本実施形態の車載機の構成を説明する。

【0009】

車両１０には、車両１０の各部を制御する各種のＥＣＵ（電子制御ユニット）１５が搭載されている。ＥＣＵ１５の例としては、エンジンＥＣＵ、変速機ＥＣＵ、ブレーキＥＣＵ、先進運転支援ＥＣＵ、マルチメディアＥＣＵが挙げられる。

【0010】

また、車両１０には、車両１０でのソフトウェア更新の管理を行う車載機であるＯＴＡマスタ１１が搭載されている。ＯＴＡマスタ１１は、処理回路１２及び記憶装置１３を備えている。記憶装置１３には、ソフトウェア更新の管理用のプログラムが予め格納されている。ＯＴＡマスタ１１は、記憶装置１３に格納されたプログラムを処理回路１２が読み込んで実行することで、ソフトウェア更新の管理に関する処理を行うように構成されている。本実施形態では、ＯＴＡマスタ１１が、車両１０のソフトウェアの更新を管理する車載機に対応する。ＯＴＡマスタ１１には、移動体通信網１８を通じた車外通信を行うための無線通信モジュール１７が接続されている。

【0011】

さらに車両１０には、ＨＭＩ（ヒューマン・マシン・インターフェイス）１６が搭載されている。ＨＭＩ１６は、乗員の操作を受け付ける入力装置と、画像や音声により乗員に情報を提示する出力装置と、を備えている。本実施形態の場合、ＨＭＩ１６は、走行経路を案内するナビゲーション機能、及び音楽や映像を再生するエンターテイメント機能を備えている。ＯＴＡマスタ１１、各ＥＣＵ１５、及びＨＭＩ１６は、車載ネットワーク回線１４を介して互いに通信可能に構成されている。

【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】

１０ 車両
１１ ＯＴＡマスタ
１２ 処理回路
１３ 記憶装置
１４ 車載ネットワーク回線
１５ ＥＣＵ
１６ ＨＭＩ
１７ 無線通信モジュール
１８ 移動体通信網
２０ ＯＴＡサーバ
２１ 処理回路
２２ 記憶装置
３０ 携帯端末
３１ 処理回路
３２ 記憶装置
３３ ＨＭＩ

【図1】

【図2】

【図3】

【図4】

【図5】