JP6805559B2 - リプログマスタ - Google Patents

Description

本発明は、リプログマスタに関する。

車両には多数の電子制御装置（ＥＣＵ）が搭載されており、これらの電子制御装置が車内ネットワークを通じて連携して車両用機器を制御している。従来、この電子制御装置の内部メモリに記憶されたプログラムを更新する技術が提供されている（例えば特許文献１参照）。この特許文献１記載の技術によれば、プログラム更新装置が、センタ装置からプログラムを更新するための更新ファイルを受信し、この更新ファイルに対応するプログラムを更新することが記載されている。

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

近年、特許文献１記載の技術のように、各種無線通信技術を用いて車内ネットワークに接続しプログラムを更新することが可能になりつつある。しかしながら、車両ユーザにより操作可能な端末からの要求に応じて無線通信により遠隔更新するときには、車両ユーザが車両を運転操作可能な環境下でもプログラム更新処理を実行できるようになる虞がある。このような場合、車両ユーザがプログラムを書換途中にも拘わらず、車両を運転操作してしまう虞がある。例えばプログラム書換処理が不十分なまま、車両ユーザが車両を運転操作すると車両が意図しない挙動をしてしまう虞がある。

本発明の開示の目的は、車両ユーザにより操作可能な端末からの要求に応じてプログラム更新するときに、車両ユーザが安全に運転操作でき安全性を確保できるようにしたリプログマスタを提供することにある。

請求項１記載の発明によれば、車両内ネットワークに接続された電子制御装置の一つであるリプログマスタは、外部からの要求に基づいて同じく電子制御装置の一つであるリプログスレーブに記憶されたプログラムを更新するための制御を行う。リプログマスタは、他の電子制御装置と通信可能に構成され、リプログスレーブと他の電子制御装置とを含む電子制御装置から車両の状態を受信する受信部と、受信部により受信した車両の状態に基づいてリプログスレーブに記憶されたプログラムの更新の実行可否を判定する実行可否判定部と、実行可否判定部により実行可と判定された場合、リプログスレーブへ、当該リプログスレーブに記憶されたプログラムの更新実行を指令する実行指令部と、更新実行の指令に先立って、記憶部に記憶された走行可否判定テーブルに基づいて、リプログスレーブに記憶されたプログラムを更新中の車両が走行可であるか走行不可であるかを判定する第１走行可否判定部と、を備える。また、更新実行の指令後において、前記電子制御装置から送信された走行可否信号に基づいて、リプログスレーブに記憶されたプログラムを更新中の前記車両が走行可であるか走行不可であるか、を判定する第２走行可否判定部と、第１走行可否判定部による判定結果及び第２走行可否判定部による判定結果を、バスへ送信する送信部と、を備える。

請求項２記載の発明によれば、報知指令部は走行可否判定部による判定結果に応じて走行可又は走行不可である旨を報知媒体に報知指令する。このため、走行可否の情報を報知媒体に報知することができ、走行可否を車両ユーザに適切に知らせることができる。車両ユーザは走行可であることが報知媒体を通じて知らされたときには走行可能であると判断するため安全に運転操作できる。また車両ユーザは走行不可であることが報知媒体を通じて知らされたときには走行不可であると判断するため運転を止める。これにより安全性を確保できる。

第１実施形態における車両用システムの構成を概略的に示すブロック図 ゲートウェイ装置の電気的構成例を示すブロック図 ＥＣＵの電気的構成例を示すブロック図 ネットワーク接続形態の一部構成を示すブロック図 携帯端末の電気的構成例を示すブロック図 携帯端末と車載表示装置の外観図 走行可否判定テーブルの内容説明図 全体動作を示すシーケンス図 中断時動作を示すシーケンス図 表示器の表示内容（その１） 表示器の表示内容（その２） 表示器の表示内容（その３） 表示器の表示内容（その４） 表示器の表示内容（その５） 第２実施形態におけるリプログマスタの処理内容を示すフローチャート 報知媒体の決定方法の流れを示すフローチャート 表示器の表示内容（その６） 中断時処理を示すフローチャート リプログマスタの処理内容を示すフローチャート 第３実施形態におけるリプログスレーブの処理内容を示すフローチャート リプログマスタの処理内容を示すフローチャート

以下、車両用装置の幾つかの実施形態について図面を参照しながら説明する。以下に説明する各実施形態において、同一又は類似の動作を行う構成については、同一又は類似の符号を付して必要に応じて説明を省略する。なお、下記の実施形態において同一又は類似する構成には、符号の十の位と一の位とに同一符号を付して説明を行っている。

（第１実施形態）
図１から図１４は第１実施形態の説明図を示している。図１に示すように、本実施形態の車両用システム１は、車両内に設置された車両用電子制御装置（以下、ＥＣＵと称す： Electronic Control Unit）に実装されているプログラムを更新可能にするシステムであり、ファイルサーバ２及びウェブサーバ３を備えるセンタ装置４、車両ユーザにより所持され操作可能でありウェブサーバ３に無線接続可能に構成される携帯端末（端末相当）５、車両に搭載される車両内システム６、を互いに接続して構成される。後述するが、車両内システム６には外的にモニタツール４８を接続可能になっている。

ファイルサーバ２とウェブサーバ３とはネットワーク接続されている。ウェブサーバ３は携帯端末５との間で車外ネットワーク７を通じて通信可能になっている。またウェブサーバ３は、車両内システム６との間で通信インタフェース８を通じて通信可能になっている。車外ネットワーク７は、例えば３Ｇ回線、４Ｇ回線等による移動通信網、インターネット網、無線ＬＡＮ（例えばＷｉＦｉ（登録商標））などの各種の通信ネットワークを示すものである。

ファイルサーバ２には、プログラム更新用ファイルがプログラム提供事業者により蓄積される。ファイルサーバ２はプログラム管理機能を備え、更新処理を要するＥＣＵを搭載する車両に更新ファイルを通信インタフェース９を通じて車両内システム６に送信可能になっている。

車両内の車両内システム６は、中央ゲートウェイ装置（ＣＧＷ：Central GateWay：以下ゲートウェイ装置と略す）１０と、このゲートウェイ装置１０に接続される車載ＬＡＮのバス１１〜１５と、バス１１〜１５に接続されるデータコミュニケーションモジュール（以下、ＤＣＭと称す：Data Communication Module）２１及び各種のＥＣＵ２２〜３１と、を備え、バッテリ電圧の供給を受けて動作する。ＤＣＭ２１は、センタ装置４や携帯端末５との間で無線を介してデータ通信するためのインタフェースモジュールである。

ゲートウェイ装置１０は、ＤＣＭ２１を用いて外部のファイルサーバ２、ウェブサーバ３、及び、携帯端末５と通信接続できる。ゲートウェイ装置１０は、ファイルサーバ２から更新用ファイルをダウンロードし、プログラム更新対象のＥＣＵに当該更新用ファイルを送信し更新制御するリプログマスタＲＭとしての機能を備える。リプログマスタＲＭはリプログラムのマスタ装置の略である。

以下、プログラム更新処理のことを「リプログラム」と称すると共に、プログラム更新対象のＥＣＵのことを必要に応じてリプログスレーブＲＳと称す。リプログスレーブＲＳとはリプログラムのスレーブ装置の略である。ここでリプログスレーブＲＳとなるのは、ＥＣＵ２２〜３１のうち何れか１つ以上のＥＣＵである。

図２にゲートウェイ装置１０の電気的構成例を示す。ゲートウェイ装置１０は複数のバス１１〜１５の全てに接続されている。ゲートウェイ装置１０は、ＣＰＵ３２、ＲＯＭ３３、ＲＡＭ３４、フラッシュメモリ３５を備えるマイクロコンピュータ（以下マイコン）３６、及びトランシーバ３７を備え、ＣＰＵ３２が非遷移的記録媒体としてのメモリに記憶されているプログラムに基づいて各種処理を行うが、ゲートウェイ装置１０は、車両用装置動作用のバッテリ電源＋Ｂから電源入力する電源回路３９を用いて動作し、タイマが内蔵されている。電源回路３９には、アクセサリ電源ＡＣＣ、イグニッション電源ＩＧも入力される。

例えば、ゲートウェイ装置１０のマイコン３６にはＬＥＤ３８が接続されており、マイコン３６がこのＬＥＤ３８を点灯／点滅することで内部情報（例えば、走行可否、リプログラムの進捗状況）を外部に表示可能になっている。

図１に示す車載ＬＡＮのバス１１〜１５は、例えば互いに通信プロトコルが異なる又は同一となる複数のネットワークにより構築されており、これらのネットワークは、例えば、ボディ系ネットワークＮ１、走行系ネットワークＮ２、マルチメディア系ネットワークＮ３、など複数のネットワークに分けることができる。これらのネットワークＮ１〜Ｎ３のバス１２〜１４には各種のＥＣＵ２２〜３１が接続されている。

ボディ系ネットワークＮ１のバス（以下、ボディ系バスと称す）１２には、例えば、ドアをロック／アンロック制御するための各種機能を備えるドアＥＣＵ２２、制御対象となるメータの表示制御を行うための各種機能を備えるメータＥＣＵ２３、エアコンディショナを制御するためのエアコンＥＣＵ２４、ウィンドウガラスを開閉制御するためのウィンドウＥＣＵ２５、等のＥＣＵが接続されている。これらのＥＣＵ２２〜２５を必要に応じてボディ系ＥＣＵ２２〜２５と称す。ドアＥＣＵ２２はドアロックモータを接続して構成される。

また、その他にも様々な機能を備えるＥＣＵ（例えばエアバッグ制御機能を備えるエアバッグＥＣＵ、ワイヤレスキー又はスマートキー等の操作に基づくキーレスエントリー制御機能を備えるキーレスエントリーＥＣＵ）がボディ系バス１２に接続されることもあるがその図示及び説明は省略する。例えば、メータＥＣＵ２３は、車速情報に基づく車速、エンジン回転数情報に基づくエンジン回転数、残量センサ（図示せず）により取得されるガソリンの残量情報、による各種情報をインストルメントパネル等の表示器に表示させるための電子制御装置である。

走行系ネットワークＮ２のバス（以下、走行系バスと称す）１３には、例えば、制御対象となるエンジンを制御するための各種機能を備えるエンジンＥＣＵ２６、ブレーキを制御するための各種機能を備えるブレーキＥＣＵ２７、自動変速機を制御するための各種機能を備えるＥＣＴＥＣＵ２８、パワーステアリングを制御するパワステＥＣＵ２９、等のパワートレイン系ＥＣＵが接続されている。これらのＥＣＵ２６〜２９を必要に応じて走行系ＥＣＵ２６〜２９と称す。エンジンＥＣＵ２６は例えばガソリン燃料を用いたエンジンを駆動することで車両を走行可能にする。

