JP6323968B1 - 車両用保守ツール - Google Patents

Abstract

【課題】車両コストを抑制しつつ、電子制御装置（ＥＣＵ）に対する保守作業を効率良く行うことが可能な車両用保守ツールを提供する。【解決手段】車両に搭載される複数の電子制御装置が接続された車両ネットワークに接続される車両用保守ツールは、車両ネットワークに接続された状態で車両に搭載されている車両側コネクタに対して着脱可能な端子部と、無線を介して外部から実行指令を受信する無線通信部と、端子部及び無線通信部にそれぞれ接続された制御部であって、実行指令の受信に応じて、所定の処理を実行するためのスクリプトに記述された１以上の命令を順次解釈するスクリプト命令解釈部、及びスクリプト命令解釈部によって解釈された命令を順次実行することにより車両ネットワークを介して所定の処理を実行するスクリプト命令実行部を、有する制御部と、端子部、無線通信部、及び制御部を保持するハンディ式保持ケースと、を備える。【選択図】 図１

Description

本開示は、車両用保守ツールに関する。

従来から、自動車や建設機械等の車両に搭載された電子制御装置（ＥＣＵ：Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）のソフトウェア（制御プログラム）を更新する技術が提案されている（例えば、特許文献１〜２）。

例えば、特許文献１には、小型、軽量化され、持ち運びや取り扱いが容易なハンディ式の車両用プログラム書き換え装置（リプロツール）が開示されている。一般に、車両に搭載される複数のＥＣＵはバス型などの車両ネットワークで相互に接続されているが、このリプロツールは、その端子部（ツールコネクタ）を、車両ネットワークに接続された状態でダッシュボードに設置された車両側コネクタに接続することにより、制御プログラムの更新（書き換え）を行うことが可能となっている。より具体的には、制御プログラムの更新は、ツールコネクタの車両側コネクタへの接続を契機に、または、リプロツールの容器部（ハウジング）に設けられたボタンの押下により開始される。また、リプロツールは、無線通信するための受信装置を備えておらず、制御プログラムの更新データは、容器部が備えるＳＤカードスロットに着脱されるＳＤカードに記憶される。このように構成することで、無線による通信状態が不安定な場合に更新データの無線受信に時間を要するといったことを回避し、制御プログラムの更新を短時間で可能とする旨が記載されている。

また、特許文献２には、夫々異なる制御ソフト更新処理が必要な複数のＥＣＵから構成される自動車システムであっても、夫々のＥＣＵの制御ソフト更新を利用に応じた適切な方法で容易に実施することが可能なソフト更新装置が開示されている。具体的には、このソフト更新装置は、車内ネットワークにＥＣＵと共に接続された状態で車両に搭載された装置であり、無線（移動体通信網）を介してサーバに接続する一方、車内ネットワークを介して複数の制御装置（ＥＣＵ）と接続し、データの送受信を行う。また、ソフト更新装置は、複数の制御装置毎に、更新データと、更新データを制御装置に適用するための適用方法を識別するための識別情報と、を含む更新制御情報をサーバから受信し、複数の制御装置毎に、適用される更新データを送信し、識別情報に基づいて更新データを適用するように、複数の制御装置を制御する。より詳細には、このソフト更新装置はＥＣＵと共に車内ネットワークに接続された状態で車両に搭載されている。更新データは、エンジン起動時などにサーバからダウンロードし、ソフト更新装置の記憶部に保持される。

なお、特許文献３には、車両データのリモート収集システムが開示されている。具体的には、車両ネットワークに接続された情報収集ＥＣＵが、車両データの収集条件を１乃至複数の命令により記述したスクリプトを車両外部のセンターなどから無線通信により受信すると、そのスクリプトを解釈・実行することによって、車両ネットワークに接続された車載のＥＣＵから車両データを収集し、センターに返信する。

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

近年、車両の高機能化、高性能化に伴い、車両を制御する電子制御装置（ＥＣＵ）に搭載されるソフトウェア（制御プログラム）の規模が増大している（特許文献２参照）。ソフトウェアの規模が増大すると不具合が生じる可能性も増えるなど、複数の車両に対してソフトウェアの更新を行う必要が生じる。この際、特許文献２のソフト更新装置や特許文献３の情報収集ＥＣＵのように、そのための専用の装置を車両毎に定常的に設置すると、車両コストの増大を招く。

この点、特許文献１のリプロツールは、各車両に専用に設けるものではなく、必要時に車種を問わずに共通に用いることができることから、車両コストの抑制が可能である。しかし、その反面、ソフトウェアの更新に際して各ＥＣＵに特有の処理を行う必要がある場合には、このような特有の処理を実行するための機能をＥＣＵ毎にそれぞれリプロツールに実装する必要があるなど、更新処理を実際に実行するまでの準備に多大な時間を費やすことになる。このような課題は、車両に搭載されるＥＣＵの数が多くなるほど顕著となり、作業効率の観点で改善の余地がある。また、特許文献１のリプロツールは、外部と無線通信用のインタフェースを省略しており、複数台の車両に対する上記の更新処理の実行を管理したい場合への対応が容易ではない。

上述の事情に鑑みて、本発明の少なくとも一実施形態は、車両コストを抑制しつつ、電子制御装置に対する保守作業を効率良く行うことが可能な車両用保守ツールを提供することを目的とする。

（１）本発明の少なくとも一実施形態に係る車両用保守ツールは、
車両に搭載される複数の電子制御装置が接続された車両ネットワークに接続される車両用保守ツールであって、
前記車両ネットワークに接続された状態で前記車両に搭載されている車両側コネクタに対して着脱可能な端子部と、
無線を介して外部から実行指令を受信する無線通信部と、
前記端子部及び前記無線通信部にそれぞれ接続された制御部であって、前記実行指令の受信に応じて、所定の処理を実行するためのスクリプトに記述された１以上の命令を順次解釈するスクリプト命令解釈部、及び前記スクリプト命令解釈部によって解釈された前記命令を順次実行することにより前記車両ネットワークを介して前記所定の処理を実行するスクリプト命令実行部を、有する制御部と、
前記端子部、前記無線通信部、及び前記制御部を保持するハンディ式保持ケースと、を備える。

