JP6344036B2 - 車両用情報処理装置 - Google Patents

Description

本発明は、車両においてリモートでリプログラミングが実行されることを支援する車両用情報処理装置に関する。

たとえば特許文献１には、車両内の制御装置によって実行されるプログラムを更新するための更新用データを管理センターから車両に送信することが提案されている。詳しくは、管理センターから送信された更新用データは、車両内の受信装置によって受信され、車両内のネットワークを介して更新対象のプログラムを所持する制御装置に送信される。

特開２０１２−１７８０３５号公報

ところで、上記車両において更新用データを受信する受信機能に異常がある場合や、車両内の電源電圧が低下する場合などには、プログラムを更新する処理に異常が生じる可能性がある。そして、異常が生じた場合に、管理センターにおいて異常が生じたことを検出できない場合には、異常に対処することができず、車両の走行などに影響が生じるおそれがある。

本発明は、そうした実情に鑑みてなされたものであり、その目的は、車両においてリモートでリプログラミングがなされる際に異常が生じた場合に、これを把握することのできる車両用情報処理装置を提供することにある。

以下、上記課題を解決するための手段およびその作用効果について記載する。
技術的思想１：車載制御装置によって実行されるプログラムを更新する更新用データを前記車載制御装置を搭載する車両に送信する送信処理部と、前記更新用データの送信に伴って前記車両において前記更新用データに基づきリプログラミングを完了するまでに実行される各処理に要する予測時間と、前記車両における前記各処理の開始からの経過時間との比較に基づき、前記各処理が正常に行われているか否かを判断する判断処理部と、を備える車両用情報処理装置。

上記装置では、車両においてリプログラミングのための各処理が実行されるに際し、それら各処理の開始からの継続時間と、各処理に要する予測時間とが比較される。ここで、継続時間が予測時間を上回る場合には、その処理が正常に実行されることなく異常な事態に陥っている可能性が高い。そこで、上記装置では、比較に基づき、各処理が正常に行われているか否かを判断する。このため、正常になされていない処理がある場合には、これを把握することが可能となる。

技術的思想２：前記車両は、前記各処理のそれぞれが完了する毎に、該処理が完了した旨の信号を送信するものであり、前記判断処理部は、前記完了した旨の信号を受信するまでの時間が前記予測時間を所定以上超過している場合に異常と判断する技術的思想１記載の車両用情報処理装置。

上記装置では、車両が各処理を完了する毎に、処理が完了した旨の信号を受信することができる。そして、処理が完了した旨を受信した後、次の処理が完了した旨の信号を受信するまでの時間が予測時間を所定以上超過している場合に異常と判断することで、異常の有無を迅速に判断することができる。

車両用情報処理装置の一実施形態にかかるシステム構成図。 同実施形態にかかるステータスの更新処理の手順を示す流れ図。 同実施形態にかかる救済処理の手順を示す流れ図。

以下、本実施形態にかかる車両用情報処理装置の一実施形態について、図面を参照しつつ説明する。
図１に、本実施形態にかかるシステム構成を示す。図１には、２台の車両１０がセンター２０と通信可能とされていることが記載されている。また、２台の車両１０のうちの１台については、その内部の構成の一部がブロック図によって示されている一方、もう１台については、ブロック図を省略している。ただし、センター２０と通信可能とされる車両１０はいずれも、ブロック図を示した１台の車両１０と同様の機能を有するものであり、また、センター２０と通信可能とされる車両１０の数は実際には、２台に限定されない。

図１に示されるように、車両１０は、車両側処理装置１２を備えている。車両側処理装置１２は、車両１０内に搭載される電子制御装置（ＥＣＵ）１４が所持するプログラムを更新する処理を実行するものである。詳しくは、ＥＣＵ１４は、中央処理装置（ＣＰＵ）１６と、メモリ１８とを備えており、ＣＰＵ１６は、メモリ１８内に記憶されたプログラム１８ａを実行する。そして、プログラム１８ａを更新する必要が生じることでセンター２０から車両１０に更新用のプログラムが送信されると、車両側処理装置１２は、メモリ１８内のプログラム１８ａを更新用プログラムに書き換える処理を実行する。なお、プログラム１８ａを更新する必要は、プログラム１８ａのバージョンアップや、プログラム１８ａの修正が必要となるときなどに生じるものである。