また、その他にも様々な機能を備えるＥＣＵ（例えばパーキングブレーキのオン／オフ状態を検知するパーキングＥＣＵなど）が走行系バス１３に接続されているが、その説明は省略する。図示しないが、エンジンＥＣＵ２６には車速センサ、スロットル開度センサ、及びアクセルペダル開度センサ等の各種センサが接続されている。また、ブレーキＥＣＵ２７にはブレーキペダルセンサが接続されている。前述のパーキングブレーキのオン／オフ状態の検出センサはブレーキＥＣＵ２７に接続されていても良い。

また、ＥＣＴＥＣＵ２８にはシフトレバー位置センサなどが接続されている。シフトレバー位置は、例えばパーキング（Ｐ）、リバース（Ｒ）、ニュートラル（Ｎ）、ドライブ（Ｄ）などの位置であり、ＥＣＴＥＣＵ２８はこの位置をシフトレバー位置センサにより検出できる。

マルチメディア系ネットワークＮ３のバス（以下、マルチメディア系バスと称す）１４には、例えば、制御対象となるナビゲーション装置を制御するためのナビゲーションＥＣＵ（以下ナビＥＣＵと称す）３０、電子式料金収受システム（ＥＴＣ：Electronic Toll Collection System：登録商標）の制御を行うためのＥＴＣＥＣＵ３１、等のＥＣＵが接続されている。これらのＥＣＵ３０、３１を必要に応じてマルチメディア系ＥＣＵ３０、３１と称す。これらのマルチメディア系ＥＣＵ３０、３１は各種情報をユーザに提供するためのマルチメディア系の電装品を制御対象として制御する車両用電子制御装置である。

図３にナビＥＣＵなどの各種ＥＣＵの基本的な電気的構成例を示している。例えば、ナビＥＣＵ３０は、バス１４へのデータの送出／取込を行うためのトランシーバ４０と、バス１４を介して通信を制御する通信コントローラ（図示せず）を用いて他のＥＣＵと通信し他のＥＣＵと連動して自らのＥＣＵに割り当てられた各種機能を実現するマイクロコンピュータ（以下マイコン）４１と、を備える。マイコン４１は、ＣＰＵ４２、ＲＯＭ４３、ＲＡＭ４４、フラッシュメモリ４５を備えており、ＣＰＵ４２が非遷移的記録媒体としてのメモリに記憶されているプログラムに基づいて各種処理を行う。ゲートウェイ装置１０は、バッテリ電源＋Ｂから電源を入力する電源回路４９の出力電圧を用いて動作する。ナビＥＣＵ３０には各種記憶装置が接続され、これらの記憶装置には地図データや音楽データ等が記憶されている。そして、このナビＥＣＵ３０は、位置検出器（例えばＧＰＳ受信機等）及び記憶装置の地図データに基づいて取得される車両の現在位置の情報をマルチメディア系バス１４に定期的に送出する。

ＥＣＵ２２〜３１は、当該ＥＣＵ２２〜３１に接続される負荷（センサ、アクチュエータ）が互いに異なることがあるものの、この図３に示すナビＥＣＵ３０と概ね同様のハードウェア構成をなしている。また、図２及び図３に例を示すように、ゲートウェイ装置１０又はＥＣＵ２２〜３１は、バッテリ電源＋Ｂの電圧値、アクセサリ電源ＡＣＣの電圧値、イグニッション電源ＩＧの電圧値を検出し、これらをそれぞれ所定の閾値電圧と比較し比較結果をマイコン３６、４１に出力する検出部３９ａ、４９ａを備える。

各ＥＣＵ２２〜３１の全て又は何れかには当該各ＥＣＵ２２〜３１の動作温度を取得する温度センサ（図示せず）が接続されており、各ＥＣＵ２２〜３１は当該温度センサのセンサ情報を取得することで動作温度の情報を取得できる。

また、ボディ系ＥＣＵ２２〜２５にはエンジン始動／停止用のイグニッションスイッチ又はプッシュボタンに基づくスイッチ信号が入力されており、このボディ系ＥＣＵ２２〜２５のマイコン４１が、スイッチ信号に応じて、アクセサリ電源ＡＣＣ、イグニッション電源ＩＧの出力オン／オフをリレー（図示せず）を用いて制御する。

このスイッチ信号が、ＯＦＦのときにはバッテリ電源＋Ｂだけが供給対象のＥＣＵに供給され、ＡＣＣのときにはアクセサリ電源ＡＣＣが供給対象のＥＣＵ（２２〜３１の何れか１つ以上）に供給され、ＩＧとされるとアクセサリ電源ＡＣＣと共にイグニッション電源ＩＧが供給対象のＥＣＵ（２２〜３１の何れか１つ以上）に供給される。

図４に示すように、各ＥＣＵ２２〜３１はゲートウェイ装置１０にネットワーク接続されているが、各ＥＣＵ２２〜３１には前述した各種センサなどのセンサＳＥ、スイッチＳＷが接続されている。センサＳＥは、各ＥＣＵ２２〜３１に接続される各種センサ（例えば、車速センサ、水温センサ、カメラ、エンジン回転数、温度センサ、気温センサ、ガソリンの残量センサ）を総称して示すものであり、スイッチＳＷは、各ＥＣＵ２２〜３１に接続される各種スイッチ（例えばイグニッションスイッチ、パーキングブレーキのオン／オフ状態の検出センサ、シフトレバー位置センサ、ロックポジションスイッチ、シートベルトの判断スイッチ、着座スイッチ、等）を総称して示すものである。

多数のＥＣＵ２２〜３１のうち何れか一つ以上のＥＣＵ（例えばナビＥＣＵ３０）は表示器４６を接続して構成される。以下、表示器４６がナビＥＣＵ３０に接続されているものとして説明を行う。この表示器４６は、センターインフォメーションディスプレイ（Center Information Display：ＣＩＤ）、ヘッドアップディスプレイ（Head-Up Display:ＨＵＤ）、などによる車載表示装置である。表示器４６はインストルメントパネルのメータ表示器であっても良い。

図６（ｂ）に表示器４６としてＣＩＤの外観図を示しているが、表示器４６は表示部４６ａ及び操作部４６ｂを搭載している。操作部４６ｂは、表示器４６の表示部４６ａの脇に搭載される操作スイッチ群、又は／及び、表示部４６ａの表示画面下のタッチパネルを用いて構成され、車両ユーザにより操作可能に構成される。操作部４６ｂがユーザ操作されると、操作に係る信号をナビＥＣＵ３０に伝達し、ナビＥＣＵ３０のマイコン４１は各種処理を実行する。

図５に携帯端末５の電気的構成例を示すように、携帯端末５は、表示器５ａ、操作部５ｂと共に、通信部５ｃ、及びマイコン５０を備える。マイコン５０はＣＰＵ、ＲＯＭ、ＲＡＭ等（何れも図示せず）を備えており、非遷移的記録媒体としてのメモリに記憶されているプログラムに基づいて操作部５ｂの操作情報の受付処理及び表示器５ａへの表示処理等の各種処理を行う。マイコン５０は、通信部５ｃにより、車外ネットワーク７の他、近距離無線通信（例えばブルートゥース（登録商標））により図１に示すＤＣＭ２１にアクセス可能になっている。携帯端末５のマイコン５０のメモリにはウェブサーバ３にアクセスするためのアプリケーション（例えばブラウザ）がユーザ指示に応じて予めインストールされており、ユーザがこのアプリケーションを実行することでウェブサーバ３を通じてプログラムの更新指示を行うことができる。また、図６（ａ）は携帯端末５の外観図を示しており、表示器５ａと操作部５ｂとを外観上備える。

図１に示す各ＥＣＵ２２〜３１のマイコン４１の内部に記憶されるプログラムは、各ＥＣＵ２２〜３１が自らのＥＣＵに割当てられた制御対象機器を制御するときに行う必要なプログラムであり、更新対象となる更新用ファイル及びその他の非更新対象のファイルにより構成される。すなわち、更新用ファイルは全体のプログラムのファイルのうち、少なくとも一部又は全部のプログラムのファイルを指す。

また図１に示すように、ゲートウェイ装置１０は、開発、テスト、解析用のネットワークのバス１５に接続されており、このバス１５にはＯＢＤ（On-board diagnostics）コネクタ４７が接続されている。ＯＢＤコネクタ４７は、例えば車両設計者、ディーラや修理工場の作業者が必要なときに外部からモニタツール４８を接続可能になっている。

ゲートウェイ装置１０は、全てのバス１１〜１５に送出されるデータを全て受信し、車両内の状態、すなわち、運転者による操作状態、車両状態、車両挙動、を検出する。また、ゲートウェイ装置１０は、各ＥＣＵ２２〜３１毎にプログラムを更新可能な条件が規定された走行可否判定テーブルＴＡ１をフラッシュメモリ３５内に備える。

図７に示すように、走行可否判定テーブルＴＡ１には、各ＥＣＵ２２〜３１の走行可否と、当該ＥＣＵ２２〜３１を接続するＣＡＮＩＤ、接続バス、名称とを対応づけた関係情報が記されている。この走行可否判定テーブルＴＡ１には、ＣＡＮＩＤ、接続バス、名称の全てに対応づけて走行可否が記されていなくても良く、ＣＡＮＩＤ、接続バス又は名称の何れか一つに対応づけて走行可否が記されていれば良い。

この走行可否判定テーブルＴＡ１の内容の一部を説明する。例えば、ドアＥＣＵ２２はボディ系バス１２に接続されているが、例えばモニタツール４８やゲートウェイ装置１０がＣＡＮＩＤとして０ｘ７００を付与して送信すると、ドアＥＣＵ２２がこの要求を受付け、ドアＥＣＵ２２はＣＡＮＩＤとして０ｘ７０８を付して要求に応答することが対応付けて記されており、このドアＥＣＵ２２はプログラム更新中においても走行可能（走行可否＝可）であることが記されている。

また、例えば、パワステＥＣＵ２９は走行系バス１３に接続されているが、モニタツール４８、ゲートウェイ装置１０がＣＡＮＩＤとして０ｘ７０２としてバス１３を介してパワステＥＣＵ２９に送信すると、パワステＥＣＵ２９はこの要求を受付け、パワステＥＣＵ２９はＣＡＮＩＤとして０ｘ７０Ａとし応答を返信することが記されており、このパワステＥＣＵ２９は内部プログラム更新中において走行不可（走行可否＝否）であることが記されている。

