JP2007004499A - プログラムデータ配信システム - Google Patents

Abstract

【課題】指定された電子制御ユニットのリプログラミングデータを、変更が認められていない部分の変更を防止すると共に、変更が認められた部分の調整を容易とするプログラムデータ配信システムを提供する。
【解決手段】更新用のプログラムデータを変更が認められていないリプログラミングデータ１０１と変更が認められたコンフィグレーションデータ１０２とに分け、修理支援サーバ３が、ネットワーク回線４を介してコンフィグレーションデータ１０２を変更手段を備える整備者端末２に送信し、リプログラミングデータ１０１を整備者端末２を介さずに整備対象機種１の更新端末に送信し、整備者端末２が変更を受け付けたコンフィグレーションデータ１０２を更新端末宛てに送信し、更新端末が両データ１０１、１０２を受信して指定された電子制御ユニットのプログラムデータを更新する。
【選択図】図１

Description

本発明は、整備が必要な整備対象機種に搭載され、かつプログラムで制御される電子制御ユニットに対して、最新のプログラムデータを送信手段によって送信すると共に、整備者か整備対象機種の調子や装備などの状態を確かめ、その状態に応じてプログラムデータの内容変更を行うことができるシステムに関するものである。

従来、電子制御ユニットについて、そのプログラムデータを出荷後に更新可能とすることで、出荷後であってもより好適なプログラムに更新して機能を変更または向上するサービスを提供することが行われている。また修理の場合であっても、プログラムデータを記憶する電子制御ユニット自体を交換するとコストや載せ代えの時間がかかる為、プログラムデータの更新で対応できる場合は、ユーザーやサービス工場の整備者等が、プログラムデータ更新機能を有する整備者端末を用いてプログラムデータを変更し適切なものに調整して電子制御ユニットに記憶させることが行われている。

ところで、上記のような更新用のプログラムデータは最新のものが必要であり、それがメーカーから整備者に届けられる場合、記憶媒体に記憶させて輸送すると、記憶媒体の準備と入手に時間がかかる為、プログラムデータの更新を必要とする電子制御ユニットのユーザーを待たせてしまいサービス性が悪化することが懸念される。したがってインターネットなどの通信回線を利用してメーカーから整備者端末、あるいは搭載された電子制御ユニットへプログラムデータを送信する方法が考えられている。

そして電子制御ユニットに必要な最新のプログラムデータを送信するシステムとして、下記特許文献１が知られている。

同文献１に記載のシステムは、遠隔故障診断用プログラムによって制御される車載コンピュータにより、この車載コンピュータが搭載された自動車の故障診断を自動で行うものであり、故障診断の対象となる対象車に搭載された車載コンピュータと、対象車に対するユーザー情報や最新の故障診断用プログラムデータを記憶しておき、該プログラムデータをインターネットなどの通信回線を利用して送信可能な遠隔故障診断サーバとを有している。この車載コンピュータは、通信手段と遠隔故障診断用プログラムを記憶する記憶手段を備え、必要に応じて遠隔故障診断用プログラムを実行する機能と、遠隔故障診断サーバから最新の遠隔故障診断用プログラムデータを受信し、遠隔故障診断用プログラムを書き換える機能を有している。そして、必要に応じて遠隔故障診断サーバが最新の故障診断プログラムを指定する対象車の車載コンピュータに転送するようになっている。このようなシステムにより、対象車が遠隔故障診断サーバから離れた遠隔地に位置したとしても、サービス工場に出向くことなく最新の故障診断プログラムによる適切な故障診断を実施可能となっている。

一方、更新すべき最新のプログラムデータには、整備対象機種で共通の部分もあれば、整備能力を有する整備者により、個別の電子制御ユニットおよび整備対象機器の調子や装備といった状態を確認して、プログラムデータの内容を一部変更する必要のある部分もある。例えば、上記特許文献１に記載の自動車においては、電子燃料制御システム（本願の燃料噴射量制御ユニット）などの走行性能や安全性といった商品価値に直結する電子制御ユニットのプログラムを更新する場合が挙げられる。
この場合、この電子制御ユニットを搭載した整備対象機種がサービス工場から離れた場所にあり、整備者が実際の電子制御ユニットや整備対象機種の状態が適正かどうかを確認せずに更新を行ってしまうことや、通信回線を介して何らかの別データがプログラムデータとして更新端末に受信され、更新されてしまうことを防止する為に、整備者が実際に整備対象機種の近傍にいて、直接整備対象機種の状態を診断できると共に、必要に応じてプログラムデータの内容を調整可能な環境で作業が行われ、プログラムデータが適切に更新されることが望まれている。そしてこの更新作業において、自動車における燃料噴射量制御ユニットのプログラムデータなど、商品価値に関わる性能に特に強い影響を与えるものにおいては、一定の範囲内でのみ変更を認めることで、サービス性を維持した上でメーカーの意図した性能を保証することが望まれている。

ところで、整備者端末は一般的にパーソナルコンピュータと呼ばれる汎用性の高い機器であることが考えられ、この機器は、様々なデータ処理機能を実現する為に、演算装置や入出力装置、及び記憶装置、データ変更手段、通信装置等を備え、任意のデータ処理機能を実現する為のプログラムをインストールし実行することで、該プログラムの目的とするデータ処理機能を備えることができる。このような機器においては、記憶装置に記憶したデータに対して変更やコピーを完全に禁止することは困難であるので、整備者がプログラムデータの変更を行う際、プログラムデータの変更が認められていない部分も変更が可能な環境に置かれることになり、メーカーの意図した整備対象機種の性能を保証する為には好ましいものではなかった。
特開２００２−２２８５５２号公報

以上から本発明は、電子制御ユニットのプログラムデータを設定された整備対象機種の更新端末に対して送信する送信手段を備えたプログラムデータ送信システムにおいて、プログラムデータのうち変更が認められた部分を整備者端末により変更可能とし、変更が認められていない部分の変更を防止することを目的とする。

本発明に関わるプログラムデータ配信システムの第１の構成は、 指定された整備対象機種に搭載された電子制御ユニットのプログラムデータを設定された端末に対して送信する送信手段を備えたプログラムデータ配信システムであって、上記プログラムデータは、
整備者による変更が認められた第１プログラム部分と、整備者による変更が認められていない第２プログラム部分とを有し、上記送信手段は、上記プログラムデータの第１プログラム部分を送信すべき、上記プログラムデータの内容を変更する為の整備者端末を設定すると共に、上記第２プログラム部分を送信すべき、上記指定された電子制御ユニットのプログラムデータを更新する為の更新端末を設定する設定手段を有し、上記第１プログラム部分を上記整備者端末に送信すると共に、上記第２プログラム部分を上記整備者端末を介さずに上記更新端末に送信するものであることを特徴とするものである。

第１の構成によれば、プログラムデータを変更が認められた部分である第１プログラム部分と認められていない部分である第２プログラム部分とに分け、プログラムデータのうち第１プログラム部分は、データの変更が可能な整備者端末において変更できるので、従来どおり整備者が個別の整備対象機種に対して調整ができ、変更が認められていない第２プログラム部分は、整備者端末を介さずに更新端末に送信されるので変更されることを防止でき、サービス性を維持した上で、指定された整備対象機種に対してメーカー、あるいは管理者の意図した性能を保証できる。

本発明に関わる第２の構成は、上記構成１において上記送信手段が、遠距離通信可能な通信回線を介して上記更新端末と整備者端末とに上記プログラムデータを送信するものであることを特徴とするものである。

第２の構成によれば、送信手段に対して整備者端末や更新端末が離れていても、プログラムデータを送信できる。

本発明に関わる第３の構成は、上記構成１または構成２のいずれか１つの構成において、上記整備対象機種は自動車における特定の車種であることを特徴とするものである。

第３の構成によれば、安全性や走行性能の確保が重要な車両における電子制御ユニットのプログラムデータを更新する際に、整備者による車両の確認を促すことで安全性を向上することができる。

本発明に関わる第４の構成は、上記構成１ないし構成３のいずれか１つの構成において、上記送信手段および更新端末は、相互通信可能な相互通信手段を備え、上記送信手段は、通信相手との間で、該通信相手が上記設定手段により設定された更新端末であるかどうかの認証を行う認証手段を備え、上記認証手段により上記通信相手が設定された更新端末であると認証されたときのみ、上記通信相手に対して上記第２プログラム部分を送信するものであることを特徴とするものである。

第４の構成によれば、通信相手が更新端末でない場合は、データを変更できる端末である可能性があるが、第２プログラム部分を確実に更新端末に直接送信できるので、同プログラム部分の変更を防止できる。

本発明に関わる第５の構成は、上記構成１ないし構成３のいずれか１つの構成において、上記送信手段は、上記第２プログラム部分を暗号化する暗号化手段を備え、該暗号化手段により暗号化された上記第２プログラム部分を送信するものであると共に、上記更新端末は、上記暗号化された第２プログラム部分を復号化する復号化手段を備えることを特徴とするものである。

第５の構成によれば、第２プログラム部分の送信の中継手段として更新端末以外の別端末を介在させる場合など、第２プログラム部分が変更またはコピー可能な環境に置かれる場合であっても、暗号化されているので変更を抑制できる。

本発明に関わる第６の構成は、上記構成１ないし構成３のいずれか１つの構成において、上記更新端末が上記整備者端末に対して上記第２プログラム部分を出力不能に構成されていることを特徴とするものである。

第６の構成によれば、変更が認められていない第２プログラム部分が、変更可能な環境に置かれることを防ぎ、変更を防止できる。

本発明に関わる第７の構成は、上記構成１ないし構成３のいずれか１つの構成において、上記更新端末が整備者端末を指定する指定手段を備え、上記送信手段は、上記更新端末の指定手段により指定された上記整備者端末に上記第１プログラム部分を送信することを特徴とするものである。

第７の構成によれば、更新端末により指定された整備者端末に第１プログラム部分を送る為、送信先を限定できるので指定する整備者端末の選定作業を効率化できると共に、上記指定された電子制御ユニットおよび更新端末を整備者端末のある場所に着く前に指定された整備者端末へ第１プログラム部分の送信を開始できるので、第１プログラム部分受信の待ち時間を低減して迅速なサービスを提供できる。

本発明に関わる第８の構成は、上記構成１ないし構成３および構成７のいずれか１つの構成において、上記更新端末は、上記整備者端末が上記第１プログラム部分の受信を完了したことを検出する第１受信完了検出手段と、該第１受信完了検出手段が受信完了を検出することで、ユーザーに整備者への案内を報知する案内手段とを備えることを特徴とするものである。

第８の構成によれば、案内の報知により上記指定された電子制御ユニットおよび更新端末が整備者端末の元に着いた時には、既に整備者端末はプログラムデータ変更に必要な環境が整っており、整備者は、第１プログラム部分受信の待ち時間なく迅速なサービスを提供できる。

本発明に関わる第９の構成は、上記構成１ないし３のいずれか１つの構成において、上記更新端末は、上記第１プログラム部分と第２プログラム部分とを共に受信完了したことを検出する第２受信完了検出手段と、該第２受信完了検出手段が受信完了を検出することで、両プログラム部分を上記電子制御ユニットに対して有効にするものであることを特徴とするものである。

