(57)【要約】【課題】サーバから情報を取得した機器がその情報を他の機器に送信する際の挙動を変更できる。【解決手段】車載装置は、車両に搭載され、車両に搭載された他の機器に他の機器に格納されている情報を更新させる更新本体を提供する車載装置において、サーバから更新本体およびモードを含む更新情報を受信する外部通信部と、モードを判別する種別判定部と、モードが第１のモードであると判断すると他の装置からの応答を待たずに他の装置へ更新本体を送信し、モードが第２のモードであると判断すると他の装置へ問い合わせを行い承諾が得られると他の装置に更新本体を送信する車内通信部とを備える。【選択図】図２
2019177745.tif 000002
【特許請求の範囲】
【請求項１】
車両に搭載され、前記車両に搭載された他の機器に前記他の機器に格納されている情報を更新させる更新本体を提供する車載装置において、
サーバから前記更新本体およびモードを含む更新情報を受信する取得部と、
前記モードを判別する種別判定部と、
前記モードが第１のモードであると判断すると前記他の装置からの応答を待たずに前記他の装置へ前記更新本体を送信し、前記モードが第２のモードであると判断すると前記他の装置へ問い合わせを行い承諾が得られると前記他の装置に前記更新本体を送信する配信部とを備える車載装置。
【請求項２】
請求項１に記載の車載装置において、
不揮発性の記憶領域である記憶部と、
前記更新本体を送信する前に電源の供給が遮断されると判断すると前記更新本体を前記記憶部に格納する格納部と、をさらに備える車載装置。
【請求項３】
請求項１に記載の車載装置において、
ユーザにより操作されるイグニッションスイッチの信号を受信する受信部をさらに備え、
前記配信部は、前記受信部がイグニッションスイッチがオフにされる信号を受信すると、前記他の装置に前記問い合わせを再送する車載装置。
【請求項４】
請求項１に記載の車載装置において、
不揮発性の記憶領域である記憶部をさらに備え、
前記配信部は、前記他の装置から前記更新本体を送信する承諾が得られない場合に前記更新本体を前記記憶部に格納する車載装置。
【請求項５】
車両に搭載され、前記車両に搭載された他の機器に前記他の機器に格納されている情報を更新させる更新本体を提供する車載装置が実行する配信方法であって、
サーバから前記更新本体およびモードを含む更新情報を受信することと、
前記モードを判別することと、
前記モードが第１のモードであると判断すると前記他の装置からの応答を待たずに前記他の装置へ前記更新本体を送信し、前記モードが第２のモードであると判断すると前記他の装置へ問い合わせを行い承諾が得られると前記他の装置に前記更新本体を送信することとを含む配信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車載装置、および配信方法に関する。
【背景技術】
【０００２】
車両には多数の電子機器が搭載され、電子機器に内蔵される情報は必要に応じて更新される。従来は車両をディーラー等へ持ち込み、作業員が電子機器の情報を更新することが多かった。利便性の向上のために、無線通信を利用してインターネット上のサーバから情報を取得して更新することが望まれている。ただし全ての電子機器が個別にインターネットに接続する機能を有する構成はコスト面から現実的ではないため、サーバと通信する機器を設けてその機器を介してサーバから情報を取得する構成が知られている。
特許文献１には、車両に備わる車載コンピュータシステムにおいて、データ配信装置の公開鍵証明書である第１の公開鍵証明書を記憶する第１の車載コンピュータと、第２の車載コンピュータと、前記第１の公開鍵証明書の生成に使用される第２の秘密鍵に対応する第２の公開鍵証明書を記憶する第１のセキュアエレメントと、を備え、前記第１の車載コンピュータと前記第２の車載コンピュータとが前記車両に備わる通信ネットワークに接続され、前記第１のセキュアエレメントは、前記第２の公開鍵証明書を使用して前記第１の公開鍵証明書を検証し、前記第１の車載コンピュータは、前記データ配信装置から受信された第１のデータに付されている第１の電子署名を、前記第１のセキュアエレメントによって検証が合格した前記第１の公開鍵証明書を使用して検証する暗号処理部を備え、前記第１の車載コンピュータまたは前記第２の車載コンピュータに対して、前記暗号処理部によって検証が合格した前記第１の電子署名が付されていた前記第１のデータを適用する、車載コンピュータシステムが開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１７−１２０９８４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１に記載されている発明では、サーバから情報を取得した機器について、その情報を他の機器に送信する際の挙動を変更できない。
【課題を解決するための手段】
【０００５】
本発明の第１の態様による車載装置は、車両に搭載され、前記車両に搭載された他の機器に前記他の機器に格納されている情報を更新させる更新本体を提供する車載装置において、サーバから前記更新本体およびモードを含む更新情報を受信する取得部と、前記モードを判別する種別判定部と、前記モードが第１のモードであると判断すると前記他の装置からの応答を待たずに前記他の装置へ前記更新本体を送信し、前記モードが第２のモードであると判断すると前記他の装置へ問い合わせを行い承諾が得られると前記他の装置に前記更新本体を送信する配信部とを備える。
本発明の第２の態様による配信方法は、車両に搭載され、前記車両に搭載された他の機器に前記他の機器に格納されている情報を更新させる更新本体を提供する車載装置が実行する配信方法であって、サーバから前記更新本体およびモードを含む更新情報を受信することと、前記モードを判別することと、前記モードが第１のモードであると判断すると前記他の装置からの応答を待たずに前記他の装置へ前記更新本体を送信し、前記モードが第２のモードであると判断すると前記他の装置へ問い合わせを行い承諾が得られると前記他の装置に前記更新本体を送信することとを含む。
【発明の効果】
【０００６】
本発明によれば、サーバから情報を取得した機器がその情報を他の機器に送信する際の挙動を変更できる。
【図面の簡単な説明】
【０００７】
【図１】更新システムＳのハードウエア構成図
【図２】ＴＣＵ１が備える機能を示す機能ブロック図
【図３】図３（ａ）はサーバ４がＴＣＵ１に送信するサーバパケット８００の構成を示す図、図３（ｂ）はＴＣＵ１がＥＣＵ３０に送信するＴＣＵパケット９００の構成を示す図
【図４】第１の実施の形態における配信部１１３の受信動作を表すフローチャート
【図５】第１の実施の形態における配信部１１３の常時動作を表すフローチャート
【図６】変形例１における配信部１１３の受信動作を表すフローチャート
【図７】第２の実施の形態における配信部１１３の受信動作を表すフローチャート
【図８】第２の実施の形態における配信部１１３の定常動作を表すフローチャート
【発明を実施するための形態】
【０００８】
―第１の実施の形態―
以下、図１〜図４を参照して、本発明に係る車載装置の第１の実施の形態を説明する。
【０００９】
（ハードウエア構成）
図１は更新システムＳのハードウエア構成図である。更新システムＳは、車両５とサーバ４とから構成される。ただし図１では車両５は１台のみ記載しているが更新システムＳには複数の車両５が含まれてもよい。車両５は、ＴＣＵ１と、第１ＥＣＵ３１と、第２ＥＣＵ３２と、第３ＥＣＵ３３と、ＩＧＮセンサ３９とを備える。
【００１０】
以下では、第１ＥＣＵ３１と、第２ＥＣＵ３２と、第３ＥＣＵ３３とを特に区別しない場合にＥＣＵ３０と呼ぶ。車両５は不図示のバッテリーを備え、バッテリーはＴＣＵ１、ＥＣＵ３０、およびＩＧＮセンサ３９に電力を供給する。この電力の供給は車両５のイグニションスイッチの状態を問わずに行われるので、たとえばイグニッションスイッチがオフにされた後もＴＣＵ１、ＥＣＵ３０、およびＩＧＮセンサ３９は動作可能である。
【００１１】
ＴＣＵ１は、ＣＰＵ１１と、ＲＯＭ１２と、ＲＡＭ１３と、無線通信装置１４と、車内通信装置１５と、フラッシュメモリ１７とを備える。ＣＰＵ１１は中央演算装置であり、ＲＯＭ１２に格納されるプログラムをＲＡＭ１３に展開して実行することにより後述する機能を実現する。ＲＡＭ１３は揮発性の記憶装置であり、ＲＡＭ１３にはプログラムの動作に必要な情報も格納される。無線通信装置１４は、無線通信モジュールであり、たとえば３Ｇや４Ｇの通信規格に対応する。無線通信装置１４は、最寄りの基地局を介してインターネットＸに接続し、インターネットＸを経由してサーバ４と通信する。
【００１２】
車内通信装置１５は、ＥＣＵ３０や車両５に搭載される不図示の機器と通信する通信モジュールであり、たとえばＩＥＥＥ８０２．３やＣＡＮ（登録商標）に対応する。ただし車内通信装置１５とＥＣＵ３０との間に通信を中継する装置、いわゆるゲートウェイ装置が存在してもよい。フラッシュメモリ１７は、後述する情報を記憶する不揮発性の記憶装置である。
【００１３】
ＥＣＵ３０は、車両５に内蔵され車両５の動作に関する何らかの演算を行う電子制御装置（Electronic Control Unit）、すなわちＥＣＵである。ここではＥＣＵ３０が担う具体的な機能は説明しないが、それぞれのＥＣＵ３０はプログラムを実行することによりそれぞれの機能を実現する。ＥＣＵ３０はプログラム、およびプログラムが使用するデータの少なくとも一方が更新可能である。
【００１４】
ＥＣＵ３０は、ＴＣＵ１から更新用の情報（以下、「更新本体」と呼ぶ）を受信すると、プログラムまたはプログラムが使用するデータを更新する。ただしＥＣＵ３０は、他の演算などの負荷が高く更新が不可能と判断する場合は更新本体を受信しても更新を行わなくてもよいし、更新本体を受信しなくてもよい。またＥＣＵ３０は、ＴＣＵ１から更新本体の送信可否を問われると、自己の演算負荷などに基づき更新が可能と判断する場合は更新本体の送信を承諾する旨の回答をＴＣＵ１に送信する。ＥＣＵ３０は、更新が不可能と判断する場合は送信を拒否する旨の回答をＴＣＵ１に送信するか、ＴＣＵ１に何ら回答を送信しない。なおＥＣＵ３０が車両５の動作中に行う更新は、車両５の機能を発揮した状態で行われる更新なので「バックグラウンド更新」とも呼べる。
【００１５】
更新本体は、新たなプログラムそのものでもよいし、従前のプログラムと新たなプログラムの差分情報でもよい。また更新本体はプログラムが使用する新たなデータの全部であってもよいし、プログラムが使用する従前のデータと新たなデータの差分であってもよい。さらに更新本体は、通信量を低減するために圧縮されていてもよいし、情報の安全性の観点から暗号化されていてもよいし、改ざん検出のためにハッシュやＭＡＣ（Message Authentication Code）が付加されていてもよい。更新本体が圧縮や暗号化されている場合はＴＣＵ１またはＥＣＵ３０が伸長や復号化を行う。更新本体にハッシュやＭＡＣが付加されている場合は、ＴＣＵ１またはＥＣＵ３０がハッシュやＭＡＣを検証し、改ざんされていないことが確認された場合に更新を行う。
【００１６】
ＩＧＮセンサ３９は、車両５のイグニションスイッチの状態を検出するセンサである。ＩＧＮセンサ３９は、ユーザによるイグニッションスイッチの操作、すなわちオン状態またはオフ状態への切り替えを検出してＴＣＵ１に伝達する。ＩＧＮセンサ３９は、ＴＣＵ１とはＴＣＵ１が備える不図示のインタフェースを介して接続されてもよいし、車内通信装置１５を介して接続されてもよい。
【００１７】
サーバ４は、ＣＰＵ４１と、ＲＯＭ４２と、ＲＡＭ４３と、ＨＤＤ４４と、サーバ通信部４５とを備える。ＣＰＵ４１は中央演算装置であり、ＲＯＭ４２に格納されるプログラムをＲＡＭ４３に展開して実行することにより後述する機能を実現する。ＨＤＤ４４は不揮発性の記憶装置、たとえばハードディスクドライブである。ＨＤＤ４４にはデータベース（以下、「ＤＢ」）４４１が格納される。ＤＢ４４１に格納される情報は、オペレータにより手動で更新される。
【００１８】
ＤＢ４４１には、サーバ４に接続されるＴＣＵ１のネットワーク上の識別子、そのＴＣＵ１に接続される機器のＩＤ、およびその機器に対応する更新本体が格納される。ＴＣＵ１のネットワーク上の識別子とは、たとえばＩＰアドレスである。サーバ４は、ＤＢ４４１に格納された情報を用いて後述するサーバパケット８００を作成し、ネットワークＸに送信する。ネットワークＸに送信されたサーバパケット８００は、宛先であるＴＣＵ１において処理される。
【００１９】
（機能構成）
図２は、ＴＣＵ１が備える機能を示す機能ブロック図である。ただし図２にはフラッシュメモリ１７に格納される情報も示している。ＴＣＵ１はその機能として、取得部１１１と、種別判定部１１２と、配信部１１３と、イグニッション受信部１１４とを備える。またフラッシュメモリ１７には、更新本体８２３、および転送先８２２が格納される。ただし更新本体８２３、および転送先８２２は必ずしも常にフラッシュメモリ１７に格納されていなくてもよい。またフラッシュメモリ１７には、更新本体８２３および転送先８２２の組み合わせが２組以上格納される場合もある。
【００２０】
取得部１１１は、ＣＰＵ１１が実行するプログラムおよび無線通信装置１４により実現される。取得部１１１は、サーバ４からサーバパケット８００を受信してＲＡＭ１３に保存する。
【００２１】
種別判定部１１２は、ＣＰＵ１１が実行するプログラムにより実現される。種別判定部１１２は、取得部１１１が受信したサーバパケット８００の所定の一部分に着目し、配信部１１３が直接モードと待機モードのいずれのモードで動作するかを判定する。種別判定部１１２はたとえば、特定のビットが０か１かでモードを判定してもよいし、所定の値に一致するか否かでモードを判定してもよい。
【００２２】
配信部１１３は、ＣＰＵ１１が実行するプログラムおよび車内通信装置１５により実現される。配信部１１３は、サーバ４から取得した更新本体８２３を適切なＥＣＵ３０に転送する。ただし配信部１１３は、種別判定部１１２が判定する動作モードにより異なる動作をする。種別判定部１１２が直接モードであると判断する場合は、配信部１１３はＥＣＵ３０からの応答を待たずに更新本体８２３を転送する。種別判定部１１２が待機モードであると判断する場合は、配信部１１３は転送先のＥＣＵ３０に更新本体８２３の送信の可否を問い合わせ、送信の承諾が得られると更新本体８２３を送信する。
【００２３】
イグニッション受信部１１４は、ＣＰＵ１１が実行するプログラムにより実現される。イグニッション受信部１１４は、ＩＧＮセンサ３９からの信号を受信する。すなわちイグニッション受信部１１４は、ユーザにより操作されるイグニッションスイッチの信号を受信する。
【００２４】
（パケットの構成）
図３（ａ）はサーバ４がＴＣＵ１に送信するサーバパケット８００の構成を示す図であり、図３（ｂ）はＴＣＵ１がＥＣＵ３０に送信するＴＣＵパケット９００の構成を示す図である。サーバパケット８００は、ヘッダ８１０とペイロード８２０とから構成される。サーバパケット８００のヘッダ８１０には、宛先８１１と、送信元８１２とが含まれる。サーバパケット８００のペイロード８２０には、モード８２１と、転送先８２２と、更新本体８２３とが含まれる。ＴＣＵパケット９００は、ヘッダ９１０とペイロード９２０とから構成される。ヘッダ９１０には、宛先９１１が含まれる。ペイロード９２０には、更新本体８２３が含まれる。すなわち、ペイロード８２０に含まれる更新本体８２３とペイロード９２０に含まれる更新本体８２３は同一である。
【００２５】
ヘッダ９１０に含まれる宛先９１１は、ペイロード８２０に含まれる転送先８２２と実質的に同一の情報である。すなわち転送先８２２が示すいずれかのＥＣＵに更新本体８２３が届けられるように、ＴＣＵパケット９００の宛先９１１が適切に設定される。たとえば転送先８２２と宛先９１１が同一でもよいし、ＴＣＵ１がＩＰアドレスと符号の対応が記載された不図示の対応表を備えて転送先８２２が符号であり宛先９１１が前述の符号により特定されるＩＰアドレスでもよい。
【００２６】
（配信部１１３の受信動作）
図４は、第１の実施の形態における配信部１１３の受信動作を表すフローチャートである。配信部１１３は、取得部１１１がサーバ４からサーバパケット８００を受信すると図４に示す動作を行う。配信部１１３はまず、Ｓ５１０において種別判定部１１２を用いてサーバパケット８００に含まれるモード８２１の種別を判定する。続くＳ５１４では配信部１１３は、サーバパケット８００に含まれる転送先８２２を特定する。
【００２７】
続くＳ５１８では配信部１１３は、Ｓ５１０において判定したモードが直接モードであったか否かを判断する。直接モードであったと判断する場合はＳ５２２に進み、直接モードではなかった、すなわち待機モードであったと判断する場合はＳ５２６に進む。Ｓ５２２では配信部１１３は、更新本体８２３を転送先に送信して図４に示す処理を終了する。詳述するとＳ５２２では、Ｓ５１４において特定した転送先を宛先９１１としてヘッダ９１０に含み、更新本体８２３をペイロード９２０に含むＴＣＵパケット９００が作成される。
【００２８】
Ｓ５１８において否定判定されると実行されるＳ５２６では配信部１１３は、Ｓ５１４において特定した転送先に更新本体８２３の送信可否を問い合わせる。続くＳ５３０では配信部１１３は、転送先から承諾が得られたか否かを判断する。承諾を得られたと判断する場合はＳ５２２に進み、承諾が得られないと判断する場合はＳ５３４に進む。なおＳ５３０では、所定時間内に応答が得られない場合も承諾が得られない場合と同様に扱う。Ｓ５３４では配信部１１３は、イグニッション受信部１１４がイグニッションスイッチがオフにされる信号を受信したか否かを判断する。配信部１１３は、受信したと判断するとＳ５３８に進み、受信していないと判断するとＳ５２６に戻る。
【００２９】
Ｓ５３８では配信部１１３は、格納部１１５に更新本体８２３および転送先８２２をＲＡＭ１３から読み取ってフラッシュメモリ１７に格納させて図４に示す処理を終了する。配信部１１３は、待機モードと判断した場合に、転送先のＥＣＵ３０から承諾が得られない場合は、Ｓ５２６〜Ｓ５３４の処理を繰り返す。この処理を繰り返している際に、イグニッションスイッチがオフにされるとＳ５３４からＳ５３８に進んで、更新本体８２３および転送先８２２がフラッシュメモリ１７に格納される。
【００３０】
（配信部１１３の常時動作）
図５は、第１の実施の形態における配信部１１３の常時動作を表すフローチャートである。配信部１１３は、ＴＣＵ１の電源がオンにされると図５に示す動作を行う。配信部１１３はまず、Ｓ５５０において配信部１１３は、フラッシュメモリ１７に未送信の更新本体８２３が格納されているか否かを判断する。なおフラッシュメモリ１７に格納される更新本体８２３は、図４のＳ５３８で格納されたものである。配信部１１３はフラッシュメモリ１７に更新本体８２３が格納されていると判断する場合はＳ５５４に進み、フラッシュメモリ１７に更新本体８２３が格納されていないと判断する場合はＳ５６４に進む。
【００３１】
Ｓ５５４では、配信部１１３は転送先に更新本体８２３の送信可否を問い合わせる。続くＳ５５８では配信部１１３は、転送先から承諾が得られたか否かを判断する。承諾を得られたと判断する場合はＳ５６０に進み、承諾が得られないと判断する場合はＳ５６４に進む。なおＳ５５８では、所定時間内に応答が得られない場合も承諾が得られない場合と同様に扱う。Ｓ５６０では配信部１１３は、更新本体８２３を転送先に送信する。続くＳ５６２では配信部１１３は、Ｓ５６０において送信した更新本体８２３およびその更新本体８２３とともに格納されていた転送先８２２をフラッシュメモリ１７から削除してＳ５６４に進む。
【００３２】
Ｓ５６４では配信部１１３は、イグニッション受信部１１４がイグニッションスイッチがオフにされる信号を受信したか否かを判断する。配信部１１３は、受信したと判断するとＳ５６６に進み、受信していないと判断するとＳ５５０に戻る。Ｓ５６６では配信部１１３はスリープ状態に移行し、図５に示す処理を終了する。
【００３３】
上述した第１の実施の形態によれば、次の作用効果が得られる。
（１）ＴＣＵ１は、車両５に搭載され、車両５に搭載されたＥＣＵ３０に更新本体８２３を提供する。ＴＣＵ１は、サーバ４から更新本体８２３およびモード８２１を含むサーバパケット８００を受信する取得部１１１と、モード８２１を判別する種別判定部１１２と、モード８２１が直接モードであると判断するとＥＣＵ３０からの応答を待たずにＥＣＵ３０へ更新本体８２３を送信し、モード８２１が待機モードであると判断するとＥＣＵ３０へ問い合わせを行い承諾が得られるとＥＣＵ３０に更新本体８２３を送信する配信部１１３とを備える。ＴＣＵ１は、サーバパケット８００に含まれるモード８２１により表される動作モードにより、更新本体８２３の配信手順を決定する。
【００３４】
そのためサーバ４から更新本体８２３を取得したＴＣＵ１について、更新本体８２３をＥＣＵ１０に送信する際の挙動を変更できる。これにより、更新本体８２３の種類や内容、更新本体８２３の転送先であるＥＣＵ３０の特性にあわせて、サーバ４で設定したとおりにＴＣＵ１を動作させることができる。直接モードにおいてＴＣＵ１が受信した更新本体８２３を即座にＥＣＵ３０に送信する場合は、ＴＣＵ１はサーバ４とＥＣＵ３０とを結ぶ単なる通信路、いわば土管として機能している。その一方で、待機モードにおいてＴＣＵ１がＥＣＵ３０の承諾を得てから更新本体８２３をＥＣＵ３０に送信する場合は、更新本体８２３の蓄積場所、いわばバッファとして機能している。すなわちＴＣＵ１は、サーバパケット８００に含まれるモード８２１に基づき、いわゆる土管とバッファの２つの性質を使い分けることができる。
【００３５】
（２）ＴＣＵ１は、不揮発性の記憶領域であるフラッシュメモリ１７を備える。配信部１１３は、更新本体８２３を送信する前にイグニッションスイッチがオフになったので電源の供給が遮断されると判断すると、更新本体８２３をフラッシュメモリ１７に格納する（図４のＳ５３８）。そのため通常は更新本体８２３をＲＡＭ１３に格納してアクセスを高速にし、電源の遮断を予測すると更新本体８２３を不揮発性のフラッシュメモリ１７に格納して消失を防ぐことができる。
【００３６】
（変形例１）
上述した第１の実施の形態では、ＴＣＵ１は、それぞれのＥＣＵ３０を同等に扱った。しかしあらかじめ定められたＥＣＵ３０を特別に扱い、サーバパケット８００に含まれるモード８２１にかからわず直接モードまたは待機モードとして動作してもよい。本変形例では、ＴＣＵ１は動作モードを固定するＥＣＵ３０のリストを有する。このリストには、たとえば第１ＥＣＵ３１は常に待機モード、第２ＥＣＵ３２は常に直接モードである旨書き解されている。
【００３７】
図６は変形例１における配信部１１３の受信動作を表すフローチャートである。配信部１１３は、取得部１１１がサーバ４からサーバパケット８００を受信すると、まずＳ５１４において転送先を特定する。続くＳ５９１では配信部１１３は、Ｓ５１４において特定した転送先が前述のリストに記載されているか否か、換言すると動作モードが固定の転送先であるか否かを判断する。配信部１１３はＳ５９１を肯定判断する場合はＳ５９２に進み、否定判断する場合はＳ５１０に進む。Ｓ５９２では配信部１１３は、前述のリストの記載にしたがって動作モードを決定してＳ５１８に進む。Ｓ５１０では配信部１１３は、種別判定部１１２を用いてサーバパケット８００に含まれるモード８２１の種別を判定してＳ５１８に進む。Ｓ５１８以降の処理は第１の実施の形態と同様なので説明を省略する。
【００３８】
本変形例によれば、ＴＣＵ１はＥＣＵ３０の特性に合わせてあらかじめ動作を決定することができる。たとえば車両５の動作に不可欠なＥＣＵ３０は、車両５の走行中に更新を行うことが困難なので、ＴＣＵ１が常に待機モードとして動作することで、サーバ４のサーバパケット８００からモード８２１を省略できる。
【００３９】
（変形例２）
車両５に搭載されるＥＣＵ３０の数は３つに限定されない。車両５はＥＣＵ３０を少なくとも１つ備えればよい。またＩＧＮセンサ３９も車内通信装置１５を介してＴＣＵ１と接続され、ＥＣＵ３０と同様に更新可能であってもよい。
【００４０】
―第２の実施の形態―
図７〜図８を参照して、本発明に係る車載装置の第２の実施の形態を説明する。以下の説明では、第１の実施の形態と同じ構成要素には同じ符号を付して相違点を主に説明する。特に説明しない点については、第１の実施の形態と同じである。本実施の形態では、主に、更新本体８２３をフラッシュメモリ１７に格納するタイミングが第１の実施の形態と異なる。
【００４１】
（構成）
第２の実施の形態における更新システムＳのハードウエア構成図および機能構成は第１の実施の形態と同様である。ただし以下に説明するように配信部１１３の動作が第１の実施の形態と異なる。
【００４２】
（配信部１１３の受信動作）
図７は、第２の実施の形態における配信部１１３の受信動作を表すフローチャートである。第１の実施の形態と同一の処理には同一のステップ番号を付し、説明を省略する。Ｓ５３０までの処理は第１の実施の形態と同様なので説明を省略する。配信部１１３は、Ｓ５３０において肯定判断をする場合は第１の実施の形態と同様にＳ５２２に進むが、否定判断をする場合は第１の実施の形態とは異なりＳ５３８に進む。そしてＳ５３８では配信部１１３は、格納部１１５に更新本体８２３をＲＡＭ１３からフラッシュメモリ１７に格納させて図７に示す処理を終了する。第１の実施の形態におけるＳ５３４に相当する処理、および再度の問い合わせ（Ｓ５３４：ＮＯ、Ｓ５２６）は次の配信部１１３の第２の動作が実行する。
【００４３】
（配信部１１３の定常動作）
図８は、第２の実施の形態における配信部１１３の定常動作を表すフローチャートである。第２の実施の形態では、配信部１１３は常時動作は行わず、その代わりに定常動作を行う。配信部１１３は、一定時間ごと、たとえば１００ミリ秒ごとに図８に示す処理を実行する。
【００４４】
Ｓ５５０では配信部１１３は、フラッシュメモリ１７に未送信の更新本体８２３が格納されているか否かを判断する。配信部１１３はフラッシュメモリ１７に更新本体８２３が格納されていると判断する場合はＳ５５２に進み、フラッシュメモリ１７に更新本体８２３が格納されていないと判断する場合はＳ５６４に進む。Ｓ５５２では配信部１１３は、フラッシュメモリ１７に格納されている更新本体８２３の送信可否を前回問い合わせてから所定時間、たとえば３００ミリ秒が経過したか否かを判断する。配信部１１３は所定時間が経過していると判断する場合はＳ５５４に進み、所定時間は経過していないと判断する場合はＳ５５６に進む。
【００４５】
Ｓ５５６では配信部１１３は、イグニッション受信部１１４を用いてイグニッションスイッチの状態が変化したか否か、すなわちオンからオフ、またはオフからオンに変化したか否かを判断する。配信部１１３はイグニッションスイッチの状態が変化したと判断する場合はＳ５５４に進み、イグニッションスイッチの状態が変化していないと判断する場合はＳ５６４に進む。
【００４６】
Ｓ５５２またはＳ５５６において肯定判断されると実行されるＳ５５４では、配信部１１３は転送先に更新本体８２３の送信可否を問い合わせる。続くＳ５５８では配信部１１３は、転送先から承諾が得られたか否かを判断する。承諾を得られたと判断する場合はＳ５６０に進み、承諾が得られないと判断する場合はＳ５６４に進む。Ｓ５５８では、所定時間内に応答が得られない場合も承諾が得られない場合と同様に扱う。Ｓ５６０では配信部１１３は、更新本体８２３を転送先に送信する。続くＳ５６２では配信部１１３は、Ｓ５６０において送信した更新本体８２３およびその更新本体８２３とともに格納されていた転送先８２２をフラッシュメモリ１７から削除してＳ５６４に進む。
【００４７】
Ｓ５６４では配信部１１３は、イグニッション受信部１１４がイグニッションスイッチがオフにされる信号を受信したか否かを判断する。配信部１１３は、受信したと判断するとＳ５６６に進み、受信していないと判断すると図８に示す処理を終了する。
【００４８】
上述した第２の実施の形態によれば、次の作用効果が得られる。
（３）ＴＣＵ１は、不揮発性の記憶領域であるフラッシュメモリ１７を備える。配信部１１３は、ＥＣＵ３０から更新本体８２３を送信する承諾が得られない場合に更新本体８２３をフラッシュメモリ１７に格納する（図７のＳ５３０：ＮＯ、Ｓ５３８）。ＴＣＵ１はＥＣＵ３０に送信できない場合は更新本体８２３を不揮発性のフラッシュメモリ１７に格納するので、イグニションスイッチの操作によらない電源の遮断が生じた場合でも、取得した更新本体８２３の消失を防止できる。
【００４９】
（４）ＴＣＵ１は、ユーザにより操作されるイグニッションスイッチの信号を受信するイグニッション受信部１１４を備える。配信部１１３は、イグニッション受信部１１４がイグニッションスイッチがオフにされる信号を受信すると、ＥＣＵ３０に問い合わせを再送する（図８のＳ５５６：ＹＥＳ、Ｓ５５４）。そのためＥＣＵ３０の演算の負荷が低いと推測される車両５の停止時に更新本体８２３を送信し、ＥＣＵ３０に更新を実行させることができる。
【００５０】
上述した各実施の形態および変形例において、ＴＣＵ１のプログラムはＲＯＭ１２に格納されるとしたが、プログラムはフラッシュメモリ１７に格納されていてもよい。また、ＴＣＵ１が不図示の入出力インタフェースを備え、必要なときに入出力インタフェースとＴＣＵ１が利用可能な媒体を介して、他の装置からプログラムが読み込まれてもよい。ここで媒体とは、たとえば入出力インタフェースに着脱可能な記憶媒体、または通信媒体、すなわち有線、無線、光などのネットワーク、または当該ネットワークを伝搬する搬送波やディジタル信号、を指す。また、プログラムにより実現される機能の一部または全部がハードウエア回路やＦＰＧＡにより実現されてもよい。
【００５１】
上述した各実施の形態および変形例は、それぞれ組み合わせてもよい。上記では、種々の実施の形態および変形例を説明したが、本発明はこれらの内容に限定されるものではない。本発明の技術的思想の範囲内で考えられるその他の態様も本発明の範囲内に含まれる。
【符号の説明】
【００５２】
４…サーバ
５…車両
１４…無線通信装置
１５…車内通信装置
１７…フラッシュメモリ
１１１…取得部
１１２…種別判定部
１１３…配信部
１１４…イグニッション受信部
１１５…格納部
３２１…モード
８００…サーバパケット
８１０…ヘッダ
８１１…宛先
８１２…送信元
８２０…ペイロード
８２１…モード
８２２…転送先
８２３…更新本体
【図１】
2019177745.tif 000003
【図２】
2019177745.tif 000004
【図３】
2019177745.tif 000005
【図４】
2019177745.tif 000006
【図５】
2019177745.tif 000007
【図６】
2019177745.tif 000008
【図７】
2019177745.tif 000009
【図８】
2019177745.tif 000010