また他のＥＣＵにおいても、モニタツール４８やゲートウェイ装置１０がＣＡＮＩＤとして７００番台の番号を付して送信すると、対応するＥＣＵが、この要求を受付け、このＥＣＵが受信したＣＡＮＩＤに８を加入した番号を付して応答を返信することが記されており、これらの個々のＥＣＵに対応して走行可否の情報が記憶されている。図７に示すように、これらのＣＡＮＩＤ，ＥＣＵ名称、接続バスと走行可否とを対応づけた関係情報は、例えばＣＡＮ仕様に規定される標準フォーマットでも拡張フォーマットでも同様に対応づけされている。

図７に示されている内容を概略的にまとめて説明すると、この走行可否判定テーブルＴＡ１では、走行系ＥＣＵ２６〜２９は、当該内部プログラムの更新中には走行不可であることが記されており、マルチメディア系ＥＣＵ３０、３１は、当該内部プログラムの更新中であっても走行可能であることが対応づけて記されている。また、ボディ系バス１２に接続されるメータＥＣＵ２３やエアコンＥＣＵ２４は内部プログラム更新中においても走行可能であることが記憶されている。この走行可否判定テーブルＴＡ１に、車両の走行時／停止時の更新条件（例えばバッテリ残量の高低、接続バス負荷の高低、車両負荷の高低、車室内温度条件、等）を詳細に設定し、これらの更新条件に走行可否情報を対応づけて関係情報として記憶させても良いし、また、これらに例外条件を設けて設定しても良い。

そして、ゲートウェイ装置１０のマイコン３６は、ＣＰＵがメモリに記憶されているプログラムに基づいて、フラッシュメモリ３５に格納されている走行可否判定テーブルＴＡ１を参照しプログラム更新処理を実行する。

以下、システム全体におけるプログラム更新処理の流れについて、図８、図９のシーケンス図、図９〜図１３の表示画面を参照しながら説明する。
下記の説明では、ユーザがワイヤレスキー又はスマートキーを用いて車外から車両内装置（例えばエンジン始動／停止、すなわち電源ＡＣＣ、ＩＧ等の投入）をリモート操作可能である車両を想定すると共に、プログラム更新処理の経過をユーザが所持する携帯端末５の表示器５ａに表示させる例を挙げて説明する。また、以下の動作説明における携帯端末５の表示器５ａの表示内容は、例えばナビＥＣＵ３０が表示器４６に表示処理させても良いため、必要に応じて説明を加入する。

また、以下に説明する図８中のゲートウェイ装置１０の処理は、マイコン３６がプログラムを実行することにより行われる処理であり、携帯端末５の処理は内蔵のマイコン５０がプログラムを実行することにより行われる処理である。

まず図８に示すように、ステップＳ１において、センタ装置４のファイルサーバ２に更新用ファイルが蓄積されると、このファイルサーバ２は、図８のステップＳ２においてネットワークを通じてウェブサーバ３にリプログラムのイベント発生を通知する。車両ユーザが、携帯端末５を操作してウェブサーバ３にアクセスすると、図８のステップＳ３においてイベント発生の通知を受信する。携帯端末５が自動的にウェブサーバ３にアクセスしてイベント発生の通知を受信しても良い。このとき携帯端末５はその表示器５ａに図１０に示すようにイベント内容を表示する。例えば、図１０に示すように、携帯端末５は、「車載プログラムのアップデートデータが確認されました。ダウンロードしますか？」と表示器５ａに表示させると共に、ダウンロードのボタンＢ１を表示器５ａに表示させる。車両ユーザが例えば携帯端末５の表示器５ａに表示されたダウンロードのボタンＢ１を押下することで、プログラムの更新用ファイルをアップデート（ダウンロードＤＬ）要求する。携帯端末５は、タッチパネルによる操作部５ｂを通じてこの要求を受け付ける。携帯端末５は、図８のステップＳ４においてウェブサーバ３を通じてゲートウェイ装置１０にダウンロード要求することで更新用ファイルを指定する。なお、このとき図１０に示すように、携帯端末５は走行可否情報Ｘ２を表示器５ａに表示させても良く、この場合、走行可否情報Ｘ２を「可」として表示させても良い。

ウェブサーバ３は更新用ファイルが指定されると、ウェブサーバ３がステップＳ４においてＤＣＭ２１を通じてゲートウェイ装置１０に更新用ファイルをダウンロード指令する。ゲートウェイ装置１０は、フラッシュメモリ３５等の空き容量やリソースの判断を行うことでダウンロード可否の判定を行う。このダウンロード可否の判定は、車両に搭載されるバッテリ電源＋Ｂの残量が所定量以上に十分に残っていること、例えばバッテリ電源＋Ｂの電圧が所定電圧以上であること、また、ＤＣＭ２１と通信インタフェース８又は／及び９との通信電波環境が安定していること、例えば相互の受信電界強度レベルが所定以上であること、などの何れか一つ以上又は全ての条件を含んでいても良い。

そして、ゲートウェイ装置１０は、ダウンロード可能になったことを条件として、図８のステップＳ５においてＤＣＭ２１を通じてファイルサーバ２に更新用ファイルを要求する。これにより、ファイルサーバ２が、図８のステップＳ６においてＤＣＭ２１を通じてゲートウェイ装置１０に更新用ファイルを配信し、ゲートウェイ装置１０はステップＳ６において更新用ファイルをダウンロードできる。

ゲートウェイ装置１０が更新用ファイルをダウンロード完了すると、図８のステップＳ７ａにおいてダウンロード完了したことを携帯端末５に通知し、携帯端末５が表示器５ａにダウンロード完了したことを表示する。またゲートウェイ装置１０は、図８のステップＳ７ｂに示すようにダウンロード完了したことをナビＥＣＵ３０に伝達し、ナビＥＣＵ３０が表示器４６にダウンロード完了したことを表示させるようにしても良い。図１１はダウンロード完了画面の表示例を示している。携帯端末５はこの時点においても表示部５ａの画面に走行可否情報を表示させている。携帯端末５はこのダウンロード完了画面に更新開始ボタンＢ２も合わせて表示させており、携帯端末５は、この更新開始ボタンＢ２のユーザ押下指示を受付けるようになっている。車両ユーザはダウンロード完了画面を確認すると、携帯端末５の操作部５ｂを操作したり、表示器４６に搭載される操作部４６ｂを操作したりすることで更新用ファイルをリプログラム開始指示する。リプログラム開始指示するときには、ユーザは車両の外部から例えばワイヤレスキー又はスマートキーを操作することに応じて車両内装置の操作指令（例えばエンジンの始動指令）を行う。するとゲートウェイ装置１０の電源回路３９、各ＥＣＵ２２〜３１の電源回路４９には各種動作用の電源が印加される。

車両ユーザがステップＳ８ａにおいて携帯端末５に記憶されるアプリケーションを実行することで更新開始指示しリプログラム実行指令したときには、この指令情報はウェブサーバ３に伝えられる。するとウェブサーバ３がステップＳ８ａにおいてＤＣＭ２１を通じて指令をゲートウェイ装置１０に通知する。

他方、車両ユーザがステップＳ８ｂにおいて操作部４６ｂを操作することでナビＥＣＵ３０に更新要求したときには、ナビＥＣＵ３０がこの更新要求をゲートウェイ装置１０に通知することで図８のステップＳ８ｂにおいてリプログラム実行要求する。

ゲートウェイ装置１０は、更新用ファイルの内容に応じてリプログスレーブＲＳとなるＥＣＵ（２２〜３１のうち何れか１つ以上）を特定する。そして、ゲートウェイ装置１０は、図８のステップＳ９において乗車／降車状態を判定し、図８のステップＳ１０において車両状態を判定し、これらの状態が必要な条件を満たしているときに、特定されたリプログスレーブＲＳに対し更新用ファイルを送信しリプログラム指令する。

この図１０のステップＳ９、Ｓ１０の処理を行う前に先立って、又は、並行して、ゲートウェイ装置１０は、リプログスレーブＲＳのＣＡＮＩＤ，接続バス又は名称を走行可否判定テーブルＴＡ１に照合して走行可否を判定し、ステップＳＡにおいてこの情報を携帯端末５、ナビＥＣＵ３０に初期報知指令するようにしても良い。

特に、ゲートウェイ装置１０は、リプログスレーブＲＳが走行系バス１３に接続されたＥＣＵ２６〜２９であるときには走行不可と判定する。この場合、ゲートウェイ装置１０はこの走行不可である旨の走行可否情報Ｘ２を携帯端末５に初期報知指令しても良い。すると、携帯端末５が走行不可である旨の走行可否情報Ｘ２を表示器５ａに表示することで、車両ユーザは、この走行不可である走行可否情報Ｘ２を認識できる。この場合、ゲートウェイ装置１０はリプログラム実行指令を出力しない。

以下、ステップＳ９、Ｓ１０の判定条件例を詳細に述べる。ステップＳ９の判定条件は、例えば、条件Ａ１：乗員が車両内に存在していないこと、条件Ａ２：バッテリ電源＋Ｂの電圧が所定値以上であること、条件Ａ３：ドアロックポジションがロック状態であること、条件Ａ４：シフトポジションがパーキングで且つパーキングブレーキがオン状態であること、条件Ａ５：リプログラムの開始タイミングから所定時間以内に前述のＡ１〜Ａ４の条件を満たしていること、などの条件をその一部又は全て満たすことである。

このときゲートウェイ装置１０が必要な情報をゲートウェイ装置１０自身又はＥＣＵ２２〜３１等から取得し条件Ａ１〜Ａ５を満たすか判定したり、又は、各ＥＣＵ２２〜３１のうち対象のＥＣＵが条件Ａ１〜Ａ５を満たすか否か自主的に判定すると良い。

条件Ａ１は、前述した乗車判定処理により判定すると良い。条件Ａ２は、バッテリ電源＋Ｂの電圧の検出値を検出する検出器３９ａ、４９ａ出力結果、又は／及び、電源回路３９、４９の出力に基づいて判定すると良い。条件Ａ３は、例えばドアＥＣＵ２２により取得されるドアロックモータの駆動によるドアロック／アンロック状態に基づいて判定すると良い。条件Ａ４は、例えばＥＣＴＥＣＵ２８などにより取得されるシフトレバー位置センサのセンサ情報、パーキングＥＣＵ又はブレーキＥＣＵ２７などのＥＣＵから取得されるパーキングブレーキのオン／オフ状態の検知センサの情報に基づいて判定すると良い。条件Ａ５は、ゲートウェイ装置１０や他のＥＣＵが例えばタイマを用いて時間を計測し、この計測時間が所定時間を経過する前に条件Ａ１〜Ａ４を満たすこととすると良い。これにより、ステップＳ９において乗車／降車状態を判定できる。