第９の構成によれば、一方のプログラム部分のみ受信完了した場合など、プログラムデータが不完全な状態で更新され、電子制御ユニットが誤作動してしまうことを防止できる。

本発明に関わる第１０の構成は、上記構成１ないし３のいずれか１つの構成において、上記整備者端末の転送手段が、第１プログラム部分を上記送信手段に返送するものであると共に、上記送信手段は、上記返送された第１プログラム部分を、上記第２プログラム部分と共に上記更新端末に送信するものであることを特徴とするものである。

第１０の構成によれば、両プログラム部分が揃った状態で送信するので、更新端末において両プログラム部分が揃わず更新が不完全な状態となることを確実に防止できる。

本発明に関わる第１１の構成は、上記構成１ないし３のいずれか１つの構成において、上記送信手段は、上記第１プログラム部分を転送すべき更新端末の送信宛先を上記整備者端末に送信するものであることを特徴とするものである。

第１１の構成によれば、整備者が、第１プログラム部分の送信宛先の設定を容易かつ確実に行える。

本発明に関わる第１２の構成は、上記構成１ないし３のいずれか１つの構成において、上記更新端末の位置を検出する更新端末位置検出手段と、上記更新端末が設定された整備者端末の登録された所在地から所定距離以内に位置していない時には、該整備者端末により変更された第１プログラム部分を上記更新端末に送信することが規制されることを特徴とするものである。

第１２の構成によれば、整備者が整備対象機器を実際に確認せずにプログラムデータを変更することを抑制でき、より適切なサービスをユーザーに提供できる。

以上のように、本発明によれば、プログラムデータの変更を認められた部分である第１プログラム部分と認められていない部分である第２プログラム部分を分け、プログラムデータのうち第１プログラム部分は、データの変更が可能な整備者端末において変更できるので、従来どおり整備者が個別の電子制御ユニットおよびその制御対象の状態に対応した調整ができ、変更が認められていない第２プログラム部分は、整備者端末を介さずに更新端末に送信されるので変更されることを防止でき、サービス性を維持した上で、整備対象機器に対してメーカーの意図した性能を保証できる。

以下、本発明を実施するために最適と考える第１実施形態を、図面に基づいて説明する。
図１は、本発明の好適な第１実施形態に係るシステムの全体図、図２は、修理支援サーバと接続されるデータベースの構成図、図３は更新端末および車載ユニットの構成図である。

本実施形態は、整備対象機種が自動車であり、自動車を整備可能な施設を備えたサービス工場などにおいて、整備者からの依頼により、指定された車種の車両に搭載され、該車両を制御する電子制御ユニットである車載ユニットのプログラムデータを更新する場合に、本発明に係るプログラムデータ配信システムを適用した場合に関するものである。

図１に示すように、本発明に係るプログラムデータ配信システムは、プログラムデータの更新を必要とする自動車１（以降、整備対象車１と呼ぶ）に搭載され、該車両を制御する電子制御ユニットである車載ユニットと、同様に整備対象車１に搭載され、上記車載ユニットのプログラムデータを更新する更新端末と、更新用のプログラムデータを変更可能な修理業者等の整備者端末２と、上記プログラムデータを管理し必要に応じて設定された端末に送信可能な修理支援サとーバ３と、これらを通信可能に接続するネットワーク回線４とから構成され、本発明の第１実施形態は、整備者が上記整備者端末２を操作して上記修理支援サーバ３に上記整備対象車１のプログラムデータを更新するリプログラミング要求を行う場合を想定している。

上記ネットワーク回線４は、固定電話および自動車電話や携帯電話を含む電話回線、およびインターネット網、無線通信回線、赤外線等光通信回線等の各種通信回線の１つあるいは複数を組み合わせた回線から構成され、上記回線に接続可能な地域における任意の場所で端末やサーバから通信相手の宛先を指定することで遠距離通信が可能な通信回線を指すものとする。上記宛先とは上記ネットワーク回線が例えば電話回線であれば電話番号であり、インターネット網であればＵＲＬ（Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒｓ）であり、無線通信回線、赤外線等光通信回線であれば固有のコール信号であることが考えられる。

上記修理支援サーバの詳細を説明する。上記修理支援サーバ３は、上記ネットワーク回線４に接続されることで必要なデータを上記整備者端末２、及び更新端末５に送信可能な送信手段を備えると共に、上記プログラムデータを記憶するデータベース１００と回線が連結されている。該データベース１００には、上記プログラムデータのうち整備者端末２による変更が認められていない第２のプログラム部分であるリプログラミングデータ１０１と、変更が認められた第１のプログラム部分であるコンフィグレーションデータ１０２とが分けて記憶されている。

そして、整備対象車１において車載ユニットのプログラムデータを更新する必要が発生した場合は、上記リプログラミングデータ１０１を上記暗号プログラムによって暗号化し、直接上記更新端末５へ送信すると共に、上記コンフィグレーションデータ１０２を上記整備者端末２に送信するようになっている。

図２に示すように、上記データベース１００は、上記リプログラミングデータ１０１、コンフィグレーションデータ１０２の他に、自動的に故障を診断し、整備対象車１のユーザーや整備者、あるいは修理支援サーバに診断結果を報告するために、車種や個別の自動車の特性に応じて用意された最新の故障診断プログラム１０３、個別の自動車を識別する為の車両ＩＤデータ１０４、個別の整備者端末を識別する為の端末ＩＤデータ１０５、整備者端末の予め登録された所在地を記憶した整備者端末アドレスデータ１０６、後述する通信相手端末を認証する為の確認用認証プログラム１０７、送信データを暗号化するための暗号プログラム１０８、各種車載ユニットを識別する為のユニットＩＤデータ１０９を記憶しており、これらのデータおよびプログラムは夫々車種または個別の車両に対応した個別のファイルとして分割され、上記リプログラミングデータ１０１、コンフィグレーションデータ１０２、故障診断プログラム１０３、確認用認証プログラム１０７、暗号プログラム１０８、ユニットＩＤデータ１０９の各データは、対応する車両ＩＤに関連付けられ、一方整備者端末アドレスデータ１０６のアドレスデータは、端末ＩＤに関連付けられ、夫々上記修理支援サーバ３によって管理されている。またこれらのデータは、逐次更新されるようになっている。

次に整備者端末２の詳細を説明をする。図１に示すように、上記整備者端末２は、様々なデータ処理機能を実現する為に、演算装置や記憶装置、ディスプレイ、キーボード、マウス等の入出力装置、及びデータ変更手段、ネットワーク回線４に接続して通信可能な通信装置等を備え、任意のデータ処理機能を実現する為のプログラムを実行することで、該プログラムの目的とするデータ処理機能を提供できる、一般的にパーソナルコンピュータと呼ばれる周知の汎用性の高い機器から構成され、詳細については説明を省略する。

この整備者端末は、データベース２００を備えており、該データベースには、整備者の操作を受け付けることで上記コンフィグレーションデータ１０２を所定の範囲内で変更可能な機能を、整備者端末で実行されることで提供するコンフィグレーションプログラム２０１が記憶されている。

そして、このコンフィグレーションプログラム２０１は、上記修理支援サーバ３とネットワーク回線４を介して通信し、上記整備対象車１の上記コンフィグレーションデータ１０２を受信して記憶することができる。また受信したコンフィグレーションデータ１０２を整備者が必要に応じて変更することを受け付けた後、上記整備対象車１宛てに送信宛先を設定して送信することができるようになっている。

次に更新端末５の説明をする。図３に示すように、整備対象車１は、更新端末５と、電子制御ユニットの一例として燃料噴射量制御ユニット６とエアバッグ制御ユニット７を搭載している。これら電子制御ユニット６、７の性能は、整備対象車の走行性能または安全性といった商品価値への影響が大きいので、本発明を適用することが好ましい。
上記更新端末５は車載制御ユニット８と、無線通信を行う送受信アンテナ９と、データの記憶と読み出しおよび消去が可能な一時記憶メモリ１０とを備え、上記修理支援サーバ３で暗号プログラム１０８により暗号化されたデータを車載制御ユニット８で復号化する為の復号プログラム１１と、上記修理支援サーバ３の確認用認証プログラム１０７との間で認証用コードを交信し合うことで認証を行う為の応答用認証プログラム１２と、車両ＩＤ１３とを記憶しており、送受信アンテナ９を介してネットワーク回線４に接続されている。

また上記車載制御ユニット８は、キーの位置を検出するイグニッションスイッチ２６、ドアの開閉を検出するドアセンサ２７、複数のＧＰＳ衛星からの電波を受信することにより自車の位置を特定すると共に、位置情報を外部へ出力可能なＧＰＳユニット２８、ユーザーへの映像情報の出力とユーザーからの入力が可能なタッチパネルディスプレイ２９と通信可能に接続されている。これらイグニッションスイッチ２６及びドアセンサ２７、ＧＰＳユニット２８、タッチパネルディスプレイ２９は周知の製品を用いればよく、詳細については説明を省略する。

上記送受信アンテナ９は、専用の通信衛星や基地局と通信する無線アンテナの他、自動車電話や携帯電話のアンテナを利用し、ネットワーク回線４に接続することが考えられる。また無線によってインターネットに接続する無線ＬＡＮ（ローカルエリアネットワーク）技術によりネットワーク回線４に接続するようにしても良い。なお、無線に代えてユーザーの住居や公衆電話等において更新端末を有線で電話回線やインターネットに接続するものでも良い。この方法によれば、接続場所が限られる為、タイムリーなサービスを提供することに対して不利な点があるが、通信の速度と安定性の点で有利な場合が多く、特に送受信するデータが大量である場合は好ましい。また赤外線等の光を送信する素子と受信するセンサとから成る光通信ユニットを用いてネットワーク回線４に接続しても良い。

上記燃料噴射量制御ユニット６は、車輪の速度を検出して出力する車輪速検出センサ１４と、アクセルペダルの踏込み量を検出して出力するアクセルペダルセンサ１５と、エンジンの吸気量を調整するスロットル開度を出力すると共に制御信号に応じて開度を調整するスロットルアクチュエータ１６とに通信可能に接続され、また自身を制御する為のプログラムデータ１７と、整備対象車１の状態に対応させて制御量を調整する為のコンフィグレーションデータ１８を、更新可能に記憶しており、さらにユニット識別用のユニットＩＤ１９を書き換え不能に記憶している。

そして、上記燃料噴射量制御ユニット６は、上記プログラムデータ１７をコンフィグレーションデータ１８の設定に基いて動作させることで、上記各センサ１４、１５及びスロットルアクチュエータ１６から出力された車輪速、アクセルペダル踏込み量、スロットル開度に対応したスロットル開度と燃料噴射量を演算し、求められたスロットル開度となるようスロットルアクチュエータに制御信号を送信すると共に、求められた量の燃料を噴射するようになっている。

上記プログラムデータ１７及びコンフィグレーションデータ１８は、後述する所定の手順を踏むことで、上記修理支援サーバ３のデータベース１００に記憶された最新のリプログラミングデータ１０１、及びコンフィグレーションデータ１０２に更新されるようになっている。

