JP6500672B2 - 制御システム - Google Patents

Description

本発明は、複数の異なる制御目的で使用される少なくとも１つの装備を有する車載装置のための制御システムに関する。

例えば、特許文献１には、車両の運転モード状態を制御する車両制御装置について開示されている。この車両制御装置は、運転モード管理部と、その運転モード管理部から出力される制御指令信号に含まれる運転モードにて、アクチュエータを駆動制御する制御部とを備えている。制御部は、アクチュエータが指示された運転モードで作動することができない場合、他の運転モードでアクチュエータを作動させる。

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

上述した特許文献１の車両制御装置は、車両の運転モードを、スノーモード、スポーツモード、エコモード等に切り換え可能として、車両の運動特性を、雪道での走行に適するようにしたり、スポーティにしたり、あるいは、燃費の向上を優先したりできるようにしたものである。ただし、上記車両制御装置では、車両の運転モードの切り換えに係わらず、同じ制御部が、常に同じ装備（エンジン、ブレーキなど）を制御するように構成されている。換言すれば、制御目的の変更に応じて、所定の装備を制御する制御部を変更することはなんら考慮されていない。

本発明は、上記の点に鑑みてなされたものであり、複数の異なる制御目的で使用される少なくとも１つの装備を有する車載装置のための新規かつ有用な制御システムを提供することを目的とする。

上記目的を達成するために、本発明に係る制御システムは、以下の構成を採用する。すなわち、制御システム（１０）は、複数の異なる制御目的で使用される少なくとも１つの装備（３２、５０、８０）を有する車載装置（３０〜３６）のためのものであって、予め複数の論理ブロック（１２〜２６）に区分けされ、それら複数の論理ブロック間の連結関係を規定することによって構成されており、複数の論理ブロックが論理ブロック間の連結関係に従って連携して動作することにより、車載装置を制御するものであり、
複数の論理ブロックは、それぞれ、少なくとも１つの制御ブロックを有し、
制御目的に応じて、装備に対する制御責任を負う管理主体となる制御ブロックが管理制御ブロックとして予め定められており、
制御目的の変更の有無を判定する変更判定手段（Ｓ１００）と、
変更判定手段によって制御目的が変更されたと判定されたことに応じて、予め定められた制御目的と管理制御ブロックとの対応関係に基づき、管理制御ブロックを変更する管理制御ブロック変更手段（Ｓ１５０）と、を備え、
装備は、車載機器を動作させるためのアクチュエータを含み、
アクチュエータに対する制御責任を負う前記管理制御ブロックは、アクチュエータの制御目標値を定めるとともに、その制御目標値に応じた制御信号を、別の制御ブロックを介することなく、直接、アクチュエータに与えるものである。

上述したように、制御目的が変更された場合には、装備に対する制御責任を負う管理制御ブロックが、変更後の制御目的に対応する管理制御ブロックに変更される。これにより、装備に関して、より適切な制御処理を実行することが可能となる。

例えば、車両の駆動源として、エンジンとモータジェネレータとを備えるいわゆるハイブリッド車両において、同じ冷却液がエンジンとモータジェネレータのインバータとに循環するようにして、エンジンの冷却系と、モータジェネレータのインバータの冷却系とを共通化することが考えられる。この場合、それぞれの温度調節（冷却等）の必要性に応じて、ポンプ及び流路切換弁などを用いて、冷却液がいずれも循環しない状態、冷却液がエンジンだけを循環する状態、冷却液がインバータだけを循環する状態、及び冷却液がエンジン及びインバータを循環する状態のいずれかに切り換え可能に構成される。

そして、エンジンの温度調節だけが必要である場合には、エンジンの運転状態を制御するエンジン制御論理ブロックに含まれる制御ブロックが、装備としてのポンプ及び流路切替弁を制御するようにする。このようにすれば、エンジンの発熱温度が適切となるように、温度調節制御を行うことができる。一方、インバータの温度調節だけが必要である場合には、インバータの動作状態を制御するモータジェネレータ制御論理ブロックに含まれる制御ブロックが、ポンプ及び流路切換弁を制御するようにする。これにより、モータジェネレータの駆動電流を調節するために動作するインバータの温度調節を適切に行うことが可能となる。さらに、エンジン及びインバータの双方の温度調節が必要である場合には、例えば、エンジン制御論理ブロック及びモータジェネレータ制御論理ブロックに対して、発生トルクを指示するパワートレイン制御論理ブロックに含まれる制御ブロックが、ポンプ及び流路切換弁を制御するようにする。この場合、エンジンの運転状態とインバータの動作状態を共に把握しているのは、パワートレイン制御論理ブロックであるためである。

上述した、管理制御ブロックは、装備の異常判定及び異常発生時のフェールセーフ処理の実行も担うものであることが好ましい。これにより、装備に対する制御責任を負う管理制御ブロックが変更された場合であっても、装備に対する安全管理責任の所在が不明確となることを防止することができる。

上記括弧内の参照番号は、本発明の理解を容易にすべく、後述する実施形態における具体的な構成との対応関係の一例を示すものにすぎず、なんら本発明の範囲を制限することを意図したものではない。

また、上述した特徴以外の、特許請求の範囲の各請求項に記載した技術的特徴に関しては、後述する実施形態の説明及び添付図面から明らかになる。

ハイブリッド車両における車載装置を制御対象とした場合において、制御システムが有する各種機能の一例を機能ブロックにより示した図である。 複数の異なる制御目的で使用される装備に関して、その装備に対する制御責任を負う管理制御ブロックが、制御目的の変更に応じて、変更される第１のケースについて説明するための説明図である。 １つの論理ブロックであるＥＭＳ内の制御ブロックから、他の論理ブロックであるＰＴＣ内の制御ブロックへと、管理制御ブロックとしての役割が移行される具体的な例を示した図である。 管理制御ブロックが、制御目的の変更に応じて、変更される第２のケースについて説明するための説明図である。 管理制御ブロックが、制御目的の変更に応じて、変更される第３のケースについて説明するための説明図である。 管理制御ブロックが、制御目的の変更に応じて、変更される第４のケースについて説明するための説明図である。 管理制御ブロックの変更処理のメインルーチンを示すフローチャートである。 管理制御ブロックの変更処理における、ルート選定処理を示すフローチャートである。 管理制御ブロックの変更処理における、移行判定処理を示すフローチャートである。 管理制御ブロックの機能を分割して、それぞれ異なる制御ブロックに割り当てた事例を説明するための説明図である。

以下、本発明に係る制御システムの実施形態を、図面を参照しつつ説明する。以下に説明する実施形態では、車両の走行駆動源として、エンジンと電動モータとを有するハイブリッド車両に搭載される各種の車載機器に対して、本発明による制御システムを適用した例について説明する。しかしながら、本発明による制御システムは、ハイブリッド車両における車載機器の制御に適用されるばかりでなく、エンジンのみを有する通常の車両や、電動モータのみを有する電動車両の各種の車載機器の制御に適用されても良い。

図１は、上述したハイブリッド車両における車載装置の制御システム１０が有する各種機能の一例を機能ブロック図として表したものである。ただし、図１に示す例では、制御システムが有する機能の全てが示されている訳ではない。これは、説明の便宜のため、図１には、本実施形態に係る制御システム１０の特徴を説明するために必要な構成の一例しか示していないためである。

具体的には、図１には、制御システムが、車載機器としてのエンジン３０、ＩＳＧ（Integrated Starter Generator）３２、高圧バッテリ３４、及びヒートポンプ３６を制御するための機能ブロックしか示していない。しかしながら、制御システム１０は、その他にも、変速機、ブレーキ装置、ステアリング装置など、車両の走行に影響を与える全ての車載装置を制御するものであっても良い。

