(57)【要約】      （修正有）【課題】車載ソフトウエア等のアップデートか未完了となった場合でも、そのアップデートを自律的に再開することができる車載用データ更新装置を提供する。【解決手段】車載用データ更新装置２０は、記憶部１４と、制御部１５と、通信部１３とを有する。車載用データ更新装置２０は、記憶部１４に保存されている車載アプリケーションやデータをアップデートする。更に、車載用データ更新装置２０は、このアップデートが未完了であった場合に、未完了となった理由を自ら診断し、その理由に応じてアップデートを再開する。【選択図】図１
2018097764.tif 000002
【特許請求の範囲】
【請求項１】
車載ソフトウエアのアップデート対象ユニットをアップデートするためのアップデートデータを、車両の外部に存在するサーバから受信する通信部と、
前記車両の内部で、前記アップデート対象ユニットに転送される前記アップデートデータを記憶する記憶部と、
前記アップデートデータを用いて前記アップデート対象ユニットをアップデートする制御部と、を具備し、
前記制御部は、
前記アップデート対象ユニットの各アップデート領域へのアップデート状況を検出し、
アップデートが未完了となった前記アップデート領域が存在する場合、アップデートが未完了となった要因を検出し、
アップデートを再開することが可能な場合は、アップデートを再開することを特徴とする車載用データ更新装置。
【請求項２】
前記制御部は、アップデートが未完了となった前記アップデート領域に対してアップデートの再開を行い、アップデートが完了した前記アップデート領域に対してアップデートの再開を行わないことを特徴とする請求項１に記載の車載用データ更新装置。
【請求項３】
前記制御部は、前記車両に備えられたバッテリの電圧が低下したことで、アップデートが未完了となったことを検出した場合、
前記バッテリの前記電圧の復旧を待って、アップデートを再開することを特徴とする請求項１に記載の車載用データ更新装置。
【請求項４】
前記制御部は、不正規の前記アップデートデータをアップデートしたことで、アップデートが未完了となったことを検出した場合、
正規の前記アップデートデータを用いて、アップデートを再開することを特徴とする請求項１に記載の車載用データ更新装置。
【請求項５】
前記制御部は、アップデートを行っている間に、前記車両のエンジンの始動に伴う電源状態が変化したことで、アップデートが未完了となったことを検出した場合、
前記電源状態の変化が安定するのを待って、アップデートを再開することを特徴とする請求項１に記載の車載用データ更新装置。
【請求項６】
前記制御部は、アップデートの再開を試みる回数が上限回数を超えたら、アップデートの再開を中止することを特徴とする請求項１から請求項５の何れかに記載の車載用データ更新装置。
【請求項７】
前記制御部は、アップデートが未完了となった前記要因に応じて、前記上限回数を異ならせることを特徴とする請求項６に記載の車載用データ更新装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車載用データ更新装置に関し、特に、車載ソフトウエア等をアップデートすることができる車載用データ更新装置に関する。
【背景技術】
【０００２】
近年に於いて乗用車等の車両は電子機器を多数搭載しており、これらの電子機器の動作は、電子機器自体に組み込まれたソフトウエアやデータで制御されている。例えば、電子機器としてのナビゲーション装置は、その装置に記憶されたソフトウエアで動作し、その装置に記憶された地図データをディスプレイに表示する。
【０００３】
これらのソフトウエアやデータは、動作の安定化やデータの更新の為に、アップデートを行う場合がある。アップデートの具体的な方法は、整備工場や特約店にて整備用の電子端末を車両に接続し、上記したソフトウエアやデータを更新するのが一般的である。
【０００４】
近年、このようなデータの更新作業を、無線通信を通じて行う技術が登場している。このようなデータの更新作業を実行した際に、更新作業が正常に終了しなかった場合の対処方法が、以下の特許文献１および特許文献２に記載されている。
【０００５】
特許文献１では、車載機器のソフトウエアをアップデートする為の書き換え用ソフトウエアを、移動体通信網を介してサービスセンターから無線配信する。そして、車両側の受信手段で書き換え用ソフトウエアをダウンロードした後に、その書き換え用ソフトウエアが正常であるか否かを判断し、正常と判断できる場合のみ、書き換え用ソフトウエアを用いて車載機器のソフトウエアを書き換えている。また、書き換え後に車載機器の動作が正常であるか否かを判定し、正常で無いと判定された場合は、車載機器のソフトウエアを書き換え前の状態に戻している。このようにすることで、書き換え用ソフトウエアの異常や、アップデート後の動作異常を予防することができる。
【０００６】
特許文献２では、ソフトウエア更新部で、ダウンロードした新しいソフトウエアをメモリ空き領域に書き込むことでソフトウエアの更新作業を行う。そして、この更新作業が異常終了した場合には、更新前に使用していた現行のソフトウエアをサーバからダウンロードし、メモリに書き込む。このようにすることで、ソフトウエアを更新する際に何らかの問題が生じた場合であっても、車載機を継続的に使用することができる。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００４−３２６６８９号公報
【特許文献２】特開２０１５−４１３３４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、上記した各特許文献に記載された発明では、車載ソフトウエアの更新作業が正常で無い場合に、その状態を更新前に戻しているため、更新作業そのものは正常に終了していない。従って、車載ソフトウエアの更新作業を正常に行うためには、整備工場等に車両を持ち込み、専門業者にその更新作業を依頼することになる。そのような車両を持ち込む作業は、車両の所有者にとっては煩雑である課題があった。
【０００９】
本発明は、上記の事情に鑑みてなされたものであり、その目的とするところは、車載ソフトウエア等のアップデートが未完了（例えば、失敗や不正終了等）となった場合であっても、そのアップデートを自ら再開することができる車載用データ更新装置を提供することにある。
【課題を解決するための手段】
【００１０】
本発明の車載用データ更新装置では、車載ソフトウエアのアップデート対象ユニットをアップデートするためのアップデートデータを、車両の外部に存在するサーバから受信する通信部と、前記車両の内部で、前記アップデート対象ユニットに転送される前記アップデートデータを記憶する記憶部と、前記アップデートデータを用いて前記アップデート対象ユニットをアップデートする制御部と、を具備し、前記制御部は、前記アップデート対象ユニットの各アップデート領域へのアップデート状況を検出し、アップデートが未完了となった前記アップデート領域が存在する場合、アップデートが未完了となった要因を検出し、アップデートを再開することが可能な場合は、アップデートを再開することを特徴とする。
【００１１】
また、本発明の車載用データ更新装置では、前記制御部は、アップデートが未完了となった前記アップデート領域に対してアップデートの再開を行い、アップデートが完了した前記アップデート領域に対してアップデートの再開を行わないことを特徴とする。
【００１２】
また、本発明の車載用データ更新装置では、前記制御部は、前記車両に備えられたバッテリの電圧が低下したことで、アップデートが未完了となったことを検出した場合、前記バッテリの前記電圧の復旧を待って、アップデートを再開することを特徴とする。
【００１３】
また、本発明の車載用データ更新装置では、前記制御部は、不正規の前記アップデートデータをアップデートしたことで、アップデートが未完了となったことを検出した場合、正規の前記アップデートデータを用いて、アップデートを再開することを特徴とする。
【００１４】
また、本発明の車載用データ更新装置では、前記制御部は、アップデートを行っている間に、前記車両のエンジンの始動に伴う電源状態が変化することで、アップデートが未完了となったことを検出した場合、前記電源状態の変化が安定するのを待って、アップデートを再開することを特徴とする。
【００１５】
また、本発明の車載用データ更新装置では、前記制御部は、アップデートの再開を試みる回数が上限回数を超えたら、アップデートの再開を中止することを特徴とする。
【００１６】
また、本発明の車載用データ更新装置では、前記制御部は、アップデートが未完了となった前記要因に応じて、前記上限回数を異ならせることを特徴とする。
【発明の効果】
【００１７】
本発明の車載用データ更新装置では、車載ソフトウエアのアップデート対象ユニットをアップデートするためのアップデートデータを、車両の外部に存在するサーバから受信する通信部と、前記車両の内部で、前記アップデート対象ユニットに転送される前記アップデートデータを記憶する記憶部と、前記アップデートデータを用いて前記アップデート対象ユニットをアップデートする制御部と、を具備し、前記制御部は、前記アップデート対象ユニットの各アップデート領域へのアップデート状況を検出し、アップデートが未完了となった前記アップデート領域が存在する場合、アップデートが未完了となった要因を検出し、アップデートを再開することが可能な場合は、アップデートを再開することを特徴とする。従って、本発明では、アップデート対象ユニットのアップデートに失敗した場合、自らアップデートを再開するので、アップデートに失敗した場合の復帰行程を、専門業者に頼らずとも、自動的に行うことを可能としている。
【００１８】
また、本発明の車載用データ更新装置では、前記制御部は、アップデートが未完了となった前記アップデート領域に対してアップデートの再開を行い、アップデートが完了した前記アップデート領域に対してアップデートの再開を行わないことを特徴とする。従って、アップデートが未完了であったアップデート領域に対してのみ、アップデートの再開を行うことで、アップデートの再開に要する時間を短縮することができる。
【００１９】
また、本発明の車載用データ更新装置では、前記制御部は、前記車両に備えられたバッテリの電圧が低下したことで、アップデートが未完了となったことを検出した場合、前記バッテリの前記電圧の復旧を待って、アップデートを再開することを特徴とする。従って、バッテリの電圧が低下したことでアップデートが未完了となったとしても、その後、バッテリの電圧が一定以上に安定した状態で、アップデートを安全に再開することができる。
【００２０】
また、本発明の車載用データ更新装置では、前記制御部は、不正規の前記アップデートデータをアップデートしたことで、アップデートが未完了となったことを検出した場合、正規の前記アップデートデータを用いて、アップデートを再開することを特徴とする。従って、アップデートデータが不正規であることでアップデートが未完成になったとしても、その後に、正規のアップデートデータを用いてアップデートを行うことができる。
【００２１】
また、本発明の車載用データ更新装置では、前記制御部は、アップデートを行っている間に、前記車両のエンジンの始動に伴う電源状態が変化することで、アップデートが未完了となったことを検出した場合、前記電源状態の変化が安定するのを待って、アップデートを再開することを特徴とする。従って、アップデートの途中でエンジンが始動されることで、アップデートが未完成になったとしても、エンジンが停止した後に、再びアップデートを行うことができる。
【００２２】
また、本発明の車載用データ更新装置では、前記制御部は、アップデートの再開を試みる回数が上限回数を超えたら、アップデートの再開を中止することを特徴とする。従って、アップデートの再開を試みる回数に上限を設けることで、アップデートできる可能性が無いにも関わらず、アップデートの再開を試み続けてしまうことを防止することができる。
【００２３】
また、本発明の車載用データ更新装置では、前記制御部は、アップデートが未完了となった前記要因に応じて、前記上限回数を異ならせることを特徴とする。従って、例えば、アップデートを再開できる可能性が高ければ、上限回数を多くすることで、アップデートの再開が成功する可能性を向上させることができる。
【図面の簡単な説明】
【００２４】
【図１】本発明の一実施形態にかかる載用データ更新装置を示す図であり、（Ａ）は車載用データ更新装置が適用される車両等を示す概念図であり、（Ｂ）は車載用データ更新装置の接続構成を示すブロック図である。
【図２】本発明の一実施形態にかかる載用データ更新装置で用いられるアップデート対象ユニットの構成を示すブロック図である。
【図３】本発明の一実施形態にかかる載用データ更新装置を用いて、車載ソフトウエア等をアップデートする方法を示すフローチャートである。
【図４】本発明の一実施形態にかかる載用データ更新装置を用いて、車載ソフトウエア等をアップデートする際の、再開を判定する行程を詳細に示すフローチャートである。
【発明を実施するための形態】
【００２５】
以下、本発明の一実施形態に係る車載用データ更新装置を、図面に基づき詳細に説明する。以下の説明では、同一の部材には原則として同一の符番を用い、繰り返しの説明は省略する。
【００２６】
図１（Ａ）は本形態の車載用データ更新装置２０が組み込まれた車両１０等を示す概念図であり、図１（Ｂ）は車載用データ更新装置２０の構成を示すブロック図である。
【００２７】
図１（Ａ）を参照して、車載用データ更新装置２０は、乗用車等の車両１０に組み込まれている。車載用データ更新装置２０は、記憶部１４と、制御部１５と、通信部１３と、を有する。車載用データ更新装置２０は、記憶部１４に保存されている車載ソフトウエアやデータをアップデートする。このような更新を行うシステムは、ＯＴＡ（Ｏｖｅｒ  Ｔｈｅ  Ａｉｒ）と称される。また、係るシステムは、テレマティクスとも称される。更に、車載用データ更新装置２０は、このアップデートが未完了（例えば、失敗や不正終了等）であった場合、その理由に応じて自らアップデートを再開する。
【００２８】
車載用データ更新装置２０は、通信網１１を介してサーバ１２と通信可能とされている。通信網１１で採用される通信規格は、例えば、Ｗｉ−ｆｉ、ＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）、３Ｇ（第３世代移動通信システム、Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ  ２０００）である。
【００２９】
サーバ１２は、車両１０の外部に設置されており、車載用データ更新装置２０がアップデートに用いるアップデートデータを保存している。サーバ１２は、車載用データ更新装置２０の要求に応じ、通信網１１を経由してアップデートデータを車載用データ更新装置２０に送信する。
【００３０】
図１（Ｂ）を参照して、車載用データ更新装置２０に含まれる制御部１５は、例えばＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）から成る。制御部１５は、上記したサーバ１２からダウンロードされたアップデートデータを用いて、後述するアップデート対象ユニット３１をアップデートする。更に、制御部１５は、後述するように、アップデートの状況を検出し、アップデートが未完了となった場合はその要因を検出し、アップデートを再開する。
【００３１】
記憶部１４は、例えば、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ  Ｅｒａｓａｂｌｅ  Ｐｒｏｇｒａｍｍａｂｌｅ  ｒｅａｄ−ｏｎｌｙ  ｍｅｍｏｒｙ）等の汎用のメモリから成る。記憶部１４は、アップデートデータ記憶部３０およびアップデート対象ユニット３１を有する。
【００３２】
アップデートデータ記憶部３０は、サーバ１２から転送されたアップデートデータを、暫定的に記憶する。
【００３３】
アップデート対象ユニット３１は、アップデートされる車載ソフトウエアやデータである複数のアップデート領域３６から構成されている。具体的には、アップデート領域３６は、第１アップデート領域３２、第２アップデート領域３３、第３アップデート領域３４および第４アップデート領域３５、を有する。ここで、車載ソフトウエアは、車載ファームウエアとも称される。また、アップデートされるデータは、例えば、ナビゲーション装置が用いる地図データである。更に、各アップデート領域３６は、アップデートデータの他にも、アップデートが完了したか否かの判断に用いられる証明書も記憶している。
【００３４】
図２を参照して、上記したアップデート対象ユニット３１の構成を詳述する。アップデート対象ユニット３１は、車両１０の各種構成機器を制御する機能が記憶されており、アプリケーション部４１と、基本ソフトウエア部４７と、を有している。
【００３５】
アプリケーション部４１は、例えば、スイッチ状態監視機能部４２、異常検出機能部４３および画像処理機能部４４と、を有する。スイッチ状態監視機能部４２は、車両１０に備えられる各スイッチが正常に動作可能な状態か否かを監視する。異常検出機能部４３は、車両１０に含まれる各種構成機器の動作状態が異常か否かを検出している。画像処理機能部４４は、車両１０に備えられたステレオカメラ等で取得された画像データを処理することで、画像に写り込んだ物体の種類や物体までの距離等を推定する。アプリケーション部４１は、車両１０が備える各種機能の中でも、車両１０の走行機能や安全対策機能には直接的には関わらない応用的な機能を発揮する。アプリケーション部４１は、本実施形態においてアップデートの対象となる。アプリケーション部４１をアップデートすることで、動作の安定化やデータの更新を行うことが出来る。
【００３６】
基本ソフトウエア部４７は、例えば、ＣＰＵ監視機能部４８、起動制御機能部４９、アップデートファーム部５０を有する。ＣＰＵ監視機能部４８は、上記した制御部１５の機能を監視する。起動制御機能部４９は、車両１０が起動された際における各種構成機器の機能を制御している。アップデートファーム部５０は、アプリケーション部４１をアップデートする機能を有し、アップデートが未完了である場合に、状況に応じてアップデートを再開する。かかる事項については後述する。基本ソフトウエア部４７は、車両１０が備える各種機能の中でも、車両１０の走行機能や安全対策機能に関わる基本的な機能を発揮する。よって、アプリケーション部４１は、本実施形態においてアップデートの対象とはならない。
【００３７】
図３のフローチャートを参照して、次に、本実施形態に係る車載用データ更新装置２０を用いて、車載用ソフトウエア等を更新する全体的方法を説明する。ここで説明する車載用データの更新作業は、例えば、車両１０を所有する乗員の自宅駐車場等で行われる。
【００３８】
先ず、ステップＳ１０では、制御部１５が、アップデートを行うための条件が成立しているか否かを判断する。具体的には、制御部１５は、車載用データ更新装置２０にバッテリから印加されている電圧の電圧値が、正常な範囲であるか否かを判断する。
【００３９】
更に、制御部１５は、サーバ１２に最新版の車載ソフト等が存在するか否かを判断する。この判断は、制御部１５が、サーバ１２に保存された車載ソフト等の証明書と、車両１０側の証明書とを照合することで行う。この証明書の照合では、例えば、ＭＡＣ（Ｍｅｓｓａｇｅ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃｏｄｅ：メッセージ認証符号）等を利用する。そして、サーバ１２に最新版の車載ソフト等が存在すれば、制御部１５は、通信網１１を経由してサーバ１２からアップデートデータをダウンロードし、そのダウンロードデータをアップデートデータ記憶部３０に保存する。このダウンロードが終了した後は、車両１０の内部でアップデート作業およびアップデート再開作業が行われる。
【００４０】
更に、制御部１５は、車両１０を所有する乗員が車載ソフトウエア等のアップデートを行うことを選択したか否かを判断する。具体的には、車両１０がエンジンを停止して停車状態となった際に、制御部１５は、車室内のディスプレイに、車載ソフトウエア等のアップデートを行うか否かの判断を促す画面を表示する。そして、乗員がタッチパネル等に対して所定の承認操作を行ったら、制御部１５は、乗員がアップデートを行うことを承認したと判断する。車載ソフトウエア等のアップデートには数十分の時間がかかり、その間は車両１０を走行させることは基本的には出来ないため、このアップデートは所有者の承認に基づいて行うのが好適である。一方、アップデートの再開に際して、乗員による承認動作は必ずしも必要とされず、制御部１５は、乗員による承認動作を省いて、自動的にアップデートを開始することもできる。
【００４１】
上記したアップデートを開始するための条件が成立したら、即ちステップＳ１０がＹＥＳの場合は、制御部１５は、ステップＳ１１に移行する。例えば、車載用データ更新装置２０に適切な電圧値の電圧が印加されており、アップデートデータ記憶部３０にアップデートデータが保存されており、乗員がアップデートを行うことを認めたら、制御部１５は、車載ソフトウエア等のアップデートを開始するための条件が成立したと見做す。一方、これらの条件が一つでも満たされなかったら、即ちステップＳ１０でＮＯの場合は、ステップＳ１１には移行しない。
【００４２】
ステップＳ１１では、制御部１５が、データを転送することでアップデートを行う。具体的には、図１（Ｂ）を参照して、制御部１５の指示に基づいて、アップデートデータ記憶部３０から、アップデート対象ユニット３１に含まれるアップデート領域３６に、アップデートデータを転送する。このようにすることで、例えば、図２に示す、アプリケーション部４１に含まれるスイッチ状態監視機能部４２等がアップデートされる。この行程では、上記した証明書を比較して、アップデートが必要とされるアップデート領域３６のみをアップデートしている。これにより、アップデートに要する時間を短縮することが出来る。
【００４３】
ステップＳ１２では、上記したアップデート行程が正常に終了したか否かを判断する。具体的には、制御部１５が、アップデートが終了したアップデート領域３６から証明書を読み出す。そして、制御部１５は、アップデート領域３６の証明書と、アップデートデータ記憶部３０の対応するアップデートデータの証明書とを照合し、両者が一致したらアップデートが完了したと判断し、両者が不一致であればアップデートが未完了で有ると判断する。
【００４４】
アップデート対象とされた全てのアップデート領域３６のアップデートが正常に完了したら、即ちステップＳ１２でＹＥＳの場合は、制御部１５は、車載ソフトウエア等のデータ更新作業を終了する。一方、アップデート対象とされたアップデート領域３６のうち、アップデートが未完了であるアップデート領域３６が一つでも存在したら、即ちステップＳ１２でＮＯの場合は、制御部１５は、アップデートの再開を試みるステップＳ１３以降のステップに移行する。
【００４５】
ステップＳ１３では、制御部１５が、アップデートが未完了となった失敗理由を読み取る。アップデートが未完了となった各アップデート領域３６には、アップデートが未完成であった理由が保存されている。アップデートが未完成であった理由としては、例えば、アップデートデータの転送中にエンジンが始動された（例えば、エンジンの始動に伴う電源状態が変化した）こと、バッテリから印加される電圧の電圧値が低下したこと、外部からの電波の影響等によりアップデート対象ユニット３１に転送されたアップデートデータが不正規のものであったこと、等である。
【００４６】
ステップＳ１４では、制御部１５が、アップデートの再開を可能とする条件が成立しているか否かを判断する。制御部１５は、アップデートを再開するための条件が成立したら、即ちステップＳ１４でＹＥＳの場合は、アップデートを再開するためにステップＳ１５に移行する。一方、制御部１５は、アップデートを再開するための条件が成立しなかったら、即ちステップＳ１４でＮＯの場合は、失敗理由を読み取るステップＳ１３に戻り、アップデートの再開を待つ。ステップＳ１４の詳細は、図４を参照して後述する。
【００４７】
ステップＳ１５では、証明書を読み出す。詳しくは、制御部１５は、図１（Ｂ）を参照して、アップデート領域３６の証明書と、アップデートデータ記憶部３０の対応するアップデートデータの証明書とを照合することで、アップデートが未完了であるアップデート領域３６を特定する。
【００４８】
ステップＳ１６では、アップデートが未完了とされているアップデート領域３６に対して、再度のアップデートを試みる。図１（Ｂ）を参照して、例えば、第１アップデート領域３２および第２アップデート領域３３のアップデートが正常に完了しており、第３アップデート領域３４および第４アップデート領域３５のアップデートが未完了であるとする。この場合、制御部１５は、第３アップデート領域３４および第４アップデート領域３５に対してのみアップデートの再開を試み、第１アップデート領域３２および第２アップデート領域３３に対してはアップデートの再開は行わない。このようにすることで、アップデートの再開に要する電力および時間を節約することが出来る。
【００４９】
ここで、ステップＳ１６に於いて、制御部１５は、アップデートを再開する旨を車両１０のディスプレイに表示し、乗員が再開を承認する操作を行ったら、アップデートを再開するようにしても良い。
【００５０】
ステップＳ１７では、制御部１５は、上記した再度のアップデートが正常に終了したか否かを判断する。このステップに於いても、制御部１５は、アップデートが正常に終了したか否かの判断を、上記と同様に各アップデート領域３６が有する証明書を用いて行っている。
【００５１】
再度のアップデートが正常に終了したら、即ちステップＳ１７でＹＥＳの場合は、制御部１５は、アップデート作業を終了する。この場合、アップデート作業が正常に終了した旨を、車両１０のディスプレイに表示しても良い。一方、アップデートが正常に終了しなかったら、即ちステップＳ１７でＮＯの場合は、制御部１５は、再度のアップデートを行うために、ステップＳ１３に戻る。
【００５２】
以上の行程を経て、本実施の形態に係る車載用データ更新装置２０による再アップデートが終了する。
【００５３】
図４のフローチャートを参照して、次に、上記したステップＳ１４に於ける再開条件を判定する方法を詳述する。
【００５４】
まず、ステップＳ２０では、制御部１５は、アップデートが未完了となった理由が、バッテリから印加された電圧の低下が原因だったか否かを判断する。アップデートが未完了となった理由は、各アップデート領域３６に記憶されている。未完了の原因が電圧の低下であれば、即ちステップＳ２０でＹＥＳの場合は、制御部１５は、ステップＳ２１でバッテリの電圧が復旧するのを待つ。一方、未完了の原因が電圧の低下でなければ、即ちステップＳ２０でＮＯの場合は、アップデートが未完了となったのは他の原因にあるので、ステップＳ２３に移行する。
【００５５】
ステップＳ２１では、制御部１５は、バッテリの電圧が所定の範囲になるまで復旧するのを待つ。即ち、車両１０が走行することで発電された電力でバッテリを充電し、バッテリの電圧を所定の電圧値以上に回復させる。
【００５６】
ステップＳ２２では、バッテリの電圧値が回復した後に、アップデートが未完了であったアップデート領域３６に対して、再度のアップデートを行う。即ち、再開を判定するこのフローは終了し、図３に示したステップＳ１５に移行し、再度のアップデートを行う。
【００５７】
ここで、未完了の原因がバッテリの電圧の低下である場合は、原因が他の要因であった場合と比較して、再度のアップデートを試みる回数を多くしても良い。例えば、回数の制限無く再度のアップデートを行っても良い。このようにすることで、再度のアップデートに成功する可能性を向上できる。
【００５８】
ステップＳ２３では、制御部１５は、不正規のアップデートデータをアップデートしたか否かを判断する。具体的には、制御部１５は、未完了と判断されているアップデート領域３６の証明書と、アップデートデータ記憶部３０の対応するアップデートデータの証明書とを照合する。そして、制御部１５は、両者が不一致であれば、不正規アップデートデータをアップデートしたと判断し、即ちステップＳ２３でＹＥＳと判断し、ステップＳ２４に移行する。一方、制御部１５は、両者が一致すれば、不正規アップデートデータをアップデートしたことが未完了の原因ではないと判断し、即ちステップＳ２３でＮＯと判断し、後述するステップＳ２７に移行する。ここで、不正規のアップデートデータをアップデートする原因としては、外部から与えられている電波等が挙げられる。
【００５９】
ステップＳ２４では、図１（Ｂ）に示したアップデートデータ記憶部３０に、正規のアップデートデータが転送されているか否かを検出する。本ステップの判断も、上記と同様に証明書を照合することで行う。アップデートデータ記憶部３０に正規のアップデートデータが転送されていることを確認したら、制御部１５は、ステップＳ２５に移行する。
【００６０】
ステップＳ２５では、再度のアップデートを試みる回数が上限回数によりも多いか否かを判断する。ここでは、アップデートの上限回数を例えば１回としている。アップデートが未完了であった理由が、不正規アップデートデータのアップデートであった場合、再度のアップデートを多数回行っても、アップデートが正しく完了する可能性が低い。従って、この場合に上限回数を少なくすることで、再度のアップデートで不必要に多くの時間や電力が消費されることを抑制できる。
【００６１】
制御部１５は、再度のアップデートを試みる回数が上限回数である１回よりも多ければ、即ちステップＳ２５でＹＥＳの場合は、アップデートを再開するフローを終了し、本実施形態に於けるアップデートの再開を中止する。そして、乗員は車両１０を整備工場等に持ち込み、そこでアップデートを再開することになる。この場合は、車両１０のディスプレイに、アップデートの完了が出来ない旨を表示しても良い。
【００６２】
一方、制御部１５は、再度のアップデートを試みる回数が上限回数である１回以下であれば、即ちステップＳ２５でＮＯの場合は、ステップＳ２６で再度のアップデートを行う。即ち、図３に示すステップＳ１５に移行する。
【００６３】
ここで、外部から与えられている電波等により上記の不正規アップデートデータが行われた場合は、制御部１５は、この電波等の影響が無くなったことを確認してから、ステップＳ２６で再度のアップデートを行うようにしても良い。
【００６４】
ステップＳ２７では、アップデートが未完了となった理由が、アップデートデータを書き込み中にエンジンが始動されたことによるものか否かを判断する。未完了の理由がエンジンの始動であった場合は、即ちステップＳ２７でＹＥＳの場合は、制御部１５は、ステップＳ２８で次回のエンジン停止を待つ。一方、未完了の理由がエンジンの始動でなかった場合は、即ちステップＳ２７でＮＯの場合は、制御部１５は、ステップＳ３１に移行する。
【００６５】
ステップＳ２８で次回のエンジン停止が行われたら、制御部１５は、ステップＳ２９では、再度のアップデートを試みる回数が上限回数によりも多いか否かを判断する。ここでは、アップデートの上限回数を例えば２回としている。再度のアップデートを試みる回数が３回以上となった場合、乗員はエンジン停止によるアップデートの失敗を繰り返す恐れがあるので、上限回数をこのようにしている。
【００６６】
制御部１５は、再度のアップデートを試みる回数が上限回数である２回よりも多ければ、即ちステップＳ２９でＹＥＳの場合は、アップデートを再開するフローを終了し、本実施形態に於けるアップデートの再開は終了する。一方、制御部１５は、再度のアップデートを試みる回数が上限回数である２回以下であれば、即ちステップＳ２９でＮＯの場合は、ステップＳ３０で再度のアップデートを行う。即ち、図３に示すステップＳ１５に移行する。
【００６７】
ステップＳ３１にて、アップデートが未完了となった理由が、その他の理由であれば、ステップＳ３２に移行する。その他の理由とは、例えば半導体チップである制御部１５や記憶部１４の誤動作等である。
【００６８】
ステップＳ３２では、制御部１５は、再度のアップデートを試みる回数が上限回数によりも多いか否かを判断する。ここでは、アップデートの上限回数を例えば１回としている。
【００６９】
制御部１５は、再度のアップデートを試みる回数が上限回数である１回よりも多ければ、即ちステップＳ３２でＹＥＳの場合は、制御部１５は、アップデートを再開するフローを終了する。一方、制御部１５は、再度のアップデートを試みる回数が上限回数である１回以下であれば、即ちステップＳ３２でＮＯの場合は、ステップＳ３３で再度のアップデートを行う。即ち、図３に示すステップＳ１５に移行する。
【００７０】
上記したように、本実施の形態に係る車載用データ更新装置２０では、車載ソフトウエア等のアップデートが未完了であった場合、乗員が整備工場に車両１０を持ち込まなくても、車載用データ更新装置２０自体が再度のアップデートを行っている。従って、アップデートが未完了であった際に、アップデートを再開する為に乗員が車両１０を整備工場等に持ち込む手間を少なくすることが出来る。
【００７１】
また、車載用データ更新装置２０では、上記アップデートが未完了であった場合に、全てのアップデート領域３６に対して再度のアップデートを行うのでは無く、アップデートが未完了であったアップデート領域３６のみに対して再度のアップデートを行う。よって、再度のアップデートに要する時間を短縮すると共に、再度のアップデートの際に失敗が生じることを抑止できる。再度のアップデートが終了するまでは基本的には車両１０を運転できないため、再度のアップデートを短縮することで、車両１０を運転できない時間を短縮することが出来る。
【００７２】
以上、本発明の実施形態を示したが、本発明は、上記実施形態に限定されるものではない。
【符号の説明】
【００７３】
１０   車両
１１   通信網
１２   サーバ
１３   通信部
１４   記憶部
１５   制御部
２０   車載用データ更新装置
３０   アップデートデータ記憶部
３１   アップデート対象ユニット
３２   第１アップデート領域
３３   第２アップデート領域
３４   第３アップデート領域
３５   第４アップデート領域
３６   アップデート領域
４１   アプリケーション部
４２   スイッチ状態監視機能部
４３   異常検出機能部
４４   画像処理機能部
４７   基本ソフトウエア部
４８   ＣＰＵ監視機能部
４９   起動制御機能部
５０   アップデートファーム部
【図１】
2018097764.tif 000003
【図２】
2018097764.tif 000004
【図３】
2018097764.tif 000005
【図４】
2018097764.tif 000006