上記コンフィグレーションデータ１８は、変更が予め定められた所定の範囲内で認められており、例えば使用されるタイヤサイズ、あるいは寒冷地や高地等の整備対象車の使用される自然環境やユーザーの走行に対する嗜好等、整備対象車１の状態が上記コンフィグレーションデータ１８の初期設定では最適ではない場合、燃料の噴射タイミングや噴射量、点火タイミング等を調整する為にプログラムの演算における補正量の設定変更が可能とされ、アイドリング回転数や出力特性等を調整できるようになっている。
その他、生産後に所定期間が経過した後、燃費や出力特性、耐久性などに関してより最適な最新の噴射タイミングや噴射量のデータが判明したときにも、このデータを反映して補正量の設定変更が可能とされている。

また上記エアバッグ制御ユニット７は、例えば正面衝突時に運転席と助手席に座る乗員の前方に展開され、乗員を衝撃から保護するエアバッグを制御するものであり、自車の減速度を検出し出力する減速度検出センサ２０と、自車の周囲にレーザーを発振して反射光を検出することで周囲の障害物との方向と距離とを検出し出力するレーザーレーダー２１と、制御信号に応じてエアバッグの展開を制御するエアバッグアクチュエータ２２とに、通信可能に接続され、また自身を制御する為のプログラムデータ２３と、自車の状態に対応させて制御量を調整する為のコンフィグレーションデータ２４を、後述する所定の手順を踏むことで、上記修理支援サーバ３のデータベース１００に記憶された最新のリプログラミングデータ１０１、及びコンフィグレーションデータ１０１に更新可能に記憶しており、さらにユニット識別用のユニットＩＤ２５を書き換え不能に記憶している。

そして、上記エアバッグ制御ユニット７は、上記プログラムデータ２３を上記コンフィグレーションデータ２４の設定に基いて動作させることで、上記減速度検出センサ２０及びレーザーレーダー２１から受信した減速度、及び障害物の位置と接近方向から、エアバッグ展開条件が満たされたかを演算し、展開条件が満たされたならばエアバッグ展開用の制御信号を上記エアバッグアクチュエータ２２に送信するようになっている。
上記コンフィグレーションデータ２４は、変更が予め定められた所定の範囲内で認められており、例えば、整備対象車１の主要な走行環境が荒地であるので、エアバッグが不意に開くことを防止する為にエアバッグ展開条件となる減速度の閾値を上昇させるなどの設定変更が可能とされている。
なお、上記エアバッグ制御ユニット７は、前面衝突用のエアバッグを制御するものに限らず、側面衝突時に乗員の側部に展開され、乗員を衝撃から保護するサイドエアバッグを制御するものであっても良い。

但し、上記車載制御ユニット８は、上記燃料噴射量制御ユニット６に記憶されたプログラムデータ１７とコンフィグレーションデータ１８、および上記エアバッグ制御ユニット７に記憶されたプログラムデータ２３とコンフィグレーションデータ２４、および一時記憶メモリ１０に記憶されたリプログラミングデータ１０１とコンフィグレーションデータ１０２とを、外部に出力することを禁止するようになっている。

次に、認証方法の説明を図を用いて行う。
図４は修理支援サーバ３と更新端末５との間における認証動作を説明する為の構成を示し、図５は本実施例で用いる認証動作のフローチャートを示す。
図２ないし４に示すように、修理支援サーバ３は、確認用認証プログラム１０７を備え、一方更新端末５は、応答用認証プログラム１２を備えている。
これら認証プログラム１０７、１２による認証方法は、一般的にチャレンジレスポンス方式と呼ばれる方式を採用している。

以下に上記認証方法を説明する。まず上記修理支援サーバ３は、更新端末５との通信を開始すると、データベース１００から確認用認証プログラム１０７を呼び出し、実行するようになっている。
図４に示すように、この確認用認証プログラム１０７は、更新端末５に送信する為のチャレンジコードを出力するチャレンジコード作成プログラム１０７ａと、上記チャレンジコードを読み込み、所定の演算に従って確認用のレスポンスコードを出力する確認用レスポンスコード作成プログラム１０７ｂを備え、
図５に示すように、上記確認用認証プログラム１０７は、認証が必要になったとき、ステップＳ４３０１において上記チャレンジコード作成プログラム１０７ａを動作させ、作成された上記チャレンジコードと、通信相手と予想される更新端末の車両ＩＤとを組み合わせた認証データを通信相手に送信し、ステップＳ４３０２において確認用レスポンスコード作成プログラム１０７ｂを動作させて、該確認用レスポンスコード作成プログラム１０７ｂに作成した上記チャレンジコードを渡して確認用レスポンスコードを作成し、ステップＳ４３０３にて所定時間レスポンスデータを待ち受ける状態に移行するようになっている。
もし所定時間以内にレスポンスデータを受信できない場合は、処理を終了するようになっている。

一方、更新端末５の応答用認証プログラム１２は、上記確認用レスポンスコード作成プログラム１０７ｂと同等のコードを出力する応答用レスポンスコード作成プログラム１２ｂを備えている。そして更新端末５は、車載ユニットのプログラムデータを更新可能な後述するリプログラミング許容モードとなる条件が成立した場合、車載制御ユニット８において上記応答用認証プログラム１２を動作させる。
この応答用認証プログラム１２は、ステップＳ４８０１において上記修理支援サーバ３から認証データを受け取ると、ステップＳ４８０２において車両ＩＤを照合し、一致した場合、ステップＳ４８０３に進み、上記応答用レスポンスコード作成プログラム１２ｂを動作させる。その後、ステップ４８０４において出力された応答用レスポンスコードを車両ＩＤと組み合わせたレスポンスデータを上記修理支援サーバ３に返信する。

上記修理支援サーバ３側の確認用認証プログラム１０７は、ステップＳ４３０４において上記更新端末５からの応答用レスポンスデータを受信すると、ステップＳ４３０５において受信した車両ＩＤおよび応答用レスポンスコードと上記修理支援サーバ３側の車両ＩＤおよび確認用レスポンスコード作成プログラム１０７ｂが出力した確認用レスポンスコードと比較し、一致した場合、ステップＳ４３０６に進み、通信相手が整備対象車１の更新端末５と認証ＯＫのフラグを立て、一方一致しなかった場合は、ステップＳ４３０７に進み認証ＮＧのフラグを立てるようになっている。
以上のようなチャレンジレスポンス方式の認証方法によれば、認証コードが一定ではないので十分なセキュリティ強度を確保でき、リプログラミングデータ等の誤送信や解析および変更、およびコピー可能な環境への送信を防止できる。

次に、本発明の第１実施形態におけるフローを図を用いて説明する。
図６乃至図１１は、本発明の第１実施形態におけるシステムのフローチャートであり、図６は主にサービスメニューを整備者が選択するまでの修理支援サーバと整備者端末の手順を示し、図７は、故障診断メニューが選択された場合の修理支援サーバと整備者端末の手順を示し、図８は、部品発注メニューが選択された場合の修理支援サーバと整備者端末の手順を示し、図９は、リプログラミングメニューが選択された場合の修理支援サーバと整備者端末の手順を示し、図１０および１１は、主にリプログラミングメニューが選択された場合の修理支援サーバと更新端末の手順を示すフローチャートである。また図１２は整備者端末２に表示されるメニュー画面であり、図１３はコンフィグレーションデータ調整画面、図１４は終了画面である。

図６に示すように、上記整備者端末２は、ステップＳ１２０１において、整備者からメニューリクエスト操作を受け付けると、上記修理支援サーバ３にメニューリクエスト信号を送信する。
上記修理支援サーバ３は、ステップＳ１３０１において、上記整備者端末２からのメニューリクエスト信号を受け付ける待ち受け状態になっており、上記整備者端末のメニューリクエスト信号が受信されたならば、ステップＳ１３０２に進む。
上記修理支援サーバ３は、ステップＳ１３０２において、上記整備者端末２に図１２に示すメニュー画面Ｗ１のデータを送信すると共に、記号Ｂ１１に進み、整備者端末２から送信される整備者の選択メニュー信号を受け付ける状態となる。

上記整備者端末２は、ステップＳ１２０２において整備者に受信したメニュー画面Ｗ１を表示する。このメニュー画面Ｗ１には、各種修理の項目として故障診断項目Ｗ１０１や部品発注項目Ｗ１０２、プログラムデータの更新を行うリプログラミング項目Ｗ１０３などが選択可能に表示されると共に、故障診断項目Ｗ１０１に対応して整備対象車１の車種コードを入力する車種コード入力欄Ｗ１０４が設けられ、部品発注項目Ｗ１０２に対応して発注する部品の部品コードを入力する部品コード入力欄Ｗ１０５、及び部品の費用請求先の業者コードを登録する業者コード入力欄Ｗ１０６が設けられ、リプログラミング項目Ｗ１０４に対応して整備対象車を識別する車両ＩＤを入力する車両ＩＤ入力欄Ｗ１０７、及び整備者端末を識別する端末ＩＤを入力する端末ＩＤ入力欄Ｗ１０８、更新が必要な車載ユニットを識別するユニットＩＤを入力する為のユニットＩＤ入力欄Ｗ１０９が設けられている。

これら入力欄は、図１２（ａ）の車種コード入力欄Ｗ１０４に示すように整備者が直接入力することができると共に、図１２（ｂ）のユニットＩＤ入力欄Ｗ１０９に対応するプルダウンメニューＷ１１０に示すように入力可能な情報が比較的少ない特定の種類に限られる、車種コード入力欄Ｗ１０４、部品コード入力欄Ｗ１０５、ユニットＩＤ入力欄Ｗ１０９については、入力欄に隣接して表示された検索ボタンＢ１０１、Ｂ１０２、Ｂ１０３が整備者により選択されることで、入力欄に対象となるコードのプルダウンメニューＷ１１０が表示され、簡単に必要な情報を選択できるようになっている。

なお、このプルダウンメニューＷ１１０に表示されるコードのデータは、メニュー画面とともに最新のデータを修理支援サーバから送信されるようになっている。このように、メニュー画面Ｗ１が、プルダウンメニューＷ１１０のリストも含めて修理支援サーバから整備者端末に送信されることで、整備者端末２のデータ容量及びデータのバージョンアップ作業を削減することができる。

そして、整備者端末２は、ステップＳ１２０３〜Ｓ１２０４において上記メニュー画面Ｗ１に表示された選択項目を整備者が選択する操作を受け付け、整備者により所望の項目が選択され、選択された項目に対する入力事項が入力された後、ＯＫボタンＢ１０４が選択されたならば、後述するステップＳ１２０５〜Ｓ１２０７に進んで選択された項目を判断し、対応する機能を提供するようになっており、キャンセルボタンＢ１０５が選択されたならば、処理を終了するようになっている。
この際、車載制御ユニット８は、何もせず記号Ａ１１に進むようになっている。

そしてステップＳ１２０５において、故障診断項目Ｗ１０１が選択され、この故障診断項目Ｗ１０１に対応した入力事項である車種コード入力欄Ｗ１０２に必要事項が入力されていると判断された場合には、記号Ｃ１１に進み、図７に示すようにステップＳ１２０８において、入力された車種コードと故障診断プログラム１０３の要求信号を上記修理支援サーバ３に送信するようになっている。