上記（１）の構成によれば、車両用保守ツールはハンディ式の装置であり、車両に常時搭載されるのではなく、必要時に車両に取り付けて使用することが可能に構成される。また、車両用保守ツールは、スクリプトの実行機能を有すると共に、実行指令の受信に応じて、所望の処理（例えばソフト更新処理や通信ログ取得処理など）を記述したスクリプトを実行するように構成される。このようにハンディ式の車両用保守ツールがスクリプトの実行機能を有することにより、車両のコストを抑制しつつ、複数の電子制御装置（ＥＣＵ）毎に特有な処理を実行する必要があるような保守要求にも柔軟に、かつ、効率良く対応することができる。また、無線を通して外部からスクリプトの実行指令を受信するように構成することによって、複数台の車両に対してスクリプトを実行する場合であっても、各車両に車両用保守ツールをそれぞれ取り付けておくことによりソフト更新処理の実行を管理することができ、保守作業の効率性やユーザビリティなどの向上を図ることができる。

（２）幾つかの実施形態では、上記（１）の構成において、
前記スクリプトは、少なくとも１つの前記電子制御装置に対してソフトウェアの更新処理を実行するのに必要な前記命令の記述を含む。
上記（２）の構成によれば、スクリプトを実行することにより、１以上の電子制御装置のソフトウェアの更新を容易に行うことができる。

（３）幾つかの実施形態では、上記（２）の構成において、
前記スクリプトは、前記複数の電子制御装置毎に特有な前記命令の記述を含む。
上記（３）の構成によれば、車両のエンジン制御用ＥＣＵ、ブレーキ制御用ＥＣＵなどの複数種類の電子制御装置の各々に特有な処理をスクリプトに記述することによって、ソフトウェアの更新処理を適切に、かつ、容易に実行することができる。

（４）幾つかの実施形態では、上記（２）〜（３）の構成において、
前記ハンディ式保持ケースに対して着脱可能に接続される着脱可能記憶媒体であって、前記制御部による読み取りが少なくとも可能な着脱可能記憶媒体を、さらに備え、
前記着脱可能記憶媒体には、前記スクリプトの実行による前記ソフトウェアの更新のための更新データが記憶される。
上記（４）の構成によれば、更新データは、例えばマイクロＳＤカードなどの着脱可能記憶媒体に記憶される。更新データは、スクリプトや実行指令に比較してデータサイズが非常に大きい。よって、電子制御装置のソフトウェアの更新に際して、更新データが予め記憶された着脱可能記憶媒体を車両用保守ツールに取り付けるようにすれば、例えば、外部のコンピュータから無線により実行指令を受信するような場合であっても、無線の通信状態によるソフトウェアの更新の完了までに要する時間への影響を抑制することができ、スクリプトの実行を短時間で完了することができる。

（５）幾つかの実施形態では、上記（１）〜（４）の構成において、
前記スクリプトは、前記車両ネットワークを伝送される伝送データを収集するのに必要な前記命令の記述を含む。
上記（５）の構成によれば、スクリプトを実行することにより、車両ネットワークを流れる伝送データを収集することができ、少なくとも１つの電子制御装置が車両ネットワークを介して行う通信ログの取得を容易に行うことができる。

（６）幾つかの実施形態では、上記（１）〜（５）の構成において、
前記スクリプト命令解釈部は、前記無線通信部からの前記実行指令の受信に応じて、前記スクリプトに記述された前記１以上の命令の解釈を開始する。
上記（６）の構成によれば、制御部は、無線通信部からの実行指令を受信することにより、スクリプトの実行を開始する。これによって、保守作業の効率性やユーザビリティなどの向上を図ることができる。

（７）幾つかの実施形態では、上記（１）〜（６）の構成において、
英数字による表示が可能な表示部を、さらに備える。
上記（７）の構成によれば、例えば、スクリプトの開始、完了、終了状態などを表示部に表示することで、車両用保守ツールの使用者にスクリプトの実行状況を知らせることができ、ユーザビリティを向上させることができる。

（８）幾つかの実施形態では、上記（１）〜（７）の構成において、
前記車両側コネクタは、前記車両の車室に露出することが可能な位置に設けられている。
上記（８）の構成によれば、車両側コネクタは、電子制御装置が設置されてるような位置ではなく、乗員が居住する車室から容易に手の届く位置に設置される。よって、ハンディ式の車両用保守ツールを車両側コネクタに容易に取り付けることができる。

本発明の少なくとも一実施形態によれば、車両コストを抑制しつつ、電子制御装置に対する保守作業を効率良く行うことが可能な車両用保守ツールが提供される。

本発明の一実施形態に係る車両用保守ツールの構成を概略的に示す図である。 本発明の一実施形態に係る車両用保守ツールの外観を示す斜視図であり、（ａ）は車両用保守ツールの前面側からの斜視図であり、（ｂ）は後面側からの斜視図である。 本発明の一実施形態に係る車両用保守ツールをダッシュボードのツール設置部に設置した状態を示す図であり、（ａ）はダッシュボードの運転席付近の斜視図であり、（ｂ）はツール設置部付近を拡大した図である。 本発明の一実施形態に係る車両用保守ツールを複数の車両にそれぞれ接続した様子を示す図であり、延長ケーブルを用いて車両に取り付けられている。 本発明の一実施形態に係る電子制御装置のソフトウェアを更新するフローを示す図である。 本発明の一実施形態に係る車両ネットワークを流れる伝送データを取得するフローを示す図である。