また、ステップＳ１０の判定条件は、条件Ａ１０：ゲートウェイ装置１０、ＤＣＭ２１、リプログスレーブＲＳに何らかのダイアグの異常を生じていないこと、条件Ａ１１：ゲートウェイ装置１０、ＤＣＭ２１、リプログスレーブＲＳの動作温度が高温ではない、例えば適切な動作温度範囲内で動作していること、条件Ａ１２：リプログスレーブＲＳ又はリプログスレーブＲＳに関連するＥＣＵが使用されていないこと、条件Ａ１３：バッテリ電源＋Ｂの残量が充分、条件Ａ１４：ガソリンの残量が充分、例えばガソリン残量が所定以上であること、条件Ａ１５：車両ユーザ指示に応じて遠隔書換えする場合にはユーザ確認を得たこと、条件Ａ１６：ゲートウェイ装置１０の中間バッファ領域（記憶部相当）にリプログラム対象の更新用ファイルが格納されていること、などの所定条件である。ゲートウェイ装置１０はこれらの情報を当該ゲートウェイ装置１０自身、ＤＣＭ２１、ＥＣＵ２２〜３１等から取得して各条件Ａ１０〜Ａ１６を判定したり、又は、各ＥＣＵ２２〜３１のうち対象のＥＣＵが該当する条件Ａ１０〜Ａ１６を満たすか否か自主的に判定し、その結果をゲートウェイ装置１０に送信し、ゲートウェイ装置１０が総合的に条件Ａ１０〜Ａ１６を満たすか判定すると良い。

条件Ａ１０は、ゲートウェイ装置１０が、ＤＣＭ２１、ＥＣＵ２２〜３１の全て又はリプログスレーブＲＳとなる対象ＥＣＵから異常の内容を示すダイアグ情報を取得して判定することが望ましい。条件Ａ１１は、例えばゲートウェイ装置１０、ＤＣＭ２１、リプログスレーブＲＳに設置された温度センサの検出情報に基づいて判定すると良い。条件Ａ１２は、リプログスレーブＲＳの動作情報、及び、この動作情報に関連するＥＣＵの動作情報に基づいて判定すると良い。条件Ａ１３は、例えば検出部３９ａ、４９ａによるバッテリ電源＋Ｂの検出電圧が閾値電圧以上、又は、電源回路３９、４９の出力電圧が所定値以上である条件を満たすことを条件とすると良い。条件Ａ１４は、例えばメータＥＣＵ２３に接続されるガソリンの残量センサの検出情報に基づいて判定すると良い。

条件Ａ１５において、ゲートウェイ装置１０は、携帯端末５の表示器５ａに「プログラム書換を開始しても良いですか？」などのメッセージと共に確認ボタン（図示せず）を表示指令し、携帯端末５は確認ボタンが車両ユーザにより押下されこの押下信号を操作部５ｂを通じて受け付けたことを条件としてゲートウェイ装置１０に確認完了信号を送信し、ゲートウェイ装置１０が確認完了信号を受け付けたことを条件として条件Ａ１５を満たすと判定すると良い。条件Ａ１６は、図８のステップＳ６においてダウンロードＤＬが異常なく完了したことで可と判定すると良い。これにより、車両状態を判定できる。

ゲートウェイ装置１０は、ステップＳ９及びＳ１０の条件を満たしていないときには、走行不可である走行可否情報Ｘ２を携帯端末５に表示指令し表示器５ａに表示させる。すると、車両ユーザは走行不可であると認識できる。この場合、ゲートウェイ装置１０は、ステップＳ９及びＳ１０の条件を満たすまで、リプログラム実行指令を出力しない。

ゲートウェイ装置１０は、このようなステップＳ９、Ｓ１０の条件を満たしていると判定したときには、図８のステップＳ１１においてリプログスレーブＲＳに更新用ファイルを送信し、リプログラムを実行指令する。

ゲートウェイ装置１０は、リプログスレーブＲＳに対応したＥＣＵに係る走行可否テーブルＴＡ１に記された走行可否が走行不可で、且つ、ステップＳ９、Ｓ１０の条件を満たすことを条件としてリプログラム実行指令しても良い。さらに、ゲートウェイ装置１０は、リプログスレーブＲＳに対応した全てのＥＣＵに係る走行可否テーブルＴＡ１に記された走行可否が走行可であることを条件としてリプログラム実行指令しても良い。

ゲートウェイ装置１０が、図８のステップＳ１１においてリプログスレーブＲＳに更新用ファイルを送信しリプログラム実行指令すると、リプログスレーブＲＳは更新用ファイルを受信しステップＳ１２においてリプログラム処理を実行する。この書換処理は、エントリ、古いプログラムの消去処理、新たな更新用ファイルの書込処理、書き込まれた更新用ファイルのベリファイ処理、その事後処理などからなっている。

このようにゲートウェイ装置１０がリプログラム実行指令するときには、図８のステップＳＢ、ＳＣにおいて、リプログラムの実施中であることを示す情報、及び、安定状態維持要求をリプログスレーブＲＳ及びナビＥＣＵ３０を含む他の全てのＥＣＵ２２〜３１に送信する。この処理を行うことで、ゲートウェイ装置１０はリプログスレーブＲＳを含む全てのＥＣＵ２２〜３１にリプログラムの可否状態、及び、走行可否の状態の維持を要求できる。

この安定状態維持要求は、例えば、状態Ｃ１：各ＥＣＵ２２〜３１のリプログラムの可否状態の維持、状態Ｃ２：エンジン始動／停止用のキースイッチ（又はプッシュボタン）又はワイヤレスのキースイッチによるスイッチがユーザ操作されてもイグニッション電源ＩＧ又はアクセサリ電源ＡＣＣの状態を保持し各ＥＣＵ２２〜３１への電源供給停止又は電源供給停止させないことを維持、状態Ｃ３：キーレスエントリーに用いられるワイヤレスキー又はスマートキー等による無線操作指示を受けてもドアロック状態を維持、状態Ｃ４：シフトポジションをパーキング状態に維持、することなどを、各ＥＣＵ２２〜３１に要求するものである。またゲートウェイ装置１０は、状態Ｃ５：ダウンロードのユーザ指示を受信してもダウンロード非実施、とするように自身のプログラムのサブルーチンを変更する。

各ＥＣＵ２２〜３１は、安定状態維持要求を受け付けると、状態Ｃ１〜Ｃ４を維持するように、メモリ（例えばＲＡＭ４４、フラッシュメモリ４５）の保持内容を書換えたり、接続負荷（アクチュエータ）を制御する。状態Ｃ１を維持するため、各ＥＣＵ２２〜３１は、リプログラムの可否状態を書換不可に設定するようにデータをメモリに保持する。状態Ｃ２を維持するため、ボディ系ＥＣＵ２２〜２５は、スイッチ信号の変化に応じたアクセサリ電源ＡＣＣ、イグニッション電源ＩＧのリレー制御による出力停止を不可とする。また、状態Ｃ３を維持するため、ドアＥＣＵ２２はドアロックモータＭ１の状態を保持することでドアロック状態を維持し、状態Ｃ４を維持するため、ＥＣＴＥＣＵ２８はシフトポジションをパーキング状態に維持する。

安定状態維持要求は、ステップＳ９及びＳ１０の条件を満たすことでリプログラム可能になった状態を、リプログスレーブＲＳを含む各ＥＣＵ２２〜３１に対し安定的に維持するために設けられる。言い換えると、この安定状態維持要求は、車両内部の各状態（例えば、イグニッション電源ＩＧ、アクセサリ電源ＡＣＣによる電源電圧供給状態、シフトポジション、車室内無人状態、等）をリプログラム中においても安定的に保持するために設けられる要求を示す。ゲートウェイ装置１０が、この安定状態維持要求を行うことで、例えばドアロック操作を禁止したり、パーキングブレーキをオン状態に保持したりするなど、車両の各状態を維持することができ、リプログラム処理を安定して実行完了できる。

この後、リプログスレーブＲＳはリプログラムを開始する。リプログスレーブＲＳは、更新用ファイルの書換処理を実施する開始タイミングなどにおいて走行可否信号をゲートウェイ装置１０に通知する。リプログスレーブＲＳを構成するＥＣＵ以外の他のＥＣＵ（特に走行系バス１３に接続されるＥＣＵ２６〜２９）もまた、例えばゲートウェイ装置１０からの要求に応じて走行可否信号をゲートウェイ装置１０に送信する。このとき、ゲートウェイ装置１０はこれらの複数の走行可否信号を受付けたときに、ステップＳ１３において走行不可である旨の信号を何れか一のＥＣＵから受付けると、この走行不可の情報を優先して受付けると良い。

ゲートウェイ装置１０は、このような走行不可の情報を受け付けることなく図８のステップＳ１３において走行可であると判定すると、走行可能通知信号を例えば走行系バス１３に出力する。すると、走行系バス１３に接続されたＥＣＵ２６〜２９は走行可能な状態にプログラム処理ルーチンを戻す。また、ゲートウェイ装置１０は、図８のステップＳ１３において走行可であると判定したときには、図８のステップＳ１４において走行可である旨を報知指令する。このとき例えばゲートウェイ装置１０は、ユーザの携帯端末５又は／及びナビＥＣＵ３０に走行可能通知信号を通知する。例えば携帯端末５が走行可能通知信号を受信すると、図１２（ａ）に示すように、携帯端末５は、表示器５ａに、プログラム更新に係る進捗状況Ｘ１、走行可否情報Ｘ２、キャンセルボタンＢ３を表示させる。この表示器５ａの表示画面には、プログラム更新途中であっても走行可能であることを示すメッセージが表示されている。

ゲートウェイ装置１０は、ステップＳ１３において何れか一のＥＣＵから走行不可である旨の走行可否信号を受け付けると、走行系バス１３に走行可能通知信号を出力しない。このとき走行系バス１３に接続されたＥＣＵ２６〜２９は走行不可と判定し走行制御を不能とする。また、ゲートウェイ装置１０は走行系バス１３に走行不能通知信号を出力するようにしても良い。このときも走行系バス１３に接続されたＥＣＵ２６〜２９は走行不可と判定し走行制御を不能とする。

このときゲートウェイ装置１０は、図８のステップＳ１５において走行不可である旨を示す走行可否情報Ｘ２を報知指令する。携帯端末５は走行不可である信号を受信したとき、又は、走行可であることを受信していないときには、図１２（ｂ）に示すように、走行不可であることを示す走行可否情報Ｘ２を表示器５ａに表示させる。このとき、走行可否情報Ｘ２と共に例えばあと何秒で走行可能になるかを示す残余時間情報Ｘ３ｂを携帯端末５の表示器５ａに表示させることが望ましい。

