JP5891917B2 - 通信復旧支援装置、および通信復旧支援用インターフェース - Google Patents

Description

本発明は、車両の外部との電力の授受を行なう車載電力授受システムと外部電源装置との間に通信不良が生じる場合に通信の復旧を支援する通信復旧支援装置、および通信復旧支援用インターフェースに関する。

たとえば下記特許文献１には、監視対象となる機器に記憶されたソフトウェアのバージョン情報を管理データベースに記憶しておき、新規プログラムが作成される都度、管理データベースを参照して、プログラムの更新が必要な機器を特定する遠隔保守システムも提案されている。

特開２００２−１８９５９９号公報

ところで、充電スタンドにおいて車載バッテリの充電がなされる際には、充電スタンドと車両側との間で通信がなされる。この通信は、車両、充電スタンドの双方に搭載されたハードウェアによって、通信用のソフトウェアが実行されることで実現される。このシステムにおいて、上記遠隔保守システムを用いて、たとえば充電スタンド側のソフトウェアを都度更新したとしても、車両との通信が成立するとは限らないことが発明者らによって見出されている。

本発明は、上記課題を解決する過程でなされたものであり、その目的は、車両の外部との電力の授受を行なう車載電力授受システムと外部電源装置との間に通信不良が生じる場合に通信の復旧を支援する新たな通信復旧支援装置、および通信復旧支援用インターフェースを提供することにある。

以下、上記課題を解決するための手段、およびその作用効果について記載する。

第１の発明は、車両の外部との電力の授受を行なう車載電力授受システム（１０，１２，１４，１６）と外部電源装置（２０，２２，２４，２６）との間に通信不良が生じる場合、前記通信不良が生じている車載電力授受システムおよび該システムが搭載される車両の少なくとも一方を特定する情報である車両側情報、および前記通信不良が生じている外部電源装置を特定する情報である電源側情報の少なくとも一方と、前記車載電力授受システムと前記外部電源装置との間に生じた通信の不具合を特定するための情報とを入力とし、データベースに基づき、前記通信不良の対処手段を選択する選択手段（Ｓ３８，Ｓ５２）を備え、前記データベースは、前記通信不良への対処手段を、該通信不良が生じた前記車両側情報に関する１または複数の項目と、該通信不良が生じた前記電源側情報に関する１または複数の項目との少なくとも一方と、前記不具合を特定するための情報との双方に関連付けるものであり、前記選択手段は、前記入力された情報と、前記データベース内の前記対処手段に関連付けられた前記情報とを照合する照合手段（Ｓ３６，Ｓ８４）を備え、該照合の結果に基づき、前記選択を行なうことを特徴とする。

上記発明では、照合の結果に基づき対処手段を選択するため、通信不良が生じた状況に応じた各別の対処が可能となる。このため、バージョンアップ等の一律の対処と比較して、不具合を解消できる可能性を向上させることができる。

なお、本発明にかかる以下の代表的な実施形態に関する概念の拡張については、代表的な実施形態の後の「その他の実施形態」の欄に記載してある。

第１の実施形態にかかるシステム構成図。 同実施形態にかかる充電スタンドによる不具合の通知処理の手順を示す流れ図。 同実施形態にかかるサーバによる復旧処理の手順を示す流れ図。 同実施形態にかかる充電スタンドによる復旧処理の手順を示す流れ図。 同実施形態にかかるサーバによる対処可能パッチの推定処理の手順を示す流れ図。 第２の実施形態にかかるサーバによる不具合の対処処理の手順を示す流れ図。 同実施形態にかかるサーバによる対処可能パッチの推定処理の手順を示す流れ図。 第３の実施形態にかかる充電スタンドによるパッチの試行処理の手順を示す流れ図。 同実施形態にかかるサーバによるパッチの試行処理の手順を示す流れ図。 第４の実施形態にかかるサーバによる情報公開処理の手順を示す流れ図。 第５の実施形態にかかる充電スタンドによる復旧処理の手順を示す流れ図。 第６の実施形態にかかるシステム構成図。 同実施形態にかかる充電スタンドによる復旧処理の手順を示す流れ図。 同実施形態にかかる充電スタンドによる復旧処理の手順を示す流れ図。

＜第１の実施形態＞
以下、本発明にかかる通信復旧支援装置および通信復旧支援用インタ−フェースを車載充電システムと充電スタンドとの間の通信に適用した第１の実施形態について、図面を参照しつつ説明する。

図１に示される充電スタンドＣＳは、車両に電力を供給するものである。図では、充電スタンドＣＳに、車両ＥＶが電気的に接続された状態を示している。車両ＥＶは、車載バッテリ１０と、外部の電源に接続可能とされて且つ外部の電源の電力を車載バッテリ１０に充電する電力変換回路１２と、電力変換回路１２を操作することで車載バッテリ１０の充電電力を制御する車両側制御装置１４と、外部の電源側との通信を行なう車両側トランシーバ１６とを備える。ここで、車両側制御装置１４や車両側トランシーバ１６は、中央処理装置（ＣＰＵ）等を備えるソフトウェア処理手段である。なお、車載バッテリ１０、電力変換回路１２、車両側制御装置１４、および車両側トランシーバ１６は、本実施形態において、車載電力授受システムを構成する。

上記充電スタンドＣＳは、商用電源３０の電力を車両に供給するためのインターフェースである。すなわち、充電スタンドＣＳは、商用電源３０から電力変換回路１２に供給される電力を制御するための出力部２０と、出力部２０を操作するためのスタンド側制御装置２２と、外部との通信をするスタンド側トランシーバ２４と、スタンド側メモリ２６とを備えている。ここで、スタンド側制御装置２２やスタンド側トランシーバ２４は、中央処理装置（ＣＰＵ）等を備えるソフトウェア処理手段である。また、スタンド側メモリ２６には、ＣＰＵによって実行されて且つ、車両側トランシーバ１６との通信を行なうためのプログラム等が記憶されている。なお、出力部２０、スタンド側制御装置２２、スタンド側トランシーバ２４、およびスタンド側メモリ２６は、本実施形態において、外部電源装置を構成する。

ちなみに、本実施形態では、スタンド側トランシーバ２４と車両側トランシーバ１６との通信として、電力線通信（ＰＬＣ通信）を想定している。

上記スタンド側トランシーバ２４は、ネットワーク３２を介して外部のサーバ４０と通信可能となっている。サーバ４０は、スタンド側トランシーバ２４と通信するためのサーバ側トランシーバ４２と、サーバ側制御装置４４と、サーバ側メモリ４６とを備えている。これらサーバ側トランシーバ４２、サーバ側制御装置４４、およびサーバ側メモリ４６は、本実施形態において、通信復旧支援装置を構成する。