以下、添付図面を参照して本発明の幾つかの実施形態について説明する。ただし、実施形態として記載されている又は図面に示されている構成部品の寸法、材質、形状、その相対的配置等は、本発明の範囲をこれに限定する趣旨ではなく、単なる説明例にすぎない。
例えば、「ある方向に」、「ある方向に沿って」、「平行」、「直交」、「中心」、「同心」或いは「同軸」等の相対的或いは絶対的な配置を表す表現は、厳密にそのような配置を表すのみならず、公差、若しくは、同じ機能が得られる程度の角度や距離をもって相対的に変位している状態も表すものとする。
例えば、「同一」、「等しい」及び「均質」等の物事が等しい状態であることを表す表現は、厳密に等しい状態を表すのみならず、公差、若しくは、同じ機能が得られる程度の差が存在している状態も表すものとする。
例えば、四角形状や円筒形状等の形状を表す表現は、幾何学的に厳密な意味での四角形状や円筒形状等の形状を表すのみならず、同じ効果が得られる範囲で、凹凸部や面取り部等を含む形状も表すものとする。
一方、一の構成要素を「備える」、「具える」、「具備する」、「含む」、又は、「有する」という表現は、他の構成要素の存在を除外する排他的な表現ではない。

図１は、本発明の一実施形態に係る車両用保守ツール１の構成を概略的に示す図である。図２は、本発明の一実施形態に係る車両用保守ツール１の外観を示す斜視図である。図３は、本発明の一実施形態に係る車両用保守ツール１をダッシュボード７１のツール設置部７２に設置した状態を示す図である。また、図４は、本発明の一実施形態に係る車両用保守ツール１を複数の車両７にそれぞれ接続した様子を示す図であり、延長ケーブル９３を用いて車両７に取り付けられている。

図１〜図４に示すように、車両用保守ツール１は、車両７に搭載される複数の電子制御装置８が接続された車両ネットワーク７ｎに接続されることによって、車両ネットワーク７ｎを介した通信（データの送受信）が可能になるように構成された装置である。車両ネットワーク７ｎは、複数の電子制御装置８（以下、適宜、ＥＣＵ８という。）を相互に接続するネットワークであり、車両７には、ＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）やＫライン、ＬＩＮ（Ｌｏｃａｌ Ｉｎｔｅｒｃｏｎｎｅｃｔ Ｎｅｔｗｏｒｋ）、ＦｌｅｘＲａｙなどの少なくとも１つの車両ネットワーク７ｎが搭載される。また、車両用保守ツール１はハンディ式の装置であり、小型、軽量であると共に、持ち運びや取り扱いが容易なように構成されており、その使用時に車両７に取り付けて使用するよう構成される（図３参照）。

そして、車両用保守ツール１は、図１に示すように、端子部２と、無線通信部３と、制御部４と、ハンディ式保持ケース５とを備える。
以下、車両用保守ツール１が備える上記の構成について、それぞれ説明する。

端子部２は、車両ネットワーク７ｎに接続された状態で車両７に搭載されている車両側コネクタ７ｃに対して着脱可能に構成される（図３参照）。換言すれば、端子部２は、上記の車両側コネクタ７ｃに嵌り合うように構成されたコネクタであり、車両側コネクタ７ｃに嵌り合った状態（接続状態）でにおいて端子部２と車両側コネクタ７ｃとは電気的に接続される。また、車両側コネクタ７ｃは、車両ネットワーク７ｎを介してＥＣＵ８に電気的に接続されている。よって、車両側コネクタ７ｃに端子部２を接続することにより、車両用保守ツール１とＥＣＵ８とが車両ネットワーク７ｎを介して電気的に接続される。幾つかの実施形態では、図３に示すように、端子部２は、車両側コネクタ７ｃに直接接続されも良い。他の幾つかの実施形態では、図４に示すように、延長ケーブル９３を介して車両側コネクタ７ｃに接続されても良い。

また、一般に、車両７の内部には、ダッシュボード７１やフロアパネル７４などに区画されることによって乗員が居住する車室７ｓが形成される（図２参照）。また、車室７ｓ以外の車両７の内部に、エンジン制御用のＥＣＵ８１、ブレーキ制御用のＥＣＵ８２、オーディオ制御用のＥＣＵ８３、ドア制御用のＥＣＵ８４、衝突防止制御用のＥＣＵ８５、メータ制御用のＥＣＵ８６などの複数種類のＥＣＵ８が設置されると共に、これらの複数のＥＣＵ８を相互に接続するように車両ネットワーク７ｎが設置される（図１参照）。そして、上記の車両側コネクタ７ｃは、図３に示すように、車両７の内部における、ＥＣＵ８が設置されるような場所ではなく、車室７ｓに面するなど、車室７ｓに露出することが可能な場所に設置されている。図１〜図４に示す実施形態では、図３に示すように、上述した車両側コネクタ７ｃは、ダッシュボード７１における運転席のハンドル（不図示）の右部に配置された、下方に向けて開口する空間を形成しているツール設置部７２の上記空間内に設置されている。また、車両側コネクタ７ｃは、ＳＡＥＪ１９６２規格で規定されたコネクタとなっている。但し、本実施形態に本発明は限定されない。他の幾つかの実施形態では、他の規格で規定されたコネクタであっても良い。また、ツール設置部７２にはカバーが設けられており、カバーを開くことで車両側コネクタ７ｃが車室７ｓに露出するように構成しても良い。あるいは、車両７の外部に面することが可能な位置にツール設置部７２が設けられても良い。