これに対して上記修理支援サーバ３は、ステップＳ１３０９において故障診断プログラム１０３の要求信号を受信すると、ステップＳ１３１０に進み、受信した車種コードに対応する故障診断プログラム１０３をデータベース１００から検索し、ステップＳ１３１１において上記整備者端末２へ検索で抽出した故障診断プログラム１０３を送信し、記号Ｂ１２に進むようになっている。しかしながら、上記ステップＳ１３０９において故障診断プログラム１０３の要求信号を受信できなかった場合は、何もせず記号Ｂ１２に進むようになっている。

上記整備者端末２は、ステップＳ１２０９において受信した上記故障診断プログラム１０３を実行して整備対象車１を診断する機能を提供した後、ステップＳ１２１０に進み診断結果を上記整備者に対して表示し、処理を終了する。
この際、車載制御ユニット８は、何もせず記号Ａ１２に進むようになっている。

このように整備対象車１に対応する最新の故障診断プログラムデータが修理サーバ３から整備者端末２に送信され、整備者端末２が整備対象車１に対して最新の故障診断プログラム１０３に基いた診断を行うことができる。

また整備者端末２は、図６に示すように上記ステップＳ１２０６において、部品発注項目Ｗ１０２が選択され、この部品発注項目Ｗ１０２に対応した発注する部品のコードが部品コード入力欄Ｗ１０５に入力されると共に、発注する部品の費用請求先となる業者のコードが業者コード入力欄Ｗ１０６に入力されていると判断された場合には、記号Ｃ１２に進み、図８に示すようにステップＳ１２１１において、選択された部品コードと登録された請求先の業者コードを部品発注信号と組み合わせた部品発注データを修理支援サーバ３に送信し、処理を終了するようになっている。

これに対して上記修理支援サーバ３は、ステップＳ１３１２において部品発注データを受信すると、ステップＳ１３１３に進み、受信した部品コードと一致する部品と費用請求書を、業者コードと一致する業者へ発送するよう手配し、記号Ｃ１３に進むようになっている。しかしながら、上記ステップＳ１３１２において部品発注データを受信できなかった場合は、何もせずに記号Ｂ１３に進むようになっている。
この際、車載制御ユニット８は、何もせず記号Ａ１３に進むようになっている。
このように、整備者は同じメニュー画面を呼び出して操作をするだけで故障診断の他に部品発注もできるため、作業の効率化ができる。

また整備者端末２は、図６に示すように上記ステップＳ１２０７において、リプログラミング項目Ｗ１０３が選択され、このリプログラミング項目Ｗ１０３に対応した整備対象車を識別する為の車両ＩＤを入力する車両ＩＤ入力欄Ｗ１０７と、整備者端末の端末ＩＤを入力する端末ＩＤ入力欄Ｗ１０８と、プログラムデータの更新が必要な車載ユニットを識別する為のユニットＩＤを入力するユニットＩＤ入力欄Ｗ１０９に必要事項が入力されていると判断された場合には、記号Ｃ１３へ進み、図９に示すようにステップＳ１２１２において、リプログラミング要求信号と共に、入力された車両ＩＤ、端末ＩＤ、ユニットＩＤを組み合わせたリプログラミング要求データを上記修理支援サーバ３に送信する。

これに対して上記修理支援サーバ３は、ステップＳ１３１４において、上記リプログラミング要求データを受信すると、ステップＳ１３１５に進み、受信した車両ＩＤに対応する更新端末１を、リプログラミングデータを送信すべき更新端末に設定し、受信した端末ＩＤに対応する整備者端末２を、コンフィグレーションデータを送信すべき整備者端末に設定した後、ステップＳ１３１６に進み、受信した車両ＩＤの車種及びユニットＩＤと一致するコンフィグレーションデータ１０２を検索する。しかしながら、上記ステップＳ１３１４において、上記リプログラミング要求データを受信できなかった場合は、処理を終了するようになっている。
そして、上記ステップＳ１３１６での検索が完了した後、ステップＳ１３１７において、車両ＩＤ、ユニットＩＤと共に、検索されたコンフィグレーションデータ１０２を整備者端末２に送信し、整備者により変更されたコンフィグレーションデータを受け付ける状態になる。

これに対して、整備者端末２は、ステップＳ１２１３において修理支援サーバ３からコンフィグレーションデータ１０２を受信すると、コンフィグレーションプログラム２０１を動作させて、例えば燃料噴射量制御ユニットのコンフィグレーションデータ調整であれば、図１３（ａ）に示すように、コンフィグレーションデータ調整画面Ｗ２によりコンフィグレーションデータを整備者に対して表示し、エアバッグユニットのコンフィグレーションデータ調整であれば、図１３（ｂ）に示すように、コンフィグレーションデータ調整画面Ｗ３によりコンフィグレーションデータを整備者に対して表示する。
そして、ステップＳ１２１４に進み、コンフィグレーションデータ１０２の変更を受け付ける状態となる。

ここで、整備者は必要に応じて上記コンフィグレーションデータ１０２を変更することができる。まず燃料噴射量制御ユニットのコンフィグレーションデータ調整を行う場合を説明する。上記整備者端末２は上記画面Ｗ２の整備対象車情報欄Ｗ２０１、Ｗ２０２、Ｗ２０３に、受信したコンフィグレーションデータ１０２に対応する車両ＩＤ、所有者、ユニットＩＤを表示する。また上記画面Ｗ２のコンフィグレーションデータ表示欄Ｗ２０４、Ｗ２０５、Ｗ２０６に、タイヤサイズ、アイドリング回転数、燃費改善係数等の値を変更可能に表示する。整備者は、これを見て表示されたコンフィグレーションデータがこれから整備する整備対象車１のものであるかを確認できる。

そして整備者は、Ｗ２０５の欄に整備対象車１の実際のタイヤサイズを入力すると共に、寒冷地や酷暑地、あるいは高地であるかどうか、またはエンジン等部品の経年変化などの条件を考慮して、最適なアイドリング回転数に変更することができる。また表示欄Ｗ２０６の燃費改善指数は、加速性能やアクセル操作に対するレスポンスを抑え、効率の良い燃焼状態を維持することを重視した燃費重視とするか、加速性能を高め、回転数と車速とのダイレクト感やアクセル操作に対するレスポンスを重視するか等のエンジン出力性能を、燃料の噴射量や噴射タイミング、および点火タイミングに関連付けて指数化した指数であり、整備者は、ユーザーの嗜好を聴いてこの燃費改善指数を変更することで、ユーザーに適した走行性能を提供することができ、ユーザーのサービス満足度を向上することができる。

次に、エアバッグユニットのコンフィグレーションデータ調整を行う場合を説明する。上記整備者端末２は図１３（ｂ）に示すようにコンフィグレーション調整画面Ｗ３の整備対象車情報欄Ｗ３０１、Ｗ３０２、Ｗ３０３に、受信したコンフィグレーションデータ１０２に対応する車両ＩＤ、所有者、ユニットＩＤを表示する。また上記画面Ｗ３のコンフィグレーションデータ表示欄Ｗ３０４、Ｗ３０５、Ｗ３０６に、衝撃判定指数、衝突予測指数、助手席展開可否等の値を変更可能に表示する。整備者は、これを見て表示されたコンフィグレーションデータがこれから整備する整備対象車１のものであるかを確認できる。

上記表示欄Ｗ３０４の衝撃判定指数は、減速度検出センサ２０の出力特性や、この減速度検出センサ２０の車体への取り付け位置により、入力される衝突荷重伝達特性を、実際に乗員が受ける衝撃力と関連付けて、どの程度の衝撃力が乗員に加わった時にエアバッグを展開すべきと判定するかどうかを指数化した指数であり、整備者は、例えば減速度検出センサ２０を交換して出力特性が変化した場合に適切な値に変更する、またはユーザーの運転状況を聞くなどして、例えば荒地走行が多く、通常走行時の衝撃が大きい場合には誤作動を防ぐ為に指数を鈍感な値に変更するなどの調整を行うことができる。

上記表示欄Ｗ３０５の衝突予測指数は、上記エアバッグ制御ユニット７が上記レーザーレーダー２１から受信した障害物との相対速度、及び障害物の位置と接近方向から、エアバッグ展開条件が満たされたかを演算する場合に、障害物との相対速度及び接近方向等の様々な異なる条件と、ユーザーの運転技能や、整備対象車１のブレーキ等走行性能に応じた衝突可能性に関して予めテストしたデータとを関連付けて指数化した指数であり、整備者は、ユーザーの運転技能や整備対象車１の走行条件が障害物と接近しやすいスポーツ走行であるかなどを考慮して、現状の展開条件を満たす場合でも展開させない方が良いと判断した場合に、ユーザーが衝突を回避できるにも係らずエアバッグが誤作動することを防止する為に、指数を鈍感な値に変更することができる。一方、逆にユーザーの反応速度が比較的遅いなどの状況では、回避よりも衝撃吸収による安全性向上を考慮して指数を敏感な値に変更することができる。

また上記表示欄Ｗ３０６の助手席展開可否は、助手席エアバッグを適用できないチャイルドシートを助手席に装着する場合等に、助手席エアバッグの展開を禁止する為のものであり、整備者は、ユーザーの使用状況を確認し、必要に応じて助手席エアバッグの展開を禁止するよう値を変更することができる。

このように上記整備者端末２は整備者からのコンフィグレーションデータ１０２の変更を受け付けた後、ステップＳ１２１５においてコンフィグレーションデータ調整画面Ｗ２またはＷ３に表示されたキャンセルボタンＢ２０２またはＢ３０２が選択されたかどうか判断し、選択された場合には処理を終了し、選択されない場合は次のステップＳ１２１６に進み、ＯＫボタンＢ２０１またはＢ３０１が選択されたかどうかが判断し、選択されなかった場合にはステップＳ１２１４に戻り、引き続きコンフィグレーションデータ調整画面Ｗ２またはＷ３を表示する。一方上記ステップＳ１２１６においてＯＫボタンＢ２０１またはＢ３０１が選択された場合には、ステップＳ１２１７へ進む。
そして、ステップＳ１２１７において、整備者による変更を受け付けた後のコンフィグレーションデータを上記車両ＩＤ、ユニットＩＤと共に上記修理支援サーバ３へ転送する。

上記修理支援サーバ３は、ステップＳ１３１８において上記変更後のコンフィグレーションデータを車両ＩＤ、ユニットＩＤと共に受信すると、ステップＳ１３１９において、整備者端末２から受信した車両ＩＤの車種及びユニットＩＤと一致するリプログラミングデータ１０１を検索する。
そして、ステップＳ１３２０に進み、上記ステップＳ１３１９において、暗号プログラム１０８を動作させることによって検索されたリプログラミングデータ１０１及び変更後のコンフィグレーションデータ１０２を、対応するユニットＩＤと共に上記整備者端末２から受信した車両ＩＤに固有の演算による暗号化処理をする。そして、記号Ｂ１４へ進むようになっている。

