(57)【要約】【課題】車両の状態や通信状況を考慮したダウンロードを実行できる。【解決手段】車載装置は、車両に搭載される車載装置であって、複数のファイルのリストである更新リストを取得するリスト取得部と、無線通信によりファイルを取得する無線通信部と、車両の状態を検出する車両状態検出部と、無線通信の状況を検出する無線状況検出部と、車両の状態および無線通信の状態の少なくとも一方に基づき、複数のファイルを取得することの可否および取得する順番を決定するファイル取得制御部とを備える。【選択図】図２
2019179331.tif 000002
【特許請求の範囲】
【請求項１】
車両に搭載される車載装置であって、
複数のファイルのリストである更新リストを取得するリスト取得部と、
無線通信により前記ファイルを取得する無線通信部と、
前記車両の状態を検出する車両状態検出部と、
前記無線通信の状況を検出する無線状況検出部と、
前記車両の状態および前記無線通信の状態の少なくとも一方に基づき、前記複数のファイルを取得することの可否および取得する順番を決定するファイル取得制御部とを備える車載装置。
【請求項２】
請求項１に記載の車載装置において、
前記ファイル取得制御部は、前記無線通信の状況が通信可能な状態と通信不可能な状態が所定の時間に所定の回数切り替わると、前記複数のファイルを取得しないと決定する車載装置。
【請求項３】
請求項１または請求項２に記載の車載装置において、
前記更新リストには前記ファイルごとに、優先度およびダウンロードの条件が記載されており、
前記ファイル取得制御部は、前記ダウンロードの条件を満たすファイルのうち、前記優先度が高いファイルからダウンロードを行う車載装置。
【請求項４】
請求項３に記載の車載装置において、
前記ファイル取得制御部は、前記ファイルごとの前記優先度に基づき、優先してダウンロードする前記ファイルほど分割数を減らす車載装置。
【請求項５】
請求項３または請求項４に記載の車載装置において、
前記ファイル取得制御部は、前記ファイルごとの前記優先度に基づき、優先してダウンロードする前記ファイルほどレジュームを行わない車載装置。
【請求項６】
請求項１から請求項３までのいずれか一項に記載の車載装置において、
前記更新リストにはファイルごとのレジュームの可否が記載されており、
前記ファイル取得制御部は、前記ファイルのダウンロード中にダウンロードを行っているファイルのダウンロードの条件を満たさなくなると、前記更新リストに記載されたレジュームの可否にあわせてダウンロード途中のデータの廃棄可否を判断する車載装置。
【請求項７】
請求項１から請求項６までのいずれか一項に記載の車載装置において、
前記ファイル取得制御部は、前記無線通信の状況が通信不可能な状態であると、前記複数のファイルを取得しないと決定する車載装置。
【請求項８】
車両に搭載される装置が実行するファイル取得方法であって、
複数のファイルのリストである更新リストを取得することと、
前記複数のファイルを有するサーバと無線通信することと、
前記車両の状態を検出することと、
前記無線通信の状況を検出することと、
前記車両の状態および前記無線通信の状態の少なくとも一方に基づき、前記サーバから前記複数のファイルを取得することの可否および取得する順番を決定することとを含むファイル取得方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車載装置、およびファイル取得方法に関する。
【背景技術】
【０００２】
車両に搭載される機器には多数のソフトウエアが搭載される。ソフトウエアに不具合が発見されるとディーラー等に車両を預けてソフトウエアのアップデートが行われた。しかし利便性の向上から無線通信を利用した直接の更新、すなわちＯＴＡ（Over The Air）による更新が望まれている。特許文献１には、複数の車載装置間でデータの通信を行う車載ネットワーク装置において、自車両の状態を取得する状態取得部と、前記データを監視する通信監視部と、を有し、前記自車両の状態に基づいて、前記データの監視方法を変えることを特徴とする車載ネットワーク装置が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１７−０４７８３５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１に記載されている発明では、車両の状態や通信状況を考慮したダウンロードを実行できない。
【課題を解決するための手段】
【０００５】
本発明の第１の態様による車載装置は、車両に搭載される車載装置であって、複数のファイルのリストである更新リストを取得するリスト取得部と、無線通信により前記ファイルを取得する無線通信部と、前記車両の状態を検出する車両状態検出部と、前記無線通信の状況を検出する無線状況検出部と、前記車両の状態および前記無線通信の状態の少なくとも一方に基づき、前記複数のファイルを取得することの可否および取得する順番を決定するファイル取得制御部とを備える。
本発明の第２の態様によるファイル取得方法は、複数のファイルのリストである更新リストを取得することと、前記複数のファイルを有するサーバと無線通信することと、前記車両の状態を検出することと、前記無線通信の状況を検出することと、前記車両の状態および前記無線通信の状態の少なくとも一方に基づき、前記サーバから前記複数のファイルを取得することの可否および取得する順番を決定することとを含む。
【発明の効果】
【０００６】
本発明によれば、車両の状態や通信状況を考慮したダウンロードを実行できる。
【図面の簡単な説明】
【０００７】
【図１】プログラム更新システムＳのハードウエア構成図
【図２】ＴＣＵ１の機能ブロック図
【図３】更新リスト１７１の一例を示す図
【図４】ダウンロードリスト１７２の一例を示す図
【図５】ＴＣＵ１の更新処理を表すフローチャート
【図６】図５におけるＳ５２０のダウンロード処理を示すフローチャート
【図７】サーバ４の処理を表すフローチャート
【発明を実施するための形態】
【０００８】
―第１の実施の形態―
以下、図１〜図７を参照して、本発明にかかるプログラム更新システムの実施の形態を説明する。本実施の形態では、装置ごとに更新するプログラムは１つのみとする。
【０００９】
（ハードウエア構成）
図１はプログラム更新システムＳのハードウエア構成図である。プログラム更新システムＳは、車両５とサーバ４とから構成される。ただし図１では車両５は１台のみ記載しているがプログラム更新システムＳには複数の車両５が含まれてもよい。車両５は、ＴＣＵ１と、第１ＥＣＵ３１と、第２ＥＣＵ３２と、第３ＥＣＵ３３と、第４ＥＣＵ３４と、第５ＥＣＵ３５と、第６ＥＣＵ３６と、第７ＥＣＵ３７と、とを備える。
【００１０】
以下では、第１ＥＣＵ３１〜第７ＥＣＵ３７を特に区別しない場合にＥＣＵ３０と呼ぶ。車両５は不図示のバッテリーを備え、バッテリーはＴＣＵ１およびＥＣＵ３０に電力を供給する。この電力の供給は車両５のイグニションスイッチの状態を問わずに行われるので、たとえばイグニッションスイッチがオフにされた後もＴＣＵ１およびＥＣＵ３０は動作可能である。
【００１１】
ＴＣＵ１は、ＣＰＵ１１と、ＲＯＭ１２と、ＲＡＭ１３と、無線通信部１４と、車内通信部１５と、フラッシュメモリ１７とを備える。ＣＰＵ１１は中央演算装置であり、ＲＯＭ１２に格納されるプログラムをＲＡＭ１３に展開して実行することにより後述する機能を実現する。無線通信部１４は、無線通信モジュールであり、たとえば３Ｇや４Ｇの通信規格に対応する。無線通信部１４は、最寄りの基地局を介してインターネットＸに接続し、インターネットＸを経由してサーバ４と通信する。
【００１２】
車内通信部１５は、ＥＣＵ３０や車両５に搭載される不図示の機器と通信する通信モジュールであり、たとえばＩＥＥＥ８０２．３やＣＡＮ（登録商標）に対応する。ただし車内通信部１５とＥＣＵ３０との間に通信を中継する装置、いわゆるゲートウェイ装置が存在してもよい。フラッシュメモリ１７は、後述する情報を記憶する不揮発性の記憶装置である。ただしＴＣＵ１がフラッシュメモリ１７を備えず、ＲＯＭ１２に必要な情報を全て記憶してもよい。
【００１３】
ＥＣＵ３０は、車両５に内蔵され車両５の動作に関する何らかの演算を行う電子制御装置（Electronic Control Unit）、すなわちＥＣＵである。ここではＥＣＵ３０が担う具体的な機能は説明しないが、それぞれのＥＣＵ３０はプログラムを実行することによりそれぞれの機能を実現する。ＥＣＵ３０が実行するプログラムにはバージョン番号が付与されており、新しいプログラム、すなわちより大きい番号のバージョン番号を有するプログラムがサーバ４で作成されることがある。そのような場合は、その新しいプログラムを実行するための情報を格納したファイル（以下、「更新ファイル」と呼ぶ）がＴＣＵ１から各ＥＣＵ３０に送信される。各ＥＣＵ３０は、受信した更新ファイルを用いてプログラムを更新し、更新の完了をＴＣＵ１に伝達する。
【００１４】
なお更新ファイルは、新たなプログラムの全体でもよいし、現在のプログラムと新たなプログラムの差分でもよい。また更新ファイルは圧縮されていてもよいし、事前に取り決めた暗号化が施されていてもよい。さらに更新ファイルには、電子署名が付加されていてもよい。
【００１５】
またＴＣＵ１もＥＣＵ３０と同様にプログラムを実行しており、これらのプログラムは同様の手順で更新される。以下では、ＴＣＵ１とＥＣＵ３０とをまとめて「更新可能機器」と呼ぶ。更新可能機器はプログラムを不揮発性の記憶装置に格納しており、プログラムは適宜書き換えられる。
【００１６】
サーバ４は、ＣＰＵ４１と、ＲＯＭ４２と、ＲＡＭ４３と、ＨＤＤ４４と、サーバ通信部４５とを備える。ＣＰＵ４１は中央演算装置であり、ＲＯＭ４２に格納されるプログラムをＲＡＭ４３に展開して実行することにより後述する機能を実現する。ＨＤＤ４４は不揮発性の記憶装置、たとえばハードディスクドライブである。ＨＤＤ４４にはデータベース（以下、「ＤＢ」）４４１、および様々なプログラムに対応する更新ファイルが格納される。
【００１７】
ＤＢ４４１には、サーバ４に接続される様々な車両５に搭載される機器で動作しているプログラムの現在のバージョン番号、および各プログラムの最新バージョン番号が格納される。たとえば新しいバージョンのプログラムが作成されると、そのプログラムの更新ファイルがＨＤＤ４４に格納され、ＤＢ４４１に記載されるそのプログラムの最新バージョン番号が更新される。サーバ通信部４５は、インターネットＸを経由してＴＣＵ１と通信する。またＤＢ４４１には、プログラムごとにダウンロードに関する各種情報、具体的には優先度、レジュームの可否、分割数、およびダウンロード条件が設定されている。ＤＢ４４１に格納される情報は、現在のバージョン番号および最新のバージョン番号以外はオペレータ、すなわち人間が定めたものである。
【００１８】
（機能構成）
図２は、ＴＣＵ１が備える機能を示す機能ブロック図である。ただし図２にはフラッシュメモリ１７に格納される情報も示している。ＴＣＵ１はその機能として、ファイル取得部１１１と、リスト取得部１１２と、車両状態検出部１１３と、無線状況検出部１１４と、ファイル取得制御部１１５と、更新部１１６とを備える。またフラッシュメモリ１７には、更新リスト１７１と、更新ファイル１７９とが格納される。ただし更新リスト１７１、および更新ファイル１７９は必ずしも常にフラッシュメモリ１７に格納されていなくてもよい。
【００１９】
ファイル取得部１１１は、ＣＰＵ１１が実行するプログラムおよび無線通信部１４により実現される。ファイル取得部１１１は、サーバ４からプログラムの更新に用いる更新ファイル１７９をダウンロードする。ファイル取得部１１１は、ファイル取得制御部１１５の動作指令により動作する。ファイル取得部１１１は、サーバ４から更新ファイル１７９の断片を少しずつ取得し、ＲＡＭ１３に設けた作業領域に一時ファイルとして格納する。そしてサーバ４から更新ファイル１７９の全体の取得が完了すると、一時ファイルが更新ファイル１７９となるのでこの更新ファイル１７９をＲＡＭ１３からフラッシュメモリ１７に移動させる。
【００２０】
ファイル取得部１１１は、更新ファイル１７９を取得している途中でサーバ４との通信が切断されると、ファイル取得制御部１１５の動作指示に従い次のいずれかの動作を行う。すなわち第１の動作は一時ファイルの削除である。第１の動作は後述するレジュームが不可に設定されている場合に対応し、一時ファイルを再利用できないため一時ファイルを削除する。第２の動作は一時ファイルの保存である。このときファイル取得部１１１は、一時ファイルをＲＡＭ１３にそのまま保存してもよいし、フラッシュメモリ１７に保存してもよい。第２の動作は、後述するレジュームが可に設定されている場合に対応し、一時ファイルを後に利用するので廃棄せずに保管する。
【００２１】
リスト取得部１１２は、ＣＰＵ１１が実行するプログラムおよび無線通信部１４により実現される。リスト取得部１１２はサーバ４から更新リスト１７１を取得し、フラッシュメモリ１７に格納する。車両状態検出部１１３は、ＣＰＵ１１が実行するプログラムおよび車内通信部１５により実現される。車両状態検出部１１３は、ＥＣＵ３０および車両５に備えられる不図示の機器から車両５の状態に関する情報、たとえばイグニッションスイッチのオン／オフ状態、車両５の速度、ステアリング角度、車両５の位置などを取得する。
【００２２】
無線状況検出部１１４は、ＣＰＵ１１が実行するプログラムおよび無線通信部１４により実現される。無線状況検出部１１４は、常にサーバ４との通信状態を監視しており、現在のサーバ４との通信状態を判断する。通信状態は、大きく受信強度とノイズレベルの２つにより評価される。なお、受信強度が強くノイズレベルが低いほど良好な通信状態である。さらに無線状況検出部１１４は、直前の所定期間における通信状態に基づきフェージング状態にあるか否かの判断を行う。たとえば無線状況検出部１１４は、サーバ４と通信可能な状態と通信不可能な状態が所定の時間に所定の回数切り替わると、フェージング状態にあると判断する。具体的には、通信可能な状態と通信不可能な状態が１分間に２回切り替わるとフェージング状態にあると判断する。
【００２３】
ファイル取得制御部１１５は、車両５の状態および無線通信の状態に基づき、複数のファイルを取得することの可否および取得する順番を決定する。ファイルを取得する順番は、取得することを決定したファイルのうち、優先度が高いファイルを優先する。ファイル取得制御部１１５は、ファイル取得部１１１に動作指令を出力してファイルを取得させる。更新部１１６は、ＣＰＵ１１が実行するプログラムおよび車内通信部１５により実現される。更新部１１６は、ＥＣＵ３０に更新ファイル１７９を送信してプログラムの更新を実行させる。また更新部１１６は、プログラムの更新を実行させた更新可能機器から更新完了通知を受信すると、無線通信部１４を介してサーバ４に更新の完了を通知する。
【００２４】
（更新リスト１７１）
図３は更新リスト１７１の一例を示す図である。更新リスト１７１は、サーバ４により作成されＴＣＵ１に送信される。更新リスト１７１には、更新対象となるプログラムが存在する更新可能機器のそれぞれについて、機器名、優先度、レジュームの可否、分割数、ダウンロード条件が含まれる。優先度は１以上の整数で表され、数が小さいほど優先されることを示す。すなわち優先度が「１」の場合は最も優先されることを示す。レジュームの可否は、ダウンロードの再開時に従前に取得したファイルの利用可否を示す。
【００２５】
たとえばあるファイルのサイズが１０ＭＢであり、８ＭＢまでダウンロードした際に通信が途切れても、レジュームが可能であれば従前に取得したデータに続けてダウンロードできるので残り２ＭＢを取得すればよい。ただし、通信が途切れた際のデータの扱いやダウンロード済みのデータに新たに取得したデータを追加する処理に問題が生じて数ビットのデータが気づかれずに消失していることがある。そのため本実施の形態では、データが重要であるほどはレジュームを行わない傾向としている。
【００２６】
分割数は、更新ファイルをいくつに分割しているかを示す数である。たとえば１０ＭＢのファイルを分割数「２」とすれば、５ＭＢのファイルが２つ生成される。１つのファイルのサイズが大きいとダウンロードに長い時間を要し、場合によっては１回のダウンロードでは取得できないことも考えられる。そのためサイズが大きいファイルは複数に分割することが望ましい。ただし分割や結合の際に何らかの問題が生じ、データが失われる、または書き換わる可能性がゼロではないので、重要なデータは分割しないことが望ましい。
【００２７】
ダウンロード条件は、更新ファイルをサーバ４から取得する条件であり、車両の状態の条件と電波状態の条件の少なくとも一方を含む。車両状態の条件とは、たとえばイグニッションスイッチがオフの状態、車両５の速度が所定の速度以下、車両の現在位置が予め定めた範囲などである。電波状態の条件とは、たとえば電波強度が第１の閾値以上であり、ノイズレベルが第２の閾値以下の状態などである。ダウンロード条件は、優先度が高いほど厳しく設定される傾向にある。そのためたとえば、優先度１のあるファイルのダウンロード条件は満たさないが、優先度３のあるファイルのダウンロード条件は満たす、という状況が発生しうる。
【００２８】
（ダウンロードリスト１７２）
図４はダウンロードリスト１７２の一例を示す図である。ダウンロードリスト１７２はＴＣＵ１が更新リスト１７１に基づき作成する。ダウンロードリスト１７２は、更新リスト１７１から「優先度」の列が削除され、「処理番号」、および「未／完」の列が追加される。ＴＣＵ１は、更新リスト１７１の優先度の列に注目し、優先度が高い行、すなわち優先度の値が低い行からダウンロードリスト１７２に記載する。優先度が同一である行が複数存在する場合は、更新リスト１７１に記載された順番にダウンロードリスト１７２に記載してもよいし、ランダムとしてもよい。「処理番号」の列には１からの連番を記載し、「未／完」の列は全て「未」とする。このダウンロードリスト１７２は、更新ファイル１７９のダウンロードの際に参照され、「未／完」の列が必要に応じて更新される。なお以下では、「ダウンロード」を「ＤＬ」とも記載する。
【００２９】
（更新処理のフローチャート）
図５は、ＴＣＵ１の更新処理を表すフローチャートである。以下に説明する各ステップの実行主体はＴＣＵ１のＣＰＵ１１である。ＴＣＵ１は、車両５のイグニションスイッチがオフにされると図５に示す動作を開始する。すなわち以下に説明する処理が実行されている間は、車両５は停止している。またイグニションスイッチがオフにされたことは、車両状態検出部１１３が検出する。
【００３０】
車両５のイグニションスイッチがオフにされるとＴＣＵ１は、まずＳ５１０において無線状況検出部１１４が電波状況を取得する。続くＳ５１２ではＴＣＵ１は、Ｓ５１０において取得した電波状況から圏外であるか否か、換言するとサーバ４との通信が不可能な状態であるか否かを判断する。ＴＣＵ１は、圏外であると判断する場合は図５に示す処理を終了し、圏外ではないと判断する場合はＳ５１４に進む。Ｓ５１４ではＴＣＵ１は、フェージング状態にあるか否かを判断し、フェージング状態にあると判断する場合は図５に示す処理を終了し、圏外ではないと判断する場合はＳ５１６に進む。
【００３１】
Ｓ５１６ではＴＣＵ１はサーバ４に接続してＴＣＵ１の識別子を送信し、続くＳ５１８ではサーバ４から更新リスト１７１を取得する。そしてＴＣＵ１は、Ｓ５２０において後に詳述するダウンロード処理を行い、続くＳ５２２ではダウンロード処理が正常終了したか否かを判断する。ＴＣＵ１はダウンロード処理が正常終了していないと判断する場合は更新を行わず図５に示す処理を終了する。ＴＣＵ１はダウンロード処理が正常終了したと判断する場合は、Ｓ５２４で更新部１１６を用いてＥＣＵ３０の更新を行う。
【００３２】
続くＳ５２６ではＴＣＵ１は、所定時間以内に更新成功の通知を受信したか否かを判断する。ＴＣＵ１は、受信したと判断する場合はＳ５２８に進みサーバ４に更新完了を通知し、Ｓ５３０でスリープ状態に移行して図５に示す処理を終了する。Ｓ５２６において否定判断をするとＴＣＵ１はＳ５３２に進み、更新成功を所定時間以内に送信しなかった装置にロールバック指令、すなわち更新前のプログラムに書き戻すように指令して図５に示す処理を終了する。
【００３３】
（ダウンロード処理のフローチャート）
図６は、図５におけるＳ５２０のダウンロード処理を示すフローチャートである。
ＴＣＵ１はまずＳ６１０において、受信した更新リスト１７１を加工してダウンロードリスト１７２を作成してＳ６１２に進む。具体的には、更新リスト１７１を優先度が小さいほど上位に位置するように並び替えるとともに、「処理番号」と「未／完」の列を追加する。ＴＣＵ１は「処理番号」の列には１からの連番を記載し、「未／完」の列には全て「未」を格納する。Ｓ６１２ではＴＣＵ１は、変数ｉに未処理の最も小さい番号を代入してＳ６１４に進む。詳述するとＴＣＵ１は、ＤＬリストの「未／完」の列の値が「完」ではなく、「処理番号」の値が最も小さい値を代入する。たとえばＳ６１２を初回に実行する際には、「未／完」の列は全て「未」なので変数ｉには「１」が代入される。
【００３４】
Ｓ６１４ではＴＣＵ１は、処理番号ｉのダウンロード条件を満たすか否かを判断し、満たすと判断する場合はＳ６２２に進み、満たさないと判断する場合はＳ６１６に進む。Ｓ６１６ではＴＣＵ１は、変数ｉが最後の値、すなわちダウンロードリスト１７２の行数と同数であるか否かを判断する。たとえば図４に示すダウンロードリスト１７２の例では変数ｉが８の場合にＳ６１６が肯定判断される。ＴＣＵ１は変数ｉが最後の値であると判断する場合はＳ６１７に進み、変数ｉが最後の値ではないと判断する場合はＳ６２０に進む。Ｓ６１７ではＴＣＵ１は、処理番号ｉが１から連続でダウンロード条件を満たさないか否かを判断し、全て連続で満たさないと判断する場合は図６に示す処理を終了し（Ｓ６５４）、全て連続で満たさないわけではないと判断する場合はＳ６１８に進む。Ｓ６１８ではＴＣＵ１は所定時間だけ待機してＳ６１２に戻る。Ｓ６２０ではＴＣＵ１は変数ｉをインクリメント、すなわち「１」だけ増加させてＳ６１４に戻る。
【００３５】
Ｓ６１４において肯定判定されると実行されるＳ６２２ではＴＣＵ１は、処理番号ｉのファイルのダウンロードを開始してＳ６２４に進む。ＴＣＵ１は、ダウンロード中にＳ６２４，Ｓ６２６，およびＳ６２８を繰り返し判断する。Ｓ６２４ではＴＣＵ１は、変数ｉよりも上位の処理番号でかつ未ダウンロードであるファイルのダウンロード条件を満たすか否かを判断する。ＴＣＵ１はＳ６２４を肯定判断する場合はＳ６１２に戻り、Ｓ６２４を否定判断する場合はＳ６２６に進む。
【００３６】
なおＳ６２４が肯定判断されるのは、たとえば以下の場合である。すなわち、処理番号１のダウンロード条件を満たさないが処理番号２のダウンロード条件を満たすと判断して処理番号２のダウンロードを開始した。そして処理番号２のダウンロードが完了する前に状況が変化して、処理番号１のダウンロード条件を満たすようになった場合である。
【００３７】
Ｓ６２６ではＴＣＵ１は、処理番号ｉのダウンロード条件が引き続き満たされている状態であるか否かを判断する。ＴＣＵ１はＳ６２６を肯定判断する場合はＳ６２８に進み、Ｓ６２６を否定判断する場合はＳ６３０に進む。Ｓ６２８ではＴＣＵ１は、処理番号ｉのダウンロードが完了したか否かを判断し、ダウンロードが完了したと判断する場合はＳ６３６に進み、ダウンロードが完了していないと判断する場合はＳ６２４に戻る。Ｓ６２６において否定判断されると実行されるＳ６３０ではＴＣＵ１は、処理番号ｉはレジュームに対応するか否かを判断する。ＴＣＵ１は、レジュームに対応すると判断する場合はダウンロードキャッシュを保存して（Ｓ６３２）からＳ６２０に進む。ＴＣＵ１は、レジュームに対応しないと判断する場合はダウンロードキャッシュを削除して（Ｓ６３４）からＳ６２０に進む。
【００３８】
Ｓ６２８において肯定判断されるとＴＣＵ１は、ダウンロードが完了したファイルをフラッシュメモリ１７に保存し（Ｓ６３６）、ダウンロードリスト１７２の処理番号ｉのレコードにダウンロード完了を記録して（Ｓ６３８）、Ｓ６４０に進む。ただしＳ６３８では、更新ファイル１７９の分割数が２以上の場合は、分割されたファイルのうち何番目までのダウンロードが完了したかを識別可能に記録する。たとえばある更新ファイル１７９について分割数が「５」の場合は、１つ目のダウンロード完了時に「１完了」、２つ目のダウンロード完了時に「２完了」などと識別可能に記録する。Ｓ６４０ではＴＣＵ１は、ダウンロードリスト１７２に記載された全ファイルのダウンロードが完了したか否かを判断し、すべて完了していると判断する場合は図６に示す処理を終了し（Ｓ６５２）、ダウンロードしていないファイルが存在すると判断する場合はＳ６１２に戻る。
【００３９】
（サーバ４のフローチャート）
図７は、サーバ４の処理を表すフローチャートである。サーバ４は、ＴＣＵ１から識別子を受信すると図７に示す処理を開始する。以下に説明する各ステップの実行主体は、サーバ４のＣＰＵ４１である。
【００４０】
サーバ４は識別子を受信するとまずＳ７０１において、ＤＢ４４１を参照して更新リスト１７１を作成してＴＣＵ１に送信する。更新リスト１７１はたとえば次のように作成される。サーバ４はまずＤＢ４４１を参照して、受信した識別子が付された車両５に搭載される全ての更新可能機器を特定する。そしてサーバ４は、それぞれに新たなプログラムが存在するか否かを判断する。新たなプログラムが存在すると判断する更新可能機器について、図４に示したように機器の名称、優先度、レジューム、分割数、およびダウンロード条件をＤＢ４４１からコピーして更新リスト１７１を作成する。以上が更新リスト１７１の作成方法である。
【００４１】
Ｓ７０１の次に実行されるＳ７０２では、サーバ４は、更新リスト１７１の送信から所定時間以内にデータ要求を受けたか否かを判断する。サーバ４は、データ要求を受けたと判断する場合はＳ７０３に進んで要求されたデータ、すなわち更新ファイル１７９を配信してＳ７０４に進む。サーバ４は、Ｓ７０２において否定判断すると図７に示す処理を終了する。
【００４２】
Ｓ７０４ではサーバ４は、更新完了通知を受信したか否かを判断する。サーバ４はＳ７０４において肯定判断をするまでＳ７０４に留まる。サーバ４はＳ７０４において肯定判断をすると、すなわち受信したと判断するとＳ７０５に進みＤＢ４４１を更新して図７に示す処理を終了する。なおＳ７０５におけるＤＢ４４１の更新は、Ｓ７０３において配信した更新本体により送信先の更新可能機器のプログラムのバージョン番号が最新に書き換えられたことの記録である。
【００４３】
上述した第１の実施の形態によれば、次の作用効果が得られる。
（１）ＴＣＵ１は車両５に搭載される。ＴＣＵ１は、複数のファイルのリストである更新リスト１７１を取得するリスト取得部１１２と、無線通信によりファイルを取得する無線通信部１４と、車両５の状態を検出する車両状態検出部１１３と、無線通信の状況を検出する無線状況検出部１１４と、車両５の状態および無線通信の状態の少なくとも一方に基づき、複数のファイルを取得することの可否および取得する順番を決定するファイル取得制御部１１５とを備える。
【００４４】
車両５の状態がイグニッションオフである場合に図５に示す処理が開始され、無線通信の状態が圏外でなく（Ｓ５１２：ＮＯ）、フェージング状態でもない（Ｓ５１４：ＮＯ）場合に更新ファイル１７９のダウンロード処理（Ｓ５２０）が実行される。またダウンロードリスト１７２のダウンロード条件は、車両５の状態および無線通信の状態の少なくとも一方であり、ダウンロード条件を満たす場合にダウンロードが実行されるので、取得する順番が車両５の状態および無線通信の状態により決定されているといえる。そのためＴＣＵ１は、車両の状態や通信状況を考慮したダウンロードを実行できる。
【００４５】
（２）ファイル取得制御部１１５は、無線通信の状況が通信可能な状態と通信不可能な状態が所定の時間に所定の回数切り替わると、複数のファイルを取得しないと決定する（図５のＳ５１４：ＹＥＳ）。そのため通信が不安定な状況での更新ファイル１７９のダウンロードを未然に防止できる。通信が不安定な状況では、ダウンロードの開始と中断が繰り返され電力消費が課題になるため好ましくない。
【００４６】
（３）更新リスト１７１にはファイルごとに、優先度およびダウンロードの条件が記載される。ファイル取得制御部１１５は、ダウンロードの条件を満たすファイルのうち、優先度が高いファイルからダウンロードを行う。ダウンロードリスト１７２は、優先度が小さいほど上位に位置するように作成され（Ｓ６１０）、ダウンロードリスト１７２の上から順番によりされるため、ダウンロードの順番は優先度が高いファイルほど先にダウンロードされる。そのため設定された優先度に応じてダウンロードを実行できる。
【００４７】
（４）更新リスト１７１にはファイルごとのレジュームの可否が記載されている。
ファイルのダウンロード中にダウンロードを行っているファイルのダウンロードの条件を満たさなくなると、更新リストに記載されたレジュームの可否にあわせてダウンロード途中のデータの廃棄可否を判断する（図６のＳ６２６：ＮＯ、Ｓ６３０）。そのため不要なファイルをフラッシュメモリ１７に保存せず、効率よく記憶装置を使用できる。
【００４８】
（５）ファイル取得制御部１１５は、無線通信の状況が通信不可能な状態であると複数のファイルを取得しないと決定する（図５のＳ５１２：ＹＥＳ）。そのため通信が不可能な状況での更新ファイル１７９のダウンロードを未然に防止し、不要な電力の浪費を抑制できる。
【００４９】
（変形例１）
上述した実施の形態では、サーバ４が送信する更新リスト１７１にレジュームの可否、および分割数が記載されており、ＴＣＵ１は更新リスト１７１の記載に基づき更新ファイル１７９のダウンロード処理を行った。しかしＴＣＵ１は、レジュームの可否および分割数について更新リスト１７１の記載を無視して更新ファイル１７９のダウンロード処理を行ってもよい。また本変形例では、サーバ４は更新リスト１７１にレジュームおよび分割数の列を設けなくてもよい。
【００５０】
ＴＣＵ１は、優先度に基づきレジュームの可否を決定してもよい。たとえばＴＣＵ１は、優先度が１または２の更新ファイル１７９は一律でレジューム不可とし、優先度が３以上の更新ファイル１７９は一律でレジューム可能としてもよい。この場合はＴＣＵ１は、図６のＳ６１０におけるダウンロードリスト１７２の作成時にこの判断を行い、優先度に基づいてダウンロードリスト１７２におけるレジュームの可否を書き込んでもよい。またＴＣＵ１は、ダウンロードリスト１７２にレジュームの可否ではなく優先度を記載し、図６のＳ６３０において逐一判断をしてもよい。
【００５１】
ＴＣＵ１は、優先度に基づき分割数を決定してもよい。ＴＣＵ１は、優先度が高いほど分割数を少なく設定し、優先度が低いほど分割数を多く設定する。たとえば優先度が１の場合は分割数は１、すなわち分割しないこととし、優先度が３の場合は分割数を１０とする。そしてこの場合は、決定した分割数をサーバ４に伝達し、サーバ４は受信した分割数に応じてあらかじめ更新ファイル１７９を分割し、分割したそれぞれのファイルをＴＣＵ１の要求に応じて送信する。
【００５２】
この変形例１によれば、次の作用効果が得られる。
（６）ファイル取得制御部１１５は、ファイルごとの優先度に基づき、優先してダウンロードするファイルほど分割数を減らす。そのためＴＣＵ１は、優先度が高い重要なファイルは分割数を減らすことで、分割に伴う問題を避けることができる。
【００５３】
（７）ファイル取得制御部１１５は、ファイルごとの優先度に基づき、優先してダウンロードするファイルほどレジュームを行わない。そのためＴＣＵ１は、優先度が高い重要なファイルはレジュームに伴う問題を避けることができる。
【００５４】
（変形例２）
上述した実施の形態では、サーバ４が作成する更新リスト１７１に更新ファイル１７９ごとの優先度が記載された。しかしＴＣＵ１に更新可能機器ごとの更新の優先度をあらかじめフラッシュメモリ１７に格納し、その情報を参照させることで更新リスト１７１から優先度の記載を省略してもよい。その場合には、ＴＣＵ１は、図６のＳ６１０においてフラッシュメモリ１７に格納した前述の情報を参照する。
【００５５】
（変形例３）
上述した実施の形態では、サーバ４が作成する更新リスト１７１に更新ファイル１７９ごとの優先度が数字で記載された。しかし数字の代わりに更新の分類を記載してもよい。更新の分類とは例えば、安全、プライバシー、有料情報、車両、その他である。「安全」の分類には、たとえば車両５の乗員の安全性を向上させるものや、外部からの意図しないアクセスを遮断するものが含まれる。「プライバシー」には、車両５の所有者や乗員の個人情報を扱うものが含まれる。「有料情報」には、有料のコンテンツである地図情報などが含まれる。「車両」には、安全性とは直接に関係がない車両の動作が含まれる。「その他」は他に分類されないものである。
【００５６】
この場合にはＴＣＵ１のフラッシュメモリ１７には、更新の分類と優先度の対応があらかじめ格納され、ＴＣＵ１は、図６のＳ６１０においてフラッシュメモリ１７に格納した前述の情報を参照する。
【００５７】
（変形例４）
上述した実施の形態では、サーバ４は１つの物理的な装置であった。しかしサーバ４が有する機能を複数の物理的な装置で分担してもよい。たとえばサーバ４の機能を２つの異なる装置に分担させ、一方は要求に応じて更新ファイル１７９を提供する機能を有し、他方はその余の機能を有してもよい。この変形例４によれば、サーバ４を様々な形態で実現でき、容易にスケールアウトが可能である。
【００５８】
（変形例５）
上述した実施の形態では、ＴＣＵ１、およびＥＣＵ３０を更新可能機器とした。しかしいずれかの機器がプログラムを更新可能であればよい。特にＴＣＵ１がＴＣＵ１のプログラムを更新しなくてもよい。また更新ファイル１７９は更新可能機器に格納されている情報を更新すればよく、たとえばプログラム以外のデータを更新してもよい。
【００５９】
（変形例６）
上述した実施の形態では、ダウンロードリスト１７２に記載された全てのファイルがダウンロードされたから更新を実行した（図６のＳ６４０：ＹＥＳ、Ｓ６５２）。しかし１つの更新可能機器についてのファイルのダウンロードが完了するごとに更新を実行してもよい。
【００６０】
（変形例７）
上述した実施の形態では、それぞれの更新可能機器は１つのプログラムのみを更新対象とした。しかし１つの更新可能機器が複数のプログラムを更新可能であってもよい。この場合は、更新可能機器ごとに、更新リスト１７１およびダウンロードリスト１７２においてプログラムが識別可能に記載されればよい。
【００６１】
上述した各実施の形態および変形例において、ＴＣＵ１のプログラムはＲＯＭ１２に格納されるとしたが、プログラムはフラッシュメモリ１７に格納されていてもよい。また、ＴＣＵ１が不図示の入出力インタフェースを備え、必要なときに入出力インタフェースとＴＣＵ１が利用可能な媒体を介して、他の装置からプログラムが読み込まれてもよい。ここで媒体とは、例えば入出力インタフェースに着脱可能な記憶媒体、または通信媒体、すなわち有線、無線、光などのネットワーク、または当該ネットワークを伝搬する搬送波やディジタル信号、を指す。また、プログラムにより実現される機能の一部または全部がハードウエア回路やＦＰＧＡにより実現されてもよい。
【００６２】
上述した各実施の形態および変形例は、それぞれ組み合わせてもよい。上記では、種々の実施の形態および変形例を説明したが、本発明はこれらの内容に限定されるものではない。本発明の技術的思想の範囲内で考えられるその他の態様も本発明の範囲内に含まれる。
【符号の説明】
【００６３】
４…サーバ
５…車両
１１…ＣＰＵ
１４…無線通信部
１５…車内通信部
１７…フラッシュメモリ
１１１…ファイル取得部
１１２…リスト取得部
１１３…車両状態検出部
１１４…無線状況検出部
１１５…ファイル取得制御部
１１６…更新部
１７１…更新リスト
１７２…ダウンロードリスト
１７９…更新ファイル
【図１】
2019179331.tif 000003
【図２】
2019179331.tif 000004
【図３】
2019179331.tif 000005
【図４】
2019179331.tif 000006
【図５】
2019179331.tif 000007
【図６】
2019179331.tif 000008
【図７】
2019179331.tif 000009