そして、その後、リプログスレーブＲＳがリプログラム処理を実行完了すると、この実行完了した情報をゲートウェイ装置１０に通知し、ゲートウェイ装置１０は、この情報を携帯端末５にリプログラム完了情報を通知する。すると図１２（ｃ）に示すように、携帯端末５は、リプログラム完了した後に、走行可否情報Ｘ２を可とし、走行可能であることを表示することで車両ユーザに明示する。

図９は中断要求がなされた場合のシーケンス図を示す。ここでは、車両ユーザが携帯端末５を操作しキャンセルボタンＢ３を押下したことで中断要求する例を示す。車両ユーザが図９のステップＳ２０において携帯端末５を操作しキャンセルボタンＢ３を押下して中断要求すると、この中断要求はウェブサーバ３及びＤＣＭ２１を通じてゲートウェイ装置１０に与えられる。ゲートウェイ装置１０は、この中断要求を受け付けると、図９のステップＳ２１においてリプログスレーブＲＳに中断コマンドを送信することで中断要求する。このとき、リプログスレーブＲＳは、プログラム更新処理を走行に影響しない状態で停止し、又は、プログラム更新処理を初期状態として、走行可能状態に戻して書換えを中断する。

また、ゲートウェイ装置１０は中断要求を受け付けた後、図９のステップＳ２２においてリプログスレーブＲＳから中断完了した旨の中断完了信号を受信すると、図９のステップＳ２３において走行可否信号として走行可能通知信号をＤＣＭ２１及びウェブサーバ３を通じて携帯端末５に送信したり、ナビＥＣＵ３０に送信したりする。携帯端末５は、この走行可能通知信号を受け付けると、図１３に示すように、走行可能であることを示す走行可否情報Ｘ２を携帯端末５の表示器５ａに表示させる。これにより、車両ユーザは走行可能であることを判断できる。また、ゲートウェイ装置１０は走行系バス１３に走行可能通知信号を送信する。すると走行系バス１３に接続されたＥＣＵ２６〜２９は走行可能であると判断でき、車両走行可能処理ルーチンに処理を戻す。

前述した例では、携帯端末５がウェブサーバ３を通じて中断要求する例を示しているが、車両内で中断要求する場合には、他のＥＣＵ（例えばナビＥＣＵ３０）が中断要求をゲートウェイ装置１０に送信する。これにより処理が中断されることになる。

＜まとめ＞
本実施形態によれば、ゲートウェイ装置１０が、走行可否情報Ｘ２を携帯端末５に表示指令しているため、表示器５ａにより車両ユーザに運転可否を適切に報知できる。これにより車両ユーザは走行可否を確認することができ、運転可否を即座に判断できる。例えば、システム１が走行に直接影響しない部分のリプログラム実行している場合には、運転可能であることを報知できるため、車両ユーザに少しでも素早く運転してもらうことができる。

また、例えば車両ユーザが緊急であると判断した場合には、車両ユーザがキャンセルボタンＢ３を押下することでゲートウェイ装置１０が中断要求を受け付ける。このとき、ゲートウェイ装置１０がこの中断要求を受け付けると中断コマンドを送信することで更新用ファイルの書換処理を中断要求する。このとき、緊急の場合においても、リプログスレーブＲＳは、プログラム更新処理を走行に影響しない状態で停止し、又は、プログラム更新処理を初期状態として、走行可能状態に戻して書換えを中断する。そして、ゲートウェイ装置１０は中断完了後に携帯端末５に走行可能となった旨を表示指令する。これにより、リプログラム途中であっても車両ユーザが誤って操作することがなくなり、遠隔書換えであっても車両ユーザが安全な状態で運転走行できる。なお、ゲートウェイ装置１０は、車両ユーザによる携帯端末５の操作を判断することで書換中断が必要となったときに、中断コマンドを送信するようにしても良い。

ゲートウェイ装置１０は、リプログスレーブＲＳのＣＡＮＩＤ，接続バス又は名称を走行可否判定テーブルＴＡ１に照合して走行可否を判定し、この走行可否情報を携帯端末５に表示指令するときには、表示器５ａがこの走行可否情報Ｘ２を表示するため、車両ユーザは走行可否情報Ｘ２を即座に確認できる。

ゲートウェイ装置１０は、走行可否判定テーブルＴＡ１に記憶されたリプログスレーブＲＳに対応したＥＣＵの走行可否が走行可であると判定されたことを条件としてリプログスレーブＲＳにリプログラム実行指令すると、リプログラム処理を待機する必要なく即座に実行できる。

ゲートウェイ装置１０は、リプログスレーブＲＳ、又は、リプログスレーブＲＳを構成するＥＣＵ以外の他のＥＣＵから走行可否信号を受信すると当該走行可否信号に係る走行可否情報Ｘ２を携帯端末５等に表示指令する。このため、車両ユーザは走行可否情報Ｘ２を確認できる。

図１４に図１１に代わる表示画面を変形例として示すが、リプログラムを開始する前に、例えば更新開始後の待機時間を表示するようにしても良い。すなわち、図１４に示すように、ゲートウェイ装置１０の表示指令に応じて、携帯端末５は「更新開始後、走行するにはｘ０秒待機必要です。」という残余時間情報Ｘ３ｂを携帯端末５の表示器５ａに表示させても良い。

＜変形例＞
以下、ユーザが車両に乗車した状態においてリプログラム開始指示する場合について説明する。前述では、ユーザが車両の外部からエンジンを始動しリプログラム指示する形態を示したが、ユーザが乗車した状態においてキースイッチ（又はプッシュボタン）を操作しエンジンを始動した場合であっても適用できる。

例えば、図８のステップＳ９において判定される乗車／降車状態の条件Ａ１〜Ａ５のうち何れかは必要に応じて設ければ良いが、例えば着座センサ、侵入センサを装備していない車両も存在する。このため条件Ａ１を排除した場合について考慮する。

このような場合、図８のステップＳ９の乗車／降車状態は、条件Ａ２〜Ａ５を満たしたときに判定条件が成立することから、ユーザがたとえ車両に乗車していたとしても、例えばドアロックをロック状態にすることでドアロック条件Ａ３を満たし、シフトレバーやパーキングブレーキを前述した所定の状態に保持することで当該条件Ａ４を満たし、車両電源条件Ａ２や時間条件Ａ５を満たしていれば、ステップＳ９の乗車／降車状態の条件を満たすことになる。

ユーザが、車内のキースイッチ、プッシュボタンの操作に応じてエンジンを始動した後、表示器４６の操作部４６ｂを操作しリプログラム指示することが想定される。リプログラム開始するためには、図８のステップＳ９、Ｓ１０を満たす必要があることから、ユーザが例えばステップＳ９の条件Ａ３、Ａ４等を意図的に満たすように車両装備（例えばシフトレバー、ドアロック、パーキングブレーキ）を操作することでステップＳ９の条件が成立する。この場合、図８のステップＳ１１において、リプログラム実行指令がリプログスレーブＲＳに出力される。ユーザが乗車していることから、この後、ユーザが車両装備について様々な操作をしてしまうと、車両状態が変化しリプログラムが失敗したりすることも想定される。

このようなことを考慮した場合、特にゲートウェイ装置１０が図８のステップＳＢ、ＳＣにおいて安定状態保持要求をリプログスレーブＲＳや他のＥＣＵに出力する処理を設けることが望ましい。すると、各ＥＣＵ２２〜３１は、車両状態を安定的に保持することができ、特にユーザによる車両操作部（操作部４６ｂ、キースイッチ又はプッシュスイッチ、シフトレバー、ハンドル、アクセル等）の誤操作、当該誤操作に基づく車両誤発進、リプログラム処理失敗、ユーザの車外への脱出、等を未然に防ぐことができる。

また同様に、ステップＳ１０の判定条件Ａ１０〜Ａ１６のうち何れかは必要に応じて設ければ良い。また、プログラム更新処理の状況を車載表示装置となる表示器４６の表示画面に表示させる場合にも同様に適用できる。

（第２実施形態）
図１５から図１９は第２実施形態の追加説明図を示している。本実施形態では、進捗表示指令処理、進捗判定処理に特徴を備えているため、この進捗表示指令処理、進捗判定処理について説明する。第１実施形態に示したように、リプログスレーブＲＳは更新用ファイルを受信するとリプログラム処理を実施する。

本実施形態に係る進捗表示指令処理、進捗判定処理は、リプログマスタＲＭとなるゲートウェイ装置１０が行う処理であり、前述のリプログスレーブＲＳがリプログラム処理を行っている最中にも並行して行われる処理である。

本実施形態においても、ゲートウェイ装置１０がリプログマスタＲＭとして機能する形態を示す。本実施形態に係る携帯端末５は、ＧＰＳ信号を受信するＧＰＳ受信機を搭載しており、このＧＰＳ受信機に基づいて位置特定する位置特定機能を備える。

まず図１５のＵ１に示すようにゲートウェイ装置１０は報知媒体を決定する。この報知媒体は、例えば各種ＥＣＵに接続される表示器４６、携帯端末５、例えばゲートウェイ装置１０に搭載される例えばＬＥＤ３８などの表示器、など各種の表示媒体を示す。図１６に報知媒体の決定方法の流れをフローチャートで示す。

この図１６に示すように、ゲートウェイ装置１０が、ステップＶ１において携帯端末５の車両からの距離を特定する。例えば、ゲートウェイ装置１０は、携帯端末５の位置特定機能によりこの現在位置を受信し、この現在位置とナビＥＣＵ３０により特定される現在位置とを比較し、携帯端末５が車両周辺に存在しているか否かを判定する。また、例えば近距離無線技術（例えば通信可能範囲１０〜１００ｍ程度）により通信確立しているか否かを判定材料としても良く、例えばブルートゥース技術を用いた場合にはペアリングしたか否かを判定し、この判定結果に基づいて車両周辺に存在しているか否かを判定しても良い。

そしてゲートウェイ装置１０は、携帯端末５が車両周辺に存在しないと判定したときにはステップＶ２にてＮＯと判定し、ステップＶ３において報知媒体をユーザの所持する携帯端末５に決定する。逆に、ゲートウェイ装置１０は、携帯端末５が車両周辺に存在していると判定したときにはステップＶ２にてＹＥＳと判定し、ゲートウェイ装置１０は、ステップＶ４においてユーザが乗車しているか降車しているか特定する。例えば、このとき、ゲートウェイ装置１０は、前述実施形態に示したように車室内に予め設置された着座センサ又は侵入センサを用いて特定すると良い。