また、図１〜図４に示す実施形態では、車両用保守ツール１は、車両側コネクタ７ｃに端子部２を接続して接続状態とすることにより、車両７に搭載されたバッテリ７ｂからの電力が端子部２を介して供給されるようになっており、コンバータ６４によって１２Ｖから所望の電圧（３．３Ｖや５Ｖなど）に変圧された後、制御部４に電源が供給される。このように、車両用保守ツール１の内部に電源部を設けないことにより軽量化を図っているが、他の幾つかの実施形態では、乾電池や充電池等を内蔵するよう構成しても良い。

無線通信部３は、図１に示すように、無線を介して外部から実行指令Ｉｅを受信するよう構成される。上記の実行指令Ｉｅは制御部４による処理（後述）を開始させるための命令であり、例えば、外部のコンピュータ９から無線通信により送られる（図４参照）。図１に示すように、無線通信部３は、制御部４に電気的に接続されており、無線通信によって受信した実行指令Ｉｅを制御部４に送信する。図１〜図４に示す実施形態では、図４に示すように、無線通信部３は、無線ＬＡＮ（Ｗｉ−Ｆｉ）により、外部のコンピュータ９と通信可能に接続するように構成されている。但し、本実施形態に本発明は限定されない。他の幾つかの実施形態では、無線通信部３は、Ｂｌｕｅｔｏｏｔｈ（登録商標）、あるいは、移動体通信網などを介して外部のコンピュータ９に接続するなど、他の無線方式により両社が接続されても良い。また、無線ネットワークと外部のコンピュータ９との間に有線ＬＡＮなどといった有線ネットワークが介在していても良い。

制御部４は、図１に示すように、上述した端子部２及び無線通信部３にそれぞれ電気的に接続されると共に、上述した実行指令Ｉｅを受信すると、所望の処理が記述されたスクリプトを実行するスクリプト実行機能を有する。ここで、スクリプトとは、インタプリタ型の言語である所定のスクリプト言語により記述された少なくとも１つの命令を有する簡易プログラムであり、事前にコンパイルすることなく実行可能であるなど、ＥＣＵ８のソフトウェア（制御プログラム）の更新といった所望の処理を実行可能とするまでの準備が比較的容易に行うことが可能となる。このように制御部４がスクリプト実行機能を有することで、所望の処理を比較的容易に行うことが可能になる。さらに、スクリプトは、複数のＥＣＵ８毎に特有となる特有処理の実装もが容易であり、また、テキストベースで記述内容をチェックできるなどスクリプトの検証も容易であり、多様な処理に容易に対応することが可能となる。

例えば、スクリプトには、車両ネットワーク７ｎにおける所望のＥＣＵ８とデータを送受信するための命令や、所望のＥＣＵ８から故障コード（ＤＴＣ：Ｄｉａｇｎｏｓｔｉｃ Ｔｒｏｕｂｌｅ Ｃｏｄｅ）を読み出すための命令、車両ネットワーク７ｎを流れるデータをキャプチャするための命令（通信データの取得）などの記述が可能であっても良い。また、車両用保守ツール１がＣＡＮやＫ−Ｌｉｎｅなど複数種類の車両ネットワーク７ｎに対応可能とするために、これらの命令においてバスの指定が可能になっていても良い。また、車両ネットワーク７ｎ上で動作する複数種類のプロトコル（ＫＷＰ、ＵＤＳ、Ｋ−Ｌｉｎｅなど）に対応可能とするために、プロトコル毎に命令が容易されていても良い。また、スクリプトにおける指定行（指定箇所）への移動（ｃａｌｌやジャンプ）や復帰（ｃａｌｌの次の行へのリターン）、ループ、条件分岐、スリープといったプログラムの制御命令の記述が可能となっている。さらに、変数の宣言や、変数の論理演算や数値演算などの命令が記述可能であっても良い。また、車両用保守ツール１に設置されるＬＥＤなどの発光部６３の点灯命令や消灯命令、ＬＣＤなどの表示部６２（表示装置）への表示命令、スピーカ（不図示）からのブザーの音のオン命令やオフ命令などの搭載機器への操作命令の記述が可能であっても良い。

このようなスクリプトを、制御部４は無線通信部３を介して受信しても良く、上述した無線により送られる実行指令Ｉｅと共に受信しても良いし、実行指令Ｉｅとして受信しても良い。あるいは、スクリプトを、マイクロＳＤなどの記憶媒体である着脱可能記憶媒体６１に予め記憶しておき、車両用保守ツール１が備える着脱可能記憶媒体６１を装着するためのメモリスロット（不図示）に着脱可能記憶媒体６１を装着することにより、制御部４は、実行指令Ｉｅの受信に応じて着脱可能記憶媒体６１に記憶されているスクリプトを読み込むように構成しても良い。図１〜図４に示す実施形態では、図２（ｂ）に示すように、保護カバー１２を取り外すことにより、取り付け時に保護カバー１２で保護された状態にある上記のメモリスロット（不図示）が外部に露出するようになっている。また、図１〜図４に示す実施形態では、保護カバー１２の取り付け状態において、メモリスロット共に、ＵＳＢ接続口などの外部接続用の本体側インタフェース（不図示）が保護されており、本体側インタフェースに対してパソコンやＵＳＢスイッチ７６（後述）などが接続可能となっている。なお、図２（ｂ）に示すＵＳＢスイッチ７６は外部接続用インタフェース７７（図２（ｂ）ではＵＳＢ）を有しており、車両用保守ツール１は、この外部接続用インタフェース７７を介して上記のメモリスロットが接続されることで、メモリスロットを備えていても良い。

より詳細には、制御部４は、図１に示すように、スクリプト命令解釈部４１と、スクリプト命令実行部４２とを備える。制御部４は、図示しないプロセッサ（ＭＰＵなど）とＲＯＭやＲＡＭといったメモリを備え、ＲＡＭにロードされたスクリプト命令解釈部４１およびスクリプト命令実行部４２を実現させるためのプログラム（スクリプト実行プログラム）の命令に従ってＣＰＵが動作（データの演算など）することで、これらの機能部を実現する。