図１に示すように、制御システム１０は、予め複数の論理ブロック（機能ブロック）１２〜２６に区分けされ、それら複数の論理ブロック１２〜２６間の連結関係を規定することによって構成されている。すなわち、制御システム１０における各種の車載機器を制御するための論理構造が、論理ブロック１２〜２６と、論理ブロック１２〜２６間の連結関係によって規定されている。そして、制御システム１０は、複数の論理ブロック１２〜２６が、規定された連結関係に従って連携して動作することにより、各種の車載装置を制御する。

なお、図１には示していないが、各論理ブロック１２〜２６は、少なくとも１つ、通常は多数の制御ブロックを有している。各論理ブロック１２〜２６は、それら多数の制御ブロックにおける演算処理を適宜組み合わせることにより、それぞれの機能（役割）を発揮する。

例えば、論理ブロックとしてのエンジンマネジメントシステム（ＥＭＳ）２２は、エンジンの運転状態を検出すべく、各種のセンサからのセンサ信号を入力して、論理ブロック内で取り扱うことができる信号に変換する制御ブロックを有する。また、センサ信号から把握されるエンジンの運転状態から現状の発生トルクを算出するとともに、上位の論理ブロック（ＰＴＣ１４）から指示された指令トルクと差異がある場合に、その差異をなくすための目標とするエンジン運転状態を算出する制御ブロックを有する。さらに、目標エンジン運転状態を達成するための燃料噴射量と燃料噴射時期、及び点火時期を算出する制御ブロックを有する。その他にも、エンジンの発熱温度に応じて、エンジンの温度調節を実行する制御ブロックも有する。ただし、これらは単なる例示であって、ＥＭＳ２２は、その機能を発揮するために必要な、その他の演算処理を行う制御ブロックを有する場合もあり得る。また、例示された制御ブロックを含め、ＥＭＳ２２内の制御ブロックは、適宜、統合されたり、逆に、細分化されたりすることが可能なものである。

制御システム１０は、実際には、各論理ブロック１２〜２６を、プログラムやデータベースとして、電子制御装置（ＥＣＵ）に実装することにより具現化される。この際、論理ブロック間の連結関係が維持できる限り、各論理ブロック１２〜２６を実装する電子制御装置の数は任意である。例えば、すべての論理ブロック１２〜２６を１つの電子制御装置に実装しても良いし、各論理ブロック１２〜２６を、それぞれ別個の電子制御装置に実装しても良い。各論理ブロック１２〜２６を複数の電子制御装置に実装される場合には、それら複数の電子制御装置は、論理ブロックの連結関係を維持できるように、個別の通信線を介して接続されたり、各電子制御装置が共通のネットワークに接続され、連結関係に従う所望の電子制御装置同士が通信可能に構成されたりする。

次に、図１に論理ブロック１２〜２６として示した、制御システム１０が有する各種の機能について説明する。

図１に示すように、制御システム１０には、各種の情報が入力される。例えば、ヒューマン・マシン・インターフェース（ＨＭＩ）２は、ハイブリッド車両の運転のため、運転者によって操作される操作部を意味し、アクセルペダル、ブレーキペダル、シフトレバー、ステアリングホイールなどが該当する。それら操作部における各々の操作量がセンサ等によって検出され、制御システム１０に入力される。

ハイブリッド車両が、走行支援のための電子制御デバイスを備えている場合、それら電子制御デバイスからの情報も制御システム１０に入力される。例えば、走行支援のための電子制御デバイスとしては、アダプティブクルーズコントロールシステム（ＡＣＣ）４、パーキングコントロールシステム（ＰＣＳ）６、レーンキープアシストシステム（ＬＫＡ）８などが該当する。その他にも、ハイブリッド車両が、アンチロックブレーキシステム（ＡＢＳ）、トラクションコントロールシステム（ＴＲＣ）、ビークルスタビリティコントロールシステム（ＶＳＣ）を備えている場合には、それらのシステムからの情報も制御システム１０に入力される。それらの電子制御デバイスによって、車両の駆動トルクが決定される場合があるためである。

上述した各種の情報は、制御システム１０の前後挙動調整機能を担う制御ブロックであるＶＬＣ１２に与えられる。ただし、必要に応じて、入力された情報は、他の制御ブロックにも与えられ得る。ＶＬＣ１２は、原則として運転者の操作に対応するように車両の前後方向の挙動を制御すべく、前後方向の目標加速度（減速度）を算出するとともに、その目標加速度（減速度）を実現するための目標駆動トルク（車軸トルク目標値）を算出して、駆動力調整機能を担う論理ブロックであるＰＴＣ１４に出力する。

バッテリ制御機能を担う論理ブロックであるＢＡＴＣ２４は、高圧バッテリ３４の電圧、電流、及び温度を検出し、その検出結果を、電気負荷調整機能を担う論理ブロックであるＥＬＣ２０に出力する。また、ＢＡＴＣ２４は、検出した電圧、電流、及び温度に基づき、高圧バッテリ３４に異常が発生しているか否かを判断する。さらに、ＢＡＴＣ２４は、検出した温度に基づいて、図示しない冷却ファンを駆動することにより、高圧バッテリ３４の温度上昇を抑制する。

ＥＬＣ２０は、ＢＡＴＣ２４から提供された高圧バッテリ３４の電圧、電流、及び温度に基づき、バッテリ容量に対する充電残量の比率である充電レベル（ＳＯＣ）を算出する。そして、ＥＬＣ２０は、この充電レベルに基づいて、高圧バッテリ３４の最大許容放電量や要求充電量を算出して、モータジェネレータ調整機能を担う論理ブロックであるＭＧＣ１６に出力する。

車両には、ＩＳＧ３２に対して駆動電圧を提供したり、ＩＳＧ３２によって発電された電圧を蓄電したりする高圧バッテリ３４の他に、車両に搭載された各種の電気負荷（ＥＣＵ、モータ、表示モニタ、オーディオ機器等）に作動電圧を提供する低圧バッテリ（図示せず）も設けられている。高圧バッテリ３４と低圧バッテリとは、降圧コンバータを介して接続されており、降圧コンバータを動作させることにより、高圧バッテリ３４により低圧バッテリを充電可能となっている。

そのため、ＥＬＣ２０は、低圧バッテリの充電レベル及び上述した電気負荷の作動状態を検出し、充電が必要であるか否かを判定する。充電が必要である場合、ＥＬＣ２０は、低圧バッテリを充電するために必要な電力量を考慮して、ＩＳＧ３２の最大許容放電量や要求充電量を算出する。ただし、ＥＬＣ２０は、ＩＳＧ３２への電力量の供給を優先すべきと判定した場合には、電気負荷の作動を一時的に停止させるようにしても良い。

モータジェネレータ調整機能を担う論理ブロックであるＭＧＣ１６は、ＥＬＣ２０から出力された要求充電量に応じて、回生ブレーキ時のＩＳＧ３２が発生すべき回生電力量を定める。そして、回生ブレーキが行われる時に、ＩＳＧ３２に対して回生電力量を指示する。ＩＳＧ３２は、モータ本体の他に、インバータ、及びインバータの動作を制御するための制御部を有している。ＩＳＧ３２の制御部は、指示された回生電力量となるように、インバータを制御する。

また、ＭＧＣ１６は、ＥＬＣ２０から出力された最大許容放電量に基づいて、ＩＳＧ３２が発生可能な最大トルクを算出し、駆動力調整機能を担う論理ブロックであるＰＴＣ１４に出力する。ＰＴＣ１４は、車両において、ＶＬＣ１２から取得した目標駆動トルクを発生させるため、ＩＳＧ３２の発生可能最大トルクを考慮して、目標エンジントルク及び目標モータトルクを決定する。目標エンジントルクは、エンジン制御機能を担う論理ブロックであるＥＭＳ２２に出力される。また、目標モータトルクは、ＭＧＣ１６に出力される。ＥＭＳ２２は、与えられた目標エンジントルクを発生させるべく、エンジンの点火時期や燃料噴射量及ぶその噴射タイミングを制御する。また、ＭＧＣ１６は、与えられた目標モータトルクを発生させるべく、ＩＳＧ３２の制御部へ指示する。この場合、ＩＳＧ３２の制御部は、ＩＳＧ３２の回転を検知し、その検知した回転状態に基づき、ＩＳＧ３２が指示された目標モータトルクを発生するように、インバータを制御する。

