JP2017191360A - 車両の制御システム及び制御方法 - Google Patents

Abstract

【課題】車両の制御システムに制御プログラムのインストールを確実に実行する。
【解決手段】ブートローダは、ＴＣＵ（トランスミッション・コントロールユニット）ソフトウェアを起動できないと判定すると５０２ＮＯ、インストール要求フラグをチェックする５１６。インストール要求有５１６ＹＥＳを確認すると、メンテナンスツールに新ＴＣＵソフトウェアをＴＣＵにインストールさせる５１８。ブートローダが制御プログラムを起動可能であると判定すると５０２ＹＥＳ、ＴＣＵソフトウェアを診断する５０４。ＴＣＵソフトウェアが妥当でない場合には、ＴＣＵソフトウェアが起動される前にＴＣＵソフトウェアのインストールのリクエストがブートローダに受け入れられ５０８、５１０、ＴＣＵソフトウェアのインストールが行われる５１４。
【選択図】図５

Description

本発明は車両の制御システム及び制御方法に関し、特に自動車の変速装置を制御する制御システム及び制御方法に関する。

従来、ＡＭＴ（オートメーテッド・マニュアル・トランスミッション）と称される変速装置が知られている（例えば、特許文献１）。ＡＭＴは、トランスミッションがマニュアル機構として構成されていながら、クラッチ操作とギヤ位置の切り替えを自動化することによって、ドライバによるクラッチ操作やシフトチェンジの操作を要せずに車両を走行させることができる装置である。

自動車のＡＭＴを制御するシステムは、トランスミッション・コントロールユニット（ＴＣＵ）と呼ばれる制御ユニットを備える。ＴＣＵのソフトウェアモジュールは、少なくともＡＭＴを制御する制御プログラム及びこの制御プログラムを起動するブートローダを備える。ＴＣＵは、キーオンされるとブートローダを起動し、起動されたブートローダがＡＭＴの制御プログラムを起動する。

特開２０１３―１６９８８３号公報

ところで、車両の制御システムに制御プログラムを再インストールする必要が生じる場合がある。例えば制御プログラムをバージョンアップする場合、或いは、制御システムが搭載される車両のタイプを変更する場合に制御プログラムを再インストールする必要が生じる。

車両の制御プログラムを再インストールする場合には通常、メンテナンスツールを用いて起動中の制御プログラムにアクセスする。このとき制御プログラムは、再インストールのための処理をブートローダに指示する。ブートローダは、メンテナンスツールに既存の制御プログラムを削除し、新しい制御プログラムをアップロードしてインストールする。

しかし制御プログラムが起動されている状態でメンテナンスツールを用いて制御プログラムにアクセスしても、制御プログラムは車両の制御のための処理を優先して継続する。この場合、制御プログラムは制御プログラムの再インストールをブートローダに指示することはない。よって車両の制御ユニットに制御プログラムを再インストールすることができないという課題がある。

本発明は、車両の制御システムに制御プログラムのインストールを確実に実行させることを目的とする。

そこで本発明は、上記の目的を達成するために、制御対象と、制御対象の制御ユニットとを備える車両の制御システムであって、制御ユニットは、制御プログラムを起動する前に制御プログラムをインストールするためのアクセスを受け入れるようにしたことを特徴とする。

さらに本発明は、制御対象を制御ユニットが制御する車両の制御方法であって、制御ユニットは、制御プログラムを起動する前に制御プログラムをインストールするためのアクセスを受け入れるようにしたことを特徴とする。

本発明によれば、車両の制御システムに制御プログラムのインストールを確実に実行させることができる。

車両のハードウェアブロック図である。 変速制御システムの機能ブロック図である。 ＴＣＵのハードウェアブロック図である。 インストール処理の経過を示すブロック図である。 ＴＣＵの起動処理の一例を示すフローチャートである。 ＴＣＵの起動処理の他の例を示すフローチャートである。 ＴＣＵの起動処理のさらに他の例を示すフローチャートである。