サーバ側メモリ４６には、図中上方に示すデータベースＤＢが記憶されている。データベースＤＢは、車載電力授受システムと外部電源装置との通信不良が生じた場合について、その状況を特定するための情報を記憶したファイルである。ここで、状況を特定するための情報としては、車両ＥＶや搭載される車載電力授受システムを特定するための情報である車両側情報と、充電スタンドＣＳを特定するための情報であるスタンド側情報と、通信の不具合がいかなるものかを特定する不具合情報とが含まれている。

車両側情報は、車両ＥＶや搭載される車載電力授受システムを特定するための複数の項目ａ１，ａ２，…のそれぞれに関するものとされる。図では、特に、項目ａ１として、車両を特定する情報としての車種が、また、項目ａ２として、車載電力授受システムを特定するための車載器がそれぞれ設けられていることを例示してある。

一方、スタンド側情報は、充電スタンドを特定するための複数の項目ｂ１，ｂ２，…のそれぞれに関するものとされている。図では、特に、項目ｂ１として、充電スタンドＣＳ自体を特定するためのＩＤが、また、項目ｂ２として、充電スタンドＣＳの製造メーカが、項目ｂ３として、充電スタンドＣＳのモデルイヤーが、項目ｂ４として、過去に通信不良を起こしたことがあるか否か（過去実績）が、項目ｂ５として、充電スタンドＣＳの設置場所が、例示されている。

なお、不具合情報については、単一の項目ｃ１が割り当てられている。

これら各項目ａ１，ａ２，…，ｂ１，ｂ２，…，ｃ１によって特定される状況は、この状況において通信不良を解消した実績のあるソフトウェア（パッチ）に関連付けられている。パッチは、スタンド側メモリ２６に記憶されている通信のための正規のプログラム（通常時に使用されるプログラム）に対する拡張プログラムである。詳しくは、パッチは、上記項目ａ１，ａ２，…，ｂ１，ｂ２，…，ｃ１によって特定される状況毎に、関連付けられている。このため、項目ａ１，ａ２，…，ｂ１，ｂ２，…，ｃ１の少なくとも一部が相違する状況に対して、同じパッチが関連付けられていることもある。

上記データベースＤＢには、さらに、項目ａ１，ａ２，…，ｂ１，ｂ２，…，ｃ１のそれぞれについて、通信不良が生じた状況同士の類似度合いに寄与する度合いを定量化する寄与度定量値α１，α２，…β１，β２，…，γが含まれている。

以下、車両ＥＶと充電スタンドＣＳとの間に通信不良が生じる場合について、復旧支援装置による復旧支援態様を、図２〜図５に基づき説明する。以下では、「１．通信不良が生じた際の状況が、データベースＤＢに登録されている場合」、「２．通信不良が生じた際の状況が、データベースＤＢに登録されていない場合」、「３．その他」の順に説明する。
「１．通信不良が生じた際の状況が、データベースＤＢに登録されている場合」
図２は、充電スタンドＣＳによって実行される処理である。詳しくは、スタンド側制御装置２２とスタンド側トランシーバ２４との協働で、たとえば所定周期で行われるものである。

この一連の処理では、まずステップＳ１０において、車両ＥＶと充電スタンドＣＳとの接続に伴って通信（ケーブルコネクト通信）が成立するか否かを判断する。ここで、否定判断される場合、ステップＳ１２において、自動チューニングを行なう。これは、たとえば、通信に用いる信号の周波数の微調整等の処理となる。そして、ステップＳ１４においては、通信が成立したか否かを判断する。

ステップＳ１４において肯定判断される場合や、ステップＳ１０において肯定判断される場合には、ステップＳ１６において、充電スタンドＣＳの電力を車両ＥＶに充電する際に取り交わされる通信（充電通信）が成立するか否かを判断する。ここで、取り交わされる情報としては、たとえば、充電方式に関する情報や、料金に関する情報、充電に際しての許容電力や許容充電電流に関する情報等である。

ステップＳ１６において否定判断される場合や、ステップＳ１４において否定判断される場合には、ステップＳ２２に移行する。ステップＳ２２においては、通信不良が生じている状況を特定する情報をサーバ４０に出力する。ここで、スタンド側情報については、スタンド側メモリ２６に記憶保持されている。また、車両側情報については、ステップＳ１４において否定判断される場合には困難と考えられるものの、ステップＳ１６において否定判断される場合には、車両側情報についてもいくつかを取得できる可能性がある。すなわち、ステップＳ１０において肯定判断されたり、ステップＳ１４において肯定判断されたりする時点で、ある程度の通信が可能であるため、通信した内容によっては、車両側情報を取得可能となる。さらに、不具合情報として、車載電力授受システムとの通信記録（ログ）を送信する。

なお、ステップＳ２２の処理が完了する場合や、ステップＳ１６において肯定判断される場合には、この一連の処理を一旦終了する。

図３は、サーバ４０によって実行される処理である。詳しくは、サーバ側制御装置４４とサーバ側トランシーバ４２との協働で、先の図２のステップＳ２２の処理に伴って実行される。

この一連の処理では、まずステップＳ３０において、充電スタンドＣＳから、通信不良が生じている状況を特定する情報（状況特定情報）を受信する。ちなみに、図では、状況特定情報として、各項目ａ１，ａ２，…，ｂ１，ｂ２，…ｃ１に関する情報を、特定情報ａ１０，ａ２０，…，ｂ１０，ｂ２０，…ｃ１０として記載している。ただし、これは、項目ａ１，ａ２，…，ｂ１，ｂ２，…ｃ１の全てについて、情報が取得されることを必ずしも意味していない。すなわち、たとえば特定情報ａ２０に内容がないこともある。

ステップＳ３０において状況特定情報を受信したと判断される場合、ステップＳ３２において、不具合原因を推定する。これは、ステップＳ３０において受信された不具合情報に基づき行なうことができる。すなわちたとえば、ログを解析することで、通信のタイミングをチェックすることができる。そして、予め定められていたタイミング内に応答がないことが判明する場合、タイミング違反が生じていると判断することができる。またたとえば、ログに基づき、プロトコルチェックを行なうこともできる。これにより、充電スタンドＣＳおよび車両ＥＶ間の通信のためのプログラムのうち、充電スタンドＣＳにおいて使用されているものと、車両ＥＶにおいて使用されているものとのバージョンの相違がある場合には、その旨判断することができる。また、プログラムの誤記等が生じているか否かについても検討することができる。

続くステップＳ３４においては、上記不具合原因の推定結果に基づき、ソフトウェア処理が可能であるか否かを判断する。すなわち、先の図１に示したデータベースＤＢにおいて関連付けられているパッチを当てることで対処可能か否かを判断する。ここでは、たとえば不具合原因の推定ができない場合等において、否定判断されることとなる。