ハイブリッド車両において、効率の良い領域でエンジンを運転すると、廃熱が減るため、必要な暖房エネルギーが確保できない可能性が生じる。一方、暖房エネルギーを確保するためにエンジンの廃熱を増やすようにすると、燃費が悪化する。このような暖房による燃費の悪化を防止するため、車両は、暖房熱源として、ヒートポンプ３６を備えている。

熱調整機能を担う論理ブロックであるＴＨＣ１８は、外気温度及び設定温度を検出し、車室内の暖房のために必要な暖房エネルギーを算出する。そして、エンジンの冷却水から得られる暖房エネルギーが、必要な暖房エネルギーに対して不足する場合、最も効率良く必要な暖房エネルギーが得られるようにヒートポンプ３６の目標運転状態を算出する。ＴＨＣ１８は、この算出したヒートポンプ３６の目標運転状態を、ヒートポンプ制御機能を担う論理ブロックであるＨＰＣ２６に出力する。ＨＰＣ２６は、ヒートポンプ３６の運転状態が与えられた目標運転状態となるように、ヒートポンプ３６の運転状態を制御する。

次に、本実施形態に係る制御システム１０の特徴について説明する。上述した制御システム１０は、いくつかの車載装置（エンジン３０、ＩＳＧ３２、高圧バッテリ３４、ヒートポンプ３６）を制御対象としているが、これら車載装置の中には、複数の異なる制御目的で使用される少なくとも１つの装備を有するものがある。なお、装備との用語が、車載装置そのものを示す場合もあり得る。このような前提の下、本実施形態に係る制御システムでは、複数の異なる制御目的で使用される装備に関して、その装備に対する制御責任を負う制御ブロック（管理制御ブロック）が、制御目的の変更に応じて、変更されるように構成した点に特徴がある。

以下、いくつかのケースを例示として示しつつ、具体的に説明する。まず、第１のケースについて、図２及び図３に基づいて説明する。

ハイブリッド車両において、エンジン３０の冷却系と、ＩＳＧ３２のインバータの冷却系とを共通化し、同じ冷却液がエンジン３０とＩＳＧ３２のインバータとを循環するように構成することが考えられる。この場合、冷却系には、温められた冷却水を空気と熱交換して冷却するためのラジエータの他、図２に示すように、冷却液を循環させるためのポンプ５２、冷却水の温度を検出する水温センサ５４、冷却水の循環経路を切り換える３方弁などの流路切換弁５６などが設けられる。

ポンプ５２及び流路切換弁５６を制御することにより、エンジン３０及びＩＳＧ３２のインバータの温度調節（冷却等）の必要性に応じて、冷却液がいずれも循環しない状態、冷却液がエンジン３０だけを循環する状態、冷却液がＩＳＧ３２のインバータだけを循環する状態、及び冷却液がエンジン３０及びインバータの双方を循環する状態のいずれかに切り換えることが可能となる。

エンジン３０の温度調節だけが必要である場合には、図２に示すように、エンジン３０の運転状態の制御機能を担うＥＭＳ２２に属する制御ブロックが、ポンプ５２や水温センサ５４を含む装備５０の制御責任を負う管理制御ブロック４８となることが合理的である。ＥＭＳ２２は、エンジン３０の運転状態及び発熱状態を把握しており、水温センサ５４によって検出された温度に基づいて、ポンプ５２による流量を制御することにより、エンジン３０の発熱温度が適切となるように、冷却水の循環による温度調節制御を行うことができるためである。

なお、「制御責任を負う」とは、対象がポンプ５２のようなアクチュエータであれば、そのアクチュエータに対して、制御目標値を定め、その制御目標値に応じた制御信号を出力する役割を担うことを意味する。また、対象が水温センサ５４のようなセンサであれば、そのセンサによって検出されるセンサ信号の受信処理を実行する役割を担うことを意味する。

また、ＩＳＧ３２のインバータの温度調節だけが必要である場合には、図２に示すように、ＩＳＧ３２のインバータの制御機能を担うＭＧＣ１６に属する制御ブロックが、装備５０の管理制御ブロック４８となることが合理的である。これにより、ＩＳＧ３２の駆動電流を調節するために動作するインバータの温度調節を適切に行うことができるためである。

さらに、エンジン３０及びＩＳＧ３２のインバータの双方の温度調節が必要である場合には、図２に示すように、ＥＭＳ２２及びＭＧＣ１６に対して、発生トルクを指示するＰＴＣ１４に属する制御ブロックが、装備５０の管理制御ブロック４８となることが合理的である。この場合、エンジン３０の運転状態とＩＳＧ３２のインバータの動作状態を共に把握できるのは、ＰＴＣ１４であるためである。

このように、温度調節を行う制御目的の変更に応じて、制御主体としての管理制御ブロック４８を変更することにより、変更された制御目的に対して、より適切な制御を実行することが可能となる。

本実施形態では、管理制御ブロック４８は、管理主体として装備５０の制御責任を負っている。この制御責任は、上述したような制御信号の出力処理やセンサ信号の受信処理に限られる訳ではない。例えば、管理制御ブロック４８は、制御責任の一つとして、装備５０の異常判定及び異常発生時のフェールセーフ処理の実行も担う。これにより、装備５０に対する制御責任を負う管理制御ブロック４８が変更された場合であっても、その装備５０に対する安全管理責任の所在が不明確となることを防止することができる。

例えば、管理制御ブロック４８は、装備がアクチュエータの場合であれば、制御信号の出力に対して、アクチュエータがどのように動作したかをセンサ等により検出する。そして、出力した制御信号に応じた動作を行っていない場合には、アクチュエータに異常が発生したと判定する。管理制御ブロック４８は、異常の発生を判定した場合、異常が発生したこと、及びその異常の内容を他の論理ブロックに伝達することでフェールセーフ処理を実行する。例えば、ポンプ５２に異常が生じて、エンジン３０等の冷却ができない場合、その旨が、管理制御ブロック４８から各制御ブロックに伝達される。これにより、各制御ブロックは、オーバーヒートを防ぐためにエンジンの回転を所定回転数以下に制限したり、インバータが過度に発熱しないように、ＩＳＧの回転数を所定回転数以下に制限したりするといった安全処置を取ることができる。

また、管理制御ブロック４８は、装備がセンサの場合、センサの信号のレベルや、時間的変化の有無などに基づいて、センサの異常を判定する。センサが異常であると判定された場合、アクチュエータの場合と同様に、異常の発生を他の論理ブロックに伝達することでフェールセーフ処理を実行する。この際、管理制御ブロック４８は、制御処理上、該当するセンサからのセンサ信号を必要とする論理ブロックに対して、標準的なセンサ信号を生成して、出力するようにしても良い。

このように、本実施形態では、１つの装備５０に対して管理主体となる管理制御ブロック４８が、制御目的の変更に応じて、異なる制御ブロックに変更（移行）される。そのため、管理主体が変更される装備５０は、管理制御ブロック４８となり得る複数の制御ブロックと通信が可能に構成される。具体的には、１つの装備と、管理制御ブロック４８となり得る複数の制御ブロックとが、個別の通信線を介してそれぞれ接続されても良い。あるいは、装備５０がネットワークに接続され、そのネットワークを介して、管理制御ブロック４８となり得る複数の制御ブロックの中の任意の制御ブロックと通信可能に構成されても良い。

図３には、より具体的な例として、ＥＭＳ２２に属する制御ブロックから、ＰＴＣ１４に属する制御ブロックへと管理主体としての権限を移行する例が示されている。