スクリプト命令解釈部４１は、上記の実行指令Ｉｅの受信に応じて、上述したスクリプトに記述された１以上の命令を順次解釈するよう構成される。このスクリプト命令解釈部４１は、所定のスクリプト言語に従って記述された各種命令を機械語に翻訳することにより解釈することが可能である。そして、スクリプト命令解釈部４１は、実行指令Ｉｅを受信するとスクリプトの実行を開始すると共に、スクリプトの開始から終了まで記述された各命令を、ループや条件分岐などの制御命令に従って順次読み込みつつ、解釈していく。

上述したスクリプト命令解釈部４１による実行指令Ｉｅの受信は、幾つかの実施形態では、上述した無線通信部３を介して行われても良い（図４参照）。つまり、スクリプト命令解釈部４１（制御部４）は、無線通信部３からの実行指令Ｉｅの受信に応じて、スクリプトに記述された１以上の命令の解釈を開始する。他の幾つかの実施形態では、車両用保守ツール１が、実行開始用のスイッチ７５を備えることで、制御部４は、このスイッチ７５がオン（ＯＮ）に操作された状態で出力される信号を上記の実行指令Ｉｅとして受信するよう構成しても良い。図２に示す実施形態では、図２（ｂ）に示す保護カバー１２を取り外した状態で外部に露出する不図示の本体側インタフェース（図２（ｂ）ではＵＳＢ接続口）に、スイッチ７５を有するＵＳＢスイッチ７６を接続するようになっており、スイッチ７５を必要な時に取り付けることが可能に構成している。その他の幾つかの実施形態では、制御部４は、端子部２が車両側コネクタ７ｃに接続された状態で出力される信号を上記の実行指令Ｉｅとして受信しても良い。この場合には、実行指令Ｉｅは電源信号であっても良い。その他の幾つかの実施形態では、上述した実施形態の少なくとも１つを組み合わせても良く、モード設定などによって切り替えるように構成しても良い。例えば、モードを切り替えることで、無線通信部３を介した実行指令Ｉｅの受信や、スイッチ７５のオン操作による実行指令Ｉｅの受信の実施形態と、端子部２と車両側コネクタ７ｃとの接続契機による実行指令Ｉｅの受信の実施形態とを切り替えても良い。また、例えば、スイッチ７５がオフ（ＯＦＦ）の際に無線通信部３からの実行指令Ｉｅを受信した場合や車両側コネクタ７ｃに接続された場合には、例えばスイッチ７５のオフを優先するなど、上述した実施形態の組み合わせた場合には優先順位を設けても良い。上記の例では、スイッチ７５のオフを優先することによって、外部のコンピュータ９からの実行指令Ｉｅの誤送信による誤動作の防止や接続契機による作動（実行指令Ｉｅの受信）の回避などを行うことができる。

他方、スクリプト命令実行部４２は、スクリプト命令解釈部４１によって順次解釈された命令を順次実行することにより車両ネットワーク７ｎを介して、スクリプトに記述された所定の処理を実行するよう構成される。スクリプト命令実行部４２は、スクリプト命令解釈部４１が解釈した命令（機械語）を実行する。例えば、スクリプト命令実行部４２は、スクリプト命令解釈部４１からの入力に従って、端子部２および車両ネットワーク７ｎを介してＥＣＵ８に対して命令を送信する。また、送信した命令の応答を受信し、スクリプト命令実行部４２に引き渡す。そして、スクリプト命令解釈部４１は、解釈した命令に対する実行結果（命令の成功、失敗）を確認し、この命令の実行結果に応じてスクリプトの次の命令を選択しつつ、スクリプトの実行を進めていく。このように、相互に接続されたスクリプト命令解釈部４１およびスクリプト命令実行部４２が協同して、スクリプトを実行する。

また、スクリプト命令解釈部４１およびスクリプト命令実行部４２は、スクリプトの実行にあたって、スクリプトに記述された命令の実行を制御する情報や共通となる内容を記述した設定ファイルを読み込むように構成しても良い。具体的には、設定ファイルには、車両ネットワーク７ｎを介した送信や受信のタイムアウト時間やリトライ回数、ＤＴＣを読み出す命令を実行する前の待機時間など、複数の命令に共通する内容を記述しても良い。また、例えば、設定ファイルには、イグニッションのオンやオフのチェックの実行の有無など、所望の処理（所定の処理）を実行する前に必要と判断される処理を記述しても良い。設定ファイルを利用することで、スクリプトの作成時間の短縮化を図ることが可能となる。

ハンディ式保持ケース５はハウジングであり、上述した端子部２、無線通信部３、及び制御部４を保持するよう構成される。これによって、車両用保守ツール１がハンディ式となっている。より詳細には、図１〜図４に示す実施形態では、図１に示すように、ハンディ式保持ケース５は、端子部２、無線通信部３、及び制御部４を内部に収容するとともに、端子部２の少なくとも一部が外部に露出した状態で保持するように構成されており、外部に露出した端子部２により、上述した車両側コネクタ７ｃとの接続が容易に行えるように図っている。

上記の構成によれば、車両用保守ツール１はハンディ式の装置であり、車両７に常時設置されるのではなく、必要時に車両に取り付けて使用することが可能に構成される。また、車両用保守ツール１は、スクリプトの実行機能を有すると共に、実行指令Ｉｅの受信に応じて、所望の処理（例えばソフト更新処理や通信ログ取得処理など）を記述したスクリプトを実行するように構成される。このようにハンディ式の車両用保守ツール１がスクリプトの実行機能を有することにより、車両７のコストを抑制しつつ、複数の電子制御装置８毎に特有な処理を実行する必要があるような保守要求にも柔軟に、かつ、効率良く対応することができる。また、無線を通して外部からスクリプトの実行指令Ｉｅを受信するように構成することによって、複数台の車両７に対してスクリプトを実行する場合であっても、各車両に車両用保守ツール１をそれぞれ取り付けておくことによりソフト更新処理の実行を管理することができ、保守作業の効率性やユーザビリティなどの向上を図ることができる。