上記ステップＳ３４において肯定判断されると、ステップＳ３６において、先の図１に示したデータベースＤＢを検索する。ここでは、データベースＤＢにおいてパッチと関連付けられた特定情報のうち、項目ａ１，ａ２，…，ｂ１，ｂ２，…ｃ１の全てが受信された特定情報ａ１０，ａ２０，…，ｂ１０，ｂ２０，…ｃ１０と一致するものがあるか否かを、各項目毎に、その内容を照合することで行なうことができる。この処理は、本実施形態において、照合手段を構成する。

続くステップＳ３８においては、ステップＳ３６の処理における照合結果に基づき、上記完全に一致するものがあるか否かを判断する。そして、ステップＳ３８において肯定判断される場合、ステップＳ４０において、項目が完全一致する状況に関連付けられたパッチを充電スタンドＣＳに送信する。ここで、パッチを選択して送信する処理は、本実施形態において、選択手段を構成する。

続くステップＳ４２においては、充電スタンドＣＳ側で、パッチを当てることによって通信が成立したか否かについての結果を受信する。そして、通信が成立した場合（ステップＳ４６：ＹＥＳ）、ステップＳ４８に移行する。ステップＳ４８においては、ステップＳ４０において送信したパッチに関連付けられた項目ａ１，ａ２，…，ｂ１，ｂ２，…ｃ１のうち、特定情報ａ１０，ａ２０，…，ｂ１０，ｂ２０，…ｃ１０に対応するものについて、その項目に関する上記寄与度定量値（α１，α２，…，β１，β２，…γ）を増加補正する。これに対し、ステップＳ４６において否定判断される場合、ステップＳ５０に移行する。ステップＳ５０においては、ステップＳ４０において送信したパッチに関連付けられた項目ａ１，ａ２，…，ｂ１，ｂ２，…ｃ１のうち、特定情報ａ１０，ａ２０，…，ｂ１０，ｂ２０，…ｃ１０に対応するものについて、その項目に関する上記寄与度定量値（α１，α２，…，β１，β２，…γ）を減少補正する。この処理は、本実施形態において、寄与度学習手段を構成する。

図４は、充電スタンドＣＳによって実行される処理である。詳しくは、スタンド側制御装置２２とスタンド側トランシーバ２４との協働で、先の図３のステップＳ４０，Ｓ５４の処理に伴って実行される。

この一連の処理では、ステップＳ６０において、サーバ４０側から送信されるパッチを受信する。この処理は、実際には先の図２のステップＳ２２の処理の後、サーバ４０側でソフトウェア処理で解消可能と判断され、パッチが送信される旨の通知を受けることでなされる。なお、この処理は、本実施形態において、対処用受信手段を構成する。

続くステップＳ６２においては、受信したパッチを当てる。すなわち、スタンド側メモリ２６に記憶されている通信用の正規のプログラムをパッチによって拡張する。この処理は、本実施形態において、試行手段を構成する。

そして、ステップＳ６４では、通信が成立したか否かを判断する。そして、通信が成立しない場合には、ステップＳ６６に移行し、使用したパッチが後述する処理によって推定されたものであるか否かを判断する。この処理は、ステップＳ６０の処理がなされるに際し、サーバ４０側から、パッチがいかなるものかについての情報データを受信することで実現することができる。そして、ステップＳ６４において肯定判断される場合や、ステップＳ６６において否定判断される場合には、ステップＳ７０において、パッチを当てた後の通信の成立の有無についての結果を、サーバ４０側に報告する。なお、ステップ７０の処理は、本実施形態において、結果出力手段を構成する。

これにより、サーバ４０側では、先の図３に示したステップＳ４２の処理がなされることとなる。
「２．通信不良が生じた際の状況が、データベースＤＢに登録されていない場合」
この場合、先の図３のステップ３８において否定判断され、ステップＳ５２に移行する。図５に、ステップＳ５２の処理の詳細を示す。なお、図５に示す処理は、本実施形態において、推定手段を構成する。

この一連の処理では、まずステップＳ８０において、先の図３のステップＳ３０において受信した状況特定情報を読み出す。続くステップＳ８２においては、先の図１に示したデータベースＤＢにおいて特定された状況を指定する変数ｊを「１」とする。ここで状況を指定する変数は、先の図１に示したデータベースにおける左端の番号である。

続くステップＳ８４においては、変数ｊによって指定された状況について、今回の状況（特定情報ａ１０，ａ２０，…，ｂ１０，ｂ２０，…ｃ１０によって特定される状況）との類似度合いを定量化したトータルポイントＴＰ（ｊ）を算出する。ここでは、まず、項目ａ１，ａ２，…，ｂ１，ｂ２，…ｃ１のそれぞれについて、変数ｊによって指定される状況と、特定情報ａ１０，ａ２０，…，ｂ１０，ｂ２０，…ｃ１０のそれぞれとを照合し、一致、不一致を判断する。この処理は、本実施形態において、照合手段を構成する。次に、照合結果に基づき、寄与度定量値α１，α２，…，β１，β２，…γのうち、一致する項目に対応するものを、トータルポイントＴＰ（ｊ）に加算する。なお、ステップＳ８４の処理は、本実施形態において、寄与度バイアス手段を構成する。

トータルポイントＴＰ（ｊ）を算出する処理は、データベースＤＢに記憶されている全ての状況について行われる（ステップＳ８６，Ｓ８８）。図では、データベースＤＢに記憶された状況を指定する変数ｊの最大値を最大値ｊｍａｘとして表記している。

そして、データベースＤＢに記憶されている全ての状況についてトータルポイントＴＰ（ｊ）が算出される場合（ステップＳ８６；ＹＥＳ）、ステップＳ９０に移行する。ステップＳ９０では、今回の通信不良に対処可能と推定されるパッチ（ｍ）を選択する。ここでは、トータルポイントＴＰ（ｊ）が最大となる状況に関連付けられたパッチを選択する。

こうしてステップＳ７０の処理が完了すると、先の図３に示すステップＳ５４において、推定されたパッチを充電スタンドＣＳに送信し、ステップＳ４２に移行する。

これに対し、充電スタンドＣＳ側では、先の図４に示した処理を行なう。特に、この場合、ステップＳ６４において否定判断される場合、ステップＳ６６において肯定判断されることから、ステップＳ６８に移行する。ステップＳ６８においては、車両ＥＶと充電スタンドＣＳとの通信が成立しない状況下、車両ＥＶに最低限の電力を供給する救済充電を行なう。なお、この処理を行なう場合であっても、ステップＳ７０の処理、すなわち、通信成立の有無の結果をサーバ４０に報告する処理を行なう。

ちなみに、ステップＳ６６において否定判断される場合にステップＳ６８に移行しないのは、本実施形態では、この場合、推定されるパッチを充電スタンドＣＳに送信することを想定したためである。すなわち、先の図３において、破線にて示すように、サーバ４０では、ステップＳ４０において送信したパッチによって通信が成立しない旨の報告を受ける場合、ステップＳ５２の処理を行なう。