図３に示すように、ＥＭＳ２２は、制御ブロックとして、噴射及び点火を制御する制御ブロック６８と、エンジン３０の温度調整を行う制御ブロック７２とを有している。なお、図３には、ＥＭＳ２２が有するすべての制御ブロックが示されている訳ではないことが理解されるべきである。

エンジン３０の温度調節だけが行われる場合、ＥＭＳ２２内の制御ブロック７２が、ポンプ５２及び水温センサ５４の管理主体である管理制御ブロック４８となる。この場合、制御ブロック７２は、水温センサ５４からのセンサ信号の受信処理を行って、冷却水の温度を取得する。そして、制御ブロック７２は、取得した冷却水温度に基づいて、冷却水の目標流量、すなわちポンプ５２の目標回転数を定め、その目標回転数となるようにポンプ５２に制御信号を出力する。

例えば、エンジン３０に加えてＩＳＧ３２も駆動する必要が生じると、エンジン３０だけでなく、ＩＳＧ３２のインバータの温度調節も必要となる。この場合、管理主体としての権限が、ＥＭＳ２２内の制御ブロック７２から、ＰＴＣ１４内の制御ブロック６２に移行される。なお、ＰＴＣ１４は、エンジントルクを演算する制御ブロック６０、熱管理を統合的に行うための制御ブロック６２を有している。ただし、ＰＴＣ１４に関しても、図３には、すべての制御ブロックが示されている訳ではない。

管理主体が、ＰＴＣ１４内の制御ブロック６２に移行されると、その制御ブロック６２が管理制御ブロック４８となり、水温センサ５４からのセンサ信号の受信処理、及びポンプ５２に対する制御信号の出力処理を実行する。さらに、制御ブロック６２は、流路切換弁５６を制御して、エンジン３０に向けて流れる冷却水の流量と、ＩＳＧ３２のインバータに向けて流れる冷却水の流量を調節する。これにより、エンジン３０及びＩＳＧ３２のインバータの温度調節を適切に実施することが可能になる。

次に、第２のケースについて、図４に基づいて説明する。第２のケースでは、ＩＳＧ３２の温度を検出する温度センサ８０の管理主体が、ＰＴＣ１４に属する制御ブロックから、ＭＧＣ１６に属する制御ブロックに移行される例を示す。

ＰＴＣ１４が、目標駆動トルクをエンジン３０とＩＳＧ３２とに割り振って目標エンジントルクと及び目標モータトルクを決定する際に、ＩＳＧ３２の温度を考慮することが有効な場合がある。ＩＳＧ３２の温度によっては、ＩＳＧ３２が発生可能な最大トルクに制限を設ける必要が生じる場合があるためである。そのため、通常は、ＰＴＣ１４内の制御ブロックが、温度センサ８０の管理主体としての管理制御ブロック８２となる。

ここで、運転者がブレーキペダルを操作して車両が減速される場合、機械的なブレーキ装置による制動トルクと、ＩＳＧ３２による回生ブレーキによる制動トルクとが運転者による要求制動トルクに見合うように、ブレーキ装置とＩＳＧ３２とを協調して精密に制御する必要が生じる。

この場合、ＰＴＣ１４は、ＭＧＣ１６に対して回生ブレーキによる制動トルクを指示し、ＭＧＣ１６は指示された制動トルクとなるように、ＩＳＧ３２の回生電力量を定める。しかし、ＩＳＧ３２の温度（インバータの温度）が変化すると、インバータを構成している素子のオン抵抗が変化するため、その分回生電力量が変化してしまう虞がある。

そこで、図４に示すように、回生ブレーキと機械的なブレーキとの協調制御時には、ＩＳＧ３２の温度を検出する温度センサ８０の管理主体をＭＧＣ１６内の制御ブロックに移行する。これにより、温度センサ８０からのセンサ信号の受信処理がＭＧＣ１６において実行されるので、他の制御ブロックで受信した場合の遅延やセンサ信号の受信処理時の丸め処理などの影響を受けること無く、ＭＧＣ１６内の制御ブロックがＩＳＧ３２の温度を正確に検出することができる。そして、この検出温度に基づき、指示された制動トルクに見合う回生電力量を定めることにより、回生ブレーキによる制動トルクを、指示された制動トルクに精度良く合わせ込むことができる。

この第２のケースのように、通常は、上位の論理ブロック内の制御ブロックが、管理主体としての権限を持つが、必要に応じて、その権限が下位の論理ブロック内の制御ブロックに移行されることもある。

次に、第３のケースについて、図５に基づいて説明する。第３のケースでは、ＩＳＧ３２を装備として、その管理主体としての権限を、ＥＭＳ２２内の制御ブロックと、ＭＧＣ１６内の制御ブロックとの間で移行させる例を示す。

ＩＳＧ３２は、ベルトを介してエンジン３０のクランクプーリに接続されている。そして、このＩＳＧ３２は、停止しているエンジン３０を始動するスタータ機能、加速時にエンジン３０が発生する駆動トルクをアシストするモータ機能、さらに、減速時に発電するジェネレータ機能を発揮するものである。

本実施形態では、ＩＳＧ３２がスタータ機能を発揮して、停止しているエンジン３０を始動させる場合には、エンジン３０の運転状態を把握しているＥＭＳ２２内の制御ブロックがＩＳＧ３２の制御主体となる。つまり、ＥＭＳ２２は、エンジン３０の始動時にエンジン３０の運転状態を常に監視しながらＩＳＧ３２の駆動を制御する。これにより、エンジン３０が素早くかつ確実に始動するように、ＩＳＧ３２の駆動を制御することが可能となる。

また、ＩＳＧ３２が、モータ機能を発揮してエンジン３０をアシストする場合、及びジェネレータ機能を発揮して発電する場合には、モータジェネレータ調整機能を担うＭＧＣ１６内の制御ブロックがＩＳＧ３２の制御主体となる。これにより、ＩＳＧ３２によるアシスト力の調整や、回生電力量の制御を適切に実行することができる。

ただし、図５に示すように、ＥＭＳ２２とＭＧＣ１６とは直接的に連結されていない。このため、管理制御ブロック３８を、ＥＭＳ２２内の制御ブロックとＭＧＣ１６内の制御ブロックとの間で移行させる場合、例えば、ＰＴＣ１４を介して、ＥＭＳ２２とＭＧＣ１６とが通信を行い、両者間で管理制御ブロック３８を移行させることが考えられる。実際、このようにして、管理制御ブロック３８を移行させることは可能である。ただし、ＰＴＣ１４を介することで、通信の遅れ等が生じ、一時的ではあるにせよ、ＩＳＧ３２の管理主体が不在となる可能性が生じる。

そこで、本実施形態では、異なる論理ブロック間で管理制御ブロック３８を移行させる場合、論理ブロック間の連結関係に沿って、管理制御ブロック３８を移行させるように構成されている。連結されている論理ブロック間は、情報のやり取りも円滑に行うことができ、管理制御ブロック３８の移行処理を、遅滞なくかつ確実に行うことができるためである。

さらに、上述した第３のケースのように、論理ブロック間の連結関係において、移行元の管理制御ブロック３８が属する論理ブロックと、移行先の管理制御ブロック３８が属する論理ブロックとの間に、少なくとも１つの独立した論理ブロックが介在する場合、管理制御ブロック３８を移行させる際、介在する論理ブロック内の制御ブロックを一時的に管理制御ブロック３８とする。これにより、管理制御ブロック３８の移行時に、一時的にせよ、装備の管理主体が不在となる事態の発生を防止することが可能になる。

上述した第３のケースの例で言えば、ＥＭＳ２２内の制御ブロックと、ＭＧＣ１６内の制御ブロックとの間で、管理主体となる権限（すなわち、管理制御ブロック３８としての役割）を移行させる際には、ＥＭＳ２２とＭＧＣ１６との間に介在するＰＴＣ１４内の制御ブロックを一時的に管理制御ブロック３８とする。より具体的には、例えば、ＥＭＳ２２内の制御ブロックからＭＧＣ１６内の制御ブロックへと、管理制御ブロック３８としての役割を移行する場合、管理制御ブロック３８は、ＥＭＳ２２内の制御ブロック→ＰＴＣ１４内の制御ブロック→ＭＧＣ１６内の制御ブロックへと順番に移行することになる。