車両側処理装置１２は、通信機能Ｍ１０と、車両ステータス管理機能Ｍ１２と、車両ステータスＭ１４と、リプロ機能Ｍ１６と、情報収集機能Ｍ１８とを備えている。ここで、通信機能Ｍ１０は、センター２０と無線通信する機能であり、センター２０にステータス情報３０を送信する機能などを有する。車両ステータス管理機能Ｍ１２は、車両１０内で実施中の処理のステータスを管理する機能である。ここで、ステータスとは、処理の状態を特定する情報である。たとえば、メモリ１８内に記憶されたプログラム１８ａを更新するリプログラミング処理を例にとると、この処理は、複数の段階としてのフェーズに分割され、さらにフェーズは、シーケンスに分割される。ステータスは、特定のシーケンスの処理が実行されているか否か等を特定する情報を含む。

たとえば、リプログラミング処理の場合、センター２０から更新用データを受信するフェーズと、受信したデータをチェックするフェーズと、ＥＣＵ１４に送信するフェーズと、ＥＣＵ１４においてプログラム１８ａを書き換えリブートするフェーズと、の各フェーズの処理に分割できる。そして、たとえばデータをチェックするフェーズは、データを解凍するシーケンス、復号化するシーケンス、および正当性をチェックするシーケンスを含む。ここで、正当性のチェックとしては、誤り検出や誤り訂正処理のことである。誤り検出としては、たとえば巡回冗長検査（ＣＲＣ）を採用することができる。またたとえば、送信するフェーズは、データを圧縮するシーケンス、暗号化するシーケンス、および車内のローカル通信経路を介してデータを実際に送信するシーケンス等を含む。

車両ステータスＭ１４は、車両１０において実行中の処理（シーケンス）のステータス情報を含むデータである。この情報には、実行中のシーケンスを特定する情報と、正常に実行されているか否か等、実行の状態を示す情報と、それらの情報が更新された日時を示す情報を含む。

リプロ機能Ｍ１６は、センター２０から送信された更新用データを用いてＥＣＵ１４のメモリ１８内に記憶されているプログラム１８ａを書き換える処理、すなわち上記リプログラミング処理を実行する機能である。

情報収集機能Ｍ１８は、車両１０内において授受される情報を収集し、センター２０に送信する機能である。ここで授受される情報には、たとえば車両１０内においてＥＣＵ１４が制御する際に生成される情報が含まれる。詳しくは、センター２０から送信された収集条件に従ったデータを選択的に収集し、これをセンター２０に送信する。

一方、センター２０は、通信機能Ｍ２０と、車両ステータスリストＭ２２と、通信履歴リストＭ２４と、通常処理時間リストＭ２６と、救済方法リストＭ２８と、車両ステータス管理機能Ｍ３０とを備える。

ここで、通信機能Ｍ２０は、車両１０との無線通信を実現する機能である。車両ステータスリストＭ２２は、センター２０と通信可能な車両１０において実行されている処理のステータスのリストである。リストには、車両１０を特定するＩＤや、車両情報、車両のオーナ情報、車両１０内において実行中の処理とそのステータス情報、ステータス情報を更新した日時、車両１０の位置情報が含まれる。なお、リストには、最新のステータス情報のみならず、ステータス情報の履歴が含まれる。

通信履歴リストＭ２４は、センター２０と通信可能な車両１０とセンター２０とが通信した際の通信履歴のリストである。リストには、車両ＩＤや、最終通信日、通信内容、通信時の車両１０の位置情報が含まれる。なお、リストは、車両１０との通信がなされる都度、更新される。

通常処理時間リストＭ２６は、車両１０が実施する処理に要する正常時の時間（通常処理時間）のリストである。ここで通常処理時間は、センター２０からの信号の送信によってなされるリプログラミング処理等における各フェーズのそれぞれについて設定されている。すなわちたとえば、センター２０から更新用データが送信されることで車両１０内で行われるリプログラミング処理については、上述した各フェーズの処理に関する時間が設定されている。なお、通常処理時間は、車両１０に搭載される車両側処理装置１２の仕様毎に各々独立に設定される。