次に、本発明の実施の形態を、図面を参照して説明する。なお以下の説明は、本発明を限定するものではなく、本発明の範囲内で適宜変更することができる。

図１は、制御システムの一例としての変速制御システムを備える車両のハードウェアブロック図である。変速制御システムは、トランスミッション（制御対象）２２と、ＴＣＵ（制御ユニット）２４とを備える。車両１０は、エンジン１２と、インプットシャフト１４と、インプットシャフト１４とエンジン１２とを断続するクラッチ１６と、アウトプットシャフト２０とを備える。トランスミッション２２は、インプットシャフト１４とアウトプットシャフト２０とを複数のギヤを切り替えて接続する。ＴＣＵ２４は、トランスミッション２２の変速を制御する。エンジン１２側のシステムは、インプットシャフト１４に接続するハイブリッドモータ１８と、モータ制御ユニット２６とを有する。

トランスミッション２２はＡＭＴとして構成され、動力機構（エンジン・モータ）の駆動力をインプットシャフト１４から、複数のギヤの切り替えによって駆動輪２８側のアウトプットシャフト２０に伝達する。

次に、変速制御システムの詳細を図２（変速制御システム１００の機能ブロック図）に基づいて説明する。変速制御システム１００は、制御ユニットとしてのＴＣＵ２４並びにＴＣＵ２４に接続されたチェンジレバーシフト位置検出センサ５０と車両走行状態検出センサ５２とを備える。変速制御システム１００は、さらに自動変速装置２２Ａを備え、自動変速装置２２Ａは、変速を行うトランスミッション２２と、このトランスミッション２２の変速シフトを制御するためにトランスミッション２２のギヤ入れ及びギヤ抜きを行う、例えば電動モータ等のシフトアクチュエータ５６と備える。

チェンジレバーシフト位置検出センサ５０は、チェンジレバーのシフト位置を検出してレバーシフト位置信号を出力する。車両走行状態検出センサ５２は、車両速度及びエンジン負荷等、車両の走行時における車両走行状態情報を検出して車両走行状態信号を出力する。

ＴＣＵ２４は、シフト信号生成モジュール５７、ギヤシフト制御モジュール５８及びトランスミッションインプット側回転数（回転速度）出力モジュール５９を有する。シフト信号生成モジュール５７は、チェンジレバーシフト位置検出センサ５０からのレバーシフト位置信号に基づいてチェンジレバーのシフト位置を判定してシフト位置信号を出力すると共に、車両走行状態検出センサ５２からの車両走行状態信号に基づいて、車両速度やエンジン負荷等の車両走行時における車両走行状態情報を判定して車両走行状態信号を出力する。

トランスミッションインプット側回転数出力モジュール５９は、トランスミッションのインプット側回転数のトランスミッションインプット側回転数信号をギヤシフト制御モジュール５８に出力する。トランスミッションインプット側回転数出力モジュール５９としては、例えばトランスミッションのインプットシャフト回転数のインプットシャフト回転数信号を出力するインプットシャフト回転数出力モジュール又はクラッチの従動側（出力側）の回転数である、クラッチ回転数信号を出力するクラッチ回転数出力モジュールが用いられる。

ギヤシフト制御モジュール５８は、シフト信号生成モジュール５７からのシフト位置信号、車両走行状態信号、シフトアクチュエータ５６からのシフトストローク位置信号、及び、トランスミッションインプット側回転数出力モジュール５９からのトランスミッションインプット側回転数信号に基づいてシフトアクチュエータ５６の作動制御条件を設定し、設定した作動制御条件に基づいたシフトアクチュエータ作動制御信号をシフトアクチュエータ５６に出力する。