一方、上記ステップＳ７０の処理に応じて、サーバ４０側では、先の図３のステップＳ４２〜Ｓ５３の処理がなされる。ここで、寄与度定量値α１，α２，…，β１，β２，…γのうち更新対象となるものは、ステップＳ５４において送信されたパッチに関連付けられた状況を特定する項目ａ１，ａ２，…，ｂ１，ｂ２，…ｃ１のうち、特定情報ａ１０，ａ２０，…，ｂ１０，ｂ２０，…ｃ１０と内容が一致する項目に対応するものに限定される。
「３．その他」
先の図３に示したステップＳ３４においてソフトウェア処理が可能でないと判断される場合や、ステップＳ５０の処理が完了して且つステップＳ５２の処理によって推定されたパッチである場合（ステップＳ５１：ＹＥＳ）、ステップＳ５３に移行し、通信不良が生じた旨を修理店（管理者）に連絡する。具体的には、管理者のアクセス可能なトランシーバにその旨を示すデータを送信する。これにより、管理者が不具合情報を分析し、対処方法を決定する。ただし、調査の結果、不具合原因を特定することができない場合には、充電スタンドＣＳにサービスマンが派遣され、不具合原因の調査がなされ、対処方法を決定することとなる。そして、対処方法の決定に伴い、拡張ファイル（パッチ）で対処可能と決定される場合には、不具合を解消するためのパッチが新たに作成される。そしてそのパッチによって通信不良が解消する場合には、上記データベースＤＢに、新たにパッチを作成することとなった状況がパッチに関連付けて書き込まれる。

このように新たにパッチが作成されるため、たとえば先の図３のステップＳ３２においてタイミング違反と判断されたり、プログラムのビットやバイト単位のずれであると判断されたり、プロトコルの誤記と判断されたりする場合、これに対処するパッチをデータベースＤＢから検索可能となる。したがって、次回以降、同一の状況が生じる場合には、サービスマンを派遣することなく、サーバ４０側からパッチを送信することで不具合を解消することができる。

しかも、本実施形態では、通信不良が生じる場合、その状況を特定する情報と完全一致するものがない場合であっても、状況の類似度合いが大きいものに関連付けられたパッチを当ててみることができるため、通信不良を迅速に解決できる可能性を高めることができる。

以下、本実施形態によって得られる効果のいくつかをさらに記載する。

（１）データベースＤＢに基づき、通信不良に対処するためのパッチを選択することで（選択手段）、サービスマンを派遣することなく、通信不良に迅速に対処することができる。

（２）充電スタンドＣＳから状況特定情報をサーバ４０に送信することで、サーバ４０においてパッチを選択し、充電スタンドＣＳに供給するようにした。これにより、遠隔保守システムを実現でき、充電スタンドＣＳの構成を簡素化することができる。また、他の充電スタンドＣＳによって生じた通信不良の結果をも活用しつつ、対処可能パッチを推定することもできる。

（３）通信不良が生じた状況の類似度に対する各項目の寄与度を、寄与度定量値α１，α２，…，β１，β２，…γとして定量化した（寄与度学習手段）。そして、寄与度定量値に基づき対処可能パッチを推定する（寄与度バイアス手段）ことで、状況特定情報の類似度合いに基づく対処可能パッチの推定精度を向上させることができる。
＜第２の実施形態＞
以下、第２の実施形態について、先の第１の実施形態との相違点を中心に図面を参照しつつ説明する。

上記第１の実施形態では、通信不良が生じた状況の類似度に対する各項目の寄与度を、寄与度定量値α１，α２，…，β１，β２，…γとして定量化した。本実施形態では、これに加えて、各パッチの実績に基づき、その有効性を学習し、有効性定量値ｐ（ｍ）として定量化する。

図６に、本実施形態においてサーバ４０によってなされる処理の手順を示す。なお、図６において、先の図３に示した処理に対応するものについては、便宜上、同一のステップ番号を付している。

図示されるように、本実施形態では、ステップＳ４６において通信不良が解消したと判断される場合、ステップＳ４８ａにおいて、用いられたパッチ（ｍ）の有効性が高いとして、対応する有効性定量値ｐ（ｍ）を増加補正する。これに対し、ステップＳ４６において通信不良が解消しないと判断される場合、用いられたパッチ（ｍ）の有効性が低いとして、ステップＳ５０ａにおいて、対応する有効性定量値ｐ（ｍ）を減少補正する。なお、この処理は、本実施形態において、有効性学習手段を構成する。

図７に、本実施形態にかかる対処可能パッチの推定処理の手順を示す。なお、図７において、先の図３に示した処理に対応するものについては、便宜上、同一のステップ番号を付している。

図示されるように、この一連の処理では、ステップＳ８６において肯定判断される場合、ステップＳ９０ａに移行する。ステップＳ９０ａにおいては、トータルポイントＴＰ（ｊ）の最大値ＴＰ（Ｍ）に対応する状況と、最大値ＴＰ（Ｍ）との差が規定値Δ以下であるトータルポイントＴＰ（ｋ）を有する状況とのそれぞれに対応付けられたパッチの寄与度定量値の集合ｐｘの中から、最大となるものｐ（ｍ）に対応するパッチ（図中、Ｐａｔｃｈ（ｍ））を選択する。この処理は、本実施形態において、優先手段を構成する。
＜第３の実施形態＞
以下、第３の実施形態について、先の第１の実施形態との相違点を中心に図面を参照しつつ説明する。

上記第１の実施形態では、推定されるパッチによって通信が解消しない場合、救済充電を行うこととした。救済充電がなされている期間は、電力線通信が可能であることから、データベースＤＢに蓄積されたパッチの中に車両ＥＶと充電スタンドＣＳとの通信にとって適切なソフトウェアがあるかどうかを試すことが可能である。このため、本実施形態では、救済充電がなされている間に、データベースＤＢに記憶されている様々なパッチを当てて通信不良が解消するか否かを試す。

図８に、充電スタンドＣＳ側の処理を示す。この処理は、スタンド側制御装置２２おおよびスタンド側トランシーバ２４の協働で、たとえば所定周期で繰り返し実行される。

この一連の処理では、まずステップＳ１００において、救済充電中であるか否かを判断する。そして、救済充電中であると判断される場合、ステップＳ１０２において、先の図３のステップＳ４０、Ｓ５４の処理によって送信されたパッチとは相違する試行用のパッチの送信をサーバ４０に依頼する。そして、サーバ４０側から試行用パッチが送信されると、これを受信して試行用パッチを当てる（ステップＳ１０３）。そして、通信が成立したか否かに応じた通信結果をサーバ４０に報告する（ステップＳ１０６，Ｓ１０８）。なお、通信が不成立の場合（ステップＳ１０４）、さらに別の試行用パッチを試すべく、ステップＳ１０８の処理の後、ステップＳ１００に戻る。