ただし、管理制御ブロック３８を順番に移行させる際に、管理制御ブロック３８となる制御ブロックが属する論理ブロックが停止していたり、異常が生じていたりして、正常に動作していない場合には、管理制御ブロック３８を移行させる処理は中断される。この場合、管理制御ブロック３８としての役割は、移行元の管理制御ブロック３８に戻される。これにより、管理制御ブロック３８の移行経路に存在する論理ブロックが正常に動作していない場合であっても、装備の管理主体が不在となる事態の発生を防止することができる。なお、このような論理ブロックの状態判定を含む管理制御ブロック３８の移行処理に関しては、後にフローチャートに基づいて詳細に説明する。

次に、第４のケースについて、図６に基づき説明する。第４のケースでは、冷却水の循環経路に設けられた流路切換弁５６を装備として、その管理主体としての権限を、ＰＴＣ１４内の制御ブロックから、ＴＨＣ１８内の制御ブロックへ移行させる例を示す。

上述したように、温度調節の対象をエンジン３０及びＩＳＧ３２のインバータとしている場合には、エンジン３０の運転状態とＩＳＧ３２のインバータの動作状態を共に把握可能なＰＴＣ１４内の制御ブロックが、流路切換弁５６の管理制御ブロック５８となる。しかし、車両の乗員による暖房要求が生じて、冷却水から得られるエネルギーを用いて、車室内の暖房を行う場合には、ＴＨＣ１８内の制御ブロックが、流路切換弁５６の管理制御ブロック５８となる。

ここで、図６に示す第４のケースの場合、ＰＴＣ１４内の制御ブロックからＴＨＣ１８内の制御ブロックへと、管理制御ブロック５８としての役割を移行させる場合、２つのルートが存在する。１番目のルートは、ＰＴＣ１４→ＭＧＣ１６→ＴＨＣ１８との経路を経るものであり、２番目のルートは、ＰＴＣ１４→ＭＧＣ１６→ＥＬＣ２０→ＴＨＣ１８との経路を経るものである。

このように、論理ブロック間の連結関係において、移行元の管理制御ブロック５８が属する論理ブロックから、移行先の管理制御ブロック５８が属する論理ブロックへ達する複数のルートが存在する場合、まず、管理制御ブロック５８としての役割を移行するための１つのルートが選択される。

このルート選択に際しては、複数のルートに関して、少なくとも各論理ブロックの電源系の相違の有無、各論理ブロック間の物理的な通信線の有無を考慮して、安全上の制約を評価し、相対的に安全上の制約の少ないルートが選択される。

例えば、１つのルートに含まれる論理ブロックが、異なる電子制御装置に実装されている等の理由で、その１つのルートに含まれる他の論理ブロックと電源レベルが相違している、ノイズ対策の程度が相違する別個の電源から動作電源の供給を受けているなど、電源系が相違する場合、安全上の制約が多いと判断する。逆に、１つのルートに含まれる各論理ブロックの電源が、同じ電源レベルであったり、同じ電源装置を共用していたりして、電源系の相違が少ない場合、安全上の制約が少ないと判断する。

また、例えば、論理ブロック間が通信線を介して接続されている場合、その論理ブロック間の情報のやり取りには、通信プロトコルによる制限を受けるため、安全上の制約が多いと判断する。逆に、連結された２つの論理ブロックが、同じ電子制御装置に実装されており、情報のやり取りに通信線を介しての通信が不要である場合には、安全上の制約が少ないと判断する。

このような観点から、各ルートの安全上の制約の多さ、少なさを総合的に示す評価値が算出される。そして、安全上の制約が最も少ない評価値を持つルートが、管理制御ブロック５８を移行させるルートして選択される。なお、複数のルートの安全上の制約が同等であると評価される場合には、経由する論理ブロックの数が少ない、より短いルートが選択される。

図６に示す第４のケースの場合にも、１番目のルートと２番目のルートとの安全上の制約の多さ、少なさが評価され、安全上の制約に相違があれば、より制約の少ないルートが選択される。ただし、実際のところ、図６に示す第４のケースでは、２つのルートは、重複した部分が多く、安全上の制約は同等となることが多いと考えられる。この場合、ルートの長短により、ＰＴＣ１４→ＭＧＣ１６→ＴＨＣ１８の１番目のルートが選択される。

次に、管理制御ブロックの変更処理について、図７〜図９のフローチャートを参照しつつ詳細に説明する。

なお、図７〜図９のフローチャートに示す処理は、移行元の管理制御ブロックが属する論理ブロックから、最終的な移行先の管理制御ブロックが属する論理ブロックまでが、同じ電子制御装置に実装されている場合、移行元の管理制御ブロック、移行先の管理制御ブロック、及び、それら移行元、移行先の管理制御ブロックとは別個の制御ブロックのいずれによっても実行することが可能である。同じ電子制御装置に実装されていれば、管理制御ブロックの移行が可能な状態であるか等の、管理制御ブロックの変更に必要な情報を、いずれの制御ブロックでも取得し、判断することが可能なためである。また、この場合、移行元の管理制御ブロックと、移行先の管理制御ブロックとが連携して、管理制御ブロック変更処理を実行するようにしても良い。

ただし、移行元の管理制御ブロックが属する論理ブロックと、最終的な移行先の管理制御ブロックが属する論理ブロックとが、異なる電子制御装置に実装され、その異なる電子制御装置間で、管理制御ブロックを移行させる場合、図７〜図９のフローチャートに示す処理は、移行元の電子制御装置におけるいずれかの制御ブロックと、移行先の電子制御装置におけるいずれかの制御ブロックとが、互いに通信しつつ協働して実行する必要がある。

図７のフローチャートは、管理制御ブロック変更処理のメインルーチンを示している。図７のフローチャートのステップＳ１００では、制御目的が変更されたか否かを判定する。制御目的が変更されていなければ、管理制御ブロックを変更する必要もないので、図７のフローチャートに示すメインルーチンを終了する。一方、制御目的が変更されたと判定した場合には、ステップＳ１１０の処理に進む。

ステップＳ１１０では、制御目的の変更に伴って、管理制御ブロックを移行させる先の制御ブロックを特定する。各制御目的に対応する管理制御ブロックは予め定められており、その対応関係がマップとして各電子制御装置内に記憶されている。管理制御ブロック変更処理を司る制御ブロックは、マップを参照して、いずれの制御ブロックが管理制御ブロックとなるかを特定することができる。

なお、このマップは、複数の制御目的に同時に対応する場合も想定し、制御目的の主従関係も定義できるようにしても良い。例えば、現在処理中の制御を主とし、後から要求された制御目的に対応する制御を従とし、従となる制御は、現在処理中の制御を補正する形で実行するようにしても良い。これにより、主となる制御を処理中の管理制御ブロックで、複数の制御目的に応じた制御を実行できるようになる。

例えば、ＩＳＧ３２がエンジン３０の回転軸に連結された部位とエンジン３０との間にクラッチを設け、ＩＳＧ３２がエンジン３０とは独立してエンジン３０の回転軸を回転することが可能であって、車両の走行に必要なトルクが小さい場合、エンジン３０を停止した状態で、ＩＳＧ３２だけがアシストトルクを発生することが考えられる。この場合、ＭＧＣ１６内の制御ブロックが管理制御ブロックとなり、ＩＳＧ３２が発生するトルクを制御する。このような状態から、車両の走行に必要なトルクが増加し、エンジン３０を始動する必要が生じた場合、ＩＳＧ３２は、アシストトルク発生と、エンジン始動との２つの制御目的を有することになる。この場合、現在、実行中のアシストトルク発生のための制御が主となり、エンジン始動のための制御は従となる。そして、管理制御ブロックは、ＭＧＣ１６内の制御ブロックのまま、アシストトルクの発生に加え、エンジン３０を始動するためのトルクも発生するように、ＩＳＧ３２の制御内容を補正する。