シフトアクチュエータ５６はシフトアクチュエータ作動制御信号に基づいてシフトアームを介してトランスミッション２２の対応するギヤシフトスリーブを作動させて、ギヤ入れ、又は、ギヤ抜きを行うことで、トランスミッション２２をシフト信号生成モジュール５７からのシフト位置判定信号に基づいたギヤ位置に設定する。その場合、ギヤ位置設定（シフトストローク位置設定）のフィードバック信号がシフトアクチュエータ５６からギヤシフト制御モジュール５８へ出力される。

なお図２において「モジュール」とは、ＴＣＵ２４のソフトウェア資源及び/又はハードウェア資源によって実現される。

さらにＴＣＵ２４の詳細について説明する。図３にＴＣＵ２４のハードウェアブロックを示す。ＴＣＵ２４はマイクロコンピュータとして構成され、コントローラ（ＣＰＵ）２００を中心に、ＲＯＭ２０２、ＲＡＭ（メインメモリ）２０３を有すると共に、車両内部に敷設されたＣＡＮやＫ−lineなどのダイアグツール通信ライン２０４を介して外部のメンテナンスツール２０６に接続可能である。メンテナンスツールとしては、メンテナンスプログラムを備える電子端末（ノートパソコン等）であってよい。ＲＯＭ２０２として、内容の書き換えが可能なＥＥＰＲＯＭやフラッシュメモリを利用すればよい。ＲＡＭ２０３に代えて、ＥＥＰＲＯＭやフラッシュメモリを利用してもよい。

ＴＣＵ２４のソフトウェア資源は、ブートローダ２４０と、トランスミッションのギヤ操作の制御プログラム（ＴＣＵソフトウェア）２４２と、メンテナンスツール２０６からＴＣＵ２４へのＴＣＵソフトウェアのインストールの要求を記録するインストール要求フラグ２４４とを備える。ブートローダ２４０とＴＣＵソフトウェア２４２とは、図３のＲＯＭ２０２に記録され、インストール要求フラグ２４４はＲＡＭ２０３に記録されればよい。

ＴＣＵ２４は、イグニッションスイッチ２１０がオン（キーオン）されることで、車両バッテリ（電源）２２０から電力の供給を受け、まずブートローダ２４０を起動する。そしてブートローダ２４０がＴＣＵソフトウェア２４２を起動する。即ちブートローダ２４０は、ＲＯＭ２０２の特定領域を読み、ＴＣＵソフトウェア２４２を確認すると、ＴＣＵソフトウェア２４２を起動する。

ところで、ＴＣＵ２４にＴＣＵソフトウェア２４２をインストールし直すことがある。例えばＴＣＵソフトウェア２４２のバージョンアップ又はＴＣＵ２４が搭載される車両のタイプを変更する場合（例えばトラックからバス、或いは、その反対）である。ＴＣＵ２４にＴＣＵソフトウェア２４２をインストールする場合、メンテナンスツール２０６のメンテナンスプログラムが起動後のＴＣＵソフトウェア２４２にアクセスする。するとＴＣＵソフトウェア２４２は、インストールのための処理をブートローダ２４０に指示し、ブートローダ２４０は、メンテナンスプログラムにＴＣＵソフトウェア２４２の旧バージョンの削除（アンインストール）、そして新しいＴＣＵソフトウェアのアップロードとインストールとを実行させる。

しかしながら、車両の制御プログラムが一旦起動してしまうと、メンテナンスプログラムが制御プログラムにアクセスできても、制御プログラムが車両の制御のための処理を優先し、ブートローダ２４０に制御プログラムをインストールするための処理の権限を渡すことができないことがある。例えば制御プログラムの制御対象としての車両が制御ユニットが実際に搭載されている車種と異なる場合又は制御プログラムの制御パラメータが車両の正常な走行状態にそぐわない場合である。これらの車種及び制御パラメータ等の車種情報は制御プログラムに含まれている。この場合、制御ユニットはメンテナンスツール２０６からのメンテナンス要求（制御プログラムのインストール要求）があっても、制御プログラムの処理のループから抜け出せないことがある。

