JP2017097620A

JP2017097620A - ソフトウェア更新装置

Info

Publication number: JP2017097620A
Application number: JP2015229046A
Authority: JP
Inventors: 武幸早崎; Takeyuki Hayasaki
Original assignee: Toyota Motor Corp
Current assignee: Toyota Motor Corp
Priority date: 2015-11-24
Filing date: 2015-11-24
Publication date: 2017-06-01
Anticipated expiration: 2035-11-24
Also published as: JP6428580B2

Abstract

【課題】車両乗員が指定するソフトウェア更新期間にソフトウェア更新処理を実行可能としつつ、ソフトウェア更新処理を中断及び再開できるようにするソフトウェア更新装置の提供。【解決手段】車両に実装されるソフトウェアを更新するためのソフトウェア更新装置であって、ソフトウェアの更新期間を指定する携帯端末と、指定された更新期間に車外のサーバーから更新ソフトウェアをダウンロードし、更新ソフトウェアを用いて、ソフトウェアを更新する車載器とを備え、車載器は、ソフトウェアの更新処理中に、所定の中断条件が成立すると、ソフトウェアの更新処理を中断し、該中断中に、所定の再開条件が成立すると、ソフトウェアの更新処理を再開する。【選択図】図１

Description

本発明は、ソフトウェア更新装置に関する。

車両外部からソフトウェアをダウンロードすることでソフトウェア更新を行う車載ソフトウェア更新装置であって、過去のＡＣＣのオン／オフ状態を記憶する記憶手段を備え、記憶手段内の情報に基づいて、ＡＣＣがオフされている可能性の高い最適期間を推定し、該推定した最適期間が、ソフトウェア更新に必要なダウンロード所要時間よりも長いか否かを判断し、推定した最適期間が、ソフトウェア更新に必要なダウンロード所要時間よりも長いと判断した場合に、推定した最適期間内にソフトウェア更新期間を決定し、決定したソフトウェア更新期間内にソフトウェア更新を行う車載ソフトウェア更新装置が知られている（例えば、特許文献１参照）。

ＷＯ２０１０／１１３３４８号パンフレット

しかしながら、上記の特許文献１に記載されるような従来技術では、ソフトウェア更新期間が過去のＡＣＣのオン／オフ状態に基づいて自動的に決定されるため、車両乗員が希望するソフトウェア更新期間にソフトウェア更新処理を行うことが難しい。

他方、車両乗員が希望するソフトウェア更新期間にソフトウェア更新処理を行うことを可能とすると、例えば車両の走行中等にソフトウェア更新処理が実行されうる。この場合、例えば車両乗員の安全に関わる優先度の高い処理に遅延が発生しないように、ソフトウェア更新処理を中断及び再開できるようにすることが望ましい。

そこで、本発明は、車両乗員が指定するソフトウェア更新期間にソフトウェア更新処理を実行可能としつつ、ソフトウェア更新処理を中断及び再開できるようにするソフトウェア更新装置の提供を目的とする。

上記目的を達成するため、本発明の一局面によれば、車両に実装されるソフトウェアを更新するためのソフトウェア更新装置であって、
前記ソフトウェアの更新期間を指定する携帯端末と、
指定された前記更新期間に車外のサーバーから更新ソフトウェアをダウンロードし、前記更新ソフトウェアを用いて、前記ソフトウェアを更新する車載器とを備え、
前記車載器は、前記ソフトウェアの更新処理中に、所定の中断条件が成立すると、前記ソフトウェアの更新処理を中断し、該中断中に、所定の再開条件が成立すると、前記ソフトウェアの更新処理を再開する、ソフトウェア更新装置が提供される。

本発明によれば、車両乗員が指定するソフトウェア更新期間にソフトウェア更新処理を実行可能としつつ、ソフトウェア更新処理を中断及び再開できるようにするソフトウェア更新装置が得られる。

ソフトウェア更新装置に関連するシステム１を示す図である。システム１の動作例を示すタイミングチャートである。ソフトウェア更新処理における中断及び再開場面の一例を概略的に示すタイミングチャートである。ソフトウェア更新処理における中断及び再開場面の他の一例を概略的に示すタイミングチャートである。ソフトウェア更新処理における中断しない場面の一例を概略的に示すタイミングチャートである。

以下、図面を参照して、本発明を実施するための最良の形態の説明を行う。

図１は、ソフトウェア更新装置に関連するシステム１を示す図である。

システム１は、携帯端末３と、車載器２１と、サーバー４１と、ＯＴＡ（Over-The-Air）サーバー４２とを含む。これらは、ネットワーク５を介して接続される。ネットワーク５は、携帯電話網、インターネット網、ローカルエリアネットワーク等を含む。尚、以下で説明する実施例においては、携帯端末３及び車載器２１がソフトウェア更新装置の一例を形成する。