図９に、サーバ４０側の処理の手順を示す。この処理は、サーバ側制御装置４４によって、たとえば所定周期で繰り返し実行される。この処理は、本実施形態において、試行用送信手段を構成する。

この一連の処理では、まずステップＳ１１０において、充電スタンドＣＳ側から試行用パッチの送信依頼があるか否かを判断する。そして、ステップＳ１１０において肯定判断される場合、ステップＳ１１２において、試行用パッチとして、未だ採用されていないパッチ（Ｐａｔｃｈ（ｊ））を選択する。なお、図では、先の図３に示した処理によって送信されたパッチを「ｐａｔｃｈ（ｍ）」と表記している。そして、ステップＳ１１２において試行用パッチが選択されると、ステップＳ１１４に移行し、選択されたパッチを充電スタンドＣＳに送信し、ステップＳ１１０に戻る。

なお、ステップＳ１１０において否定判断される場合、ステップＳ１１６において、パッチを指定する変数ｊをゼロとする。

このように、本実施形態では、車両ＥＶと充電スタンドＣＳとの通信にとって適切なパッチがあるか否かを試すことができる機会を利用して、データベースＤＢに蓄積されたパッチを試すことで、通信不良が解消するパッチを見出すことが可能となる。そして、通信不良を解消するパッチが見出された場合、データベースＤＢの情報を増加させることが可能となる。すなわち、この場合、パッチに関連付けられる状況特定情報が追加されることとなる。
＜第４の実施形態＞
以下、第４の実施形態について、先の第１の実施形態との相違点を中心に図面を参照しつつ説明する。

本実施形態では、先の図３のステップＳ５４の処理によって送信したパッチによって通信が成立しない場合、その情報をインターネット上で公開する。

図１０に、サーバ４０側の処理の手順を示す。この処理は、サーバ側制御装置４４とサーバ側トランシーバ４２との協働で、先の図３のステップＳ５４の処理によってパッチが送信された後に実行される。この処理は、本実施形態において、提供手段を構成する。

この一連の処理では、まずステップＳ１２０において、充電スタンドＣＳ側でパッチを当てることによって通信が成立したか否かについての結果報告を受信する。続くステップＳ１２２では、結果報告が通信成立を意味するものであるか否かを判断する。そして否定判断される場合、ステップＳ１２４において、充電スタンドＣＳと車種とを特定する。これは、先の図３のステップＳ３０の処理によって受信された状況特定情報の中から、充電スタンドＣＳの設置箇所と車種との情報を抽出する処理となる。続くステップＳ１２６においては、ステップＳ１２４において特定された充電スタンドＣＳと車種とをインターネットで公開する。

これにより、車両ＥＶのユーザは、インターネットにアクセスすることで、自分の車両がどこの充電スタンドＣＳで充電できないかを知ることができる。
＜第５の実施形態＞
以下、第５の実施形態について、先の第１の実施形態との相違点を中心に図面を参照しつつ説明する。

本実施形態では、充電スタンドＣＳに備えられる通信のための正規のプログラムによって通信を行なうことができない場合、サーバ４０から提供されるパッチを当てるに先立ち、車両ＥＶのユーザに通信の復旧処理を希望するか否かを問い合わせる。これは、ユーザがその場で待つことなく別の充電スタンドＣＳに向かう等、ユーザの選択の自由度を向上させるための設定である。

図１１に、充電スタンドＣＳ側の処理の手順を示す。この処理は、先の図２のステップＳ１０に示したケーブルコネクト通信の成立後に実行されるものである。

この一連の処理では、まずステップＳ１３０において、先の図２のステップＳ１６の処理を行なう。そして、ステップＳ１３０において否定判断される場合、ステップＳ１３２において、パッチによる通信復旧を試みることを希望するか否かに関し、ユーザに問い合わせる。これは、先の図１に示す充電スタンドＣＳのディスプレイＤＰに、正規のプログラムによって通信が成立しない旨、およびパッチによる通信復旧にかかると想定される所要時間等を表示することで実現すればよい。もっとも、問い合わせ自体は、充電スタンドＣＳと車両ＥＶとの有線または無線通信が可能な状況なら、有線通信、または無線通信によって行ってもよい。

そしてステップＳ１３４では、問い合わせによるユーザの回答が、復旧を要求するものであるか否かを判断する。ここで、上記ディスプレイＤＰをタッチパネルとするなら、これをユーザの回答の入力手段とすることができる。そして、ステップＳ１３４において肯定判断される場合、ステップＳ１３６において、サーバ４０側に通信復旧のためのパッチを要求する。なお、先の図３に示した処理では、まずサーバ４０側でパッチによる対処が可能か否かを判断している。このため、ステップＳ１３６の処理は、実際には、サーバ４０に状況特定情報を送信する処理となる。
＜第６の実施形態＞
以下、第６の実施形態について、先の第１の実施形態との相違点を中心に図面を参照しつつ説明する。

本実施形態では、充電スタンドＣＳにおいて一度使用されたパッチであって且つ、それによって通信が成立したものについては、そのときの車両側情報や不具合情報とともにスタンド側メモリ２６に記憶する。ただし、これら車両側情報や不具合情報およびパッチと、通信用の正規のプログラムとは記憶領域を分離する。すなわち、スタンド側メモリ２６は、車両側情報や不具合情報およびパッチを記憶する暫定領域２６ｂ（不具合用記憶領域）と、正規のプログラムが記憶される正規領域２６ａとを備える。ここで、正規領域２６は、原則、書き込みが禁止される領域である一方、暫定領域２６ｂは、書き込みが許可される領域である。これは、正規のプログラムが消去される事態を回避するための設定である。

ちなみに、これら暫定領域２６ｂと正規領域２６ａとは同一メモリの別のアドレスに対応する領域に限らない。たとえば、スタンド側メモリ２６を、読み出し専用メモリ（ＲＯＭ）と、電気的書き換え可能な読み出し専用メモリ（登録商標：ＥＥＰＲＯＭ）とを備えて構成し、正規領域２６ａを、読み出し専用メモリの記憶領域とし、暫定領域２６ｂを、電気的書き換え可能な読み出し専用メモリによって構成してもよい。

図１３に、充電スタンドＣＳ側の処理の手順を示す。この処理は、スタンド側制御装置２２によって、たとえば所定周期で繰り返し実行される。なお、図１３において、先の図４に示した処理に対応するものについては、便宜上、同一のステップ番号を付している。

この一連の処理では、ステップＳ６４において肯定判断される場合、ステップＳ１４０において、パッチによって通信が成立することとなった車両ＥＶに関する車両側情報と、通信不成立となったときの不具合情報と、適用されたパッチとを暫定領域２６ｂに記憶する。