そこでＴＣＵ２４は、ブートローダ２４０が制御プログラム（ＴＣＵソフトウェア２４２）を起動する前にブートローダ２４０が制御プログラムのインストールするためのアクセスを受け入れるようにした。こうすることによって、ＴＣＵ２４は、制御プログラムが起動される前にメンテナンスの要求（新たな制御プログラムのインストール）が確実に実現されるようにした。

制御プログラムのインストールのために、まず整備士は、メンテナンスツール２０６をダイアグツール通信ライン２０４の特定ポートに接続する。メンテナンスツール２０６がメンテナンスプログラムを実行すると、ＴＣＵ２４にインストール要求を発行してインストール要求フラグ２４４をセットする。ブートローダ２４０は、インストール要求に基づいて、新しいＴＣＵソフトウェアをＴＣＵ２４のＲＯＭの対応領域にインストールする。

図４は、ＴＣＵソフトウェアのインストールの経過を示すブロック図である。符号２４ＢはＴＣＵ２４の記憶領域を示す。（１）に示すように、ＴＣＵ２４のＲＯＭ２０２には、ブートローダ２４０と、ＴＣＵソフトウェア２４２とが記憶されている。ブートローダ２４０が起動されてインストール要求フラグ２４４（図３）を確認すると、メンテナンスツールとしてのノートパソコン４１０のメンテナンスプログラム（インストーラ）は、ＴＣＵ２４のＲＡＭ２０３にフラッシュドライバ４００をアップロード（４０２）する（図４の（２））。

そしてフラッシュドライバ４００は、ＴＣＵソフトウェア２４２にアクセスして（４１２）、ＲＯＭ２０２からＴＣＵソフトウェア２４２を削除する（図４の（３））。なお（３）の符号４５０は、ＲＯＭ２０２の領域のうち、ＴＣＵソフトウェア２４２が削除されることによって解放された領域を示す。

次いで、ノートパソコン４１０が新たなＴＣＵソフトウェア２４２Ａをフラッシュドライバ４００にアップロード（４０４）すると、フラッシュドライバ４００は新たなＴＣＵソフトウェア２４２Ａを開放領域４５０にインストールする（図４の（４））。

次に、ＴＣＵ２４の起動処理の一例を説明する。図５は、ＴＣＵ２４の起動処理の一例を示すフローチャートである。車両のキーオン、即ち図３のイグニッションスイッチ２１０のオンによってＴＣＵ２４がバッテリ２２０に接続されると、ＴＣＵ２４はブートローダ２４０を起動する（ステップ５００）。

次いで、ブートローダ２４０は、ＴＣＵソフトウェア２４２を起動できるか否かを判定する（ステップ５０２）。例えばＴＣＵソフトウェア２４２がＲＯＭ２０２に書き込まれていない場合、ブートローダ２４０は、ＴＣＵソフトウェア２４２を起動できないと判定する。

ブートローダ２４０がＴＣＵソフトウェア２４２を起動できないと判定すると、インストール要求の有無を判定するために（ステップ５１６）インストール要求フラグ２４４をチェックする。ブートローダ２４０は、このフラグがセットされていること（インストール要求有）を確認すると、メンテナンスツール２０６に新ＴＣＵソフトウェア２４２ＡをＴＣＵ２４にインストールさせる（ステップ５１８）。ブートローダ２４０は、新ＴＣＵソフトウェアをインストールさせると、制御プログラムが起動可能かを判定するステップにリターンする（ステップ５０２）。次いでブートローダ２４０は、新ＴＣＵソフトウェアの起動は可能と判定して、後述のように制御プログラムを診断する処理（ステップ５０４）に移行する。

ブートローダ２４０は、インストール要求フラグ２４４がセットされていないこと（インストール要求無）を確認すると、例えば車載ディスプレイ等にエラー表示を出力して（ステップ５２０）、フローチャートを終了する。