救済方法リストＭ２８は、車両１０が異常状態になった際になすべき救済処理のリストである。リストには、異常状態の種類と、実施中の処理毎の救済処理とが含まれる。ここで、異常状態が、車両１０の走行に影響を及ぼすことを意味するものである場合には、救済処理としては、たとえばセンター２０から最寄りのディーラへ連絡する処理が考えられる。また、特定のフェーズの特定のシーケンスの処理に異常が生じることで、その処理の実行で待機することとなっている場合には、その処理を強制的に終了する指令をセンター２０から車両１０に送信する処理が考えられる。また、たとえば、リプログラミング処理のうちリブートのシーケンスに異常が生じている場合には、センター２０から車両１０にリブート指令を送信する処理が考えられる。

車両ステータス管理機能Ｍ３０は、センター２０側で、車両１０内で実行される処理のステータスを管理する機能である。すなわち、車両１０の通信機能Ｍ１０によって、ステータス情報３０が送信されることで、センター２０の通信機能Ｍ２０ではこれを受信する。そして、受信されたステータス情報３０に基づき、車両ステータスリストＭ２２を更新する。そして、車両ステータスリストＭ２２と、通常処理時間リストＭ２６と、通信履歴リストＭ２４とに基づき、車両１０内で実行されている処理の異常の有無を判定し、異常が生じていると判定する場合、救済方法リストＭ２８に従って救済のための処理を実行する。

図２に、本実施形態にかかるステータスの更新処理の手順を示す。この処理は、所定の実行条件で、車両１０およびセンター２０によって実行される。
この一連の処理において、車両１０内の車両ステータス管理機能Ｍ１２は、まず、ステータス変更通知がなされたか否かを判断する（Ｓ１０）。ここでは、リプロ機能Ｍ１６や、情報収集機能Ｍ１８が、１つのシーケンスの処理を完了し、次のシーケンスの処理に移行する都度、車両ステータス管理機能Ｍ１２に、ステータスを変更する通知がなされることを想定している。車両ステータス管理機能Ｍ１２は、ステータス変更通知がなされたと判断する場合（Ｓ１０：ＹＥＳ）、車両ステータスＭ１４を更新する（Ｓ１２）。次に、車両ステータス管理機能Ｍ１２は、更新された車両ステータスＭ１４を、ステータス情報３０として、通信機能Ｍ１０を用いてセンター２０に送信する（Ｓ１４）。なお、車両ステータスＭ１４の更新タイミングにおいて、何らかの理由で通信機能Ｍ１０がステータス情報３０を送信できないことも考えられる。この場合、通信が可能となったタイミングで、最新のステータスのみならず、未送信のステータスをも送信する。

これにより、センター２０の通信機能Ｍ２０では、ステータス情報３０を受信する（Ｓ１６）。そして、通信機能Ｍ２０は、車両ＩＤや、最終通信日、通信内容、通信時の車両１０の位置情報を通信履歴リストＭ２４に保存する（Ｓ１８）。ここで、通信内容には、受信した情報がステータス情報である旨の情報が含まれる。また、車両ステータス管理機能Ｍ３０は、通信機能Ｍ２０によって受信されたステータス情報に基づき、車両ステータスリストＭ２２を更新する（Ｓ２０）。

なお、車両１０側では、ステップＳ１０において否定判断する場合や、ステップＳ１４の処理が完了することで、この一連の処理を一旦終了する。これに対し、センター２０側では、ステップＳ２０の処理が完了することで、この一連の処理を一旦終了する。

