特許第6971189号(P6971189)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ クラリオン株式会社の特許一覧

<>
  • 特許6971189-車載装置、配信方法 図000002
  • 特許6971189-車載装置、配信方法 図000003
  • 特許6971189-車載装置、配信方法 図000004
  • 特許6971189-車載装置、配信方法 図000005
  • 特許6971189-車載装置、配信方法 図000006
  • 特許6971189-車載装置、配信方法 図000007
  • 特許6971189-車載装置、配信方法 図000008
  • 特許6971189-車載装置、配信方法 図000009
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6971189
(24)【登録日】2021年11月4日
(45)【発行日】2021年11月24日
(54)【発明の名称】車載装置、配信方法
(51)【国際特許分類】
   B60R 16/02 20060101AFI20211111BHJP
【FI】
   B60R16/02 660U
【請求項の数】5
【全頁数】13
(21)【出願番号】特願2018-67188(P2018-67188)
(22)【出願日】2018年3月30日
(65)【公開番号】特開2019-177745(P2019-177745A)
(43)【公開日】2019年10月17日
【審査請求日】2020年12月15日
(73)【特許権者】
【識別番号】000001487
【氏名又は名称】フォルシアクラリオン・エレクトロニクス株式会社
(74)【代理人】
【識別番号】110002365
【氏名又は名称】特許業務法人サンネクスト国際特許事務所
(72)【発明者】
【氏名】住友 義孝
【審査官】 森本 康正
(56)【参考文献】
【文献】 特開2016−170740(JP,A)
【文献】 特開2018−037022(JP,A)
【文献】 特開2005−332148(JP,A)
【文献】 特開2017−094783(JP,A)
【文献】 特開2010−258990(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
B60R 16/00−16/08
B60R 25/00−25/40
(57)【特許請求の範囲】
【請求項1】
車両に搭載され、前記車両に搭載された他の機器に前記他の機器に格納されている情報を更新させる更新本体を提供する車載装置において、
サーバから前記更新本体およびモードを含む更新情報を受信する取得部と、
前記モードを判別する種別判定部と、
前記モードが第1のモードであると判断すると前記他の装置からの応答を待たずに前記他の装置へ前記更新本体を送信し、前記モードが第2のモードであると判断すると前記他の装置へ問い合わせを行い承諾が得られると前記他の装置に前記更新本体を送信する配信部とを備える車載装置。
【請求項2】
請求項1に記載の車載装置において、
不揮発性の記憶領域である記憶部と、
前記更新本体を送信する前に電源の供給が遮断されると判断すると前記更新本体を前記記憶部に格納する格納部と、をさらに備える車載装置。
【請求項3】
請求項1に記載の車載装置において、
ユーザにより操作されるイグニッションスイッチの信号を受信する受信部をさらに備え、
前記配信部は、前記受信部がイグニッションスイッチがオフにされる信号を受信すると、前記他の装置に前記問い合わせを再送する車載装置。
【請求項4】
請求項1に記載の車載装置において、
不揮発性の記憶領域である記憶部をさらに備え、
前記配信部は、前記他の装置から前記更新本体を送信する承諾が得られない場合に前記更新本体を前記記憶部に格納する車載装置。
【請求項5】
車両に搭載され、前記車両に搭載された他の機器に前記他の機器に格納されている情報を更新させる更新本体を提供する車載装置が実行する配信方法であって、
サーバから前記更新本体およびモードを含む更新情報を受信することと、
前記モードを判別することと、
前記モードが第1のモードであると判断すると前記他の装置からの応答を待たずに前記他の装置へ前記更新本体を送信し、前記モードが第2のモードであると判断すると前記他の装置へ問い合わせを行い承諾が得られると前記他の装置に前記更新本体を送信することとを含む配信方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、車載装置、および配信方法に関する。
【背景技術】
【0002】
車両には多数の電子機器が搭載され、電子機器に内蔵される情報は必要に応じて更新される。従来は車両をディーラー等へ持ち込み、作業員が電子機器の情報を更新することが多かった。利便性の向上のために、無線通信を利用してインターネット上のサーバから情報を取得して更新することが望まれている。ただし全ての電子機器が個別にインターネットに接続する機能を有する構成はコスト面から現実的ではないため、サーバと通信する機器を設けてその機器を介してサーバから情報を取得する構成が知られている。
特許文献1には、車両に備わる車載コンピュータシステムにおいて、データ配信装置の公開鍵証明書である第1の公開鍵証明書を記憶する第1の車載コンピュータと、第2の車載コンピュータと、前記第1の公開鍵証明書の生成に使用される第2の秘密鍵に対応する第2の公開鍵証明書を記憶する第1のセキュアエレメントと、を備え、前記第1の車載コンピュータと前記第2の車載コンピュータとが前記車両に備わる通信ネットワークに接続され、前記第1のセキュアエレメントは、前記第2の公開鍵証明書を使用して前記第1の公開鍵証明書を検証し、前記第1の車載コンピュータは、前記データ配信装置から受信された第1のデータに付されている第1の電子署名を、前記第1のセキュアエレメントによって検証が合格した前記第1の公開鍵証明書を使用して検証する暗号処理部を備え、前記第1の車載コンピュータまたは前記第2の車載コンピュータに対して、前記暗号処理部によって検証が合格した前記第1の電子署名が付されていた前記第1のデータを適用する、車載コンピュータシステムが開示されている。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開2017−120984号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
特許文献1に記載されている発明では、サーバから情報を取得した機器について、その情報を他の機器に送信する際の挙動を変更できない。
【課題を解決するための手段】
【0005】
本発明の第1の態様による車載装置は、車両に搭載され、前記車両に搭載された他の機器に前記他の機器に格納されている情報を更新させる更新本体を提供する車載装置において、サーバから前記更新本体およびモードを含む更新情報を受信する取得部と、前記モードを判別する種別判定部と、前記モードが第1のモードであると判断すると前記他の装置からの応答を待たずに前記他の装置へ前記更新本体を送信し、前記モードが第2のモードであると判断すると前記他の装置へ問い合わせを行い承諾が得られると前記他の装置に前記更新本体を送信する配信部とを備える。
本発明の第2の態様による配信方法は、車両に搭載され、前記車両に搭載された他の機器に前記他の機器に格納されている情報を更新させる更新本体を提供する車載装置が実行する配信方法であって、サーバから前記更新本体およびモードを含む更新情報を受信することと、前記モードを判別することと、前記モードが第1のモードであると判断すると前記他の装置からの応答を待たずに前記他の装置へ前記更新本体を送信し、前記モードが第2のモードであると判断すると前記他の装置へ問い合わせを行い承諾が得られると前記他の装置に前記更新本体を送信することとを含む。
【発明の効果】
【0006】
本発明によれば、サーバから情報を取得した機器がその情報を他の機器に送信する際の挙動を変更できる。
【図面の簡単な説明】
【0007】
図1】更新システムSのハードウエア構成図
図2】TCU1が備える機能を示す機能ブロック図
図3図3(a)はサーバ4がTCU1に送信するサーバパケット800の構成を示す図、図3(b)はTCU1がECU30に送信するTCUパケット900の構成を示す図
図4】第1の実施の形態における配信部113の受信動作を表すフローチャート
図5】第1の実施の形態における配信部113の常時動作を表すフローチャート
図6】変形例1における配信部113の受信動作を表すフローチャート
図7】第2の実施の形態における配信部113の受信動作を表すフローチャート
図8】第2の実施の形態における配信部113の定常動作を表すフローチャート
【発明を実施するための形態】
【0008】
―第1の実施の形態―
以下、図1図4を参照して、本発明に係る車載装置の第1の実施の形態を説明する。
【0009】
(ハードウエア構成)
図1は更新システムSのハードウエア構成図である。更新システムSは、車両5とサーバ4とから構成される。ただし図1では車両5は1台のみ記載しているが更新システムSには複数の車両5が含まれてもよい。車両5は、TCU1と、第1ECU31と、第2ECU32と、第3ECU33と、IGNセンサ39とを備える。
【0010】
以下では、第1ECU31と、第2ECU32と、第3ECU33とを特に区別しない場合にECU30と呼ぶ。車両5は不図示のバッテリーを備え、バッテリーはTCU1、ECU30、およびIGNセンサ39に電力を供給する。この電力の供給は車両5のイグニションスイッチの状態を問わずに行われるので、たとえばイグニッションスイッチがオフにされた後もTCU1、ECU30、およびIGNセンサ39は動作可能である。
【0011】
TCU1は、CPU11と、ROM12と、RAM13と、無線通信装置14と、車内通信装置15と、フラッシュメモリ17とを備える。CPU11は中央演算装置であり、ROM12に格納されるプログラムをRAM13に展開して実行することにより後述する機能を実現する。RAM13は揮発性の記憶装置であり、RAM13にはプログラムの動作に必要な情報も格納される。無線通信装置14は、無線通信モジュールであり、たとえば3Gや4Gの通信規格に対応する。無線通信装置14は、最寄りの基地局を介してインターネットXに接続し、インターネットXを経由してサーバ4と通信する。
【0012】
車内通信装置15は、ECU30や車両5に搭載される不図示の機器と通信する通信モジュールであり、たとえばIEEE802.3やCAN(登録商標)に対応する。ただし車内通信装置15とECU30との間に通信を中継する装置、いわゆるゲートウェイ装置が存在してもよい。フラッシュメモリ17は、後述する情報を記憶する不揮発性の記憶装置である。
【0013】
ECU30は、車両5に内蔵され車両5の動作に関する何らかの演算を行う電子制御装置(Electronic Control Unit)、すなわちECUである。ここではECU30が担う具体的な機能は説明しないが、それぞれのECU30はプログラムを実行することによりそれぞれの機能を実現する。ECU30はプログラム、およびプログラムが使用するデータの少なくとも一方が更新可能である。
【0014】
ECU30は、TCU1から更新用の情報(以下、「更新本体」と呼ぶ)を受信すると、プログラムまたはプログラムが使用するデータを更新する。ただしECU30は、他の演算などの負荷が高く更新が不可能と判断する場合は更新本体を受信しても更新を行わなくてもよいし、更新本体を受信しなくてもよい。またECU30は、TCU1から更新本体の送信可否を問われると、自己の演算負荷などに基づき更新が可能と判断する場合は更新本体の送信を承諾する旨の回答をTCU1に送信する。ECU30は、更新が不可能と判断する場合は送信を拒否する旨の回答をTCU1に送信するか、TCU1に何ら回答を送信しない。なおECU30が車両5の動作中に行う更新は、車両5の機能を発揮した状態で行われる更新なので「バックグラウンド更新」とも呼べる。
【0015】
更新本体は、新たなプログラムそのものでもよいし、従前のプログラムと新たなプログラムの差分情報でもよい。また更新本体はプログラムが使用する新たなデータの全部であってもよいし、プログラムが使用する従前のデータと新たなデータの差分であってもよい。さらに更新本体は、通信量を低減するために圧縮されていてもよいし、情報の安全性の観点から暗号化されていてもよいし、改ざん検出のためにハッシュやMAC(Message Authentication Code)が付加されていてもよい。更新本体が圧縮や暗号化されている場合はTCU1またはECU30が伸長や復号化を行う。更新本体にハッシュやMACが付加されている場合は、TCU1またはECU30がハッシュやMACを検証し、改ざんされていないことが確認された場合に更新を行う。
【0016】
IGNセンサ39は、車両5のイグニションスイッチの状態を検出するセンサである。IGNセンサ39は、ユーザによるイグニッションスイッチの操作、すなわちオン状態またはオフ状態への切り替えを検出してTCU1に伝達する。IGNセンサ39は、TCU1とはTCU1が備える不図示のインタフェースを介して接続されてもよいし、車内通信装置15を介して接続されてもよい。
【0017】
サーバ4は、CPU41と、ROM42と、RAM43と、HDD44と、サーバ通信部45とを備える。CPU41は中央演算装置であり、ROM42に格納されるプログラムをRAM43に展開して実行することにより後述する機能を実現する。HDD44は不揮発性の記憶装置、たとえばハードディスクドライブである。HDD44にはデータベース(以下、「DB」)441が格納される。DB441に格納される情報は、オペレータにより手動で更新される。
【0018】
DB441には、サーバ4に接続されるTCU1のネットワーク上の識別子、そのTCU1に接続される機器のID、およびその機器に対応する更新本体が格納される。TCU1のネットワーク上の識別子とは、たとえばIPアドレスである。サーバ4は、DB441に格納された情報を用いて後述するサーバパケット800を作成し、ネットワークXに送信する。ネットワークXに送信されたサーバパケット800は、宛先であるTCU1において処理される。
【0019】
(機能構成)
図2は、TCU1が備える機能を示す機能ブロック図である。ただし図2にはフラッシュメモリ17に格納される情報も示している。TCU1はその機能として、取得部111と、種別判定部112と、配信部113と、イグニッション受信部114とを備える。またフラッシュメモリ17には、更新本体823、および転送先822が格納される。ただし更新本体823、および転送先822は必ずしも常にフラッシュメモリ17に格納されていなくてもよい。またフラッシュメモリ17には、更新本体823および転送先822の組み合わせが2組以上格納される場合もある。
【0020】
取得部111は、CPU11が実行するプログラムおよび無線通信装置14により実現される。取得部111は、サーバ4からサーバパケット800を受信してRAM13に保存する。
【0021】
種別判定部112は、CPU11が実行するプログラムにより実現される。種別判定部112は、取得部111が受信したサーバパケット800の所定の一部分に着目し、配信部113が直接モードと待機モードのいずれのモードで動作するかを判定する。種別判定部112はたとえば、特定のビットが0か1かでモードを判定してもよいし、所定の値に一致するか否かでモードを判定してもよい。
【0022】
配信部113は、CPU11が実行するプログラムおよび車内通信装置15により実現される。配信部113は、サーバ4から取得した更新本体823を適切なECU30に転送する。ただし配信部113は、種別判定部112が判定する動作モードにより異なる動作をする。種別判定部112が直接モードであると判断する場合は、配信部113はECU30からの応答を待たずに更新本体823を転送する。種別判定部112が待機モードであると判断する場合は、配信部113は転送先のECU30に更新本体823の送信の可否を問い合わせ、送信の承諾が得られると更新本体823を送信する。
【0023】
イグニッション受信部114は、CPU11が実行するプログラムにより実現される。イグニッション受信部114は、IGNセンサ39からの信号を受信する。すなわちイグニッション受信部114は、ユーザにより操作されるイグニッションスイッチの信号を受信する。
【0024】
(パケットの構成)
図3(a)はサーバ4がTCU1に送信するサーバパケット800の構成を示す図であり、図3(b)はTCU1がECU30に送信するTCUパケット900の構成を示す図である。サーバパケット800は、ヘッダ810とペイロード820とから構成される。サーバパケット800のヘッダ810には、宛先811と、送信元812とが含まれる。サーバパケット800のペイロード820には、モード821と、転送先822と、更新本体823とが含まれる。TCUパケット900は、ヘッダ910とペイロード920とから構成される。ヘッダ910には、宛先911が含まれる。ペイロード920には、更新本体823が含まれる。すなわち、ペイロード820に含まれる更新本体823とペイロード920に含まれる更新本体823は同一である。
【0025】
ヘッダ910に含まれる宛先911は、ペイロード820に含まれる転送先822と実質的に同一の情報である。すなわち転送先822が示すいずれかのECUに更新本体823が届けられるように、TCUパケット900の宛先911が適切に設定される。たとえば転送先822と宛先911が同一でもよいし、TCU1がIPアドレスと符号の対応が記載された不図示の対応表を備えて転送先822が符号であり宛先911が前述の符号により特定されるIPアドレスでもよい。
【0026】
(配信部113の受信動作)
図4は、第1の実施の形態における配信部113の受信動作を表すフローチャートである。配信部113は、取得部111がサーバ4からサーバパケット800を受信すると図4に示す動作を行う。配信部113はまず、S510において種別判定部112を用いてサーバパケット800に含まれるモード821の種別を判定する。続くS514では配信部113は、サーバパケット800に含まれる転送先822を特定する。
【0027】
続くS518では配信部113は、S510において判定したモードが直接モードであったか否かを判断する。直接モードであったと判断する場合はS522に進み、直接モードではなかった、すなわち待機モードであったと判断する場合はS526に進む。S522では配信部113は、更新本体823を転送先に送信して図4に示す処理を終了する。詳述するとS522では、S514において特定した転送先を宛先911としてヘッダ910に含み、更新本体823をペイロード920に含むTCUパケット900が作成される。
【0028】
S518において否定判定されると実行されるS526では配信部113は、S514において特定した転送先に更新本体823の送信可否を問い合わせる。続くS530では配信部113は、転送先から承諾が得られたか否かを判断する。承諾を得られたと判断する場合はS522に進み、承諾が得られないと判断する場合はS534に進む。なおS530では、所定時間内に応答が得られない場合も承諾が得られない場合と同様に扱う。S534では配信部113は、イグニッション受信部114がイグニッションスイッチがオフにされる信号を受信したか否かを判断する。配信部113は、受信したと判断するとS538に進み、受信していないと判断するとS526に戻る。
【0029】
S538では配信部113は、格納部115に更新本体823および転送先822をRAM13から読み取ってフラッシュメモリ17に格納させて図4に示す処理を終了する。配信部113は、待機モードと判断した場合に、転送先のECU30から承諾が得られない場合は、S526〜S534の処理を繰り返す。この処理を繰り返している際に、イグニッションスイッチがオフにされるとS534からS538に進んで、更新本体823および転送先822がフラッシュメモリ17に格納される。
【0030】
(配信部113の常時動作)
図5は、第1の実施の形態における配信部113の常時動作を表すフローチャートである。配信部113は、TCU1の電源がオンにされると図5に示す動作を行う。配信部113はまず、S550において配信部113は、フラッシュメモリ17に未送信の更新本体823が格納されているか否かを判断する。なおフラッシュメモリ17に格納される更新本体823は、図4のS538で格納されたものである。配信部113はフラッシュメモリ17に更新本体823が格納されていると判断する場合はS554に進み、フラッシュメモリ17に更新本体823が格納されていないと判断する場合はS564に進む。
【0031】
S554では、配信部113は転送先に更新本体823の送信可否を問い合わせる。続くS558では配信部113は、転送先から承諾が得られたか否かを判断する。承諾を得られたと判断する場合はS560に進み、承諾が得られないと判断する場合はS564に進む。なおS558では、所定時間内に応答が得られない場合も承諾が得られない場合と同様に扱う。S560では配信部113は、更新本体823を転送先に送信する。続くS562では配信部113は、S560において送信した更新本体823およびその更新本体823とともに格納されていた転送先822をフラッシュメモリ17から削除してS564に進む。
【0032】
S564では配信部113は、イグニッション受信部114がイグニッションスイッチがオフにされる信号を受信したか否かを判断する。配信部113は、受信したと判断するとS566に進み、受信していないと判断するとS550に戻る。S566では配信部113はスリープ状態に移行し、図5に示す処理を終了する。
【0033】
上述した第1の実施の形態によれば、次の作用効果が得られる。
(1)TCU1は、車両5に搭載され、車両5に搭載されたECU30に更新本体823を提供する。TCU1は、サーバ4から更新本体823およびモード821を含むサーバパケット800を受信する取得部111と、モード821を判別する種別判定部112と、モード821が直接モードであると判断するとECU30からの応答を待たずにECU30へ更新本体823を送信し、モード821が待機モードであると判断するとECU30へ問い合わせを行い承諾が得られるとECU30に更新本体823を送信する配信部113とを備える。TCU1は、サーバパケット800に含まれるモード821により表される動作モードにより、更新本体823の配信手順を決定する。
【0034】
そのためサーバ4から更新本体823を取得したTCU1について、更新本体823をECU10に送信する際の挙動を変更できる。これにより、更新本体823の種類や内容、更新本体823の転送先であるECU30の特性にあわせて、サーバ4で設定したとおりにTCU1を動作させることができる。直接モードにおいてTCU1が受信した更新本体823を即座にECU30に送信する場合は、TCU1はサーバ4とECU30とを結ぶ単なる通信路、いわば土管として機能している。その一方で、待機モードにおいてTCU1がECU30の承諾を得てから更新本体823をECU30に送信する場合は、更新本体823の蓄積場所、いわばバッファとして機能している。すなわちTCU1は、サーバパケット800に含まれるモード821に基づき、いわゆる土管とバッファの2つの性質を使い分けることができる。
【0035】
(2)TCU1は、不揮発性の記憶領域であるフラッシュメモリ17を備える。配信部113は、更新本体823を送信する前にイグニッションスイッチがオフになったので電源の供給が遮断されると判断すると、更新本体823をフラッシュメモリ17に格納する(図4のS538)。そのため通常は更新本体823をRAM13に格納してアクセスを高速にし、電源の遮断を予測すると更新本体823を不揮発性のフラッシュメモリ17に格納して消失を防ぐことができる。
【0036】
(変形例1)
上述した第1の実施の形態では、TCU1は、それぞれのECU30を同等に扱った。しかしあらかじめ定められたECU30を特別に扱い、サーバパケット800に含まれるモード821にかからわず直接モードまたは待機モードとして動作してもよい。本変形例では、TCU1は動作モードを固定するECU30のリストを有する。このリストには、たとえば第1ECU31は常に待機モード、第2ECU32は常に直接モードである旨書き解されている。
【0037】
図6は変形例1における配信部113の受信動作を表すフローチャートである。配信部113は、取得部111がサーバ4からサーバパケット800を受信すると、まずS514において転送先を特定する。続くS591では配信部113は、S514において特定した転送先が前述のリストに記載されているか否か、換言すると動作モードが固定の転送先であるか否かを判断する。配信部113はS591を肯定判断する場合はS592に進み、否定判断する場合はS510に進む。S592では配信部113は、前述のリストの記載にしたがって動作モードを決定してS518に進む。S510では配信部113は、種別判定部112を用いてサーバパケット800に含まれるモード821の種別を判定してS518に進む。S518以降の処理は第1の実施の形態と同様なので説明を省略する。
【0038】
本変形例によれば、TCU1はECU30の特性に合わせてあらかじめ動作を決定することができる。たとえば車両5の動作に不可欠なECU30は、車両5の走行中に更新を行うことが困難なので、TCU1が常に待機モードとして動作することで、サーバ4のサーバパケット800からモード821を省略できる。
【0039】
(変形例2)
車両5に搭載されるECU30の数は3つに限定されない。車両5はECU30を少なくとも1つ備えればよい。またIGNセンサ39も車内通信装置15を介してTCU1と接続され、ECU30と同様に更新可能であってもよい。
【0040】
―第2の実施の形態―
図7図8を参照して、本発明に係る車載装置の第2の実施の形態を説明する。以下の説明では、第1の実施の形態と同じ構成要素には同じ符号を付して相違点を主に説明する。特に説明しない点については、第1の実施の形態と同じである。本実施の形態では、主に、更新本体823をフラッシュメモリ17に格納するタイミングが第1の実施の形態と異なる。
【0041】
(構成)
第2の実施の形態における更新システムSのハードウエア構成図および機能構成は第1の実施の形態と同様である。ただし以下に説明するように配信部113の動作が第1の実施の形態と異なる。
【0042】
(配信部113の受信動作)
図7は、第2の実施の形態における配信部113の受信動作を表すフローチャートである。第1の実施の形態と同一の処理には同一のステップ番号を付し、説明を省略する。S530までの処理は第1の実施の形態と同様なので説明を省略する。配信部113は、S530において肯定判断をする場合は第1の実施の形態と同様にS522に進むが、否定判断をする場合は第1の実施の形態とは異なりS538に進む。そしてS538では配信部113は、格納部115に更新本体823をRAM13からフラッシュメモリ17に格納させて図7に示す処理を終了する。第1の実施の形態におけるS534に相当する処理、および再度の問い合わせ(S534:NO、S526)は次の配信部113の第2の動作が実行する。
【0043】
(配信部113の定常動作)
図8は、第2の実施の形態における配信部113の定常動作を表すフローチャートである。第2の実施の形態では、配信部113は常時動作は行わず、その代わりに定常動作を行う。配信部113は、一定時間ごと、たとえば100ミリ秒ごとに図8に示す処理を実行する。
【0044】
S550では配信部113は、フラッシュメモリ17に未送信の更新本体823が格納されているか否かを判断する。配信部113はフラッシュメモリ17に更新本体823が格納されていると判断する場合はS552に進み、フラッシュメモリ17に更新本体823が格納されていないと判断する場合はS564に進む。S552では配信部113は、フラッシュメモリ17に格納されている更新本体823の送信可否を前回問い合わせてから所定時間、たとえば300ミリ秒が経過したか否かを判断する。配信部113は所定時間が経過していると判断する場合はS554に進み、所定時間は経過していないと判断する場合はS556に進む。
【0045】
S556では配信部113は、イグニッション受信部114を用いてイグニッションスイッチの状態が変化したか否か、すなわちオンからオフ、またはオフからオンに変化したか否かを判断する。配信部113はイグニッションスイッチの状態が変化したと判断する場合はS554に進み、イグニッションスイッチの状態が変化していないと判断する場合はS564に進む。
【0046】
S552またはS556において肯定判断されると実行されるS554では、配信部113は転送先に更新本体823の送信可否を問い合わせる。続くS558では配信部113は、転送先から承諾が得られたか否かを判断する。承諾を得られたと判断する場合はS560に進み、承諾が得られないと判断する場合はS564に進む。S558では、所定時間内に応答が得られない場合も承諾が得られない場合と同様に扱う。S560では配信部113は、更新本体823を転送先に送信する。続くS562では配信部113は、S560において送信した更新本体823およびその更新本体823とともに格納されていた転送先822をフラッシュメモリ17から削除してS564に進む。
【0047】
S564では配信部113は、イグニッション受信部114がイグニッションスイッチがオフにされる信号を受信したか否かを判断する。配信部113は、受信したと判断するとS566に進み、受信していないと判断すると図8に示す処理を終了する。
【0048】
上述した第2の実施の形態によれば、次の作用効果が得られる。
(3)TCU1は、不揮発性の記憶領域であるフラッシュメモリ17を備える。配信部113は、ECU30から更新本体823を送信する承諾が得られない場合に更新本体823をフラッシュメモリ17に格納する(図7のS530:NO、S538)。TCU1はECU30に送信できない場合は更新本体823を不揮発性のフラッシュメモリ17に格納するので、イグニションスイッチの操作によらない電源の遮断が生じた場合でも、取得した更新本体823の消失を防止できる。
【0049】
(4)TCU1は、ユーザにより操作されるイグニッションスイッチの信号を受信するイグニッション受信部114を備える。配信部113は、イグニッション受信部114がイグニッションスイッチがオフにされる信号を受信すると、ECU30に問い合わせを再送する(図8のS556:YES、S554)。そのためECU30の演算の負荷が低いと推測される車両5の停止時に更新本体823を送信し、ECU30に更新を実行させることができる。
【0050】
上述した各実施の形態および変形例において、TCU1のプログラムはROM12に格納されるとしたが、プログラムはフラッシュメモリ17に格納されていてもよい。また、TCU1が不図示の入出力インタフェースを備え、必要なときに入出力インタフェースとTCU1が利用可能な媒体を介して、他の装置からプログラムが読み込まれてもよい。ここで媒体とは、たとえば入出力インタフェースに着脱可能な記憶媒体、または通信媒体、すなわち有線、無線、光などのネットワーク、または当該ネットワークを伝搬する搬送波やディジタル信号、を指す。また、プログラムにより実現される機能の一部または全部がハードウエア回路やFPGAにより実現されてもよい。
【0051】
上述した各実施の形態および変形例は、それぞれ組み合わせてもよい。上記では、種々の実施の形態および変形例を説明したが、本発明はこれらの内容に限定されるものではない。本発明の技術的思想の範囲内で考えられるその他の態様も本発明の範囲内に含まれる。
【符号の説明】
【0052】
4…サーバ
5…車両
14…無線通信装置
15…車内通信装置
17…フラッシュメモリ
111…取得部
112…種別判定部
113…配信部
114…イグニッション受信部
115…格納部
321…モード
800…サーバパケット
810…ヘッダ
811…宛先
812…送信元
820…ペイロード
821…モード
822…転送先
823…更新本体
図1
図2
図3
図4
図5
図6
図7
図8