ゲートウェイ装置１０は、ステップＶ５において運転者が乗車中であると判定したときには、ステップＶ６において報知媒体を車載表示装置に決定する。この車載表示装置は表示器４６を表すものであり、ＣＩＤ、ＨＵＤ、インストメントパネルなど運転者が存在すると判定された車内から直接視認可能な位置に設置されている表示装置である。このため、運転者が、乗車中であればこれらの車載表示装置の表示画面に表示された情報を即座に確認できる。

逆に、ゲートウェイ装置１０は、ステップＶ５において運転者が乗車中でないと判定したときには、ステップＶ７において報知媒体をユーザの携帯端末５と、ＬＥＤ３８とに決定する。このとき、ゲートウェイ装置１０は、ステップＶ７において例えばＬＥＤ３８に決定したときには、進捗状況Ｘ１が０％に近いときには点滅周期を長くし、進捗状況Ｘ１が１００％に近いときには徐々に点滅周期を短くすると良い。また、ＬＥＤ３８の色を変化させても良い。このため、運転者が乗車中でなくても、車両ユーザ等はこれらの携帯端末５の表示器５ａ又はＬＥＤ３８の点灯／点滅状態を確認することで即座に情報を確認できる。

例えば、ゲートウェイ装置１０は携帯端末５に表示させることを決定したときには図１７（ａ）に示す内容を表示させるように携帯端末５に指令する。ここでは、第１実施形態と同様に、図１７（ａ）に示すように、携帯端末５は、進捗状況Ｘ１、走行可否情報Ｘ２、キャンセルボタンＢ３を表示器５ａに表示させる。初期状態では、進捗状況Ｘ１は０％を示しており、走行可否情報Ｘ２は走行可能であることを示しており、キャンセルボタンＢ３は更新中断を受付けるように表示している。

ゲートウェイ装置１０が報知媒体を決定した後には、図１５の処理に戻り、ステップＵ２においてリプログラムが進行途中であるか完了したかを判定する。ゲートウェイ装置１０が、図１５、図１６に示す一連の処理を行うときに、第１実施形態に示した処理が並行して行われているが、ゲートウェイ装置１０はリプログラムが進行途中であるときには、ステップＵ３において進捗状況を算出する。

全体シーケンスとしては、ゲートウェイ装置１０は更新用ファイルをリプログスレーブＲＳに送信し、このリプログスレーブＲＳから応答信号を受信することで送信終了更新用ファイルを把握することができる。

車載ダイアグ通信仕様に準拠した方法を説明する。ゲートウェイ装置１０は、乗用車のＥＣＵのダイアグ通信仕様であるISO14229で規定されたＵＤＳ（Unified Diagnostic Services）等の規格に準拠してリプログラム時における更新用ファイルをメッセージに分割してリプログスレーブＲＳに送信する。このときゲートウェイ装置１０は、リプログスレーブＲＳに対し、データ転送開始を示すサービスＩＤ（ＳＩＤ３４）を送信し、その後、実データ転送を示すサービスＩＤ（ＳＩＤ３６）と共にデータを複数回送信し、データ転送終了を示すサービスＩＤ（ＳＩＤ３７）を送信する。

このためゲートウェイ装置１０のマイコン３６はリプログスレーブＲＳに送信した送信データ量に応じて進捗状況を判定することができる。具体例としては、ゲートウェイ装置１０のマイコン３６が更新用ファイルの書換データ量の全体量をリプログスレーブＲＳに送信した送信データ量で除して進捗割合を進捗状況として算出すると良い。

このとき、実データ転送を示すＳＩＤ３６の繰り返し回数が全体の回数に対して何パーセント進行したかに応じて進捗状況を判定しても良いし、また、これらの一連のサービスＩＤ（ＳＩＤ３４、ＳＩＤ３６、ＳＩＤ３７）の送信繰り返し回数を計数し、この送信繰り返し回数に応じて進捗状況を判定しても良い。このような場合、ゲートウェイ装置１０は、各ＥＣＵ２２〜３１の更新用ファイルの記憶用メモリの例えば１Ｍbyteの記憶領域に対し、２５６byte、１kbyteなど単位ブロック（＝セクタ）毎に分けて更新用ファイルを送信するが、この送信データ量について、ブロックを単位として全体ブロックに対しどれだけのブロックを送信したか、により進捗状況を判定しても良い。すなわちブロック（＝セクタ）を単位として進捗状況を判定しても良い。

また、リプログスレーブＲＳに送信処理された更新用ファイルの個数が更新用ファイルの全体個数の何パーセントとなっているか、すなわち更新用ファイルの個数を単位として進捗状況を判定しても良い。また、例えばリプログスレーブＲＳが全体のＥＣＵ２２〜３１のうちの一部の幾つか複数のＥＣＵを対象とされているときには、ゲートウェイ装置１０は何個目のＥＣＵを対象として更新用ファイルを送信しているかを判定し進捗状況を判定しても良い。すなわちＥＣＵへの送信終了個数に応じて進捗状況を判定しても良い。

また、リプログスレーブＲＳとなるＥＣＵ２２〜３１は図３に示すマイコン４１を主として構成されているものの、当該マイコン４１は、主のメインマイコンとサブマイコンとを備え全体で複数個備えて構成されている場合もある。このような場合、これらのメインマイコン、サブマイコン毎に更新用ファイルをリプログラムする場合もあり、このような場合には、メインマイコン、サブマイコンをそれぞれ１つのマイコンと見做し、全体の更新対象となるメインマイコン、サブマイコンの個数に対し、何パーセントのマイコンに記憶される更新用ファイルを送信したかに応じて進捗状況を判定しても良い。

さらに、更新用ファイルのデータ量に応じて書換完了予測時間を算出し、この算出された書換完了予測時間に対する書換開始からの時間を用いて進捗状況を判定しても良い。これらの進捗状況の判定方法は組み合わせて用いることもできる。これにより詳細な進捗状況Ｘ１を取得でき、表示器５ａ、４６等へのパーセンテージの表示粒度を細かくして進捗表示できる。

そして、ゲートウェイ装置１０は、このように進捗状況を判定した後、ステップＵ４において走行可否を判定する。ゲートウェイ装置１０は、ステップＵ４においてリプログスレーブＲＳのＣＡＮＩＤ、接続バス、名称等の関係情報を走行可否判定テーブルＴＡ１に照合して走行可否を読み出して判定し、この判定処理後に携帯端末５に表示指令し、図１７（ｂ）に示すように、ステップＵ５において、進捗状況Ｘ１と共に走行可否情報Ｘ２を携帯端末５の表示器５ａに表示させる。

ゲートウェイ装置１０は、ステップＵ４において判定された走行可否が走行不可とされているときには、ステップＵ７において前述の進捗状況に基づいて走行可となるまでの時間を算出し、ステップＵ８において走行可となるまでの残余時間を表示する。この残余時間は、全体処理量に対しての処理量（例えば前述の送信データ量、受信データ量、更新用ファイルの個数、ブロック個数、ＥＣＵ個数の割合等）を減じた残余処理量に基づいて算出される。

このとき、例えば走行不可となったときには、図１７（ｂ）に画面表示イメージを示すように、ゲートウェイ装置１０は、前述の進捗状況Ｘ１、走行可否情報Ｘ２と共に、走行可となるまでの残余時間情報Ｘ３ｂを表示器５ａに表示する。その後、リプログラムが完了すれば、リプログスレーブＲＳがゲートウェイ装置１０にこの旨を通知するため、ゲートウェイ装置１０は携帯端末５にこの旨を通知する。これにより携帯端末５は表示器５ａにリプログラム完了した旨を表示して終了する。

また、図１７（ａ）、図１７（ｂ）に示したように、ユーザによる強制中断用のキャンセルボタンＢ３を表示器５ａの表示画面に表示させるようにすると良い。ユーザはこのキャンセルボタンＢ３を押下することで携帯端末５のマイコン５０はこの要求を受付ける。すると、携帯端末５はこの要求をゲートウェイ装置１０に伝達する。これにより、ゲートウェイ装置１０はリプログラム用の更新ファイルの送信処理を中断する。

例えば、ゲートウェイ装置１０は、例えば走行系バス１３に接続されるＥＣＵ２６〜２９をリプログラムしているとき、リプログラムの中断を不可と判定したときには、このキャンセルボタンＢ３をアンイネーブル状態とし、中断可能なときにこのキャンセルボタンＢ３をイネーブル状態とすると良い。

図１８は中断時におけるゲートウェイ装置１０及び携帯端末５の処理内容の流れを示す。携帯端末５がキャンセルボタンＢ３を受け付けると、このキャンセルボタンＢ３の押下情報が携帯端末５からＤＣＭ２１を通じてゲートウェイ装置１０に通知される。ゲートウェイ装置１０は、ステップＷ２において走行に影響が出ない状態で書換中止する。すなわち、リプログスレーブＲＳは前述実施形態に示したように走行可否情報を送信するが、ゲートウェイ装置１０はこの走行可否情報を受信し、ゲートウェイ装置１０はこのときの走行可否情報が走行可となるまで待機し、そして、走行可となったタイミングで書換処理を中止する。

ゲートウェイ装置１０のＣＰＵ３２はこの書換中止情報をフラッシュメモリ３５などの記憶媒体に記憶する。この場合、ゲートウェイ装置１０は、このとき更新用ファイルの書換処理を途中で停止しても安全走行可能となるタイミング、又は、リプログラム処理を停止し書き換え前のプログラムに戻すタイミング、までの時間を走行に影響が出なくなる程度の時間として算出し、この時間を携帯端末５に通知する。すると図１７（ｃ）に示すように、携帯端末５は、この通知された時間情報Ｘ３ｃを、「キャンセルされました。」などのキャンセルボタンＢ３の受付メッセージＸ３ｄと共に表示器５ａに表示させる。

携帯端末５は、算出された時間情報Ｘ３ｃをタイマなどを用いてカウントし、この時間が経過すると、ステップＷ３において走行可否情報Ｘ２を「否」から「可」に変更表示させると共に「走行可能です」などの走行可能メッセージＸ３ｅを表示器５ａに表示させる。