これにより、もし上記リプログラミングデータ１０１及び変更後のコンフィグレーションデータ１０２が、上記修理支援サーバ３から上記更新端末５への送信中継段階で変更可能な環境に置かれたとしても、車両ＩＤに固有の演算がなされ、かつ対象となるユニットＩＤと共に暗号化されているので、同車種の他車の暗号データと比較することができず、またこの暗号データの対象とするユニットＩＤも特定困難であるので、この暗号データの解析及び変更を困難とすることができる。
この際、車載制御ユニット８は、何もせず記号Ａ１４に進むようになっている。

その後、図１０に示すように、上記修理支援サーバ３は、ステップＳ１３２１において、受信した車両ＩＤに対応する整備対象車１との間で交信し、上記確認用認証プログラム１０７を動作させて認証を試みる。

これに前後して、更新端末５を構成する車載制御ユニット８では、ステップＳ１８０１において、車載ユニットのプログラムデータ更新を許容するリプログラミング許容モードの条件を満たすかどうかの判断が行われる。
上記条件は、この第１実施形態においてはドアセンサ２７からドア開閉の出力が３回検出された後、イグニッションスイッチ２６から、状態がＯＮ状態からＡＣＣ状態に３回切り替わった出力が検出されるものとしている。
その後、上記ステップＳ１８０１においてリプログラミング許容モードの条件を満たすと判断された場合は、ステップＳ１８０２に進み、リプログラミング許容モードとなって上記修理支援サーバ３からの認証を受け付ける状態となる。

次にステップＳ１８０２において、このリプログラミング許容モードを開始して１分間程度の比較的短い所定時間内において認証が始まったかどうか判断され、所定時間内に認証が始まらなければ処理を終了し、始まった場合には次のステップＳ１８０３に進むようになっている。

このようにリプログラミング許容モードとなる特殊な条件と時間とを限定することで、整備者が更新を行う際に整備対象車１の近傍にいなければならないことになり、整備者が車両を確認せずに更新を行ってしまうことや、ネットワーク回線を介して何らかの別データが正規のプログラムデータとして更新端末に受信されてしまうことを防止することができる。
また、上記リプログラミング許容モードの条件はこれに限定されるものではなく、整備者が整備対象車の近傍にいなければならない操作条件であればよい。なお、整備対象車の通常使用状態では実現困難な操作条件であることが好ましい。

そして、車載制御ユニット８は、上記ステップＳ１８０２において、１分以内に上記修理支援サーバからの認証が開始された場合、ステップＳ１８０３において上記応答用認証プログラム１２を動作させ、上記修理支援サーバ３からの認証を受け付ける。

これに対して、上記修理支援サーバ３は、ステップＳ１３２１において、上記確認用認証プログラム１０７により、上記応答用認証プログラム１２との間で上述のチャレンジレスポンス方式での認証を試み、通信相手が整備対象車１の更新端末５であると判断すると認証ＯＫのフラグを立て、そうでなければ認証ＮＧのフラグを立てる。その後、上記修理支援サーバ３は、ステップＳ１３２２に進む。

なおこの認証は、上記修理支援サーバ３から上記車載制御ユニット８へ複数回異なるチャレンジコードを送信し、上記車載制御ユニット８から返信される複数の応答用レスポンスコードと修理支援サーバ側の確認用レスポンスコードについて、所定回数以上連続して一致する場合に認証ＯＫとするようにし、通信エラーによる誤認を防ぎ、かつ認証の信頼性を向上させた方法を採用しても良い。

そして上記修理支援サーバ３は、ステップＳ１３２２において認証結果が認証ＮＧであると判断すると処理を終了し、認証ＯＫと判断すると次のステップＳ１３２３に進む。ステップＳ１３２３では、車両ＩＤ及び暗号化されたユニットＩＤ、リプログラミングデータ１０１、コンフィグレーションデータ１０２を車載制御ユニット８へ送信する。

これに対して、車載制御ユニット８は、ステップＳ１８０４において車両ＩＤ及び暗号化されたユニットＩＤ、リプログラミングデータ１０１、コンフィグレーションデータ１０２を受信し、記号Ａ１５へ進む。

図１１に示すように、車載制御ユニット８は、ステップＳ１８０５において再度リプログラミング許容モードの条件を満足するか判断する。この判断は、上記ステップＳ１８０１における判断とは条件が異なり、車速が０であり、かつイグニッションスイッチ２６の出力がＡＣＣであることとしている。これにより、直後のプログラムデータ更新を控え、確実に整備対象車１が停車し、エンジンが作動しない条件とすることで、プログラムデータ更新中に車載ユニットが不具合を起こすことを防止できる。そして、上記ステップＳ１８０５においてリプログラミング許容モードの条件を満足しないと判断された場合は、処理を終了する一方、条件を満足すると判断された場合は、ステップＳ１８０６に進む。
なお、上記ステップＳ１８０１の段階においては、まだ車載制御ユニットのプログラムデータ等が更新されるわけではないので、整備対象車を多少移動させることや、通信時のバッテリ上がりを防ぐ為にエンジンを作動させることなどを許容することでサービス性を高めることができる。

次に、上記車載制御ユニット８は、ステップＳ１８０６において、復号プログラム１１を動作させる。該復号プログラム１１は、整備対象車１の車両ＩＤ１３に固有の演算によって上記修理支援サーバより受信したリプログラミングデータ１０１、コンフィグレーションデータ１０２及びユニットＩＤを復号化し、そしてステップＳ１８０７において、復号化した各データを上記一時記憶メモリ１０に一時記憶する。

続いてステップＳ１８０８において、例えば対象ユニットが燃料噴射量制御ユニット６であった場合、リプログラミングデータ１０１を復号したユニットＩＤと一致するユニットＩＤ１９を有する燃料噴射量制御ユニット６のプログラムデータ１７として更新を行い、同様にコンフィグレーションデータ１０２を、燃料噴射量制御ユニット６のコンフィグレーションデータ１８として更新を行い、上記リプログラミングデータ１０１とコンフィグレーションデータ１０２とを燃焼噴射制御ユニット６に対して有効にする。
その後、ステップＳ１８０９において、上記プログラムデータ１７及びコンフィグレーションデータ１８の更新が両方とも完了した後、上記修理支援サーバ３に完了信号を送信し、処理を終了する。

図１４は、リプログラミング作業の完了を報知する画面であり、上記修理支援サーバ３は、ステップＳ１３２４において、上記車載制御ユニット８からの完了信号を受信すると、上記整備者端末２に上記完了信号を転送すると共に処理を終了する。さらに、上記整備者端末は、ステップＳ１２１８において、上記修理支援サーバ３から転送された上記完了信号を受信すると、図１４に示す完了画面Ｗ４を端末に表示して、整備者にリプログラミング作業終了を報知した後、ステップＳ１２１９においてボタンＢ４が選択されると処理を終了する。
なお、リプログラミング作業が終了した際に、整備対象車１のタッチパネルディスプレイ２９に完了画面Ｗ４を表示しても良い。

以上の構成により、本発明の第１実施形態においては、サーバによってデータを常に最新の状態に一元管理し、最新のデータをネットワーク回線を介して遠距離にいる整備対象車や整備者端末に届けることができるようになっており（請求項２の効果）、車載ユニットのプログラムデータ及びコンフィグレーションデータを更新る際、変更が認められていないリプログラミングデータについては整備者端末を介さずに整備対象車の更新端末に送信されるので、プログラムデータが変更されることを防止できると共に、自動車の状態に応じて調整が必要なコンフィグレーションデータについては、整備者端末での変更が可能であるので、サービス性を確保しながら、メーカーの意図する自動車の性能や安全性を保証することができる。（請求項１、３の効果）この際、コンフィグレーションデータについては、整備者端末で整備者の変更を受け付けなければ車載ユニットに送信されることがないので、整備の信頼性を向上できる。

また、通信相手を認証する認証手段を備えている為、通信相手が更新端末でない場合は、データを変更できる端末である可能性があるが、リプログラミングデータが更新端末に直接送信されることで、このリプログラミングデータの変更を防止できる。（請求項４の効果）

さらに、リプログラミングデータは修理支援サーバから更新端末へ送信する際に車両ＩＤ固有の演算によりユニットＩＤと共に暗号化されるので、リプログラミングデータの送信の中継手段として更新端末以外の別端末を利用する場合など、リプログラミングデータが変更またはコピー可能な環境に置かれる場合であっても、データの内容の解析が困難であり変更を抑制できる。（請求項５の効果）

また、更新端末は、リプログラミングデータを整備者端末に出力する手段を備えない為、リプログラミングデータが変更可能な環境に置かれることを防ぎ、変更を防止できる。（請求項６の効果）

また、整備者端末で変更されたコンフィグレーションデータが一端修理支援サーバに転送され、修理支援サーバからリプログラミングデータと共に完全な状態で更新端末に送信されるので、更新端末において更新用のデータが揃わない不完全な状態となることを確実に防止できる。（請求項１０の効果）

次に、本発明の第２実施形態を図面に基いて説明する。
図１５ないし図１７は、本発明の第２実施形態におけるシステムのフローチャートであり、図１５は主に修理支援サーバから車載ユニットのプログラムデータの更新依頼を整備対象車に送信する際の通信手順を示すものであり、図１６は、主にコンフィグレーションデータを変更する際の手順を示すものであり、図１７は、主に整備対象車の車載ユニットのプログラムデータ及びコンフィグレーションデータを更新する際の手順を示すものである。また図１８は、車載ユニットのプログラムデータの更新依頼、及び整備を依頼する整備者選択を行う為の整備者選択画面を示すものである。

本実施形態は、特定の対象車種に対して車載ユニットのプログラムデータを更新する必要があるとメーカーが判断し、メーカーから対象車に最新のリプログラミングする要求がある場合に、本発明に係るプログラムデータ配信システムを適用したものである。本実施形態は、上記第１実施形態とシステム構成が共通する為、共通する部分は同じ符号を用い、異なる部分についてのみ詳細を説明する。

図１５に示すように、上記修理支援サーバ３は、ステップＳ２３０１において、所定周期が経過するまで待機し、所定周期が経過した場合は、ステップＳ２３０２に進み、最新の情報が蓄積されているデータベース１００の情報にアクセスして、特定車種の全車両ＩＤ、または特定のユニットＩＤに関連するリプログラミングデータ１０１から、未送信のデータを検索し、未送信のリプログラミングデータ１０１と関連する車両ＩＤを特定車両ＩＤとして検索結果を出力する。

そして、ステップＳ２３０３において、検索結果がないと判断された場合は、ステップＳ２３０１に戻り、さらに所定周期が経過するまで待機する。一方、上記ステップＳ２３０３において、検索結果があると判断された場合は、上記特定車両ＩＤに対応する整備対象車１に対して、車載ユニットのプログラムデータおよびコンフィグレーションデータを最新のものに更新する必要があるため、ステップＳ２３０４に進む。このステップＳ２３０４で修理支援サーバ３は、上記特定車両ＩＤをリプログラミングデータの送信先に設定する。
こうすることで、確実にリプログラミングが必要な整備対象車１の抽出が可能であると共に、リプログラミングの必要な機会が短期間に複数発生したとしても、所定期間ごとにまとめて対応するので、ユーザーの負担を軽減できる。もちろん、至急リプログラミングが必要な場合には、その都度対応できるようにすることが好ましい。