携帯端末３は、ユーザに所持される。携帯端末３は、例えばスマートフォンである。

車載器２１は、データ通信モジュール（ＤＣＭ：Data Communication Module）２１１と、ＥＣＵ（Electronic Control Unit）２１２と、緊急通報スイッチ２１６とを含む。ＥＣＵ２１２は、メモリ２１４を含む。データ通信モジュール２１１は、車両ソフトウェアの更新やサーバー４１との通信を実施する。車両ソフトウェアは、ＥＣＵ２１２が実行する制御処理のためのソフトウェア等を含む。緊急通報スイッチ２１６は、例えば事故や病気等のような緊急時にユーザが操作するスイッチである。緊急通報スイッチ２１６が操作されると、データ通信モジュール２１１は、サーバー４１等を介して、オペレータや近くの救急センタ等に電話回線をつなぐ。

図２は、システム１の動作例を示すタイミングチャートである。

まず、事前処理として、携帯端末３は、車両更新固有アプリケーションがダウンロードされプリインストールされる（Ｓ１）。車両更新固有アプリケーションは、ディーラー等の限られた場所でしか第三者が勝手にアクセスできない様なセキュリティー機能を有する。以下で説明する携帯端末３の機能は、車両更新固有アプリケーションにより実現される。

携帯端末３は、OTAサーバー４２及びサーバー４１から、車両ソフトウェア更新通知を、(SMS：Short Message Service等)により受信する（Ｃ１）。

携帯端末３は、車両ソフトウェア更新通知を受信すると、ユーザに車両ソフトウェア更新案内を出力する（Ｓ２）。車両ソフトウェア更新案内は、ソフトウェア更新期間を入力を促すメッセージを含む。例えば、ユーザは、車両を運転をしない期間（例えば就寝時間）を入力するように促される。車両ソフトウェア更新案内は、更新に係る車両ソフトウェアの内容を表す情報を含む。これにより、ユーザは、車両ソフトウェア更新案内に基づいて、自車に更新ソフトウェアが準備されたこと、更新ソフトウェアの機能差分、更新ソフトウェアの重要性等を知ることができる。

ユーザは、車両ソフトウェア更新案内を受けて、ユーザーは車両ソフトウェアの更新に同意するか否かを判断する（Ｓ３）。同意する場合には、ユーザは、車両ソフトウェアを更新するソフトウェア更新期間を、携帯端末３に入力する（Ｓ３−１）。例えば、ユーザは、何月何日何時から何月何日何時までといった期間、又は、何月何日何時から何時間といった期間を入力する。入力されたソフトウェア更新期間情報は、サーバー４１を介してOTAサーバー４２に登録され（Ｃ５，Ｃ６）、ソフトウェアの更新準備が可能となる。他方、同意しない場合には、ユーザは、その旨を、携帯端末３に入力する。この場合、同意しない旨の通知が携帯端末３からサーバー４１を介してOTAサーバー４２に送られる（Ｃ３，Ｃ４）。この場合には、ユーザーの携帯端末３に、再度、車両ソフトウェア更新通知が送られる（図示せず）。

尚、ユーザは、指定したソフトウェア更新期間までに車両ソフトウェアの更新をキャンセルをしたくなった場合、携帯端末３にキャンセル通知を入力する。この場合、OTAサーバー４２にキャンセル通知が送られ、ソフトウェアの更新準備状態が解除される。その場合には代わりにユーザーの携帯端末３に、ディーラーでサービス対応をお願いする通知メッセージがOTAサーバー４２から送信される（図示せず）。

OTAサーバー４２は、登録されたソフトウェア更新期間情報に基づいて、ソフトウェア更新期間が到来するのを待機し（Ｓ４−１）、ソフトウェア更新期間が到来すると、ソフトウェア更新処理の開始をトリガする（Ｓ４−２）。OTAサーバー４２は、ソフトウェア更新処理の開始トリガとして、更新ソフトウェアのバージョン（版数）を知らせるバージョン通知を行う（Ｃ７，Ｃ８）。

データ通信モジュール２１１は、バージョン通知を受け取ると、更新ソフトウェアが現在の版数よりも新しいかどうかを判定し（Ｓ５）、更新ソフトウェアが現在の版数よりも新しくない場合は、更新不要通知（否定応答）をデータ通信モジュール２１１等を介してOTAサーバー４２に送信する（Ｃ９，Ｃ１０）。この場合、OTAサーバー４２は、ソフトウェア更新を実行しない（Ｓ６）。他方、更新ソフトウェアが現在の版数よりも新しい場合は、更新要通知（肯定応答）をデータ通信モジュール２１１等を介してOTAサーバー４２に送信する（Ｃ１１，Ｃ１２）。この場合、OTAサーバー４２は、差分ソフトウェアのダウンロード処理を行う（Ｓ７、Ｃ１３）。