なお、携帯端末５が走行可能メッセージＸ３ｅを表示器５ａの表示画面に表示させるタイミングは、ゲートウェイ装置１０が走行可となる走行可否信号をリプログスレーブＲＳ又は他のＥＣＵ（例えば走行系バス１３に接続されるＥＣＵ２６〜２９）から受付けた後であることが望ましい。すなわち、ゲートウェイ装置１０は、携帯端末５に時間情報Ｘ３ｃを通知した後、リプログスレーブＲＳから受け付ける走行可否情報に基づいて走行可否を判定し、その走行可否情報が走行可となったタイミングで携帯端末５にこの旨を通知し、その後、携帯端末５が走行可能メッセージＸ３ｅを表示器５ａに表示させることが望ましい。すると、ユーザは走行可能であるということを理解でき、ユーザは安全に車両運転を開始できる。

その後、通常通りユーザが車両を運転しエンジン停止した後、ゲートウェイ装置１０が主となってリプログラム処理を開始する。例えば、ゲートウェイ装置１０は再度エンジン起動したときにフラッシュメモリ３５を参照し書換中止情報が記憶されていることを確認すると、リプログラム処理を開始する。

前述と同様に、ゲートウェイ装置１０は、走行可となるまでの時間を算出し、ＤＣＭ２１を通じて走行可となるまでの残余時間情報Ｘ３ｂを携帯端末５に通知する。すると携帯端末５は、図１７（ｅ）に示すように、走行可否情報Ｘ２を「可」から「否」に切り替えて表示器５ａに表示させると共に、残余時間情報Ｘ３ｂを表示器５ａに表示させる。

そして、ゲートウェイ装置１０は、リプログラムが完了したことをリプログスレーブＲＳから受け付けると、フラッシュメモリ３５に記憶された書換中止情報をクリアすると共に、携帯端末５にこの完了情報を通知し、携帯端末５が進捗状況Ｘ１を１００％として表示させると共に、走行可否情報Ｘ２を「否」から「可」として走行可能であることをユーザに知らせる。これにより、ユーザはリプログラム完了したことを認識できると共に、安全に車両走行可能であるということを理解でき運転開始できる。

本実施形態によれば、ゲートウェイ装置１０が表示指令することで携帯端末５は走行可否情報Ｘ２を表示器５ａに表示させているため、車両ユーザに走行可否を適切に知らせることができる。ユーザは運転可能であるか否かを判定でき、これにより安全性を確保できる。

また、ゲートウェイ装置１０が表示指令することで携帯端末５は進捗状況Ｘ１を表示器５ａに表示させているため、車両ユーザに進捗状況Ｘ１を適切に知らせることができる。車両ユーザは進捗状況が報知媒体を通じて知らされたときにはプログラム更新終了までの時間を大よそ把握することができる。したがって、車両ユーザはプログラム更新中か判断することができ、誤って運転開始してしまうことを極力防止できる。これにより安全性を確保できる。

例えば、車両ユーザが進捗状況Ｘ１を把握できても、表示粒度がリプログラム中又はリプログラム終了の２段階などと荒い場合には、車両ユーザはリプログラム完了しているかどうかしか把握できない。このような場合、リプログラム時間が長い場合にリプログラムが失敗したと判断してしまう恐れがある。

本実施形態においては、ゲートウェイ装置１０がリプログスレーブＲＳに送信した送信データ量に応じて進捗状況を判定したり、ＥＣＵの送信終了個数に応じて進捗状況を判定したり、送信処理された更新用ファイルの個数に応じて進捗状況を判定したり、書換完了予測時間を算出し、書き換完了予測時間に対する書き換開始からの時間を用いて進捗状況を判定している。このため、ゲートウェイ装置１０が表示指令することに応じて、携帯端末５は進捗表示の粒度をパーセンテージ表示するなどのように極力細かくして正常に進行していることを通知できる。このため、車両ユーザは、安心してリプログラム終了を待機できる。

また、ゲートウェイ装置１０が表示指令することで携帯端末５は残余時間情報Ｘ３ｂを表示器５ａに表示させているため、ユーザは、どの程度待機すれば車両を運転可能であるかを的確に判断できる。ユーザは待ち時間を有効活用できる。

また、携帯端末５はキャンセルボタンＢ３を表示器５ａに表示させ、このキャンセルボタンＢ３の押下を受付けるように構成されているため、ユーザは中断したいタイミングで中断指令できる。

また、ユーザによりキャンセルボタンＢ３が押下され受け付けたとしても、ゲートウェイ装置１０及びリプログスレーブＲＳは走行に影響が出ない状態となり走行可と判定されるまでリプログラムを停止せず継続しているため、ユーザは車両走行に影響が出ない程度のプログラム書換状態において運転することができ安全に運転できる。

図１９は本実施形態に係るリプログマスタＲＭとなるゲートウェイ装置１０の処理内容をフローチャートにまとめて示している。ゲートウェイ装置１０は、外部からリプログラム指示を受け付けると、ゲートウェイ装置１０はステップＹ１においてリプログラムを実行するが、その後ステップＹ２において進捗状況Ｘ１を算出し判定する。

そして、ゲートウェイ装置１０はステップＹ３において走行可否を判定し、ステップＹ４においてこれらの走行可否情報Ｘ２、進捗状況Ｘ１を予め設定された表示器（例えば表示器５ａ、ＬＥＤ３８）に表示指令する。進捗状況Ｘ１をユーザ提示することで、ユーザは詳細な進捗状況Ｘ１を把握することができ、書換中に誤って操作することが無くなり、遠隔書換指令しても安全に書換可能となる。

そして、ゲートウェイ装置１０は、リプログラムを完了するまでステップＹ１から処理を繰り返す。リプログラム完了の判断方法はリプログスレーブＲＳからのリプログラム完了情報を受付けて完了と見做したタイミングでリプログラム完了したと判断することが望ましいが、更新用ファイルをリプログスレーブＲＳに送信完了した時点から所定時間経過したタイミングをリプログラム完了したと判断しても良い。本実施形態では、このようにゲートウェイ装置１０が主となって進捗状況、走行可否を判定し、表示器（例えば５ａ）に表示指令している。このような形態によれば、ゲートウェイ装置１０が情報を統括制御できる。

（第３実施形態）
図２０及び図２１は第３実施形態の追加説明図を示している。図２０及び図２１は本実施形態に係るリプログマスタＲＭとなるゲートウェイ装置１０及びリプログスレーブＲＳの処理内容をフローチャートにより示している。これらの図２０及び図２１に示すように、図１９に示したリプログマスタＲＭとなるゲートウェイ装置１０の処理内容をリプログスレーブＲＳに分担しても良い。

図２０に示すように、リプログスレーブＲＳが主となりステップＴ１において進捗状況を算出して判定し、ステップＴ２において走行可否を判定し、ステップＴ３においてリプログマスタＲＭに進捗状況、走行可否の情報を送信する。このステップＴ２において、リプログスレーブＲＳは、ゲートウェイ装置１０から受信した更新用ファイルの受信データ量に応じて進捗状況を判定すると良い。具体例としては、リプログスレーブＲＳが、受信された受信データ量を予めゲートウェイ装置１０から受信した更新用ファイルのデータ全体量で除して進捗割合を算出して進捗状況を判定しても良い。このとき、実データ転送を示すＳＩＤ３６の繰り返し回数が全体の回数に対して何パーセント進行したかに応じて進捗状況を判定しても良い。

これらの一連の処理をリプログラム完了するまで繰り返す。また、リプログマスタＲＭとなるゲートウェイ装置１０は、ステップＹ１５においてリプログスレーブＲＳから進捗状況、走行可否情報を取得し、ステップＹ１６において表示器（例えば５ａ）に表示指令する。このとき、リプログマスタＲＭとなるゲートウェイ装置１０はサービスＩＤ（ＳＩＤ２２）を出力することでリプログスレーブＲＳから定期的に進捗情報を取得することができる。

このような形態によれば、ゲートウェイ装置１０とリプログスレーブＲＳとの間で処理負担を分担できる。リプログラムの完了タイミングをリプログスレーブＲＳの完了情報に基づいて判定しているため、リプログラム完了タイミングを正確に判定できる。
前述実施形態及び本実施形態に示したように、走行可否の判定処理、進捗状況の判定処理は、リプログマスタＲＭ、リプログスレーブＲＳの何れが行っても良い。

（他の実施形態）
本発明は、前述した実施形態に限定されるものではなく、種々変形して実施することができ、その要旨を逸脱しない範囲で種々の実施形態に適用可能である。例えば以下に示す変形又は拡張が可能である。

前述した形態では、リプログマスタＲＭ又はリプログスレーブＲＳが進捗状況を取得し、表示器４６に表示させる形態を説明したが、これに限定されるものではなく、センタ装置４のウェブサーバ３側に進捗状況を送信し、ユーザがこのウェブサーバ３に携帯端末５の操作部５ｂを操作してアクセスすることで進捗状況Ｘ１を確認するようにしても良い。この場合、ウェブサーバ３が報知媒体として構成される。前述の走行可否情報Ｘ２についても同様である。

前述した実施形態のテーブルＴＡ１に設定されたＣＡＮＩＤやＥＣＵの名称と走行可否との関係は一例に過ぎず、これに限定されるものではない。
前述実施形態においては、ボディ系バス１２、走行系バス１３、マルチメディア系バス１４等のバス１２〜１４に各系統のＥＣＵ２２〜３１が接続されている形態を示しているが、ＥＣＵの種類は前述実施形態で説明したものに限られるものではない。

前述実施形態においては、ボディ系バス１２、走行系バス１３、マルチメディア系バス１４等のバス１２〜１４に各系統のＥＣＵ２２〜３１が接続されている形態を示しているが、これに限定されるものではない。例えば、これらのＥＣＵ２２〜３１の一部又は全部が一つのバスに接続されていても良い。特に前述実施形態ではボディ系バス１２に接続されたＥＣＵ２２〜２５とマルチメディア系バス１４に接続されたＥＣＵ３０、３１とは、同じバスに接続されていても良い。また、ＥＣＵ２２〜３１の接続バスの系統を変更しても良い。また各ＥＣＵ２２〜３１の少なくとも２つ以上の機能は１つのＥＣＵに統合して構成しても良い。

前述実施形態の車両用システム１においては、ゲートウェイ装置１０をリプログマスタＲＭとして用いた形態を示したが、これに限定されるものではない。例えば、リプログスレーブＲＳとして機能するＥＣＵ以外のＥＣＵのうち何れか、携帯端末５、及び、モニタツール４８の何れか一つの構成を、リプログマスタＲＭとして機能させるようにしても良い。

前述実施形態の車両用システム１においては、ゲートウェイ装置１０が走行可否判断テーブルＴＡ１を備えた形態を示しているが、これに限定されるものではない。例えば、ＥＣＵ２２〜３１又は携帯端末５のうちの何れかに走行可否判断テーブルＴＡ１を記憶させ、システム１内でこの走行可否判断テーブルＴＡ１を共有する構成であってもよい。