そして、ステップＳ１１０では、移行元の管理制御ブロックと、最終的な移行先の管理制御ブロックとが、同一の論理ブロック内に属するか否かを判定する。

移行元の管理制御ブロックと、最終的な移行先の管理制御ブロックとが同じ論理ブロック内に属している場合には、なんら安全上の制約などを考慮せずに、管理制御ブロックを移行させることが可能である。このため、ステップＳ１１０において、同一の論理ブロック内に属すると判定された場合、ステップＳ１５０に進んで、管理制御ブロックを変更する。

一方、移行元の管理制御ブロックと、最終的な移行先の管理制御ブロックとが同じ論理ブロック内に属していない場合には、管理制御ブロックを移行させるルートの選定や、移行先の論理ブロック（制御ブロック）の状態の確認を行う必要が生じる。そのため、ステップＳ１１０において、同一の論理ブロック内に属していないと判定された場合には、ステップＳ１２０の処理に進む。

ステップＳ１２０では、管理制御ブロックを移行させる移行ルートの選定処理を実行する。この移行ルート選定処理の詳細が、図８のフローチャートに示されている。以下、図８のフローチャートを参照して、移行ルート選定処理に関して説明する。

図８のフローチャートのステップＳ２００では、最初に、移行元の管理制御ブロック、及び最終的な移行先の管理制御ブロックを特定する。続くステップＳ２１０では、移行元の管理制御ブロックを、最終的な移行先の管理制御ブロックに移行させるための候補ルートを算出する。上述したように、本実施形態では、異なる論理ブロック間で管理制御ブロックを移行させる場合、論理ブロック間の連結関係に沿って、管理制御ブロックを移行させる。従って、候補ルートの算出に際しては、論理ブロック間の連結関係が考慮され、連結された論理ブロックを辿るように、候補ルートが算出される。また、移行元の管理制御ブロックが属する論理ブロックから、最終的な移行先の管理制御ブロックが属する論理ブロックに達するルートが複数ある場合には、それら複数のルートが候補ルートとして算出される。

そして、ステップＳ２２０において、候補ルートとして、複数のルートが算出されたか否かを判定する。このとき、複数のルートが算出されないと判定されると、ステップＳ２７０に進んで、算出された唯一の候補ルートを、管理制御ブロックを移行させるための移行ルートとして選定する。一方、候補ルートとして、複数のルートが算出されたと判定されると、ステップＳ２３０の処理に進む。

ステップＳ２３０では、複数の候補ルートの各々に関して、上述した安全上の制約に関する評価値を算出する。そして、ステップＳ２４０において、算出された各候補ルートの評価値に基づいて、各候補ルートの評価値は同等であるか否か、すなわち、各候補ルートの安全上の制約に相違が無いか判定する。このとき、評価値は同等であると判定されると、各候補ルートで安全上の制約に差はないとみなすことができるため、ステップＳ２６０の処理に進んで、経由する論理ブロックの数が少ない、より短い候補ルートを、移行ルートとして選定する。一方、ステップＳ２４０において、各候補ルートの評価値は同等ではないと判定された場合には、ステップＳ２５０の処理に進んで、安全上の制約の少ない候補ルートを移行ルートとして選定する。

再び、図７のフローチャートに戻って説明を続ける。ステップＳ１２０の処理において、移行ルートが選定されると、次に、ステップＳ１３０において、移行できる状態であるか否かを判定する移行判定処理が実行される。この移行判定処理の詳細が、図９のフローチャートに示されている。以下、図９のフローチャートを参照して、移行判定処理に関して説明する。

図９のフローチャートのステップＳ３００では、最初に、移行先の管理制御ブロックが正常に動作しているか否かを判定する。例えば、移行先の管理制御ブロックが、スリープしていたり、電源供給が停止されていたり、何らかの動作異常が生じたりしていた場合、正常に動作していないと判定される。なお、スリープや電源供給の停止は、論理ブロック単位で実行されるので、実際には、移行先の管理制御ブロックが属する論理ブロックの動作状態が確認されることになる。また、このステップＳ３００における「移行先の管理制御ブロック」には、最終的な管理制御ブロックだけでなく、最終的な管理制御ブロックに達するまでに経由するすべての管理制御ブロックを含む。

ステップＳ３００において、移行先の管理制御ブロックが正常に動作していないと判定されると、ステップＳ３４０の処理に進み、移行禁止状態に設定する。一方、移行先の管理制御ブロックが正常に動作していると判定された場合、ステップＳ３１０の処理に進む。

ステップＳ３１０では、制御目的の変更に伴い、制御目的の変更前の制御（現在の制御）が終了したか否かを判定する。制御目的が変更された場合、制御内容も変わり、新たな制御を開始することになる。そのためには、制御目的変更前の制御が終了される必要がある。そのため、ステップＳ３１０では、現在の制御が終了されたか否かを確認し、まだ終了されていないと判定した場合には、ステップＳ３２０の処理に進み、その制御を実行している論理ブロックに対して、現在の制御の停止処理を行うよう指令する。その後、ステップＳ３００の処理に戻る。一方、ステップＳ３１０において現在の制御が終了されていると判定した場合には、ステップＳ３３０の処理に進んで、移行許可状態に設定する。

再び、図７のフローチャートに戻って説明を続ける。ステップＳ１３０の移行判定処理が完了すると、次に、ステップＳ１４０において、ステップＳ１３０での判定結果が、移行許可状態であるか否かを判定する。このとき、移行許可状態と判定されると、ステップＳ１５０の処理に進み、管理制御ブロックを変更するための移行処理を開始する。一方、ステップＳ１４０において、移行許可状態ではない、すなわち移行禁止状態と判定されると、ステップＳ１６０の処理に進み、管理制御ブロックの移行処理は実行せず、管理制御ブロックは元のままとする。

なお、管理制御ブロックの移行処理を開始した後も、移行先の管理制御ブロックが正常に動作しているか否かの判定を継続して行うことが好ましい。そして、管理主体としての役割が、最終的な移行先の管理制御ブロックへ達する前に、最終的な移行先の管理制御ブロックに達するまでのいずれかの管理制御ブロックが正常に動作していないと判定した場合、管理制御ブロックを、移行処理を開始する以前の元の管理制御ブロックに戻すことが好ましい。なお、管理制御ブロックを元の管理制御ブロックに戻す場合にも、上述したと同様に、論理ブロックの連結関係に沿って、介在する論理ブロックを順番に辿るように、管理制御ブロックを移行させる。このようにすれば、少なくとも、元の制御を継続できる状態に戻すことができる。

以上、本発明の好ましい実施形態について説明したが、本発明は、上述した実施形態になんら制限されることなく、本発明の主旨を逸脱しない範囲において、種々変形して実施することが可能である。

例えば、ある装備の管理制御ブロックとしての役割が移行される制御ブロックを持つ論理ブロックは、車両向けの機能安全性規格（例えばＩＳＯ２６２６２の規格）による同じ安全性要求レベルを満足するように設計されることが好ましい。

なお、ＩＳＯ２６２６２は、車両を電子制御する際の安全性の確保を図るべく制定されたもので、電子制御されるシステムの機能が故障した時の危険な事象（ハザード）から、各システムを、危険レベル、発生頻度、制御可能性（回避の難易度）の３つのパラメータにより、ＡＳＩＬ（Automotive Safety Integrity Level）と呼ばれる指標を用いてランク付けする。ＡＳＩＬには、危険度の低い方から順に、ＱＭ（Quality Management）、Ａ、Ｂ、Ｃ、Ｄの５つのランクが定められている。