図１４に、充電スタンドＣＳ側の処理の手順を示す。この処理は、スタンド側制御装置２２によって、たとえば所定周期で繰り返し実行される。なお、図１４において、先の図２に示した処理に対応するものについては、便宜上、同一のステップ番号を付している。

この一連の処理では、ステップＳ１６において否定判断される場合、ステップＳ１８において、それまでの通信に関するログを解析することで、タイミングチェックを行なう。続くステップＳ２０においては、同じくログを解析することで、プロトコルチェックを行なう。そして、ステップＳ１４２においては、暫定領域２６ｂに記憶された車両側情報と不具合情報の中に、ステップＳ１８、Ｓ２０によって生成された不具合情報と、ステップＳ１８の処理以前に車両ＥＶと初歩的な通信をすることで取得された車両側情報との組み合わせに一致するものがあるか否かを判断する。

そして一致するものがある場合、ステップＳ１４４において、暫定領域２６ｂに記憶されたパッチのうち、車両側情報および不具合情報に関連付けられたパッチを適用する。
＜その他の実施形態＞
なお、上記各実施形態は、以下のように変更して実施してもよい。

「寄与度学習手段（図３：ステップＳ４８，Ｓ５０）について」
パッチによって通信不良が解消する場合、そのパッチに関連付けられた事象の全項目の寄与度定量値αｋ，βｋ，γを増大させるものに限らない。たとえば、今回利用されたパッチに関してのみ、これに関連付けられた項目に関する寄与度定量値αｋ，βｋ，γを増大させるものであってもよい。

「寄与度バイアス手段（図５：ステップＳ８４）について」
上記第１の実施形態に例示したように、寄与度定量値αｋ，βｋ，γのうち、一致する項についての総和をトータルポイントＴＰとして類似度合いの大きさを定量化するものに限らない。たとえば、寄与度定量値αｋ，βｋ，γのうち、その大きさが規定値以上のものや、大きいものから規定数個に限って、それらの総和を類似度合い大きさを定量化するものであってもよい。

「優先手段（図７：ステップＳ９０ａ）について」
パッチの有効性の学習結果に基づき、有効性が高いとされるパッチを、対処可能パッチの推定において優先させる手段としては、上記第２の実施形態に例示したものに限らない。たとえば、先の図６のステップＳ３８において否定判断される場合、対処可能パッチを２つ推定するものとして且つ、第１番目のパッチとして、有効性が最も高いパッチを常時推定するものとしてもよい。この場合、第２番目のパッチとしてトータルポイントＴＰが最高となるものに関連付けられたパッチを推定すればよい。

「推定手段について」
状況特定情報のうち、車両側情報、スタンド側情報等に関する項目が一致する数が最も多い事象に関連付けられたパッチを、通信不良を解消できるパッチであると推定する手段であってもよい。これは、上記第１の実施形態（図５）におけるトータルポイントＴＰ（ｊ）の算出に際し、寄与度定量値αｋ（ｊ），βｋ（ｊ），γ（ｊ）を、信頼度を定量化したものとすることなく、「１」とすることで実現できる。

さらに、状況特定情報の類似度合いを定量化する手法としては、項目数や寄与度定量値の加算値等に基づくものにも限らず、たとえば、各項目を成分とするベクトル同士のなす角度を用いるものであってもよい。すなわちこの場合、なす角度が小さいほど類似度合いが大きいことを表現する。

「試行用送信手段（図９）について」
上記第３の実施形態では、番号付けられたパッチを順次送信する手段として構成したが、これに限らない。たとえば、有効性学習手段を備える場合には、有効性学習手段の学習結果に基づき、有効性の高い順にパッチを送信する手段としてもよい。また、１度に１つずつパッチを送信する手段にも限らない。

なお、試行用送信手段による送信処理がなされるのは、救済充電期間に限らない。たとえば充電処理を行わないものの車両ＥＶのユーザが希望する場合に送信処理を行なってもよい。これは、充電スタンドＣＳ側で、その旨を問い合わせることで実現することができる。

「提供手段（図１０）について」
上記第４の実施形態では、パッチによっても通信が成立しない場合に、そのスタンドと、対応する車種との情報をネット上で公開する手段を例示したが、これに限らない。たとえば、対応する車種にその旨を通知する手段であってもよい。

「問い合わせ手段（図１１）について」
上記第５の実施形態では、充電通信が不成立であると判断された直後に、パッチを試すか否かをユーザに問い合わせたがこれに限らない。たとえば、先の図３のステップＳ３８において否定判断される場合に、ユーザに問い合わせる手段であってもよい。すなわち、パッチによって確実に対処可能と判断される場合については、ユーザによる問い合わせを行わない手段であってもよい。

「不具合解消用ソフトウェアについて」
正規のプログラムと相違する部分（差分データ：パッチ）に限らない。たとえば、正規のプログラムとの共通部分をも含んだプログラムであってもよい。

「対処手段について」
不具合解消用ソフトウェアに限らない。たとえば、ソフトウェア処理による対処が不可能である場合について、サービスマンがいかなる対処をすべきかを記載した文書データであってもよい。

「通信復旧支援用インターフェースについて」
充電スタンドＣＳに備えられるものに限らない。たとえば、車両ＥＶ側に備えられるものであってもよい。この場合、パッチは、車載電力授受システムに記憶されて且つ充電スタンドＣＳと通信する際に用いる通信用プログラムを拡張するソフトウェアとなる。

また、車両側情報やスタンド側情報、不具合情報を、データベースＤＢを備えたサーバ４０に出力するものに限らない。たとえば、通信の不具合を解消することを試みる管理者がアクセスすることが可能なトランシーバに送信するものであってもよい（この処理は、先の図３に示したステップＳ５３の処理の要領で行なうことができる）。この場合であっても、管理者が送信されたデータを解析し、その結果に応じて対処法を決定するなら、通信不良が生じる都度、その場にサービスマンが派遣される場合と比較して、通信不良の迅速な解消が可能となる。このため、この場合であっても、通信復旧を好適に支援することができる。

「通信復旧支援装置」
データベースの記憶された記憶手段を備えるものに限らない。たとえば、先の図３に示した処理を行なう主体を、サーバ側制御装置４４に代えて、スタンド側制御装置２２とすることで、選択手段を充電スタンドＣＳに備えてもよい。この場合、充電スタンドは、都度、サーバ４０のメモリ４６に記憶されたデータベースにアクセスすることとなる。

「データベースについて」
車両側情報とスタンド側情報との双方を記憶するものに限らない。たとえば車載電力授受システムのサプライヤが通信復旧支援サービスを行なう場合、スタンド側情報と不具合情報とを不具合解消用ソフトウェアに関連付けるデータベースを備え、このデータベースには、車両側情報が含まれないという構成も有効である。もっとも、この場合であっても、車両側情報を記憶するなら、状況特定情報の蓄積が豊富になるため、推定手段によって推定される不具合解消用ソフトウェアによって不具合が解消される可能性を高めることができるというメリットがあると考えられる。