幾つかの実施形態では、上述したスクリプトは、図５に示すようなソフトウェア（制御プログラム）の更新処理を、少なくとも１つの電子制御装置８（ＥＣＵ）に対して実行するのに必要な命令の記述を含む。図５は、本発明の一実施形態に係る電子制御装置８のソフトウェアを更新するフローを示す図である。図５のフローに従って、スクリプトの実行により行われる、ＥＣＵ８のソフトウェアの更新処理（Ｓ１〜Ｓ９。以下、適宜、ソフト更新処理という。）を説明する。なお、図５の各ステップは、スクリプトに記述された命令に基づいて実行される。図５の例示は、複数種類のＥＣＵ８に対してソフトウェアの更新を行うよう記述されスクリプトに対応している。

まず、図５のステップＳ１の実行前に、車両用保守ツール１を車両７の車両側コネクタ７ｃに接続し、両者を接続状態とする。これによって、車両用保守ツール１は、上述した実行指令Ｉｅの受信待ちの状態になる。この状態を前提として、ステップＳ１において、制御部４が実行指令Ｉｅを受信すると、スクリプトの実行を開始する。また、本実施形態では、ステップＳ２において、制御部４は、設定ファイル（リプロ設定ファイル）を読み込むようになっている。そして、次のステップＳ３において、車両全体前処理を実行する。この車両全体前処理は、ソフト更新処理の実行中に車両７のＥＣＵ８が通信エラーなどを判定しないように、全てのＥＣＵ８をスリープモードに移行するといった処理を含んでいても良い。

ステップＳ４において、ソフトウェアを更新すべき対象（ソフト更新対象）となるＥＣＵ８が車両７に搭載されているか否かを確認する。ソフト更新対象のＥＣＵ８は、スクリプトにリストなどとして記述されており、スクリプトに記載された制御命令（ループなど）に従ってリストを順番に確認していく。なお、このようなリストは設定ファイルなどの他のファイルから読み込むようにしても良い。例えば、エンジン制御用ＥＣＵ８がソフト更新対象のバージョンを有していればソフトウェアを更新する場合を例に説明すると、車両７が、エンジン制御用ＥＣＵ８を搭載しており、かつ、その種類のＥＣＵ８におけるソフト更新対象のバージョンを有しているか否かを確認し、この条件が満たされる場合にはソフト更新対象となるＥＣＵ８が車両に搭載されていると判定する。より詳細には、制御部４からバージョン情報を要求する命令を、宛先をエンジン制御用ＥＣＵ８にセットして送信し、その命令に対するエンジン制御用ＥＣＵ８からの応答があり、かつ、その応答にあるバージョンがソフト更新対象のバージョンであれば、ソフト更新対象となるＥＣＵ８が車両に搭載されていると判定する。逆に、上記の条件が満たされていない場合、エンジン制御用ＥＣＵ８を搭載されていない（応答なしなど）、または、その種類のＥＣＵ８におけるソフト更新対象のバージョンを有していない場合には、ソフト更新対象のＥＣＵ８が車両に搭載されていないと判定する。

そして、ステップＳ４において、ソフト更新対象のＥＣＵ８が搭載されていると判定した場合には、ステップＳ５〜Ｓ７において、そのＥＣＵ８に対するソフトウェアの更新を実行する。なお、ステップＳ５〜Ｓ７の詳細は後述する。また、ステップＳ８において、リストなどで記述された次のソフト更新対象のＥＣＵ８がまだあれば、そのソフト更新対象のＥＣＵ８に対してソフトウェアの更新が搭載されているか否かをステップＳ４に戻って行う。また、ステップＳ８において、リストなどの全てのソフト更新対象のＥＣＵ８に対してステップＳ４の確認が完了していれば、ステップＳ９に進む。このように、本実施形態では、スクリプトに記述可能なプログラムの制御命令により、複数のＥＣＵ９に対するソフトウェアへの更新が可能となっている。

ステップＳ９において、車両全体後処理を実行する。車両全体後処理では、全てのＥＣＵ８をスリープモードから通常モードへ移行するといった処理を含んでいても良い。その後、車両用保守ツール１を車両７（車両側コネクタ７ｃ）から取り外すことにより、保守作業が完了する。

上記の構成によれば、スクリプトを実行することにより、１以上の電子制御装置８（ＥＣＵ）のソフトウェアの更新を容易に行うことができる。

また、幾つかの実施形態では、図５のステップＳ５、Ｓ７に示すように、上述したスクリプトは、複数の電子制御装置８毎に特有な命令の記述を含む。より詳細には、ステップＳ４によってソフト更新対象のＥＣＵ８が車両７に搭載されていると判定されると、ステップＳ５において、そのＥＣＵ８に特有な前処理（対象ＥＣＵ特有前処理）を実行する。具体的には、制御部４は、そのソフト更新対象のＥＣＵ８の故障コード（ＤＴＣ）を読み出すための命令を実行し、故障コードを確認する。そして、故障コードで故障がないことを確認した後、次のステップＳ６において、ソフトウェアの更新（更新メイン処理）を実行する。具体的には更新データＵで既存のソフトウェアを書き換える処理を実行する。逆に、ステップＳ５において、故障コードで故障があることが確認された場合には、そのＥＣＵ８に対するソフトウェアの更新を中止すると共に、ステップＳ８にジャンプしたり、あるいは、ステップＳ９にジャンプすることによりスクリプトの実行自体を中止したりするなど、故障に応じた処理を行っても良い。