さらに、移行元の管理制御ブロックから、最終的な移行先の管理制御ブロックへ移行させるときのルート上に存在する論理ブロックも、同じ安全性要求レベルを満足するように設計されることが好ましい。このようにすれば、制御目的の変更に応じて、装備の管理主体を変更しても、同じ安全基準を満たす状態を維持することができる。

また、上述した第１〜第４のケースでは、センサ信号の受信処理、アクチュエータの制御目標値の算出及びその制御目標値に従う制御信号の出力処理、異常判定処理、異常判定結果に応じたフェールセーフ処理などの役割を有する管理制御ブロックが、すべての役割を保持したまま、ある制御ブロックから別の制御ブロックに変更される例について説明した。しかしながら、管理制御ブロックの役割を分割し、分割した一部の役割だけを別の制御ブロックに移すようにしても良い。

以下、具体的な事例について、図１０を参照して説明する。図１０には、エンジン３０の回転を検出する回転センサ８４を装備として、その管理制御ブロックの役割の一部を、ＥＭＳ２２内の制御ブロックから、上位のＰＴＣ１４内の制御ブロックへ移行させる例を示している。

回転センサ８４は、例えば、エンジン３０のクランクシャフトの回転角に応じて回転検出信号を出力するクランク角センサである。この回転センサ８４は、例えば、エンジン３０のクランクシャフトが１０°ＣＡ回転するごとに、回転検出信号としてのパルス信号を出力するように構成される。このため、回転センサ８４が出力する回転検出信号に基づいて、エンジン３０の運転状態を制御する上で非常に重要な情報である、エンジン３０の回転角や回転速度を算出することができる。そのため、通常は、エンジン３０の運転状態を制御するＥＳＭ２２内の制御ブロックが管理制御ブロック８６となり、回転センサ８４の回転検出信号の受信処理に加え、異常判定処理、及び異常発生時のフェールセーフ処理などを実行する。

なお、ＥＭＳ２２内の制御ブロックが回転センサ８４の回転検出信号を受信する場合、例えば、回転検出信号としてのパルス信号によって割込み処理が開始される。その割込み処理において、入力されたパルス信号をカウントし、そのカウント数からエンジン３０の回転角を算出する。さらに、過去に入力されたパルス信号との間隔から、エンジン３０の回転速度を算出する。このような割込み処理による、エンジン３０の回転角や回転速度の演算処理には、比較的高い演算能力が必要となる。そのため、ＥＭＳ２２は、このような割込みによる演算処理を可能とする能力を備えた電子制御装置に実装され、回転センサ８４と専用の通信線によって接続されている。

その一方、エンジン３０とＩＳＧ３２とが同時に駆動される場合、ＰＴＣ１４は、車両としての目標駆動トルクを実現するため、エンジン３０の発生トルクとＩＳＧ３２の発生トルクとを協調して制御する必要が生じる。つまり、時々刻々と変化するエンジン３０やＩＳＧ３２の状態に応じて、各々が発生するトルクの変動を整合させる必要がある。この協調制御を行うトリガとして、回転センサ８４からの回転検出信号を用いることができる。そのため、図１０に示す事例では、ＰＴＣ１４が、エンジン３０とＩＳＧ３２との協調制御を実行する場合には、回転センサ８４の管理制御ブロックの役割の一部をＰＴＣ１４内の制御ブロックに移す。

以下、ＥＭＳ２２内の制御ブロックに残す役割と、ＰＴＣ１４内の制御ブロックに移す役割とについて説明する。

上述したように、回転センサ８４とＥＭＳ２２とは専用の通信線で接続されており、ＥＭＳ２２内の制御ブロックが、継続的に、回転センサ８４からの回転検出信号の受信処理を行う必要がある。

そのため、図１０に示す事例では、管理制御ブロックの役割を、回転センサ８４からの回転検出信号の受信処理を行う受信部８６ａと、受信処理以外の異常判定処理やフェールセーフ処理などを行う管理部８６ｂとに分ける。そして、受信部８６ａとしての役割は、元のＥＭＳ２２内の制御ブロックに残したまま、管理部８６ｂの役割だけを、ＰＴＣ１４内の制御ブロックに移す。

このようにすることにより、上述したような物理的な制約、すなわち、センサがある特定の論理ブロックのみに接続されている、及び／又は、センサから信号を受信し、その受信した信号を処理するための構成が特定の論理ブロックにのみ用意されているような場合でも、制御目的の変更に応じて、管理制御ブロック８６の役割の一部を他の制御ブロックに移すことが可能になる。

なお、管理制御ブロックの役割を受信部８６ａと管理部８６ｂとに分けた場合、それら受信部８６ａと管理部８６ｂとは緊密に連携する必要がある。そのため、受信部８６ａにおける回転検出信号の受信、算出されたエンジン３０の回転角度及び回転速度は、逐次、管理部８６ｂに送信される。逆に、管理部８６ｂにおける異常判定の結果、及び、その異常判定結果に基づきフェールセーフ処理を実行する際には、管理部８６ｂは、それらの情報を受信部８６ａに送信する。

上述した事例は、装備がセンサに関するものであったが、装備がアクチュエータである場合にも、同様の考え方で、管理制御ブロックを分割することができる。例えば、あるアクチュエータが、特定の論理ブロックと専用の通信線によって接続されている場合、その特定の論理ブロック内の制御ブロックに、アクチュエータへの制御信号の出力処理を行う出力部だけを残し、別の論理ブロック内の制御ブロックに、制御目標値の算出処理、異常判定処理、及びフェールセーフ処理などを行う管理部を移すことができる。

例えば、上述した第３のケースのように、ＩＳＧ３２を装備とした場合であって、そのＩＳＧ３２がＭＧＣ１６と専用の通信線で接続されている場合、エンジン３０の始動のためにＥＭＳ２２内の制御ブロックを制御主体とする際には、管理部のみをＥＭＳ２２内の制御ブロックに移す。この場合、ＥＭＳ２２内の制御ブロックが、エンジン３０を始動させるためのＩＳＧ３２の制御目標値を決定する。この制御目標値は、ＭＧＣ１６内の出力部としての制御ブロックに与えられ、その制御ブロックは、制御目標値に応じた制御信号をＩＳＧ３２に出力する。

一方、ＩＳＧ３２がモータ機能を発揮してエンジン３０をアシストする場合、あるいはジェネレータ機能を発揮して発電する場合には、ＭＧＣ１６内の制御ブロックが、管理部及び出力部としての役割を果たす。この場合、例えば、ＩＳＧ３２とエンジン３０とがクラッチを介して連結しており、ＩＳＧ３２はエンジン３０とは独立して回転可能であって、車両が緩やかな下り坂を走行しており、運転者の運転操作に基づく希望車速を維持するには、ＩＳＧ３２のアシストトルクのみで十分であるとＰＴＣ１４が判断した場合、ＰＴＣ１４は、ＥＭＳ２２に対してエンジン３０の停止を指示するとともに、ＭＧＣ１６に対して、ＩＳＧ３２が発生すべきアシストトルクを指示することが考えられる。この指示を受けて、ＭＧＣ１６内の制御ブロックは、制御目標値を定め、制御信号をＩＳＧ３２に出力する。この状態で、例えば、運転者により車速の上昇が指示されると、ＰＴＣ１４は、ＥＭＳ２２に対してエンジンの始動を指示するとともに、ＭＧＣ１６に対して、エンジン始動のためのトルク分だけ、ＩＳＧ３２の発生トルクを増加するよう指示する。すると、ＭＧＣ１６内の制御ブロックは、新たな制御目標値を定め、その新たな制御目標値に応じた制御信号をＩＳＧ３２に出力する。

このようにすれば、装備としてのアクチュエータが、管理制御ブロックとなり得る複数の制御ブロックとの通信が可能に構成されていなくとも、制御目的の変更に応じて、適切な制御ブロックを実質的な管理制御ブロックとすることが可能になる。