「そのほか」
ＰＬＣ通信に限らない。

通信復旧支援装置と、通信復旧支援用インターフェースとの通信が、有線である必要もなく、無線であってもよい。

充電スタンドＣＳと車両ＥＶとの通信に限らない。たとえばスマートグリッド等において、車両ＥＶが電力を外部に供給する場合、その供給先と車両との間の通信であってもよい。

１０…車載バッテリ、１２…電力変換回路、１４…車両側制御装置、１６…車両側トランシーバ、２０…出力部、２２…スタンド側制御装置、２４…スタンド側トランシーバ、２６…スタンド側メモリ、４０…サーバ、４２…サーバ側トランシーバ、４４…サーバ側制御装置、４６…サーバ側メモリ。

Claims (16)

1. 車両の外部との電力の授受を行なう車載電力授受システム（１０，１２，１４，１６）と外部電源装置（２０，２２，２４，２６）との間に通信不良が生じる場合、前記通信不良が生じている車載電力授受システムおよび該システムが搭載される車両の少なくとも一方を特定する情報である車両側情報、および前記通信不良が生じている外部電源装置を特定する情報である電源側情報の少なくとも一方と、前記車載電力授受システムと前記外部電源装置との間に生じた通信の不具合を特定するための情報とを入力とし、データベースに基づき、前記通信不良の対処手段を選択する選択手段（Ｓ３８，Ｓ５２）を備え、
   前記データベースは、前記通信不良への対処手段を、該通信不良が生じた前記車両側情報に関する１または複数の項目と、該通信不良が生じた前記電源側情報に関する１または複数の項目との少なくとも一方と、前記不具合を特定するための情報との双方に関連付けるものであり、
   前記選択手段は、前記入力された情報と、前記データベース内の前記対処手段に関連付けられた前記情報とを照合する照合手段（Ｓ３６，Ｓ８４）を備え、該照合の結果に基づき、前記選択を行ない、
   前記データベースによって関連付けられた対処手段には、前記通信不良を解消するためのソフトウェアである不具合解消用ソフトウェアが含まれることを特徴とする通信復旧支援装置。
2. 車両の外部との電力の授受を行なう車載電力授受システム（１０，１２，１４，１６）と外部電源装置（２０，２２，２４，２６）との間に通信不良が生じる場合、前記通信不良が生じている車載電力授受システムおよび該システムが搭載される車両の少なくとも一方を特定する情報である車両側情報、および前記通信不良が生じている外部電源装置を特定する情報である電源側情報の少なくとも一方と、前記車載電力授受システムと前記外部電源装置との間に生じた通信の不具合を特定するための情報とを入力とし、データベースに基づき、前記通信不良の対処手段を選択する選択手段（Ｓ３８，Ｓ５２）を備え、
   前記データベースは、前記通信不良への対処手段を、該通信不良が生じた前記車両側情報に関する１または複数の項目と、該通信不良が生じた前記電源側情報に関する１または複数の項目との少なくとも一方と、前記不具合を特定するための情報との双方に関連付けるものであり、
   前記選択手段は、前記入力された情報と、前記データベース内の前記対処手段に関連付けられた前記情報とを照合する照合手段（Ｓ３６，Ｓ８４）を備え、該照合の結果に基づき、前記選択を行ない、
   前記選択手段は、前記データベース内において前記対処手段に関連付けられた情報である前記車両側情報および前記電源側情報の少なくとも一方および前記不具合を特定するための情報の中に、前記入力される情報と前記項目の完全一致するものがない場合、前記対処手段に関連付けられた前記項目の部分一致に基づき、前記通信不良を解消できる前記対処手段を推定する推定手段（Ｓ５２）を備えることを特徴とする通信復旧支援装置。
3. 前記対処手段を用いた通信の結果を受信する結果受信手段（Ｓ４２）を備え、
   前記推定手段は、前記対処手段のうち、該対処手段に関連付けられた項目によって特定される状況と前記入力される情報によって特定される状況との類似度が大きいものを前記通信不良を解消できる前記対処手段と推定するものであり、
   前記推定された対処手段に関する前記結果受信手段によって受信された通信結果に基づき、前記類似度に対する前記項目の寄与度の大小を学習する寄与度学習手段（Ｓ４８，Ｓ５０）と、
   前記寄与度学習手段の学習結果に基づき、寄与度の大きい項目が一致する状況の類似度を、寄与度の小さい項目が一致する状況の類似度よりも大きいとする寄与度バイアス手段（Ｓ８４）と、
   を備えることを特徴とする請求項２記載の通信復旧支援装置。
4. 前記対処手段を用いた通信の結果を受信する結果受信手段を備え、
   前記推定手段は、
   前記推定された対処手段に関する前記結果受信手段によって受信された通信結果に基づき、前記対処手段の有効性を学習する有効性学習手段（Ｓ４８ａ，Ｓ５０ａ）と、
   前記通信不良を解消できる対処手段の推定に際し、前記有効性学習手段の学習結果に基づき、有効性が高いとされる対処手段を優先する優先手段と、
   を備えることを特徴とする請求項２または３記載の通信復旧支援装置。
5. 前記データベースを記憶する記憶手段（４６）を備えることを特徴とする請求項１〜４のいずれか１項に記載の通信復旧支援装置。
6. 前記選択手段によって選択された対処手段が機能しない場合であって且つ、前記車載電力授受システムと前記外部電源装置とが通信を許容する状況下、前記選択手段によって選択されなかった対処手段を試みるべく送信する試行用送信手段（Ｓ１１４）を備えることを特徴とする請求項１〜５のいずれか１項に記載の通信復旧支援装置。
7. 車両の外部との電力の授受を行なう車載電力授受システム（１０，１２，１４，１６）と外部電源装置（２０，２２，２４，２６）との間に通信不良が生じる場合、前記通信不良が生じている車載電力授受システムおよび該システムが搭載される車両の少なくとも一方を特定する情報である車両側情報、および前記通信不良が生じている外部電源装置を特定する情報である電源側情報の少なくとも一方と、前記車載電力授受システムと前記外部電源装置との間に生じた通信の不具合を特定するための情報とを入力とし、データベースに基づき、前記通信不良の対処手段を選択する選択手段（Ｓ３８，Ｓ５２）を備え、
   前記データベースは、前記通信不良への対処手段を、該通信不良が生じた前記車両側情報に関する１または複数の項目と、該通信不良が生じた前記電源側情報に関する１または複数の項目との少なくとも一方と、前記不具合を特定するための情報との双方に関連付けるものであり、
   前記選択手段は、前記入力された情報と、前記データベース内の前記対処手段に関連付けられた前記情報とを照合する照合手段（Ｓ３６，Ｓ８４）を備え、該照合の結果に基づき、前記選択を行ない、
   前記選択手段によって選択された対処手段が機能しない場合であって且つ、前記車載電力授受システムと前記外部電源装置とが通信を許容する状況下、前記選択手段によって選択されなかった対処手段を試みるべく送信する試行用送信手段（Ｓ１１４）を備えることを特徴とする通信復旧支援装置。