この場合、車両は走行等の動作をしていない事が好ましいが、車両が動作していても差分ソフトウェアのダウンロード処理は継続実行される（Ｓ８、Ｓ７、Ｃ１３）。車両が動作状態に無く、データ通信モジュール２１１が起動していない場合には、データ通信モジュール２１１を起動させ、その応答処理をもって、差分ソフトウェアのダウンロード処理を実施する。

データ通信モジュール２１１は、差分ソフトウェアのダウンロード処理が完了後、差分ソフトウェアをデータ通信モジュール２１１のメモリ空間（図示せず）に保持しておく。そして、データ通信モジュール２１１は、差分ソフトウェアに基づいて、ソフトウェア更新処理を行う（Ｓ９）。ソフトウェア更新処理が終了すると、その旨の通知（更新処理の成功通知）をデータ通信モジュール２１１等を介してOTAサーバー４２に送信する（Ｃ１４，Ｃ１５）。

ソフトウェア更新処理は、例えば以下の通り実行される。データ通信モジュール２１１は、ＲＯＭ（Read Only Memory）等のメモリ２１４に対してのソフトウェア更新を行うが、必要なソフトウェアはRAM（Random Access Memory）に展開しておき、ソフトウェア更新処理中（即ち差分ソフトウェアによる更新処理中）に、重要アプリケーションが作動する要求を受けた場合（中断条件の一例）等には、ソフトウェア更新処理を中断し、重要機能の優先度に従いアプリケーションを実行する。更新ソフトウェアに関しては、重要アプリケーションの動作完了後に、ソフトウェア更新処理を再開し、完了する。重要アプリケーションの例は、図３等を参照して後述する。

尚、データ通信モジュール２１１は、ソフトウェア更新処理中に中断する場合、ソフトウェア更新前の状態にメモリ２１４を戻す（即ちソフトウェアのロールバック処理を行う）。ロールバック処理後、IG-OFF状態（イグニッションスイッチのオフ状態）となると（再開条件の一例）、ソフトウェア更新処理を再起動し（再開し）、それ以外の状態であればIG-OFFの条件を待ってから再起動する。

また、データ通信モジュール２１１は、ソフトウェア更新処理を開始するに当たり、車両走行状態を確認することとしてもよい。車両が起動状態であっても、ソフトウェアのダウンロードは可能であるが、データ通信モジュール２１１は、更新時間の長いソフトウェアの更新処理については、IG-OFF状態となるまでソフトウェア更新処理の開始を待機する。データ通信モジュール２１１は、ソフトウェアの更新時間が短いものに関しては、即時メモリ２１４の書き換えを実施する。尚、更新時間の長いか否かは、実際のシステムレベルで適合された閾値を用いて判断される。

車両が起動前のソフトウェア更新処理であれば、ソフトウェア更新の通知がユーザーの携帯端末３に送られ、注意喚起される。これにより、ソフトウェア更新処理中の車両起動を抑制できる。或いは、データ通信モジュール２１１は、車両の起動機能を持つモジュールと機能連携し、一時的に起動を禁止する。車両起動が実際に禁止された場合には、サーバー４１との通信を通じて携帯端末３に禁止の旨が通知される。

内臓電池がある場合は、データ通信モジュール２１１は、ソフトウェア更新処理中の電源瞬断に対し、内臓電池の電力を使用する。ソフトウェア更新処理中に、電源の瞬断等により、ソフトウェアの更新処理が中断した場合、システムに重大な影響を与える可能性がある。その状態を避ける為、内臓電源を持つシステムでは、電源ソースを内蔵電池に切り替えてソフトウェアの更新処理を完遂またはロールバックすることができる。

データ通信モジュール２１１は、ソフトウェア更新処理中も、ＥＣＵ２１４の重要機能(緊急通報等)のみメモリ２１４に機能を展開しておく。一般的に、ソフトウェアの更新処理時は、フラッシュドライバが動作しており、その場合のアプリケーションは動作しない事が一般的な設計となっている。これに対して、データ通信モジュール２１１は、重要機能をあらかじめ、RAM領域に展開しておき、動作可能に維持する。尚、ソフトウェア更新処理は通常優先度が高いですが、重要機能の実行指令が、ハードウェア要因やソフトウェア要因で起動された場合（中断条件の一例）、データ通信モジュール２１１は、ソフトウェア更新処理を一時中断し、RAM上に展開している重要アプリケーションに、高い優先度を切り替えて重要アプリケーションの処理を実行する。このようにして、ソフトウェア更新処理中も、必要時に重要機能を実行できる。データ通信モジュール２１１は、その後、重要機能の実行が完了すると（再開条件の一例）、ソフトウェア更新処理を再開し、ソフトウェア更新処理を完了する。