従って、例えば、エンジン始動に関連する装備（インジェクション、点火装置、電子スロットル、ＩＳＧ３２）の管理部としての役割を、ある制御ブロックに集約すれば、それらの装備を協調して動作させることが容易に行いうる。さらに、異常が生じて、エンジンを停止させる場合などにも、各装備の動作の整合を図ることが容易に行いうる（例えば、インジェクションは燃料噴射の停止、電子スロットルは全閉、点火装置は点火カット、ＩＳＧはエンジン停止を促すため回生動作）。

１０ 制御システム
１２〜２６ 制御ブロック
３０ エンジン
３２ ＩＳＧ
３４ バッテリ
３６ ヒートポンプ

Claims (16)

1. 複数の異なる制御目的で使用される少なくとも１つの装備（３２、５０、８０）を有する車載装置（３０〜３６）のための制御システム（１０）であって、
   前記制御システムは、予め複数の論理ブロック（１２〜２６）に区分けされ、それら複数の論理ブロック間の連結関係を規定することによって構成されており、前記複数の論理ブロックが前記論理ブロック間の連結関係に従って連携して動作することにより、前記車載装置を制御するものであり、
   前記複数の論理ブロックは、それぞれ、少なくとも１つの制御ブロックを有し、
   前記制御目的に応じて、前記装備に対する制御責任を負う管理主体となる制御ブロックが管理制御ブロックとして予め定められており、
   前記制御目的の変更の有無を判定する変更判定手段（Ｓ１００）と、
   前記変更判定手段によって前記制御目的が変更されたと判定されたことに応じて、予め定められた前記制御目的と前記管理制御ブロックとの対応関係に基づき、前記管理制御ブロックを変更する管理制御ブロック変更手段（Ｓ１５０）と、を備え、
   前記装備は、車載機器を動作させるためのアクチュエータを含み、
   前記アクチュエータに対する制御責任を負う前記管理制御ブロックは、前記アクチュエータの制御目標値を定めるとともに、その制御目標値に応じた制御信号を、別の制御ブロックを介することなく、直接、前記アクチュエータに与えるものである制御システム。
2. 前記管理制御ブロックは、前記装備の異常判定及び異常発生時のフェールセーフ処理の実行も担うものである請求項１に記載の制御システム。
3. ある制御目的の下で管理制御ブロックとなった制御ブロックが、その制御目的を達成するための制御目標値を定め、前記アクチュエータに対して制御を実行しているときに、別の制御目的にも同時に対応する必要が生じた場合、ある制御目的の下で管理制御ブロックとなった制御ブロックが、前記別の制御目的も同時に達成できるように、前記制御目標値を補正し、当該補正された制御目標値に従って、前記アクチュエータを制御する請求項１又は２に記載の制御システム。
4. 前記装備は、所定の物理量を検出するためのセンサを含み、
   前記センサに対する制御責任を負う前記管理制御ブロックは、前記センサによって検出される検出信号の受信処理を実行するものである請求項１乃至３のいずれかに記載の制御システム。
5. 前記管理制御ブロックの役割が、前記センサの異常判定及び異常発生時のフェールセーフ処理を実行する管理部と、前記センサからのセンサ信号の受信処理を行う受信部とに分割され、前記受信部の役割を担う管理制御ブロックは特定の制御ブロックに固定され、前記管理部としての役割を担う管理制御ブロックは、前記制御目的の変更に応じて変更される請求項４に記載の制御システム。
6. さらに、管理主体としての権限を、変更前の前記制御目的に対応する前記管理制御ブロックから、変更後の前記制御目的に対応する前記管理制御ブロックへ移行させる際に、移行先の制御ブロックが、管理主体としての権限を移行可能な状態であるか否かを判定する状態判定手段（Ｓ１３０）を備え、
   前記管理制御ブロック変更手段は、前記状態判定手段により移行可能な状態であるとの判定がなされたとき、前記管理制御ブロックを変更することを特徴とする請求項１乃至５のいずれかに記載の制御システム。
7. 前記状態判定手段は、前記移行先の制御ブロックが正常に動作しているか否かに基づき、移行可能な状態であるか否かを判定するものである請求項６に記載の制御システム。
8. 前記状態判定手段は、変更前の前記制御目的での制御を終了しているか否かに基づき、移行可能な状態であるか否かを判定するものである請求項６に記載の制御システム。
9. 前記管理制御ブロック変更手段は、前記管理制御ブロックを変更するために前記管理制御ブロックを異なる前記論理ブロック間で移行させることが必要な場合、前記論理ブロック間の連結関係に沿って、前記管理制御ブロックを移行させるように構成された請求項１乃至８のいずれかに記載の制御システム。
10. 前記論理ブロック間の連結関係において、変更前の前記制御目的に対応する前記管理制御ブロックが属する前記論理ブロックと、変更後の前記制御目的に対応する前記管理制御ブロックが属する前記論理ブロックとの間に、少なくとも１つの独立した前記論理ブロックが介在する場合、前記管理制御ブロック変更手段は、前記管理制御ブロックを移行させる際、介在する前記論理ブロック内の制御ブロックを一時的に前記管理制御ブロックとすることで、前記管理制御ブロックの移行時に、前記装備の管理主体が不在となる事態の発生を防止する請求項９に記載の制御システム。
11. 前記論理ブロック間の連結関係において、変更前の前記制御目的に対応する前記管理制御ブロックが属する前記論理ブロックから、変更後の前記制御目的に対応する前記管理制御ブロックが属する前記論理ブロックへ達する複数のルートが存在する場合に、１つのルートを選択するルート選択手段（Ｓ１２０）を備え、
    前記管理制御ブロック変更手段は、前記ルート選択手段によって選択されたルートに従って、前記管理制御ブロックを移行させて、前記管理制御ブロックを変更するように構成された請求項９又は１０に記載の制御システム。
12. 前記ルート選択手段は、前記複数のルートに関して、少なくとも各論理ブロックの電源系の相違の有無、各論理ブロック間の物理的な通信線の有無を考慮して、安全上の制約を評価し、相対的に安全上の制約の少ないルートを選択するように構成された請求項１１に記載の制御システム。
13. 前記ルート選択手段は、前記複数のルートの安全上の制約が同等であると評価した場合、より短いルートを選択するように構成された請求項１２に記載の制御システム。
14. 変更前の前記制御目的に対応する前記管理制御ブロックが属する前記論理ブロックと、変更後の前記制御目的に対応する前記管理制御ブロックが属する前記論理ブロックとは、機能安全規格による同じ安全性要求レベルを満足するように設計され、さらに、前記ルート選択手段によって選択されるルート上に存在する論理ブロックも、前記同じ安全性要求レベルを満足するように設計される請求項１１乃至１３のいずれかに記載の制御システム。
15. 変更前の前記制御目的に対応する前記管理制御ブロックが属する前記論理ブロックから、変更後の前記制御目的に対応する前記管理制御ブロックが属する前記論理ブロックまでが、同じ電子制御装置に実装されている場合、変更前の前記制御目的に対応する前記管理制御ブロック、変更後の前記制御目的に対応する前記管理制御ブロック、及び、それらの前記管理制御ブロックとは別個の制御ブロックのいずれかが、前記管理制御ブロックを変更するための処理を実行するように構成された請求項１乃至１４のいずれかに記載の制御システム。
16. 変更前の前記制御目的に対応する前記管理制御ブロックが属する前記論理ブロックと、変更後の前記制御目的に対応する前記管理制御ブロックが属する前記論理ブロックとが、異なる電子制御装置に実装され、その異なる電子制御装置間で、前記管理制御ブロックを移行させる場合、移行元の電子制御装置におけるいずれかの制御ブロックと、移行先の電子制御装置におけるいずれかの制御ブロックとが、互いに通信しつつ協働して、前記管理制御ブロックを変更するための処理を実行するように構成された請求項１乃至１４のいずれかに記載の制御システム。

Images