図３に、車両１０において異常が生じた場合の救済処理の手順を示す。この処理は、車両ステータス管理機能Ｍ３０によって、たとえば所定周期で繰り返し実行される。
この一連の処理において、車両ステータス管理機能Ｍ３０は、まず、車両ステータスリストＭ２２に基づき、車両１０内で行われるフェーズの処理のうち、未だ正常に処理が完了したか否かの判定がなされていない処理に関するステータス情報を取得する（Ｓ３０）。たとえば、車両１０内において車両ステータスＭ１４が更新される都度、センター２０にステータス情報３０が送信されている状況においては、この処理は、最新のステータス情報を取得する処理となる。ただし、車両１０内において車両ステータスＭ１４が更新されたタイミングにおいて、車両１０がステータス情報３０を送信することができず、さらに車両ステータスＭ１４が更新されたときに最新のステータス情報３０と未送信のステータス情報３０とを送信する場合には、事情が相違する。この場合、ステップＳ３０の処理においては、最新のステータス情報に加えて、未送信であったステータス情報が取得され、ステップＳ３２以降の処理の対象とされる。

ステップＳ３０の処理は、車両１０内において実行される処理のうち、特定のフェーズ内の処理が正常に実行されているか否かを判定するために、判定対象とする処理を特定するための処理となる。すなわち、ステータス情報によってシーケンスが特定されると、そのシーケンスを含むフェーズの処理が、判定対象とされる。

車両ステータス管理機能Ｍ３０は、ステータス情報を取得すると、通常処理時間リストＭ２６のなかから、このステータス情報に対応する処理の通常処理時間を取得する（Ｓ３２）。次に、車両ステータス管理機能Ｍ３０は、通信履歴リストＭ２４の中から、ステップＳ３０の処理によって特定されたフェーズの処理の開始時刻以降における車両１０とセンター２０との通信履歴を取得する（Ｓ３４）。

次に、車両ステータス管理機能Ｍ３０は、通信履歴に基づき、特定されたフェーズの処理の開始時刻以降において車両１０内において車両側処理装置１２が稼働している時間である車両稼働時間を算出する（Ｓ３６）。ここで、車両１０内の電源をオフすることで車両側処理装置１２を停止する場合には、これに先立って、その旨をセンター２０に通知し、電源をオンする際にも、その旨をセンター２０に通知することとする。これにより、通信履歴リストＭ２４の通信内容に、車両１０内における車両側処理装置１２の電源オフ、電源オンの情報が加わるため、車両稼働時間を精度よく算出することが可能となる。なお、たとえば、車両側処理装置１２の動作期間が、車両１０の走行許可スイッチ（ＩＧスイッチ）がオン状態となる期間であるなら、電源のオンオフ情報を、ＩＧスイッチのオンオフ情報としてもよい。また、たとえば、車両側処理装置１２の動作期間が、車両１０のアクセサリスイッチがオン状態となる期間であるなら、電源のオンオフ情報を、アクセサリスイッチのオンオフ情報としてもよい。ただし、リプログラミング処理等の途中でＩＧスイッチやアクセサリスイッチがオフ操作されても同処理を継続する設定の場合、車両側処理装置１２の電源がオフとなる旨の情報は、ＩＧスイッチやアクセサリスイッチのオフ操作とは相違する情報となる。この場合には、車両側処理装置１２の電源をオフする処理がなされる場合に、その旨を通知すればよい。

そして、車両ステータス管理機能Ｍ３０は、車両稼働時間が、通常処理時間を所定値α以上超過したか否かを判定する（Ｓ３８）。この処理は、ステップＳ３０の処理によって特定されたフェーズの処理に異常が生じたか否かを判定するためのものである。ここで、所定値αは、異常を判定するために設定される値である。すなわち、通常処理時間は、正常時に想定される時間であるものの、正常に処理がなされているとしても、これをわずかに超える事態が生じることは十分に考えられる。このため、所定値αを用いることで、異常を判定する。

車両ステータス管理機能Ｍ３０は、所定値α以上超過していると判定する場合（Ｓ３８）、異常が生じたとして、救済方法リストＭ２８に基づき、救済措置を施す（Ｓ４０）。ここで、車両ステータス管理機能Ｍ３０は、異常が生じたフェーズや、フェーズ内のシーケンスに応じて、救済措置を選択する。

そして車両ステータス管理機能Ｍ３０は、救済措置に応じて、車両ステータスリストＭ２２を更新する（Ｓ４２）。これは、救済措置が施されることで、車両１０内の処理のステータスが変更されることに鑑みたものである。