図１５および図１８に示すように、ステップＳ２３０５では、上記特定車両ＩＤと対応する整備対象車１の車載制御ユニット８に対して、プログラムデータを更新するリプログラミングの依頼及び整備者選択をユーザーに行ってもらう為の整備者選択画面Ｗ５のデータを送信する。この整備者選択画面Ｗ５のデータには、上記データベース１００に予め登録された整備者端末アドレスデータ１０６に記録された整備者の名称とアドレスが含まれている。

これに対応して、上記車載制御ユニット８は、ステップＳ２８０１において、この整備者選択画面データＷ５を受信し、上記タッチパネルディスプレイ２９に表示する。
この整備者選択画面Ｗ５は、プログラムデータを更新する必要のあるユニット及び理由を表示すると共に、整備者選択欄Ｗ５０１に任意の整備者に対応する整備者ＩＤを選択できるようになっている。なお本実施形態においては、上記整備者ＩＤを上記整備者端末の端末ＩＤと共通にしている。

整備者ＩＤを選択するには、検索ボタンＢ５０２を選択し、プルダウンメニューＷ５０２に表示される、整備者ＩＤに名称とアドレスが付加された一覧から任意の整備者ＩＤを選択するようになっており、ステップＳ２８０４において整備者ＩＤが選択された後、ＯＫボタンＢ５０１が選択されたことを検出すると、ステップＳ２８０５に進み、自車の車両ＩＤと整備者選択欄Ｗ５０１に選択された整備者の端末ＩＤを修理支援サーバに送信した後、記号Ａ２１に進む。
一方、上記修理支援サーバ３は、ステップＳ２３１０において、上記車載制御ユニット８から特定車両ＩＤと端末ＩＤのデータを受信し、受信した端末ＩＤを上記コンフィグレーションデータ１０２の送信先に設定した後、記号Ｂ２１に進むようになっている。このような構成により、上記整備対象車１のユーザーが、整備者への好みやアドレスから任意の整備者を選択できるので、サービス性を向上できる。

上記車載ユニット８側の整備者選択操作受け付け処理に前後して、上記修理支援サーバ３では、ステップＳ２３０６に進み、上記特定車両ＩＤにのみ対応する方法によって上記ユニットＩＤ及びリプログラミングデータを暗号化した後、ステップＳ２３０７において、上記車載制御ユニット８に対して、上述のチャレンジレスポンス方式による認証を試みる。これに対して、上記車載制御ユニット８は、ステップＳ２８０２で上述のチャレンジレスポンス方式による応答を行う。そして、上記修理支援サーバ３は、ステップＳ２３０８で認証ＮＧと判断すると処理を終了し、認証ＯＫと判断すると次のステップＳ２３０９に進み、車載制御ユニット８に対して暗号化したユニットＩＤ１０９とリプログラミングデータ１０１とを送信する。このように、修理支援サーバが車載制御ユニットにリプログラミングデータを送信する前に、車載制御ユニットが本物であるかどうかを認証する為、仮に同じ宛先を有する別の機器がネットワーク回線上に存在しても、誤送信を防止できる。

一方、車載制御ユニット８は、上記整備者選択操作受け付け処理に前後して、ステップＳ２８０３において、ユニットＩＤ１０９とリプログラミングデータ１０１を受信すると共に、上記一時記憶メモリ１０に一時的に記憶する。この際、上記整備者端末２は何もせずに記号Ｃ２１へ進む。
なお、ユニットＩＤ１０９及びリプログラミングデータ１０１の上記修理支援サーバ３からの送信処理と上記車載制御ユニット８の受信及び一時記憶処理は、上記整備者選択操作受け付け処理に並行して自動的に実行されるようになっており、ユニットＩＤ１０９及びリプログラミングデータ１０１の受信を順番に処理する場合に比して、整備者選択操作を受け付ける際の車載制御ユニット８の待機時間や通信回線の空きを有効に活用し、上記車載制御ユニット８の負荷増加を抑えながら処理時間を短縮している。

図１６に示すように、上記修理支援サーバ３は、ステップＳ２３１１において、設定された端末ＩＤの整備者端末２に対して上記特定車両ＩＤと、これに対応する上記コンフィグレーションデータ１０２、及び宛先を送信する。これに対して整備者端末２は、ステップＳ２２０１において上記特定車両ＩＤとコンフィグレーションデータ１０２を受信し、ステップＳ２２０２において受信完了と判断すると、ステップＳ２２０３に進み、受信完了信号を上記修理支援サーバ３に送信すると共に、上記コンフィグレーションデータ１０２の送信宛先を、先に受信した上記車載制御ユニット８の宛先に設定するようになっている。

上記修理支援サーバ３は、ステップＳ２３１２において、受信完了信号を受信し、ステップＳ２３１３で受信完了信号を受け付けたと判断した時にステップＳ２３１４に進み、そうでなければ受信完了信号受付状態を保持する。ステップＳ２３１４では、上記特定車両ＩＤの車載制御ユニット８に対して、整備案内画面Ｗ６のデータを送信した後、記号Ｂ２２に進むようになっている。

ここで図１９は整備対象車１に整備を案内する画面であり、上記車載制御ユニット８は、図１９に示すように、ステップＳ２８０６において、上記整備案内画面Ｗ６を受信してタッチパネルディスプレイ２９に表示し、ステップＳ２８０７において、ＯＫボタンＢ５が選択されたと判断するまで表示し続け、ＯＫボタンＢ５が選択されたと判断すると、ステップＳ２８０８に進むようになっている。このように、整備者端末２がコンフィグレーションデータ１０２を受信完了した後に整備案内画面Ｗ６が整備対象車１のタッチパネルディスプレイ２９に表示されるので、ユーザーは整備対象車１を整備者端末２の場所へ出向いた後に、整備者端末２がコンフィグレーションデータ１０２を受信する時間待たされることが無く、サービス性を向上できる。

上記整備者端末２は、ステップＳ２２０４において、コンフィグレーションプログラム２０１を動作させて、図１３（ａ）に示すように、コンフィグレーションデータ調整画面Ｗ２を表示し、上記コンフィグレーションデータ１０２の変更を受け付ける状態となる。ここで、整備者は上記コンフィグレーションデータ１０２を変更することができる。その後、ステップＳ２２０５においてコンフィグレーションデータ調整画面Ｗ２に表示されたキャンセルボタンＢ２０２が選択されたかどうか判断して、選択された場合は処理を完了し、そうでない場合はステップＳ２２０６に進む。ステップＳ２２０６においては、ＯＫボタンＢ２０１が選択されたかどうかを判断して、選択された場合はステップＳ２２０７に進み、選択されなかった場合はステップＳ２２０４に戻る。

上記整備者端末２は、ステップＳ２２０７において、上記車載制御ユニット８の宛先にアクセスし、整備対象車１の特定車両ＩＤ、変更後のコンフィグレーションデータ１０２、ユニットＩＤ１０９とを直接送信した後、記号Ｃ２２に進む。

これに対して上記車載制御ユニット８は、ステップＳ２８０８において、上記整備者端末２から特定車両ＩＤ、変更後のコンフィグレーションデータ１０２、ユニットＩＤとを受信し、ステップＳ２８０９において、特定車両ＩＤ、リプログラミングデータ１０１、変更後のコンフィグレーションデータ１０２、ユニットＩＤ１０９とがすべて受信完了しているかどうかを検出し、受信完了している場合、この実施形態において対象となる燃料噴射量制御ユニット６に対して、リプログラミングデータ１０１及び変更後のコンフィグレーションデータ１０２を有効にすることが可能な状態であるとして、記号Ａ２２へ進み、そうでない場合は受信を完了するまで待機する。

車載制御ユニット８は、ステップＳ２８１０において、車載ユニットのプログラミングデータ更新を許容するリプログラミング許容モードの条件である、ＧＰＳユニット２８の出力する現在地が整備者端末のアドレスと誤差の範囲内で一致し、車速が０であり、かつイグニッションスイッチ２６の出力がＡＣＣであるかを満たすかどうかの判断を行い、条件を満足しないと判断された場合は、処理を終了する。一方条件を満足する場合は、ステップＳ２８１１に進み、整備対象車１の車両ＩＤ固有の演算によって、上記修理支援サーバより受信したリプログラミングデータ１０１及びユニットＩＤを復号化し、そしてステップＳ２８１２において、復号化した各データを上記一時記憶メモリ１０に一時記憶する。これにより、整備対象車１が実際に整備者端末２の場所にあり、かつ暴走の恐れのない状態であることが保証され、安全に車載ユニットのリプログラミング作業を行うことができる。

続いて、ステップＳ２８１３において、燃料噴射量制御ユニット６のリプログラミングデータ１０１を、復号したユニットＩＤと一致するユニットＩＤ１９を有する燃料噴射量制御ユニット６のプログラムデータ１７として更新を行い、同様にコンフィグレーションデータ１０２を、燃料噴射量制御ユニット６のコンフィグレーションデータ１８として更新を行った後、上記リプログラミングデータ１０１とコンフィグレーションデータ１０２とを燃焼噴射制御ユニット６に対して有効にする。
その後、ステップＳ２８１４において、上記プログラムデータ１７及びコンフィグレーションデータ１８の更新が両方とも完了した後、上記修理支援サーバ３に完了信号を送信し、処理を終了する。

上記修理支援サーバ３は、ステップＳ２３１５において上記車載制御ユニット８からの完了信号を受信すると、上記整備者端末２に上記完了信号を転送すると共に処理を終了する。さらに、上記整備者端末は、ステップＳ２２０８において、上記修理支援サーバ３から転送された上記完了信号を受信すると、図１４に示す完了画面Ｗ４を端末に表示して、整備者にリプログラミング作業終了を報知した後、ステップＳ２２０９において、ボタンＢ４が選択されると処理を終了する。

以上の構成により、本発明の第２実施形態においては、車載ユニットのプログラムデータ及びコンフィグレーションデータを更新する際、変更が認められていないリプログラミングデータについては整備者端末を介さずに整備対象車の更新端末に送信されるので、プログラムデータが変更されることを防止できると共に、整備対象車の状態に応じて調整が必要なコンフィグレーションデータについては、整備者端末での変更が可能であるので、サービス性を確保しながら、メーカーの意図する自動車の性能を保証することができる。（請求項１、３の効果）

また、通信相手を認証する認証手段を備えている為、通信相手が更新端末でない場合は、データを変更できる端末である可能性があるが、リプログラミングデータが更新端末に直接送信されることで、このリプログラミングデータの変更を防止できる。（請求項４の効果）

さらに、リプログラミングデータは修理支援サーバから更新端末へ送信する際に車両ＩＤ固有の演算によりユニットＩＤと共に暗号化されるので、リプログラミングデータの送信の中継手段として更新端末以外の別端末を利用する場合など、リプログラミングデータが変更またはコピー可能な環境に置かれる場合であっても、データの内容の解析が困難であり変更を抑制できる。（請求項５の効果）