図３は、ソフトウェア更新処理における中断及び再開場面の一例を概略的に示すタイミングチャートである。

ＥＣＵ２１２（本例ではエアバックＥＣＵ）は、エアバックが展開したとき、その旨を表すエアバック信号を発生し（Ｃ２０）、データ通信モジュール２１１がエアバック信号を受信する。データ通信モジュール２１１は、エアバック信号を受信すると（中断条件の一例）、ソフトウェア更新処理を中断する（Ｓ２０）。この場合、データ通信モジュール２１１は、エアバックが展開した旨をコールセンタに知らせるACN（Automatic Collision Notification）コールサービス処理を実行し（Ｓ２１）、ACNコールサービス処理が終了すると（再開条件の一例）（Ｓ２２の"ＹＥＳ"）、ソフトウェア更新処理を再開し（Ｓ２３）、ソフトウェア更新処理を完了する。

図４は、ソフトウェア更新処理における中断及び再開場面の他の一例を概略的に示すタイミングチャートである。

緊急通報スイッチ２１６は、ユーザにより操作されたとき、緊急通報信号を発生し（Ｃ４０）、データ通信モジュール２１１が緊急通報信号を受信する。データ通信モジュール２１１は、緊急通報信号を受信すると（中断条件の一例）、ソフトウェア更新処理を中断する（Ｓ４０）。この場合、データ通信モジュール２１１は、コールセンタに回線を繋ぐ緊急通報サービス処理を実行し（Ｓ４１）、緊急通報サービス処理が終了すると（再開条件の一例）（Ｓ４２の"ＹＥＳ"）、ソフトウェア更新処理を再開し（Ｓ４３）、ソフトウェア更新処理を完了する。

図５は、ソフトウェア更新処理における中断しない場面の一例を概略的に示すタイミングチャートである。

OTAサーバー４２は、リモートサービス要求をサーバー４１（図示せず）を介してデータ通信モジュール２１１に送る（Ｃ５０）。リモートサービス要求は、ソフトウェア更新以外の要求である。例えば、リモートサービス要求は、ダイアグデータのアップロード要求である。データ通信モジュール２１１は、リモートサービス要求を受信した場合でも、ソフトウェア更新処理を中断せず、リモートサービスが順番待ち状態となる（Ｓ５０）。データ通信モジュール２１１は、ソフトウェア更新処理が完了すると（Ｓ５２の"ＹＥＳ"）、リモートサービスに係る処理を実行する（Ｓ５４）。

ところで、車両（自動車等）における、ソフトウェアの更新は、ソフトウェアの更新中に、動作が保障出来ない為、通常はディーラーサービス等で実施される。データ通信モジュール２１１においても、緊急通報等の重要機能をサポートしている為、動的なソフトウェア更新時に、例えば交通事故が起きた場合には、緊急通報の機能が使用できない。この点、本実施例によれば、緊急通報等におけるシステムに対しても、安全にソフトウェア更新し、機能保障を実施できる。また、緊急通報等の安全にかかわる機能におけるソフトウェア更新についても、ディーラーサービス等に行ってソフトウェア更新をしなくても、ＯＴＡサーバー４２経由でソフトウェア更新を、ユーザの指定したソフトウェア更新期間に実行可能となり、緊急通報に影響を与えない仕組みを提供できる。
以上、本発明の好ましい実施例について詳説したが、本発明は、上述した実施例に制限されることはなく、本発明の範囲を逸脱することなく、上述した実施例に種々の変形及び置換を加えることができる。

１システム
３携帯端末
２１車載器
２１１データ通信モジュール
４１ＯＴＡサーバー
４２ OTAサーバー

Claims

車両に実装されるソフトウェアを更新するためのソフトウェア更新装置であって、
前記ソフトウェアの更新期間を指定する携帯端末と、
指定された前記更新期間に車外のサーバーから更新ソフトウェアをダウンロードし、前記更新ソフトウェアを用いて、前記ソフトウェアを更新する車載器とを備え、
前記車載器は、前記ソフトウェアの更新処理中に、所定の中断条件が成立すると、前記ソフトウェアの更新処理を中断し、該中断中に、所定の再開条件が成立すると、前記ソフトウェアの更新処理を再開する、ソフトウェア更新装置。