ブートローダ２４０が制御プログラムを起動可能であると判定すると（ステップ５０２：ＹＥＳ）、ＴＣＵソフトウェア２４２を診断する。この診断は、所定の基準、例えばＴＣＵソフトウェア２４２が、妥当なものであるか否かの観点から行われてよい（ステップ５０４）。妥当でない制御プログラムが一旦起動されてしまうと、プログラムのループから抜け出せず、メンテナンスツールが制御プログラムのインストールのために制御プログラムにアクセスしようとしても制御プログラムが車両の制御を優先してこのアクセスを受け付けないおそれがある。

ブートローダ２４０は、例えばＴＣＵソフトウェア２４２の識別情報に基づいてＴＣＵソフトウェアが車両にとって正しいものであるか否かの観点からＴＣＵソフトウェアの妥当性をチェックすることができる。具体的には、ＴＣＵソフトウェア２４２の対象としている車種と、ＴＣＵ２４が搭載されている実際の車種とが合っているかどうかである。ブートローダ２４０は、ＴＣＵ２４のＲＯＭ２０２の所定領域から対象車種の情報を読み込み、一方、実際の車種の情報を他の制御ユニット、例えばエンジンコントロールユニットのメモリから読み込んで、両者を比較すればよい。

またブートローダ２４０は、ＴＣＵソフトウェア２４２の通信速度（ダイアグツール通信ライン２０４の通信速度である。）がＥＣＵ（エンジンコントロールユニット）の通信速度に等しいかという観点からＴＣＵソフトウェアの妥当性を判定することもできる。

さらにブートローダ２４０は、制御パラメータが基準値の範囲内であるか否かによってＴＣＵソフトウェアの妥当性を判定することもできる。制御パラメータとしては、例えばセンサ（シフトストロークセンサ、バッテリセンサ）の検出値がある。センサの検出値は、ＴＣＵソフトウェア２４２によって継続的にＲＡＭ２０３に記録されるが、センサの検出値が基準範囲外にあると、制御プログラムの動作が不安定化する。制御パラメータの種類及び基準値は、車両の製造メーカが適宜設定することができる。

ブートローダ２４０が、ＴＣＵソフトウェア２４２が妥当でないと判定すると、車載のディスプレイ又はメンテナンスツール２０６に新たなＴＣＵソフトウェアをインストールすることのリコメンドを送信する（ステップ５０８）。メンテナンスツール２０６が、これによって、インストール要求フラグ２４４をセットするか又は当初からこのフラグがセットされている場合では、ブートローダ２４０は、ステップ５１４に移行する（ステップ５１０：ＹＥＳ）。ブートローダ２４０は、ステップ５１８と同様、新しいＴＣＵソフトウェア２４２Ａをインストールさせる（ステップ５１４）。

ブートローダ２４０が所定期間内にインストール要求フラグ２４４のセットを確認できない場合（ステップ５１０：ＮＯ）、ＴＣＵソフトウェア２４２を起動して（ステップ５１２）、フローチャートを終了する。ブートローダ２４０がステップ５０４においてＴＣＵソフトウェアが妥当であると判定すると、ＴＣＵソフトウェア２４２を起動して（ステップ５０６）、フローチャートを終了する。

ＴＣＵソフトウェアがそもそも妥当なものである場合、ＴＣＵソフトウェアの起動後でも、メンテナンスツール２０６はＴＣＵソフトウェアを介してブートローダ２４０にＴＣＵソフトウェアのインストールをリクエストすることができる。ブートローダ２４０は、このリクエストに基づいて新たなＴＣＵソフトウェアをインストールすることができる。一方、ＴＣＵソフトウェアが妥当でない場合には、ステップ５０８及び５１０によって、ＴＣＵソフトウェアが起動される前にＴＣＵソフトウェアのインストールのリクエストがブートローダ２４０に受け入れられ、ＴＣＵソフトウェアのインストールが行われる。

妥当でないと判定されたＴＣＵソフトウェアが起動されても、キーオフ後のキーオンによって、ブートローダ２４０が改めて起動されるタイミングでブートローダによってＴＣＵソフトウェアのインストールが可能になる。なおステップ５０８は、インストール要求フラグ２４４がセットされていない場合に実行されるようにしてもよい。