そして、ステップＳ６における更新メイン処理が完了した後、ステップＳ７において、そのＥＣＵ８に特有な後処理（対象ＥＣＵ特有後処理）を実行する。具体的には、制御部４は、そのＥＣＵ８の故障コードを消去する命令を実行すると共に、所定時間経過後に故障コードを再度読み出す命令を実行し、故障コードがないことを確認する。この際、故障コードを消去したにもかかわらず、故障コードで故障が示される場合には、前処理の場合と同様に、故障コードで故障があることが確認された場合には、ステップＳ８や、ステップＳ９にジャンプするなど、故障に応じた処理を行っても良い。

上記の構成によれば、ソフト更新処理のためのスクリプトは、図５のステップＳ５やＳ７のような、少なくとも１つの電子制御装置８毎に特有な命令を含む。したがって、車両７のエンジン制御用ＥＣＵ８１、ブレーキ制御用ＥＣＵ８２などの複数種類の電子制御装置８の各々に特有な処理をスクリプトに記述することによって、ソフトウェアの更新処理を適切に、かつ、容易に実行することができる。例えば、予めコンパイルされるプログラムに対して、ＥＣＵ８毎の特有処理をそれぞれ実装するのは労力がかかるが、柔軟に記述可能なスクリプトによれば、そのようなＥＣＵ８の特有処理を比較的容易に実装することができる。

また、幾つかの実施形態では、上述したＥＣＵ８のソフトウェアの更新データＵは、上述した着脱可能記憶媒体６１に記憶されていても良い。すなわち、幾つかの実施形態では、車両用保守ツール１は、ハンディ式保持ケース５に対して着脱可能に接続される着脱可能記憶媒体６１であって、制御部４による読み取りが少なくとも可能な着脱可能記憶媒体６１を、さらに備える。そして、着脱可能記憶媒体６１には、スクリプトの実行によるソフトウェアの更新のための更新データＵが記憶される。

更新データＵは、スクリプトや実行指令Ｉｅに比較してデータサイズが非常に大きい。よって、ＥＣＵ８のソフトウェアの更新に際して、更新データＵが予め記憶された着脱可能記憶媒体６１を車両用保守ツール１に取り付けるようにすれば、例えば、外部のコンピュータ９から無線により実行指令Ｉｅを受信するような場合であっても、無線の通信状態によるソフトウェアの更新の完了までに要する時間（外部のコンピュータ９からの実行指令Ｉｅの送信からスクリプトの実行完了までに要する時間）への影響を抑制することができ、スクリプトの実行を短時間で完了することができる。

また、幾つかの実施形態では、上述したスクリプトは、図６示すような、車両ネットワーク７ｎを伝送される伝送データＴを収集するのに必要な命令の記述を含んでいても良い。図６は、本発明の一実施形態に係る車両ネットワーク７ｎを流れる伝送データＴを取得するフローを示す図である。図６のフローに従って、スクリプトの実行により行われる通信ログ取得処理（Ｓ１１〜Ｓ１６）を説明する。図６の各ステップは、スクリプトに記述された命令に基づいて実行される。なお、伝送データＴは通信の単位を意味しており、ＣＡＮであればフレームに相当する。よって、伝送データＴには、ＥＣＵ８間で通信する通信データが含まれるが、伝送データＴを収集あるいは取得するとは、伝送データＴの全てでなくても良く、伝送データＴに含まれる通信データなど所望のフィールドの情報のみを収集あるいは取得することも含むものとする。

まず、図６のステップＳ１１の実行前に、車両用保守ツール１を車両７の車両側コネクタ７ｃに接続し、両者を接続状態とする。これによって、車両用保守ツール１は、上述した実行指令Ｉｅの受信待ちの状態になる。この状態を前提として、ステップＳ１１において、制御部４が実行指令Ｉｅを受信すると、スクリプトの実行を開始する。また、本実施形態では、ステップＳ１２において、制御部４は、設定ファイル（伝送データ収集設定ファイル）を読み込む。そして、次のステップＳ１３において、伝送データ収集開始指示の受信待ちを行う。この開始指示は、上述した無線通信部３を介して受信しても良いし、既に述べた開始用のスイッチ７５がオンに操作されることで出力される信号を上記の伝送データ収集開始指示として受信するよう構成しても良い。

そして、ステップＳ１３において、伝送データ収集開始指示を受信すると、ステップＳ１４において伝送データＴの収集を実行する。具体的には、車両用保守ツール１は、端子部２を介して、車両ネットワーク７ｎを流れる伝送データＴのキャプチャ（取得）を開始する。キャプチャされた伝送データＴは通信ログとして記憶するが、書き込みも可能な着脱可能記憶媒体６１に記憶されても良い。また、ステップＳ１４における伝送データＴの収集の命令において、所望のＥＣＵ８を指定することによって、そのＥＣＵ８に関連する伝送データＴのみフィルタして、記憶するようにしても良い。そして、ステップＳ１４による伝送データＴのキャプチャは、終了指示を受信するまで実行される（ステップＳ１５）。この終了指示も、上述した無線通信部３を介して受信しても良いし、既に述べた開始用のスイッチ７５がオフに操作されることで出力される信号を上記の終了指示として受信するよう構成しても良い。そして、ステップＳ１５において終了指示を受信すると、ステップＳ１６において、伝送データＴのキャプチャ（取得）を終了する。その後、車両用保守ツール１を車両７（車両側コネクタ７ｃ）から取り外すことにより、保守作業が完了する。

上記の構成によれば、スクリプトを実行することにより、車両ネットワーク７ｎを流れる伝送データＴを収集することができ、少なくとも１つの電子制御装置８が車両ネットワーク７ｎを介して行う通信ログの取得を容易に行うことができる。