なお、車両ステータス管理機能Ｍ３０は、ステップＳ４２の処理が完了する場合や、ステップＳ３８において否定判断する場合には、この一連の処理を一旦終了する。
次に、以上の処理の作用を、車両１０内においてリプログラミング処理に異常が生じる場合を例として説明する。

センター２０から、ＥＣＵ１４のメモリ１８内のプログラム１８ａを書き換えるための更新用データが送信されると、車両１０において、更新用データを用いたリプログラミング処理が実行される。これにより、リプログラミング処理を細分したシーケンス処理がなされる毎に、そのステータス情報が車両１０からセンター２０に送信され、センター２０で管理される。そして、センター２０では、リプログラミング処理を各段階に分割したフェーズ処理が、通常処理時間を所定値α以上超過することで、そのフェーズに異常が生じたと判定する。そして、センター２０は、異常が生じたフェーズのみならず、そのうちのどのシーケンスにおいて異常が生じたか等を適宜検討の上、救済措置を施す。

以上説明した本実施形態によれば、以下に記載する効果が得られるようになる。
（１）センター２０から車両１０への信号の送信をトリガとして車両１０内において実行される処理（リプログラミング処理等）を各段階に分割した処理（フェーズ処理）に要する時間が、通常処理時間を所定値α以上超過することで、異常が生じていると判定した。これにより、車両１０で異常が生じた事態をセンター２０において把握することが可能となる。これに対し、車両１０から異常が発生した旨を通知する構成とする場合、車両１０から異常の発生をセンター２０に通知できない場合や、異常の検知自体ができない場合には、センター２０において車両１０で異常が生じたことを把握することができない。

（２）車両側処理装置１２の電源のオン、オフを加味して車両１０内において処理がなされている時間（車両稼働時間）を算出した。これにより、車両稼働時間を高精度に算出することができる。

（３）フェーズに要する時間が通常処理時間を所定値α以上超過するか否かを判断することで、リプログラミングの処理の完了までの予測時間とリプログラミングの開始からの継続時間とを比較する場合と比べて、異常を迅速に判断することができ、ひいては異常に迅速に対処することが可能となる。

（４）センター２０において、各フェーズのステータス情報のみならず、フェーズ内の各シーケンスの処理のステータス情報についてもこれを管理した。これにより、センター２０において、車両１０内で実施されている処理のフェーズのみならず、シーケンスについても把握することができる。

＜技術的思想と実施形態との対応＞
以下、上記「課題を解決するための手段」に記載された技術的思想と、実施形態との代表的な対応関係を記載する。

［技術的思想１：車両用情報処理装置…２０、車載制御装置…１４、プログラム…１８ａ、送信処理部…Ｍ２０、予測時間…通常処理時間、判断処理部…Ｓ３８］［技術的思想２：「処理が完了した旨の信号を送信する」…Ｓ１４］
＜その他の実施形態＞
なお、上記実施形態は、以下のように変更して実施してもよい。

・「予測時間について」
上記実施形態では、車種毎に、各処理に要する標準時間（通常処理時間）を記録した通常処理時間リストＭ２６に基づき、該当する車種の通常処理時間を予測時間としたが、これに限らない。たとえば、車両１０から、車両側処理装置１２やＣＰＵ１６の動作周波数に関する情報を取得することとする一方、通常処理時間リストＭ２６を、情報処理装置やＣＰＵの動作周波数毎に通常処理時間を記録したリストとし、該当する動作周波数の通常処理時間を予測時間としてもよい。

また、たとえば通常処理時間に代えて、予測される時間（標準時間）を所定以上超過する時間（通常処理時間＋α）を記憶するようにしてもよい。この時間は、予測される時間を踏まえたものであり、予測される時間に関する情報を含んでいる。

また、センター２０が予め予測時間のリスト（通常処理時間リストＭ２６）を記憶するものに限らない。たとえば、センター２０が、車両１０から送信された車両１０を特定する情報に基づき、車両１０が処理を完了するのに要する時間情報（通常処理時間）をネットワークを介して取得するようにしてもよい。

