(57)【特許請求の範囲】
【請求項１】
制御ユニット（２４）を備える車両の制御システム（１００）であって、
前記制御ユニット（２４）のソフトウェアモジュールは、
ブートローダ（２４０）と、制御プログラム（２４２）とを備え、
前記制御プログラム（２４２）は、
前記ブートローダ（２４０）によって起動され、
前記ブートローダ（２４０）は、
前記制御プログラム（２４２）を起動する前に当該制御プログラム（２４２）をインストールするためのアクセスを受け入れ可能であり、
前記ブートローダ（２４０）は、
前記制御プログラム（２４２）を起動する前に当該制御プログラム（２４２）に含まれる車両情報に基づいて当該制御プログラム（２４２）の妥当性を診断し、妥当と判定された場合は当該制御プログラム（２４２）を起動し、妥当でないと判定された場合には、新たな制御プログラム（２４２）をインストールすることのリコメンドを送信する
車両の制御システム。
【請求項２】
前記制御ユニット（２４）の制御対象（２２）は自動変速装置であり、
前記制御ユニット（２４）は、前記自動変速装置を制御する
請求項１に記載の車両の制御システム。
【請求項３】
制御ユニット（２４）が制御対象（２２）を制御する車両の制御方法であって、
キーオンによってブートローダ（２４０）を起動する第１のステップと、
前記ブートローダ（２４０）が制御プログラム（２４２）を起動する第２のステップと
を備え、
前記第２のステップにおいて、
前記制御プログラム（２４２）を起動する前に当該制御プログラム（２４２）をインストールするためのアクセスを受け入れ可能であり、
前記ブートローダ（２４０）は、
前記制御プログラム（２４２）を起動する前に当該制御プログラム（２４２）に含まれる車両情報に基づいて当該制御プログラム（２４２）の妥当性を診断し、妥当と判定された場合は当該制御プログラム（２４２）を起動し、妥当でないと判定された場合には、新たな制御プログラム（２４２）をインストールすることのリコメンドを送信する
車両の制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は車両の制御システム及び制御方法に関し、特に自動車の変速装置を制御する制御システム及び制御方法に関する。
【背景技術】
【０００２】
従来、ＡＭＴ（オートメーテッド・マニュアル・トランスミッション）と称される変速装置が知られている（例えば、特許文献１）。ＡＭＴは、トランスミッションがマニュアル機構として構成されていながら、クラッチ操作とギヤ位置の切り替えを自動化することによって、ドライバによるクラッチ操作やシフトチェンジの操作を要せずに車両を走行させることができる装置である。
【０００３】
自動車のＡＭＴを制御するシステムは、トランスミッション・コントロールユニット（ＴＣＵ）と呼ばれる制御ユニットを備える。ＴＣＵのソフトウェアモジュールは、少なくともＡＭＴを制御する制御プログラム及びこの制御プログラムを起動するブートローダを備える。ＴＣＵは、キーオンされるとブートローダを起動し、起動されたブートローダがＡＭＴの制御プログラムを起動する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１３―１６９８８３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところで、車両の制御システムに制御プログラムを再インストールする必要が生じる場合がある。例えば制御プログラムをバージョンアップする場合、或いは、制御システムが搭載される車両のタイプを変更する場合に制御プログラムを再インストールする必要が生じる。
【０００６】
車両の制御プログラムを再インストールする場合には通常、メンテナンスツールを用いて起動中の制御プログラムにアクセスする。このとき制御プログラムは、再インストールのための処理をブートローダに指示する。ブートローダは、メンテナンスツールに既存の制御プログラムを削除し、新しい制御プログラムをアップロードしてインストールする。
【０００７】
しかし制御プログラムが起動されている状態でメンテナンスツールを用いて制御プログラムにアクセスしても、制御プログラムは車両の制御のための処理を優先して継続する。この場合、制御プログラムは制御プログラムの再インストールをブートローダに指示することはない。よって車両の制御ユニットに制御プログラムを再インストールすることができないという課題がある。
【０００８】
本発明は、車両の制御システムに制御プログラムのインストールを確実に実行させることを目的とする。
【課題を解決するための手段】
【０００９】
そこで本発明は、上記の目的を達成するために、制御対象と、制御対象の制御ユニットとを備える車両の制御システムであって、制御ユニットは、制御プログラムを起動する前に制御プログラムをインストールするためのアクセスを受け入れるようにしたことを特徴とする。
【００１０】
さらに本発明は、制御対象を制御ユニットが制御する車両の制御方法であって、制御ユニットは、制御プログラムを起動する前に制御プログラムをインストールするためのアクセスを受け入れるようにしたことを特徴とする。
【発明の効果】
【００１１】
本発明によれば、車両の制御システムに制御プログラムのインストールを確実に実行させることができる。
【図面の簡単な説明】
【００１２】
【図１】車両のハードウェアブロック図である。
【図２】変速制御システムの機能ブロック図である。
【図３】ＴＣＵのハードウェアブロック図である。
【図４】インストール処理の経過を示すブロック図である。
【図５】ＴＣＵの起動処理の一例を示すフローチャートである。
【図６】ＴＣＵの起動処理の他の例を示すフローチャートである。
【図７】ＴＣＵの起動処理のさらに他の例を示すフローチャートである。
【発明を実施するための形態】
【００１３】
次に、本発明の実施の形態を、図面を参照して説明する。なお以下の説明は、本発明を限定するものではなく、本発明の範囲内で適宜変更することができる。
【００１４】
図１は、制御システムの一例としての変速制御システムを備える車両のハードウェアブロック図である。変速制御システムは、トランスミッション（制御対象）２２と、ＴＣＵ（制御ユニット）２４とを備える。車両１０は、エンジン１２と、インプットシャフト１４と、インプットシャフト１４とエンジン１２とを断続するクラッチ１６と、アウトプットシャフト２０とを備える。トランスミッション２２は、インプットシャフト１４とアウトプットシャフト２０とを複数のギヤを切り替えて接続する。ＴＣＵ２４は、トランスミッション２２の変速を制御する。エンジン１２側のシステムは、インプットシャフト１４に接続するハイブリッドモータ１８と、モータ制御ユニット２６とを有する。
【００１５】
トランスミッション２２はＡＭＴとして構成され、動力機構（エンジン・モータ）の駆動力をインプットシャフト１４から、複数のギヤの切り替えによって駆動輪２８側のアウトプットシャフト２０に伝達する。
【００１６】
次に、変速制御システムの詳細を図２（変速制御システム１００の機能ブロック図）に基づいて説明する。変速制御システム１００は、制御ユニットとしてのＴＣＵ２４並びにＴＣＵ２４に接続されたチェンジレバーシフト位置検出センサ５０と車両走行状態検出センサ５２とを備える。変速制御システム１００は、さらに自動変速装置２２Ａを備え、自動変速装置２２Ａは、変速を行うトランスミッション２２と、このトランスミッション２２の変速シフトを制御するためにトランスミッション２２のギヤ入れ及びギヤ抜きを行う、例えば電動モータ等のシフトアクチュエータ５６と備える。
【００１７】
チェンジレバーシフト位置検出センサ５０は、チェンジレバーのシフト位置を検出してレバーシフト位置信号を出力する。車両走行状態検出センサ５２は、車両速度及びエンジン負荷等、車両の走行時における車両走行状態情報を検出して車両走行状態信号を出力する。
【００１８】
ＴＣＵ２４は、シフト信号生成モジュール５７、ギヤシフト制御モジュール５８及びトランスミッションインプット側回転数（回転速度）出力モジュール５９を有する。シフト信号生成モジュール５７は、チェンジレバーシフト位置検出センサ５０からのレバーシフト位置信号に基づいてチェンジレバーのシフト位置を判定してシフト位置信号を出力すると共に、車両走行状態検出センサ５２からの車両走行状態信号に基づいて、車両速度やエンジン負荷等の車両走行時における車両走行状態情報を判定して車両走行状態信号を出力する。
【００１９】
トランスミッションインプット側回転数出力モジュール５９は、トランスミッションのインプット側回転数のトランスミッションインプット側回転数信号をギヤシフト制御モジュール５８に出力する。トランスミッションインプット側回転数出力モジュール５９としては、例えばトランスミッションのインプットシャフト回転数のインプットシャフト回転数信号を出力するインプットシャフト回転数出力モジュール又はクラッチの従動側（出力側）の回転数である、クラッチ回転数信号を出力するクラッチ回転数出力モジュールが用いられる。
【００２０】
ギヤシフト制御モジュール５８は、シフト信号生成モジュール５７からのシフト位置信号、車両走行状態信号、シフトアクチュエータ５６からのシフトストローク位置信号、及び、トランスミッションインプット側回転数出力モジュール５９からのトランスミッションインプット側回転数信号に基づいてシフトアクチュエータ５６の作動制御条件を設定し、設定した作動制御条件に基づいたシフトアクチュエータ作動制御信号をシフトアクチュエータ５６に出力する。
【００２１】
シフトアクチュエータ５６はシフトアクチュエータ作動制御信号に基づいてシフトアームを介してトランスミッション２２の対応するギヤシフトスリーブを作動させて、ギヤ入れ、又は、ギヤ抜きを行うことで、トランスミッション２２をシフト信号生成モジュール５７からのシフト位置判定信号に基づいたギヤ位置に設定する。その場合、ギヤ位置設定（シフトストローク位置設定）のフィードバック信号がシフトアクチュエータ５６からギヤシフト制御モジュール５８へ出力される。
【００２２】
なお図２において「モジュール」とは、ＴＣＵ２４のソフトウェア資源及び/又はハードウェア資源によって実現される。
【００２３】
さらにＴＣＵ２４の詳細について説明する。図３にＴＣＵ２４のハードウェアブロックを示す。ＴＣＵ２４はマイクロコンピュータとして構成され、コントローラ（ＣＰＵ）２００を中心に、ＲＯＭ２０２、ＲＡＭ（メインメモリ）２０３を有すると共に、車両内部に敷設されたＣＡＮやＫ−lineなどのダイアグツール通信ライン２０４を介して外部のメンテナンスツール２０６に接続可能である。メンテナンスツールとしては、メンテナンスプログラムを備える電子端末（ノートパソコン等）であってよい。ＲＯＭ２０２として、内容の書き換えが可能なＥＥＰＲＯＭやフラッシュメモリを利用すればよい。ＲＡＭ２０３に代えて、ＥＥＰＲＯＭやフラッシュメモリを利用してもよい。
【００２４】
ＴＣＵ２４のソフトウェア資源は、ブートローダ２４０と、トランスミッションのギヤ操作の制御プログラム（ＴＣＵソフトウェア）２４２と、メンテナンスツール２０６からＴＣＵ２４へのＴＣＵソフトウェアのインストールの要求を記録するインストール要求フラグ２４４とを備える。ブートローダ２４０とＴＣＵソフトウェア２４２とは、図３のＲＯＭ２０２に記録され、インストール要求フラグ２４４はＲＡＭ２０３に記録されればよい。
【００２５】
ＴＣＵ２４は、イグニッションスイッチ２１０がオン（キーオン）されることで、車両バッテリ（電源）２２０から電力の供給を受け、まずブートローダ２４０を起動する。そしてブートローダ２４０がＴＣＵソフトウェア２４２を起動する。即ちブートローダ２４０は、ＲＯＭ２０２の特定領域を読み、ＴＣＵソフトウェア２４２を確認すると、ＴＣＵソフトウェア２４２を起動する。
【００２６】
ところで、ＴＣＵ２４にＴＣＵソフトウェア２４２をインストールし直すことがある。例えばＴＣＵソフトウェア２４２のバージョンアップ又はＴＣＵ２４が搭載される車両のタイプを変更する場合（例えばトラックからバス、或いは、その反対）である。ＴＣＵ２４にＴＣＵソフトウェア２４２をインストールする場合、メンテナンスツール２０６のメンテナンスプログラムが起動後のＴＣＵソフトウェア２４２にアクセスする。するとＴＣＵソフトウェア２４２は、インストールのための処理をブートローダ２４０に指示し、ブートローダ２４０は、メンテナンスプログラムにＴＣＵソフトウェア２４２の旧バージョンの削除（アンインストール）、そして新しいＴＣＵソフトウェアのアップロードとインストールとを実行させる。
【００２７】
しかしながら、車両の制御プログラムが一旦起動してしまうと、メンテナンスプログラムが制御プログラムにアクセスできても、制御プログラムが車両の制御のための処理を優先し、ブートローダ２４０に制御プログラムをインストールするための処理の権限を渡すことができないことがある。例えば制御プログラムの制御対象としての車両が制御ユニットが実際に搭載されている車種と異なる場合又は制御プログラムの制御パラメータが車両の正常な走行状態にそぐわない場合である。これらの車種及び制御パラメータ等の車種情報は制御プログラムに含まれている。この場合、制御ユニットはメンテナンスツール２０６からのメンテナンス要求（制御プログラムのインストール要求）があっても、制御プログラムの処理のループから抜け出せないことがある。
【００２８】
そこでＴＣＵ２４は、ブートローダ２４０が制御プログラム（ＴＣＵソフトウェア２４２）を起動する前にブートローダ２４０が制御プログラムのインストールするためのアクセスを受け入れるようにした。こうすることによって、ＴＣＵ２４は、制御プログラムが起動される前にメンテナンスの要求（新たな制御プログラムのインストール）が確実に実現されるようにした。
【００２９】
制御プログラムのインストールのために、まず整備士は、メンテナンスツール２０６をダイアグツール通信ライン２０４の特定ポートに接続する。メンテナンスツール２０６がメンテナンスプログラムを実行すると、ＴＣＵ２４にインストール要求を発行してインストール要求フラグ２４４をセットする。ブートローダ２４０は、インストール要求に基づいて、新しいＴＣＵソフトウェアをＴＣＵ２４のＲＯＭの対応領域にインストールする。
【００３０】
図４は、ＴＣＵソフトウェアのインストールの経過を示すブロック図である。符号２４ＢはＴＣＵ２４の記憶領域を示す。（１）に示すように、ＴＣＵ２４のＲＯＭ２０２には、ブートローダ２４０と、ＴＣＵソフトウェア２４２とが記憶されている。ブートローダ２４０が起動されてインストール要求フラグ２４４（図３）を確認すると、メンテナンスツールとしてのノートパソコン４１０のメンテナンスプログラム（インストーラ）は、ＴＣＵ２４のＲＡＭ２０３にフラッシュドライバ４００をアップロード（４０２）する（図４の（２））。
【００３１】
そしてフラッシュドライバ４００は、ＴＣＵソフトウェア２４２にアクセスして（４１２）、ＲＯＭ２０２からＴＣＵソフトウェア２４２を削除する（図４の（３））。なお（３）の符号４５０は、ＲＯＭ２０２の領域のうち、ＴＣＵソフトウェア２４２が削除されることによって解放された領域を示す。
【００３２】
次いで、ノートパソコン４１０が新たなＴＣＵソフトウェア２４２Ａをフラッシュドライバ４００にアップロード（４０４）すると、フラッシュドライバ４００は新たなＴＣＵソフトウェア２４２Ａを開放領域４５０にインストールする（図４の（４））。
【００３３】
次に、ＴＣＵ２４の起動処理の一例を説明する。図５は、ＴＣＵ２４の起動処理の一例を示すフローチャートである。車両のキーオン、即ち図３のイグニッションスイッチ２１０のオンによってＴＣＵ２４がバッテリ２２０に接続されると、ＴＣＵ２４はブートローダ２４０を起動する（ステップ５００）。
【００３４】
次いで、ブートローダ２４０は、ＴＣＵソフトウェア２４２を起動できるか否かを判定する（ステップ５０２）。例えばＴＣＵソフトウェア２４２がＲＯＭ２０２に書き込まれていない場合、ブートローダ２４０は、ＴＣＵソフトウェア２４２を起動できないと判定する。
【００３５】
ブートローダ２４０がＴＣＵソフトウェア２４２を起動できないと判定すると、インストール要求の有無を判定するために（ステップ５１６）インストール要求フラグ２４４をチェックする。ブートローダ２４０は、このフラグがセットされていること（インストール要求有）を確認すると、メンテナンスツール２０６に新ＴＣＵソフトウェア２４２ＡをＴＣＵ２４にインストールさせる（ステップ５１８）。ブートローダ２４０は、新ＴＣＵソフトウェアをインストールさせると、制御プログラムが起動可能かを判定するステップにリターンする（ステップ５０２）。次いでブートローダ２４０は、新ＴＣＵソフトウェアの起動は可能と判定して、後述のように制御プログラムを診断する処理（ステップ５０４）に移行する。
【００３６】
ブートローダ２４０は、インストール要求フラグ２４４がセットされていないこと（インストール要求無）を確認すると、例えば車載ディスプレイ等にエラー表示を出力して（ステップ５２０）、フローチャートを終了する。
【００３７】
ブートローダ２４０が制御プログラムを起動可能であると判定すると（ステップ５０２：ＹＥＳ）、ＴＣＵソフトウェア２４２を診断する。この診断は、所定の基準、例えばＴＣＵソフトウェア２４２が、妥当なものであるか否かの観点から行われてよい（ステップ５０４）。妥当でない制御プログラムが一旦起動されてしまうと、プログラムのループから抜け出せず、メンテナンスツールが制御プログラムのインストールのために制御プログラムにアクセスしようとしても制御プログラムが車両の制御を優先してこのアクセスを受け付けないおそれがある。
【００３８】
ブートローダ２４０は、例えばＴＣＵソフトウェア２４２の識別情報に基づいてＴＣＵソフトウェアが車両にとって正しいものであるか否かの観点からＴＣＵソフトウェアの妥当性をチェックすることができる。具体的には、ＴＣＵソフトウェア２４２の対象としている車種と、ＴＣＵ２４が搭載されている実際の車種とが合っているかどうかである。ブートローダ２４０は、ＴＣＵ２４のＲＯＭ２０２の所定領域から対象車種の情報を読み込み、一方、実際の車種の情報を他の制御ユニット、例えばエンジンコントロールユニットのメモリから読み込んで、両者を比較すればよい。
【００３９】
またブートローダ２４０は、ＴＣＵソフトウェア２４２の通信速度（ダイアグツール通信ライン２０４の通信速度である。）がＥＣＵ（エンジンコントロールユニット）の通信速度に等しいかという観点からＴＣＵソフトウェアの妥当性を判定することもできる。
【００４０】
さらにブートローダ２４０は、制御パラメータが基準値の範囲内であるか否かによってＴＣＵソフトウェアの妥当性を判定することもできる。制御パラメータとしては、例えばセンサ（シフトストロークセンサ、バッテリセンサ）の検出値がある。センサの検出値は、ＴＣＵソフトウェア２４２によって継続的にＲＡＭ２０３に記録されるが、センサの検出値が基準範囲外にあると、制御プログラムの動作が不安定化する。制御パラメータの種類及び基準値は、車両の製造メーカが適宜設定することができる。
【００４１】
ブートローダ２４０が、ＴＣＵソフトウェア２４２が妥当でないと判定すると、車載のディスプレイ又はメンテナンスツール２０６に新たなＴＣＵソフトウェアをインストールすることのリコメンドを送信する（ステップ５０８）。メンテナンスツール２０６が、これによって、インストール要求フラグ２４４をセットするか又は当初からこのフラグがセットされている場合では、ブートローダ２４０は、ステップ５１４に移行する（ステップ５１０：ＹＥＳ）。ブートローダ２４０は、ステップ５１８と同様、新しいＴＣＵソフトウェア２４２Ａをインストールさせる（ステップ５１４）。
【００４２】
ブートローダ２４０が所定期間内にインストール要求フラグ２４４のセットを確認できない場合（ステップ５１０：ＮＯ）、ＴＣＵソフトウェア２４２を起動して（ステップ５１２）、フローチャートを終了する。ブートローダ２４０がステップ５０４においてＴＣＵソフトウェアが妥当であると判定すると、ＴＣＵソフトウェア２４２を起動して（ステップ５０６）、フローチャートを終了する。
【００４３】
ＴＣＵソフトウェアがそもそも妥当なものである場合、ＴＣＵソフトウェアの起動後でも、メンテナンスツール２０６はＴＣＵソフトウェアを介してブートローダ２４０にＴＣＵソフトウェアのインストールをリクエストすることができる。ブートローダ２４０は、このリクエストに基づいて新たなＴＣＵソフトウェアをインストールすることができる。一方、ＴＣＵソフトウェアが妥当でない場合には、ステップ５０８及び５１０によって、ＴＣＵソフトウェアが起動される前にＴＣＵソフトウェアのインストールのリクエストがブートローダ２４０に受け入れられ、ＴＣＵソフトウェアのインストールが行われる。
【００４４】
妥当でないと判定されたＴＣＵソフトウェアが起動されても、キーオフ後のキーオンによって、ブートローダ２４０が改めて起動されるタイミングでブートローダによってＴＣＵソフトウェアのインストールが可能になる。なおステップ５０８は、インストール要求フラグ２４４がセットされていない場合に実行されるようにしてもよい。
【００４５】
ＴＣＵ２４の起動処理の他の実施形態を説明する。図６は、そのフローチャートである。図６のフローチャートが図５のフローチャートと異なる点は、ＴＣＵソフトウェア２４２の妥当性を判定するステップを省き、ステップ５０２の後直ちにインストール要求の有無を判定している点である。ブートローダ２４０は、インストール要求の有りを判定するとインストールを実行し（ステップ５３２）、インストール要求の無を判定すると、ＴＣＵソフトウェア２４２を起動する。この場合、ＴＣＵソフトウェア２４２の診断が行われないことによって、ＴＣＵソフトウェアが妥当でないことが通知されることなく、ＴＣＵソフトウェアがそのまま起動されてしまうが、キーオフ後のキーオンによって、ブートローダ２４０が改めて起動されるタイミングで新たなＴＣＵソフトウェアのインストールを可能にする機会が確保される。
【００４６】
図７は、ＴＣＵ２４の起動処理のさらに他の例を示すフローチャートである。図７のフローチャートは、図５のフローチャートと図６のフローチャートとを合わせたものとして構成されている。即ちＴＣＵソフトウェア２４２の妥当性を判定するステップの前にインストール要求の有無を判定している点である。こうすることによって、ブートローダ２４０は、インストールの要求が無い場合（ステップ５２０：ＮＯ）にだけＴＣＵソフトウェアの妥当性をチェックすればよい。
【００４７】
既述の実施形態は、制御対象を変速装置として説明したが、これに限らず制御対象をエンジン、懸架装置又は操舵システム等としてもよい。
【符号の説明】
【００４８】
２２  制御対象（変速装置：ＡＭＴ）、２４  制御ユニット（ＴＣＵ）、２４０  ブートローダ、２４２  制御プログラム（ＴＣＵソフトウェア）
【図１】
0006663777.tif 000002
【図２】
0006663777.tif 000003
【図３】
0006663777.tif 000004
【図４】
0006663777.tif 000005
【図５】
0006663777.tif 000006
【図６】
0006663777.tif 000007
【図７】
0006663777.tif 000008