8. 前記外部電源装置は、充電スタンド（ＣＳ）に備えられるものであり、
   前記対処手段を用いた通信の結果を受信する結果受信手段と、
   前記結果受信手段によって受信された通信結果に基づき、車両に、前記通信不良が生じる外部電源装置を備える充電スタンドに関する情報を提供する提供手段（Ｓ１２６）と、
   を備えることを特徴とする請求項１〜７のいずれか１項に記載の通信復旧支援装置。
9. 車両の外部との電力の授受を行なう車載電力授受システム（１０，１２，１４，１６）と外部電源装置（２０，２２，２４，２６）との間に通信不良が生じる場合、前記通信不良が生じている車載電力授受システムおよび該システムが搭載される車両の少なくとも一方を特定する情報である車両側情報、および前記通信不良が生じている外部電源装置を特定する情報である電源側情報の少なくとも一方と、前記車載電力授受システムと前記外部電源装置との間に生じた通信の不具合を特定するための情報とを入力とし、データベースに基づき、前記通信不良の対処手段を選択する選択手段（Ｓ３８，Ｓ５２）を備え、
   前記データベースは、前記通信不良への対処手段を、該通信不良が生じた前記車両側情報に関する１または複数の項目と、該通信不良が生じた前記電源側情報に関する１または複数の項目との少なくとも一方と、前記不具合を特定するための情報との双方に関連付けるものであり、
   前記選択手段は、前記入力された情報と、前記データベース内の前記対処手段に関連付けられた前記情報とを照合する照合手段（Ｓ３６，Ｓ８４）を備え、該照合の結果に基づき、前記選択を行ない、
   前記外部電源装置は、充電スタンド（ＣＳ）に備えられるものであり、
   前記対処手段を用いた通信の結果を受信する結果受信手段と、
   前記結果受信手段によって受信された通信結果に基づき、車両に、前記通信不良が生じる外部電源装置を備える充電スタンドに関する情報を提供する提供手段（Ｓ１２６）と、
   を備えることを特徴とする通信復旧支援装置。
10. 請求項１〜９のいずれか１項に記載の通信復旧支援装置に、前記車両側情報および前記電源側情報の少なくとも一方と前記不具合を特定するための情報とを送信する送信手段（Ｓ２２）と、
    前記通信復旧支援装置から出力された前記対処手段を受信する対処用受信手段（Ｓ６０）と、
    前記対処用受信手段が受信した対処手段に基づき、前記車載電力授受システムと前記電源装置との通信を試みる試行手段（Ｓ６２）と、
    前記データベースによって関連付けられた対処手段には、前記通信不良を解消するためのソフトウェアである不具合解消用ソフトウェアが含まれ、
    前記対処用受信手段は、前記不具合解消用ソフトウェアを受信する機能を備えることを特徴とする通信復旧支援用インターフェース。
11. 前記試行手段による試行結果を前記通信復旧支援装置に出力する結果出力手段（Ｓ７０）を備えることを特徴とする請求項１０記載の通信復旧支援用インターフェース。
12. 前記データベースによって関連付けられた対処手段には、前記通信不良を解消するためのソフトウェアである不具合解消用ソフトウェアが含まれ、
    前記対処用受信手段は、前記不具合解消用ソフトウェアを受信する機能を備えることを特徴とする請求項１０または１１記載の通信復旧支援用インターフェース。
13. 車両の外部との電力の授受を行なう車載電力授受システム（１０，１２，１４，１６）と外部電源装置（２０，２２，２４，２６）との間に通信不良が生じる場合、前記通信不良が生じている車載電力授受システムおよび該システムが搭載される車両の少なくとも一方を特定する情報である車両側情報、および前記通信不良が生じている外部電源装置を特定する情報である電源側情報の少なくとも一方と、前記車載電力授受システムと前記外部電源装置との間に生じた通信の不具合を特定するための情報とを入力とし、データベースに基づき、前記通信不良の対処手段を選択する選択手段（Ｓ３８，Ｓ５２）を備え、
    前記データベースは、前記通信不良への対処手段を、該通信不良が生じた前記車両側情報に関する１または複数の項目と、該通信不良が生じた前記電源側情報に関する１または複数の項目との少なくとも一方と、前記不具合を特定するための情報との双方に関連付けるものであり、
    前記選択手段は、前記入力された情報と、前記データベース内の前記対処手段に関連付けられた前記情報とを照合する照合手段（Ｓ３８，Ｓ８４）を備え、該照合の結果に基づき、前記選択を行なう通信復旧支援装置に適用され、
    前記車両側情報および前記電源側情報の少なくとも一方と前記不具合を特定するための情報とを送信する送信手段（Ｓ２２）と、
    前記通信復旧支援装置から出力された前記対処手段を受信する対処用受信手段（Ｓ６０）と、
    前記対処用受信手段が受信した対処手段に基づき、前記車載電力授受システムと前記電源装置との通信を試みる試行手段（Ｓ６２）と、
    を備え、
    前記データベースによって関連付けられた対処手段には、前記通信不良を解消するためのソフトウェアである不具合解消用ソフトウェアが含まれ、
    前記対処用受信手段は、前記不具合解消用ソフトウェアを受信する機能を備えることを特徴とする通信復旧支援用インターフェース。
14. 前記不具合解消用ソフトウェアを記憶する不具合用記憶領域（２６ｂ）を備え、
    該不具合用記憶領域は、前記車載電力授受システムと前記外部電源装置との間の通信に用いる通常時のプログラムを記憶する領域（２６ａ）とは相違することを特徴とする請求項１２または１３に記載の通信復旧支援用インターフェース。
15. 前記不具合用記憶領域に記憶された前記不具合解消用ソフトウェアと、該ソフトウェアが有効に機能したときにおいて前記選択手段に入力された情報とを関連付けて記憶する関連記憶手段（２６）と、
    前記関連記憶手段に記憶されたデータに基づき、前記不具合解消用ソフトウェアを起動する起動手段（Ｓ１４２，Ｓ１４４）と、
    を備えることを特徴とする請求項１４記載の通信復旧支援用インターフェース。
16. 当該通信復旧支援用インターフェースは、車両に搭載されるものであり、
    前記車載電力授受システムと前記外部電源装置との間に通信不良が生じる場合、前記対処用受信手段によって前記不具合解消用ソフトウェアを受信するに先立ち、不具合解消用ソフトウェアを試すか否かをユーザに問い合わせる問い合わせ手段（Ｓ１３２）を備えることを特徴とする請求項１２〜１５のいずれか１項に記載の通信復旧支援用インターフェース。

Images