さらに、予測時間の算出対象となる処理としては、フェーズに限らず、たとえば各フェーズ内のシーケンスであってもよい。
・「経過時間について」
上記実施形態では、通信履歴に基づき、特定のフェーズの処理が開始されたタイミングからの経過時間であって、電源が停止される時間を除いた時間を特定のフェーズの処理の継続時間としたがこれに限らない。たとえば、リプログラミング処理がなされる期間においては、通常、リプログラミング処理を実行する電子機器に対する電源はオンとなっていると考えられることから、特定のフェーズの処理が開始されたタイミングからの経過時間としてもよい。

・「ステータス情報の送信タイミングについて」
上記実施形態では、各シーケンスの完了タイミングにおいて、車両１０からステータス情報を送信するようにしたが、これに限らない。たとえば、センター２０から車両１０にステータス情報を送信するように要求をすることが可能とし、車両１０側では、各シーケンスの完了タイミングと、センター２０からの要求を受信したタイミングとの双方においてステータス情報を送信するようにしてもよい。なお、センター２０では、要求に応じて送信されたステータス情報については、これを車両ステータスリストＭ２２に加えないことが望ましい。これにより、たとえば、車両１０から自発的に送信されるステータス情報と、要求に応じて車両１０から送信されるステータス情報との時系列が、実際のシーケンスに応じたステータス情報と矛盾することに起因して、車両ステータスリストＭ２２内のステータス情報に矛盾が生じる事態を回避することが可能となる。またたとえば、車両１０から自発的に送信されるステータス情報と、要求に応じて車両１０から送信されるステータス情報とが重複することに起因して、車両ステータスリストＭ２２内のステータス情報が重複する事態が生じることを回避することが可能となる。

・「そのほか」
上記実施形態では、リプログラミング処理に異常が生じるか否かをセンター２０で管理することを例にとって説明したが、これに限らない。たとえば、センター２０から情報の収集条件に関する信号が送信されることをトリガとして車両１０内の情報収集機能Ｍ１８によってなされる情報収集処理について、その異常を管理してもよい。この場合であっても、情報収集処理を、複数のフェーズに分割し、各フェーズに要する時間である通常処理時間を通常処理時間リストＭ２６に記憶しておくことで、上記実施形態に例示した要領で、異常の有無を管理することができる。

上記実施形態では、リプロ機能Ｍ１６を、ＥＣＵ１４とは別の車両側処理装置１２内に搭載することとしたが、これに限らず、機能の一部をＥＣＵ１４に持たせてもよい。

Ｍ１０…通信機能、Ｍ１２…車両ステータス管理機能、Ｍ１４…車両ステータス、Ｍ１６…リプロ機能、Ｍ１８…情報収集機能、Ｍ２０…通信機能、Ｍ２２…車両ステータスリスト、Ｍ２４…通信履歴リスト、Ｍ２６…処理時間リスト、Ｍ２８…救済方法リスト、Ｍ３０…車両ステータス管理機能、１０…車両、１２…車両側処理装置、１４…ＥＣＵ、１６…ＣＰＵ、１８…メモリ、１８ａ…プログラム、２０…センター、３０…ステータス情報。

Claims (1)

1. 車載制御装置によって実行されるプログラムを更新する更新用データを前記車載制御装置を搭載する車両に送信する送信処理部と、
   前記更新用データの送信に伴って前記車両において前記更新用データに基づきリプログラミングを完了するまでに実行される各処理に要する予測時間と、前記車両における前記各処理の開始からの経過時間との比較に基づき、前記各処理が正常に行われているか否かを判断する判断処理部と、を備え、
   前記車両は、前記各処理のそれぞれが完了する毎に、該処理が完了した旨の信号を送信するものであり、
   前記判断処理部は、前記完了した旨の信号を受信するまでの時間が前記予測時間を所定以上超過している場合に異常と判断するものであり、
   前記判断処理部によって異常と判断される場合、異常状態の種類と実施中の処理毎の救済処理とが含まれる救済方法リストから選択した救済措置を実行する車両用情報処理装置。