ＬＥＤ３８はゲートウェイ装置１０に接続されている形態を示したが、他のＥＣＵ２２〜３１に接続されていても良い。表示器４６はナビＥＣＵ３０に接続されている形態を示したが、他のＥＣＵ２２〜２９、３１に接続されていても良い。

前述説明した各種センサ（例えば、パーキングブレーキのオン／オフ状態の検出センサ、シフトレバー位置センサ、ガソリンの残量センサ）は、前述説明した対象ＥＣＵに接続されていなくても良い。この各種センサ（例えば、パーキングブレーキのオン／オフ状態の検出センサ、シフトレバー位置センサ、ガソリンの残量センサ）が前述以外の他のＥＣＵに接続されており、バス１１〜１５を通じて通信することで、ゲートウェイ装置１０やその他のＥＣＵがこれらのセンサ情報を取得するようにしても良い。

報知媒体となる表示器５ａ、４６を選択して各種メッセージを表示する形態を示したが、報知媒体は前述した実施形態に限られるものではなく、例えばナビＥＣＵ３０やオーディオＥＣＵ（図示せず）を通じて車両に搭載されたスピーカを通じて音を報知させる形態に適用しても良い。

フラッシュメモリ３５、４５を記憶部として構成した形態を示したが、これに限定されるものではない。例えば、ＲＡＭなどの揮発性メモリ、ＥＥＰＲＯＭなどの不揮発性メモリを記憶部として適用しても良い。前述した複数の実施形態を組み合わせて構成しても良い。

図１６のステップＶ２において携帯端末５が車両周辺に存在すると判定したことを前提として車両ユーザの乗車／降車状態を特定する実施形態を示したが、これに限定されるものではない。すなわちステップＶ２は必要に応じて設ければ良い。

携帯端末５、ゲートウェイ装置１０、リプログスレーブＲＳ以外のＥＣＵ、モニタツール４８の何れかは、リプログマスタＲＭを構成する。ＥＣＵ２２〜３１の何れか一つ以上のＥＣＵはリプログスレーブＲＳを構成する。リプログマスタＲＭのマイコン３６又は４１は走行可否を取得する取得部として構成される。また、リプログマスタＲＭのマイコン３６又は４１は車両乗員の乗車／降車状態を判定する乗車降車状態判定部として構成される。また、リプログマスタＲＭのマイコン３６又は４１はエンジンの動作／非動作状態を判定する車両状態判定部として構成される。また、リプログマスタＲＭのマイコン３６又は４１は、車両ユーザにより操作される端末５、４６から中断要求を受付けたときにはリプログスレーブＲＳに中断コマンドを送信し更新用ファイルの書換処理を中断要求する中断要求部として構成される。また、リプログマスタＲＭのマイコン３６又は４１はリプログスレーブＲＳにリプログラム実行指令するリプログラム実行指令部として構成される。また、リプログマスタＲＭのマイコン３６又は４１は、リプログラム実行指令部がリプログラム実行指令をリプログスレーブＲＳに送信するときに、リプログスレーブＲＳを含む全てのＥＣＵにリプログラムの可否状態及び走行可否の状態の維持を要求する安定状態維持要求部として構成される。

また、リプログマスタＲＭのマイコン３６又は４１は、走行可否信号に係る情報を報知媒体（携帯端末５、ＬＥＤ３８、表示器４６）に報知指令する報知指令部として構成される。リプログマスタＲＭのマイコン３６又は４１は車両ユーザに操作された端末５の車両からの距離を特定する距離特定部として構成される。このときリプログマスタＲＭのマイコン３６又は４１は距離特定部により特定された距離に応じて端末が車両周辺に存在するか否かを判定する存否判定部として構成される。リプログマスタＲＭのマイコン３６又は４１は乗車降車状態特定部として構成される。ウェブサーバ３、表示器５ａ、ＬＥＤ３８、表示器４６は走行可否又は進捗状況を報知する報知媒体として構成される。特に表示器４６は車載表示装置として構成される。フラッシュメモリ３５、４５等は記憶部として構成される。

（その他の観点での説明）
また、各実施形態において、リプログマスタＲＭは、進捗状況を判定する進捗判定部、進捗状況を報知指令する進捗報知指令部、進捗状況を報知制御する進捗報知制御部、進捗状況を表示制御する進捗表示制御部、進捗状況を取得する進捗状況取得部、車両の走行可否を判定する走行可否判定部、のうち少なくとも一部の機能を実現するように構成される。進捗判定部、走行可否判定部としての機能は、リプログスレーブＲＳが備えていても良い。

例えば、一つの構成要素が有する機能を複数の構成要素に分散させたり、複数の構成要素が有する機能を一つの構成要素に統合させたりしてもよい。また前述の実施形態の構成の少なくとも一部を、同様の機能を有する公知の構成に置き換えてもよい。また、前述の２以上の実施形態の構成の一部又は全部を互いに組み合わせて付加しても置換しても良い。なお、特許請求の範囲に記載した括弧内の符号は、本発明の一つの態様として、前述する実施形態に記載の具体的手段との対応関係を示すものであって、本発明の技術的範囲を限定するものではない。

図面中、１は車両用システム、３はウェブサーバ（報知媒体）、ＲＭはリプログマスタ（車両用装置）、ＲＳはリプログスレーブ、３６はマイコン（判定部、取得部、報知指令部、リプログラム実行指令部、乗車降車状態判定部、車両状態判定部、距離特定部、存否判定部）、４１はマイコン（判定部、取得部、報知指令部、リプログラム実行指令部、乗車降車状態判定部、車両状態判定部）、５は携帯端末（報知媒体、端末）、３５はフラッシュメモリ（記憶部）、３８はＬＥＤ（報知媒体）、４５はフラッシュメモリ（記憶部）、４６は表示器（車載表示装置、端末、報知媒体）、ＴＡ１は走行可否判定テーブル、を示す。

Claims (9)

1. 外部からの要求に基づいてプログラム更新用ファイルを車両内ネットワークに接続された電子制御装置の一つであるリプログスレーブ（ＲＳ）に送信し、当該リプログスレーブに記憶されたプログラムを更新するための制御を行う前記電子制御装置の一つであるリプログマスタ（ＲＭ）であって、
   前記リプログスレーブ以外かつ前記リプログマスタ以外の前記電子制御装置である他の電子制御装置と通信可能に構成され、
   前記リプログスレーブと前記他の電子制御装置とを含む前記電子制御装置から前記車両の状態を受信する受信部（３７）と、
   前記受信部により受信した前記車両の状態に基づいて、前記リプログスレーブに記憶されたプログラムの更新の実行可否を判定する実行可否判定部（３６、Ｓ９、Ｓ１０）と、
   前記実行可否判定部により実行可と判定された場合、前記リプログスレーブへ、当該リプログスレーブに記憶されたプログラムの更新実行を指令する実行指令部（３６、Ｓ１１）と、
   前記更新実行の指令に先立って、記憶部（３５）に記憶された走行可否判定テーブルに基づいて、前記リプログスレーブに記憶されたプログラムを更新中の前記車両が走行可であるか走行不可であるか、を判定する第１走行可否判定部（３６）と、
   前記更新実行の指令後において、前記電子制御装置から送信された走行可否信号に基づいて、前記リプログスレーブに記憶されたプログラムを更新中の前記車両が走行可であるか走行不可であるか、を判定する第２走行可否判定部（３６、Ｓ１３）と、
   前記第１走行可否判定部による判定結果及び前記第２走行可否判定部による判定結果を、バスへ送信する送信部（３７）と、
   を備えるリプログマスタ。
2. 前記第１走行可否判定部による判定結果又は前記第２走行可否判定部による判定結果に応じて、走行可又は走行不可である旨を報知媒体（３、５ａ、３８、４６）に報知指令する報知指令部（３６、Ｓ１４、Ｓ１５、Ｕ５；４１、Ｙ１６）を備える請求項１に記載のリプログマスタ。
3. 前記実行可否判定部により実行可と判定された場合、前記他の電子制御装置に対し、当該他の電子制御装置の状態記憶部に記憶された前記プログラムの更新不可状態を維持する要求を送信する第１状態維持要求部を備える請求項１または２に記載のリプログマスタ。
4. 前記実行可否判定部により実行可と判定された場合、前記車両の電源状態を維持すること、前記車両のドアロック状態を維持すること、及び、前記車両のシフトポジション状態を維持すること、のうち少なくともいずれかの要求を送信する第２状態維持要求部を備える請求項１から３の何れか一項に記載のリプログマスタ。
5. 前記車両のユーザによる前記更新の中断要求を受信した場合、
   前記リプログスレーブに記憶されたプログラムを更新するための制御を中断するか、または、前記リプログスレーブに前記更新の中断を要求するコマンドを送信する中断要求部（３６、Ｓ２１）
   を備える請求項１から４の何れか一項に記載のリプログマスタ。
6. 前記走行可否判定テーブルは、前記リプログスレーブと前記他の電子制御装置とを含む前記電子制御装置の識別情報と、当該電子制御装置に記憶されたプログラムを更新中の前記車両が走行可であるか走行不可であるかを示す第１走行可否情報と、を対応づけたものであり、
   前記第１走行可否判定部は、前記プログラム更新ファイルの内容に応じて特定された前記リプログスレーブの識別情報と前記走行可否判定テーブルとに基づいて、前記リプログスレーブに記憶されたプログラムを更新中の前記車両が走行可であるか走行不可であるか、を判定する請求項１から５の何れか一項に記載のリプログマスタ。
7. 前記第１走行可否判定部（３６；４１）は、前記リプログスレーブが前記車両内ネットワークのうち走行系ネットワーク（Ｎ２）のバス（１３）に接続されている場合、走行不可と判定する請求項１から５の何れか一項に記載のリプログマスタ。
8. 前記実行可否判定部は、前記受信部により受信した前記車両の状態として、前記車両の乗車状態、前記車両のバッテリ電源の電圧値、前記車両のドアロック状態、前記車両のシフトポジション状態、及び、前記リプログスレーブの異常、のうち少なくともいずれかに基づいて前記更新の実行可否を判定する請求項１から７の何れか一項に記載のリプログマスタ。
9. 前記第２走行可否判定部は、前記リプログスレーブと前記他の電子制御装置とを含む複数の前記電子制御装置から、前記リプログスレーブに記憶されたプログラムを更新中の前記車両が走行可であるか走行不可であるかを示す第２走行可否情報を受信した場合において、前記第２走行可否情報のいずれかが走行不可を示す場合、走行不可と判定する請求項１から８の何れか一項に記載のリプログマスタ。

Images