さらに、リプログラミング作業前に予め更新端末により整備者端末を指定して、指定された整備者端末にコンフィグレーションデータを送信する為、送信先を限定でき、送信作業を効率化できると共に、整備対象車が整備者端末のある場所に着く前に、指定された整備者端末へ修理支援サーバからコンフィグレーションデータの送信を開始できるので、整備対象車が整備者端末のある場所に着いてからのコンフィグレーションデータ受信の時間を低減して、迅速なサービスを提供できる。（請求項７の効果）

さらに、コンフィグレーションデータが整備者端末に送信完了した後にユーザーへ整備案内が報知される為、案内を受けた後であれば整備対象車を整備者端末のある場所へ何時出向こうとも、既に整備者端末はプログラムデータ変更に必要な環境が整っており、ユーザーに第１プログラム部分受信の時間を待たせることなく迅速なサービスを提供できる。（請求項８の効果）

また更新端末は、受信されたリプログラミングデータと変更されたコンフィグレーションデータの対象となる電子制御ユニットへの記憶が完了したことを検出して、両データを対象となるユニットに対して更新されるものであるので、一方のみ受信を完了した不完全な状態で対象となるユニットに対して更新されることを防止し、もって誤作動を防止できる。（請求項９の効果）

また、整備者端末には、コンフィグレーションデータと共に更新端末の送信宛先も送信されるので、整備者は、コンフィグレーションデータを送信すべき整備対象車の更新端末への送信宛先の設定を容易かつ確実に行え、誤送新を防止できる。（請求項１１の効果）

また、整備者端末の登録された所在地と整備対象車の現在地が一致しなければリプログラミング許容モードにならないため、整備者が整備対象車１を実際に確認できない程離れた状態でコンフィグレーションデータの更新をすることを防ぎ、整備者が確認せずにコンフィグレーションデータが更新されるという事態を抑制できる。（請求項１２の効果）

次に、本発明の第３実施形態を図面に基いて説明する。
図２０は、本発明の第３実施形態におけるプログラム配信システムのフローチャートであり、図２１は、車載ユニットのプログラムデータの更新依頼、及び整備を依頼する整備者選択を行う為の整備者選択画面を示すものである。

本実施形態は、特定の対象車種に対して所定の周期でネットワーク回線を利用して遠隔呼称診断を行い、車載ユニットのプログラムデータを更新する必要があるとの結果が出た場合に、本発明に係るプログラムデータ配信システムを適用したものである。本実施形態は、上記第１、第２実施形態とシステム構成が共通する為、共通する部分は同じ符号を用い、異なる部分についてのみ詳細を説明する。

図２０に示すように、上記修理支援サーバ３は、ステップＳ３３０１において、所定周期待機する。そして所定周期経過するとステップＳ３３０２に進み、データベース１００から故障診断プログラム１０３を起動して整備対象車１に対して交信し、遠隔故障診断を実行する。この故障診断プログラム１０３は、車載制御ユニット８に対して車輪速検出センサ１４、アクセルペダルセンサ１５、減速度検出センサ２０、レーザーレーダー２１等の各センサの出力値データを上記修理支援サーバ３に送信するよう命令し、この命令を上記車載制御ユニット８は、ステップＳ３８０１において受信すると共に、上記各種センサの出力データを返信する。上記修理支援サーバ３は、車載制御ユニット８から受信した各種センサの出力値データから、予め設定された故障判断処理に基いて故障の有無を検出するようになっている。

次に、上記修理支援サーバ３は、ステップＳ３３０３において、故障と判断されなかった場合、ステップＳ３３０１に戻る。一方故障と判断された場合は、ステップＳ３３０４に進み、その故障がリプログラミングが必要なものであれば、ステップＳ３３０５に進み、整備対象車１の車載制御ユニット８に対して、図２１に示すように、プログラムデータを更新するリプログラミングの依頼及び整備者選択をユーザーに行ってもらう為の整備者選択画面Ｗ７のデータを送信する。これに対して、上記車載制御ユニット８は、ステップＳ３８０２において上記整備者選択画面Ｗ７のデータを受信し、タッチパネルディスプレイ２９に表示する。
一方、ステップＳ３３０４において、故障が修理の必要なものである場合は、本実施形態では説明しないが、ユーザーに故障を通知し修理を促すなどの別途修理に必要な対策を講じることが好ましい。

その後、上記修理支援サーバ３は、ステップＳ３３０６において、整備対象車１の車両ＩＤおよび故障内容に対応したユニットＩＤ、リプログラミングデータ１０１、コンフィグレーションデータ１０２を検索してステップＳ３３０７に進み、上記暗号プログラム１０８を動作させて、ユニットＩＤとリプログラミングデータと１０１とを、車両ＩＤに固有の演算によって暗号化処理をする。

そして、上記修理支援サーバ３は、ステップＳ３３０８において、車両ＩＤに対応する整備対象車１との間で交信し、上記確認用認証プログラム１０７を動作させて認証を試みる。これに対して、車載制御ユニット８ではステップＳ３８０３において、上記応答用認証プログラム１２を動作させ、上記修理支援サーバ３からの認証を受け付ける。
その後、上記修理支援サーバ３は、上述のチャレンジレスポンス方式での認証を試み、通信相手が整備対象車１の更新端末５であると判断すると認証ＯＫのフラグを立て、そうでなければ認証ＮＧのフラグを立て、ステップＳ３３０９へ進む。

上記修理支援サーバ３は、ステップＳ３３０９において、認証結果が認証ＮＧであると判断すると処理を終了し、認証ＯＫと判断すると次のステップＳ３３１０に進む。ステップＳ３３１０では、車両ＩＤ及び暗号化されたユニットＩＤ、リプログラミングデータ１０１を車載制御ユニット８へ送信する。これに対して上記車載制御ユニット８は、ステップＳ３８０４において、車両ＩＤ及び暗号化されたユニットＩＤ、リプログラミングデータ１０１を受信すると共に、上記一時記憶メモリ１０に一時記憶する。

また図２１に示すように、上記車載制御ユニット８は、上記ステップＳ３８０３〜ステップＳ３８０４を実行する間、これと並行して上記ステップＳ３８０２で表示した画面Ｗ７において、整備者選択欄Ｗ７０１での整備者ＩＤ選択を受け付けている。そしてステップＳ３８０５においてＯＫボタンＢ７０１が選択されたかどうかを判断し、条件を満足した場合には、ステップＳ３８０６に進み、自車の車両ＩＤと選択された整備者の端末ＩＤとを、上記修理支援サーバ３に送信した後、上記第２実施形態における記号Ａ２１以降のフローと同様のフローへ進むようになっており、説明は省略する。一方ステップＳ３８０５において条件を満足しなかった場合には、ステップＳ３８０７に進み、キャンセルボタンＢ７０２が選択されたかどうかを判断し、キャンセルボタンＢ７０２が選択された場合は、ステップＳ３８０８に進み、上記一時記憶した車両ＩＤ及び暗号化されたユニットＩＤ、リプログラミングデータ１０１を消去して処理を終了する。一方キャンセルボタンＢ７０２も選択されなかった場合は、ステップＳ３８０５に戻るようになっている。

なお、検索ボタンＢ７０３は、選択されることによって上記第２実施形態における検索ボタンＢ５０２同様に整備者ＩＤに名称とアドレスが付加された一覧をプルダウンメニューとして表示するものである。このようにユニットＩＤ１０９及びリプログラミングデータ１０１の上記修理支援サーバ３からの送信処理と上記車載制御ユニット８の受信及び一時記憶処理は、上記整備者選択操作受け付け処理に並行して自動的に実行されるようになっており、上記第２実施形態と同様に処理時間を短縮している。

上記修理支援サーバ３は、ステップＳ３３１１において上記車載制御ユニット８から送信される車両ＩＤおよび選択された整備者の端末ＩＤを受信すると、この端末ＩＤに対応する整備者端末２を上記コンフィグレーションデータ１０２の送信先に設定した後、上記第２実施形態の記号Ｂ２１以降と同様のフローへ進むようになっており、説明は省略する。なお、整備者端末２のフローは、上記第２実施形態と同様のフローであるので説明は省略する。

以上の構成により、本発明の第３実施形態においては、最新の故障診断プログラムによって、サービス工場などの施設に立ち寄ることなく定期的に故障を診断でき、ユーザーへの負担を軽減しながら素早く故障に対応できると共に、上記第２実施形態と同様の効果を奏することができる。

以上、本発明を実施するための最良の形態を、図面に基づいて説明したが、実施の形態は、これらに限定されるものではない。

例えば、上記本発明の第１ないし第３実施形態においては、修理支援サーバ３が整備対象車１を認証するにあたり、チャレンジレスポンス方式による認証方法を採用しているが、認証方法はこれに限定されるものではない。例えば、後述するローリングコード方式による認証方法を採用しても良く、以下にこのローリングコード方式の認証方法を説明する。
図２２は、修理支援サーバと更新端末との間におけるローリングコード方式による認証方式の認証動作を説明する為の構成を示し、図２３はローリングコード方式における認証動作のフローチャートを示す。

図２２および２３に示すように、修理支援サーバ３は、ローリングコード方式の確認用認証プログラム１０７’を備え、一方更新端末５は、ローリングコード方式の応答用認証プログラム１２’を備えている。また上記確認用認証プログラム１０７’は、前回受信コードを元にローリングコードを作成する確認用ローリングコード作成プログラム１０７ａ’を備え、上記応答用認証プログラム１２’は、前回送信コードを元にローリングコードを作成する応答用ローリングコード作成プログラム１２ａ’を備えており、これら確認用および応答用ローリングコード作成プログラムは、予め設定された同じ複数のコードを同じ順番で出力するものであり、最後のコードを出力すると次は最初のコードを出力するようになっている。

以下に上記ローリングコード方式の認証方法を説明する。このローリングコード方式の認証方法とは、予め設定された複数のコードを順番に使用し、最後のコードを使用すると、また最初のコードを使用するようになっており、前回使用したコードから次回使用するコードが特定されることを利用して認証を試みるものである。なお、本認証方法では６回ほど認証を試み、この間に３回連続して正しいコードの回答を受信することが認証条件となっている。

まず上記修理支援サーバ３は、認証が必要になったときデータベース１００から確認用認証プログラム１０７’を呼び出し実行する。この確認用認証プログラム１０７’は、ステップＳ５３０１において応答用認証プログラム１２’からの連続正答回数をカウントするカウント変数ａと、認証の試行回数をカウントするサイクル変数ｃとの値を０に初期化すると共に、認証用のフラグを認証ＮＧに設定した後、ステップＳ５３０２に進み更新端末５にコードリクエスト命令を送信するようになっている。

一方上記更新端末５では、上記車載制御ユニット８によって上記応答用認証プログラム１２’が実行され、この応答用認証プログラム１２’は、前回送信した前回送信コードを記憶していると共に、ステップＳ５８０１において上記コードリクエスト命令を受信すると、ステップＳ５８０２に進み、応答用ローリングコード作成プログラム１２ａ’を動作させて前回送信コードを元にローリングコードを生成する。そしてステップＳ５８０３に進み、自車の車両ＩＤと共に生成したコードを送信し、その後ステップＳ５８０４において送信コードを上記一時記憶メモリ１０に一時記憶して処理を終了する。