ＴＣＵ２４の起動処理の他の実施形態を説明する。図６は、そのフローチャートである。図６のフローチャートが図５のフローチャートと異なる点は、ＴＣＵソフトウェア２４２の妥当性を判定するステップを省き、ステップ５０２の後直ちにインストール要求の有無を判定している点である。ブートローダ２４０は、インストール要求の有りを判定するとインストールを実行し（ステップ５３２）、インストール要求の無を判定すると、ＴＣＵソフトウェア２４２を起動する。この場合、ＴＣＵソフトウェア２４２の診断が行われないことによって、ＴＣＵソフトウェアが妥当でないことが通知されることなく、ＴＣＵソフトウェアがそのまま起動されてしまうが、キーオフ後のキーオンによって、ブートローダ２４０が改めて起動されるタイミングで新たなＴＣＵソフトウェアのインストールを可能にする機会が確保される。

図７は、ＴＣＵ２４の起動処理のさらに他の例を示すフローチャートである。図７のフローチャートは、図５のフローチャートと図６のフローチャートとを合わせたものとして構成されている。即ちＴＣＵソフトウェア２４２の妥当性を判定するステップの前にインストール要求の有無を判定している点である。こうすることによって、ブートローダ２４０は、インストールの要求が無い場合（ステップ５２０：ＮＯ）にだけＴＣＵソフトウェアの妥当性をチェックすればよい。

既述の実施形態は、制御対象を変速装置として説明したが、これに限らず制御対象をエンジン、懸架装置又は操舵システム等としてもよい。

２２ 制御対象（変速装置：ＡＭＴ）、２４ 制御ユニット（ＴＣＵ）、２４０ ブートローダ、２４２ 制御プログラム（ＴＣＵソフトウェア）

Claims (7)

1. 制御ユニット（２４）を備える車両の制御システム（１００）であって、
   前記制御ユニット（２４）は、
   制御プログラム（２４２）を起動する前に当該制御プログラム（２４２）をインストールするためのアクセスを受け入れる
   車両の制御システム。
2. 前記制御ユニット（２４）のソフトウェアモジュールは、
   ブートローダ（２４０）と、前記制御プログラム（２４２）とを備え、
   前記制御プログラム（２４２）は、
   前記ブートローダ（２４０）によって起動され、
   前記ブートローダ（２４０）は、
   前記制御プログラム（２４２）を起動する前に前記アクセスを受け入れる
   請求項１に記載の車両の制御システム。
3. 前記制御ユニット（２４）の制御対象（２２）は自動変速装置であり、
   前記制御ユニット（２４）は、前記自動変速装置を制御する
   請求項１又は２に記載の車両の制御システム。
4. 前記ブートローダ（２４０）は、
   前記制御プログラム（２４２）を起動する前に当該制御プログラム（２４２）を診断し、
   診断結果に基づいて、前記アクセスの有無を判定する
   請求項２又は３に記載の車両の制御システム。
5. 前記ブートローダ（２４０）は、
   前記制御プログラム（２４２）を起動する前に前記アクセスの有無をチェックする
   請求項１〜３の何れか１項に記載の車両の制御システム。
6. 前記ブートローダ（２４０）は、
   前記制御プログラム（２４２）に含まれる車種情報に基づいて、当該制御プログラム（２４２）を診断する
   請求項４に記載の車両の制御システム。
7. 制御ユニット（２４）が制御対象（２２）を制御する車両の制御方法であって、
   キーオンによってブートローダ（２４０）を起動する第１のステップと、
   前記ブートローダ（２４０）が制御プログラム（２４２）を起動する第２のステップとを備え、
   前記第２のステップにおいて、
   前記制御プログラム（２４２）を起動する前に当該制御プログラム（２４２）をインストールするためのアクセスを受け入れる
   車両の制御方法。

Images