以下、車両用保守ツール１のその他の構成について説明する。
幾つかの実施形態では、図１〜図４に示すように、車両用保守ツール１は、英数字による表示が可能な表示部６２を、さらに備えていても良い。図１〜図４に示す実施形態では、表示部６２は、ＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）を含んでいると共に、ハンディ式保持ケース５の上面にＬＣＤを設けることで、外部から視認可能となっている。また、ＬＣＤには、例えば２行で表示しても良く、ｎ文字×ｍ行（ｎ≧１、ｍ≧１）で表示可能となっている。

また、表示部６２への表示は、スクリプトに記述した命令に基づいて実行される。例えば、スクリプトには、ソフトウェアの更新処理の開始をＲＥＰＲＯ ＧＯなどと表示し（図２（ａ）参照）、何らかのエラーが発生した場合には、ＲＥＰＲＯ ＥＲＲｘ（ｘは、エラーの数字などによる識別番号）を表示するように命令が記述されている。他方、通信ログ取得処理では、伝送データＴのキャプチャの実行中にＬＯＧ ＲＵＮと表示するようになっている。このように、例えば、スクリプトに記述された処理の開始、完了、終了状態などを表示部に表示することで、車両用保守ツールの使用者にスクリプトの実行状況を知らせることができ、ユーザビリティを向上させることができる。

また、幾つかの実施形態では、図１〜図４に示すように、車両用保守ツール１は、ＬＥＤなどの発光部６３をさらに備えていても良い。この発光部６３は、表示部６２と共に、または、表示部６２に代えて、車両用保守ツール１に設けられても良い。図１〜図４に示す実施形態では、車両用保守ツール１の上面に設けられた２つのＬＥＤ（赤と青などの異なる色）を含んでいる。そして、スクリプトに記述された命令に従って、点灯すするＬＥＤや発光の仕方を変えることで、車両用保守ツール１の現在の状態を示すことが可能になっている。例えば、発光部６３により、車両ネットワーク７ｎとの間で通信を行っていることを示したり、スクリプトに記述された処理の正常終了、異常終了などを示したりするなどが可能とになっている。

本発明は上述した実施形態に限定されることはなく、上述した実施形態に変形を加えた形態や、これらの形態を適宜組み合わせた形態も含む。

１ 車両用保守ツール
１２ 保護カバー
２ 端子部
３ 無線通信部
４ 制御部
４１ スクリプト命令解釈部
４２ スクリプト命令実行部
５ ハンディ式保持ケース
６１ 着脱可能記憶媒体
６２ 表示部
６３ 発光部
６４ コンバータ
７ 車両
７ｂ バッテリ
７ｃ 車両側コネクタ
７ｎ 車両ネットワーク
７ｓ 車室
７１ ダッシュボード
７２ ツール設置部
７４ フロアパル
７５ スイッチ
７６ ＵＳＢスイッチ
７７ ＵＳＢスイッチの外部接続用インタフェース
８ 電子制御装置（ＥＣＵ）
９ コンピュータ
９３ 延長ケーブル
Ｕ 更新データ
Ｔ 伝送データ
Ｉｅ 実行指令

Claims (7)

1. 車両に搭載される複数の電子制御装置が接続された車両ネットワークに接続される車両用保守ツールであって、
   前記車両ネットワークに接続された状態で前記車両に搭載されている車両側コネクタに対して着脱可能な端子部と、
   前記端子部及び前記無線通信部にそれぞれ接続された制御部であって、前記実行指令の受信に応じて、所定の処理を実行するためのスクリプトに記述された１以上の命令を順次解釈するスクリプト命令解釈部、及び前記スクリプト命令解釈部によって解釈された前記命令を順次実行することにより前記車両ネットワークを介して前記所定の処理を実行するスクリプト命令実行部を、有する制御部と、
   前記端子部及び前記制御部を保持するハンディ式保持ケースと、を備え、
   前記スクリプトは、少なくとも１つの前記電子制御装置に対してソフトウェアの更新処理を実行するのに必要な前記命令の記述を含み、
   前記スクリプトは、前記ソフトウェアの更新処理における前記複数の電子制御装置毎に特有な前記命令の記述と、更新対象となる既存のソフトウェアを更新データで書き換える更新メイン処理を行うプログラムを実行するための前記命令の記述と、を含み、
   前記複数の電子制御装置毎に特有な前記命令の記述は、前記電子制御装置から故障コードを読み出すための命令、または、前記電子制御装置の故障コードを消去するための命令の少なくとも一方を含むことを特徴とする車両用保守ツール。
2. 前記複数の電子制御装置毎に特有な前記命令の記述は、前記電子制御装置から故障コードを読み出すための命令、および、前記電子制御装置の故障コードを消去するための命令を含むことを特徴とする請求項１に記載の車両用保守ツール。
3. 前記ハンディ式保持ケースに対して着脱可能に接続される着脱可能記憶媒体であって、前記制御部による読み取りが少なくとも可能な着脱可能記憶媒体を、さらに備え、
   前記着脱可能記憶媒体には、前記スクリプトの実行による前記ソフトウェアの更新のための更新データが記憶されることを特徴とする請求項１または２に記載の車両用保守ツール。
4. 前記スクリプトは、前記車両ネットワークを伝送される伝送データを収集するのに必要な前記命令の記述を含むことを特徴とする請求項１〜３のいずれか１項に記載の車両用保守ツール。
5. 前記スクリプト命令解釈部は、前記無線通信部からの前記実行指令の受信に応じて、前記スクリプトに記述された前記１以上の命令の解釈を開始することを特徴とする請求項１〜４のいずれか１項に記載の車両用保守ツール。
6. 英数字による表示が可能な表示部を、さらに備えることを特徴とする請求項１〜５のいずれか１項に記載の車両用保守ツール。
7. 前記車両側コネクタは、前記車両の車室に露出することが可能な位置に設けられていることを特徴とする請求項１〜６のいずれか１項に記載の車両用保守ツール。

Images