そして上記修理支援サーバ３は前回受信した前回受信コードを記憶しており、上記確認用認証プログラム１０７’は、ステップＳ５３０３において、確認用ローリングコード作成プログラム１０７ａ’を動作させて記憶している上記前回受信コードを元にローリングコードを生成し、ステップＳ５３０４に進み生成されたローリングコードを受信予定コードとして記憶する。
その後、ステップＳ５３０５において上記応答用認証プログラム１２’からローリングコードを受信し、ステップＳ５３０６に進み、受信したローリングコードを受信コードとして記憶してステップＳ５３０７に進む。ステップＳ５３０７では、記憶した受信予定コードと受信コードとを比較し、一致した場合には正答と判断してステップＳ５３０８に進み、上記カウント変数ａに１を加算した後、ステップＳ５３１０に進む。一方一致しなかった場合は誤答と判断してステップＳ５３０９に進み、上記カウント変数ａを０にリセットした後、ステップＳ５３１０に進む。

その後、上記確認用認証プログラム１０７’は、ステップＳ５３１０において上記カウント変数ａの値が３以上かどうか比較して３回連続で応答用認証プログラム１２’から正答が得られたかどうかを判断し、３回連続で正答が得られたと判断した場合はステップＳ５３１１に進み、認証用のフラグを認証ＯＫに更新してステップＳ５３１２に進む。一方３回連続で正答が得られていないと判断した場合は何もせずステップＳ５３１２に進み、上記サイクル変数ｃに１を加算すると共にステップＳ５３１３において上記サイクル変数ｃが試行回数６回を超えたかどうかを判断する。そして上記サイクル変数が６回を超えていないと判断した場合は、上記ステップＳ５３０２に戻り、逆に６回を超えたと判断した場合は処理を終了する。よって６回の認証試行の間に３回以上連続して正答が無ければ初期設定のまま認証ＮＧのフラグが立つことになり、３回以上連続して正答があれば認証ＮＧのフラグが認証ＯＫのフラグに更新されることになる。
なお正答の連続回数と認証の試行回数は、それぞれ３回と６回に限定されるものではなく、使用するネットワーク回線の通信エラー発生率と必要なセキュリティ強度等のバランスによって適宜設定されるものである。

以上のようなローリングコード方式の認証方法によれば、認証の度にコードが変わると共に、複数回連続して正答が得られなければ認証されないため、十分なセキュリティ強度を確保でき、リプログラミングデータ等の誤送信や解析および変更可能な環境への送信を防止できる。

また、上記本発明の第１ないし第３実施形態においては、プログラムデータを更新する電子制御ユニットが自動車に搭載されたものであったが、これに限られるものではない。例えば航空機や船舶、あるいは携帯電話や家電製品等、プログラムによって制御される電子制御ユニットが搭載されるものであれば良く、これらに本発明のプログラム配信システムを採用することは、当業者であれば容易に考えつくものである。

以上のように、本発明に係るプログラムデータ配信システムにおいては、プログラムデータを変更を許された部分である第１プログラム部分と認められていない部分である第２プログラム部分とに分け、プログラムデータのうち第１プログラム部分は、データの変更が可能な整備者端末において変更できるので、従来どおり整備者が個別の電子制御ユニットに対して調整ができ、変更が認められていない第２プログラム部分は、整備者端末を介さずに更新端末に送信されるので変更されることを防止でき、サービス性を維持した上で、電子制御ユニットによって制御される制御対象に対してメーカー、あるいは管理者の意図した性能を保証できる。

本発明に係るプログラム配信システムの全体構成を示す構成図 本発明に係る修理支援サーバ用データベースの記憶データを示す構成図 本発明に係る整備対象車の更新端末及び車載ユニットの構成を示す構成図 本発明の第１実施形態に係る認証方法を示す構成図 本発明の第１実施形態に係る認証方法のフローチャート 本発明の第１実施形態に係るプログラム配信システムにおいて、整備者が更新を要求した場合のフローチャートの一部 本発明の第１実施形態に係るプログラム配信システムにおいて、整備者が更新を要求した場合のフローチャートの一部 本発明の第１実施形態に係るプログラム配信システムにおいて、整備者が更新を要求した場合のフローチャートの一部 本発明の第１実施形態に係るプログラム配信システムにおいて、整備者が更新を要求した場合のフローチャートの一部 本発明の第１実施形態に係るプログラム配信システムにおいて、整備者が更新を要求した場合のフローチャートの一部 本発明の第１実施形態に係るプログラム配信システムにおいて、整備者が更新を要求した場合のフローチャートの一部 （ａ）は本発明の第１実施形態に係る整備者端末に表示されるメニュー画面を示す図であり、（ｂ）はメニュー画面において、ポップアップウィンドウを表示した状態を示す図 （ａ）は本発明の第１実施形態に係る燃料噴射量制御ユニットに関するコンフィグレーションデータ調整画面を示す図であり、（ｂ）は本発明の第１実施形態に係るエアバッグユニットに関するコンフィグレーションデータ調整画面を示す図 本発明の第１実施形態に係る終了画面を示す図 本発明の第２実施形態に係るプログラム配信システムにおいて、メーカーが更新を要求した場合のフローチャートの一部 本発明の第２実施形態に係るプログラム配信システムにおいて、メーカーが更新を要求した場合のフローチャートの一部 本発明の第２実施形態に係るプログラム配信システムにおいて、メーカーが更新を要求した場合のフローチャートの一部 本発明の第２実施形態に係る整備対象車に表示されるプログラムデータを更新する整備者選択画面を示す図 本発明の第２実施形態に係る整備案内画面を示す図 本発明の第３実施形態に係るプログラム配信システムにおけるフローチャート 本発明の第３実施形態に係る整備対象車に表示されるプログラムデータを更新する整備者選択画面を示す図 本発明の他の認証方法を示す構成図 本発明の他の認証方法におけるフローチャート

符号の説明

１：指定された車種に対応する整備対象車
２：整備者端末
３：修理支援サーバ
４：ネットワーク回線
５：更新端末５
６：燃料噴射制御ユニット（電子制御ユニット）
７：エアバッグ制御ユニット（電子制御ユニット）
８：車載制御ユニット
９：送受信アンテナ
１０：一時記憶メモリ
１１：復号プログラム
１２：応答用認証プログラム
１７、２３：電子制御ユニットのプログラムデータ
１８、２４：電子制御ユニットのコンフィグレーションデータ
２８：ＧＰＳユニット
２９：タッチパネルディスプレイ
１００：修理支援サーバのデータベース
１０１：リプログラミングデータ
１０２：更新用コンフィグレーションデータ
１０６：整備者端末アドレスデータ
１０７：確認用認証プログラム
１０８：暗号プログラム
２００：整備者端末のデータベース
２０１：コンフィグレーションプログラム
Ｗ１：メニュー画面
Ｗ２、Ｗ３：コンフィグレーションデータ調整画面
Ｗ５、Ｗ７：整備者選択画面
Ｗ６：整備案内画面

Claims (12)

1. 指定された整備対象機種に搭載された電子制御ユニットのプログラムデータを設定された端末に対して送信する送信手段を備えたプログラムデータ配信システムであって、
   上記プログラムデータは、
   整備者による変更が認められた第１プログラム部分と、
   整備者による変更が認められていない第２プログラム部分とを有し、
   上記送信手段は、上記プログラムデータの第１プログラム部分を送信すべき、上記プログラムデータの内容を変更する為の整備者端末を設定すると共に、上記第２プログラム部分を送信すべき、上記指定された電子制御ユニットのプログラムデータを更新する為の更新端末を設定する設定手段を有し、上記第１プログラム部分を上記整備者端末に送信すると共に、上記第２プログラム部分を上記整備者端末を介さずに上記更新端末に送信するものであることを特徴とするプログラムデータ配信システム。
2. 上記送信手段は、遠距離通信可能な通信回線を介して上記更新端末と整備者端末とに上記プログラムデータを送信するものであることを特徴とする請求項１に記載のプログラムデータ配信システム。
3. 上記整備対象機種は自動車における特定の車種であることを特徴とする請求項１ないし２のいずれか１つに記載のプログラムデータ配信システム。
4. 上記送信手段および更新端末は、相互通信可能な相互通信手段を備え、
   上記送信手段は、通信相手との間で、該通信相手が上記設定手段により設定された更新端末であるかどうかの認証を行う認証手段を備え、
   上記認証手段により上記通信相手が設定された更新端末であると認証されたときのみ、上記通信相手に対して上記第２プログラム部分を送信するものであることを特徴とする請求項１ないし３のいずれか１つに記載のプログラムデータ配信システム。
5. 上記送信手段は、上記第２プログラム部分を暗号化する暗号化手段を備え、該暗号化手段により暗号化された上記第２プログラム部分を送信するものであると共に、上記更新端末は、上記暗号化された第２プログラム部分を復号化する復号化手段を備えることを特徴とする請求項１ないし３のいずれか１つ記載のプログラムデータ配信システム。
6. 上記更新端末は上記整備者端末に対して上記第２プログラム部分を出力不能に構成されていることを特徴とする請求項１ないし４のいずれか１つに記載のプログラムデータ配信システム。
7. 上記更新端末は整備者端末を指定する指定手段を備え、上記送信手段は、上記更新端末の指定手段により指定された上記整備者端末に上記第１プログラム部分を送信することを特徴とする請求項１ないし３のいずれか１つに記載のプログラムデータ配信システム。
8. 上記更新端末は、上記整備者端末が上記第１プログラム部分の受信を完了したことを検出する第１受信完了検出手段と、該第１受信完了検出手段が受信完了を検出することで、ユーザーに整備者への案内を報知する案内手段とを備えることを特徴とする請求項１ないし３および７のいずれか１つに記載のプログラムデータ配信システム。
9. 上記更新端末は、上記第１プログラム部分と第２プログラム部分とを共に受信完了したことを検出する第２受信完了検出手段と、該第２受信完了検出手段が受信完了を検出することで、両プログラム部分を上記電子制御ユニットに対して有効にするものであることを特徴とする請求項１ないし３のいずれか１つに記載のプログラムデータ配信システム。
10. 上記整備者端末の転送手段は、第１プログラム部分を上記送信手段に返送するものであると共に、上記送信手段は、上記返送された第１プログラム部分を、上記第２プログラム部分と共に上記更新端末に送信するものであることを特徴とする請求項１ないし３のいずれか１つに記載のプログラムデータ配信システム。
11. 上記送信手段は、上記第１プログラム部分を転送すべき更新端末の送信宛先を上記整備者端末に送信するものであることを特徴とする請求項１ないし３のいずれか１つに記載のプログラムデータ配信システム。
12. 上記更新端末の位置を検出する更新端末位置検出手段を備え、上記更新端末が設定された整備者端末の登録された所在地から所定距離以内に位置していない時には、該整備者端末により変更された第１プログラム部分を上記更新端末に送信することが規制されることを特徴とする請求項１ないし３のいずれか１つに記載のプログラムデータ配信システム。
    
    

Images