JP6477430B2 - 電子制御装置 - Google Patents

Description

本発明は、他の電子制御装置と連携した制御と、他の電子制御装置とは独立して、単独での制御とを行う電子制御装置に関する。

例えば特許文献１には、車両に搭載された複数のＥＣＵ間での機能連携のための情報を、各ＥＣＵの車両制御用アプリケーションが使用するよりも事前に共有可能とした車載用情報処理装置が記載されている。

この車両用情報処理装置では、例えば、ナビゲーション用のアプリケーションプログラムを実行する第１ＥＣＵと、トランスミッション制御用のアプリケーションプログラムを実行する第２ＥＣＵとが、車載ＬＡＮを介して接続される。

第１ＥＣＵは、地図探索用のプログラムである地図探索用アプリケーションや、データベースに記憶されている地図情報を用いてナビゲーションに表示する地図データを描画する描画アプリケーションなどを実行する。第１ＥＣＵにおいて、地図探索用アプリケーションが実行されている場合に、車両の前方に険しく曲がりくねった坂道があることが検出されたとき、燃費向上のためには、道路の勾配、カーブに従って自動的にトランスミッションのシフト変更を適切に行うことが効果的となる。

このため、第２ＥＣＵは、機能連携のために第１ＥＣＵ２００とデータを共有する。具体的には、第２ＥＣＵがトランスミッション制御を実行する前に、予め第１ＥＣＵが第２ＥＣＵに地図データを送信しておく。これにより、第２ＥＣＵが、トランスミッション制御を行うとき、即座に詳細な地図情報を参照することが可能としている。

特開２０１１−１４０３３号公報

上述した例のように、第１ＥＣＵと第２ＥＣＵとが連携した制御を行う場合、例えば、第１ＥＣＵでは、第２ＥＣＵと連携した制御を行うための連携制御用アプリケーション（例えば、地図探索用アプリケーション）と、単独での制御を行うための単独制御用アプリケーション（例えば、描画アプリケーション）とを同時期に実行することが必要となることがある。

この際、連携制御用アプリケーションに含まれる処理であるか、それとも単独制御用アプリケーションに含まれる処理であるかをなんら考慮することなく、第１のＥＣＵが、単に、それぞれの処理を行うことが必要となった時期に応じて順番に処理することとすると、それぞれの処理を適切に処理できない状況が生じたり、また、効率的な処理を行い得ない虞がある。

本発明は、上述した点に鑑みてなされたものであり、他の電子制御装置と連携した制御と、他の電子制御装置とは独立して単独での制御とを行う場合に、それぞれの制御処理を適切かつ効率的に行い得る電子制御装置を提供することを目的とする。

上記目的を達成するために、本発明による電子制御装置は、
アプリケーションソフトを記憶する記憶部（４１）と、
そのアプリケーションソフトには、他の電子制御装置と連携した制御を行うための連携制御用アプリケーション（４１ａ、４１ｂ）と、他の電子制御装置とは独立して、単独で制御を行うための単独制御用アプリケーション（４１ｃ）とが含まれており、
連携制御用アプリケーションに含まれる処理及び単独制御用アプリケーションに含まれる処理をそれぞれ実行するものであり、リソースとして、少なくともマイクロプロセッシングユニットとキャッシュメモリとを備えたマイクロコントローラ（４８）と、
連携制御用アプリケーションに含まれる処理と、単独制御用アプリケーションに含まれる処理とを同時期に実行する必要が生じたとき、それぞれの処理の内容に基づき、いずれを優先するべきかを決定する決定部（Ｓ１２０）と、
決定部によって決定された優先順位に従い、優先順位が高い処理から、その処理の実行に必要なリソースを確保して、該当する処理に割り付けるリソース割付部（Ｓ１３０）と、を備える。

連携制御用アプリケーションと、単独制御用アプリケーションとは、互いに依存関係にはなく、一方の処理の終了後に他方の処理を開始する必要はない。換言すれば、連携制御用アプリケーションの処理と、単独制御用アプリケーションの処理とは、マイクロコントローラにおいて、並行処理を行うことが可能である。ただし、マイクロコントローラの処理能力の制約から、常に、連携用制御用アプリケーションの処理と、単独制御用アプリケーションの処理とを並行処理することができるとは限らない。

そこで、本発明の電子制御装置では、それぞれの処理内容に基づき、連携制御用アプリケーションの処理と、単独制御用アプリケーションの処理とのいずれを優先すべきか決定する決定部と、決定部によって決定された優先順位に従い、優先順位が高い処理から、その処理の実行に必要なリソースを確保して、該当する処理に割り付けるリソース割付部とを設けた。

このように構成したため、同時期に実行する処理のそれぞれの負荷が小さければ、それぞれの処理に対してリソースを確保して割り付けることができ、各処理を並行処理することができる。従って、連携制御用アプリケーションの処理と、単独制御用アプリケーションの処理とを効率的に実行することができる。一方、同時期に実行する処理の負荷の合計が、マイクロコントローラの処理能力を超え、並行処理することができない場合には、優先順位の高い処理から順に、リソースを確保して割り付けを行っているので、より早期に処理する必要性の高い処理から確実に実行することができる。このように、連携制御用アプリケーションの処理と、単独制御用アプリケーションの処理とのいずれかしか実行できない状況において、適切な順序で、処理を実行することが可能となる。

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

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

第１実施形態に係る制御システムの構成を示す構成図である。 マスタＥＣＵ及びスレーブＥＣＵのソフトウエア構造と、マスタＥＣＵとスレーブＥＣＵ間の接続関係を示す図である。 マスタＥＣＵにおけるドメイン抽象化層の役割を説明するための図である。 ドメイン抽象化層において実行される処理を示すフローチャートである。 図４のフローチャートにおける、優先順位の決定処理を詳細に示すフローチャートである。 他の実施形態に係る電子制御装置のソフトウエア構造を示す図である。

以下、本発明の実施形態に係る電子制御装置について、図面を参照しつつ説明する。なお、以下には、本実施形態に係る電子制御装置を車両の制御システムに適用した例について説明する。

車両の制御システムは、例えば、図１に示すように、走行駆動源として、エンジンと電動モータ（モータジェネレータ）とを有するハイブリッド車両に適用され、このハイブリッド車両に搭載された各種の車載装置を制御するために用いられる。しかし、制御システムは、ハイブリッド車両における車載装置の制御に適用されることに限られる訳ではなく、エンジンのみを有する通常の車両や、電動モータのみを有する電動車両の車載装置の制御に適用されても良い。

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

図１において、制御システム１は、車載装置としての冷却機構３０，エンジン３１，トランスミッション（ＴＭ）３２、モータジェネレータ（ＭＧ）３３、ブレーキ装置３４、及びステアリング装置３５などを制御するための機能を有する。しかしながら、上述したように、制御システム１は、さらに、例えば、サスペンション、高圧バッテリ、エアコン装置などのその他の車載装置を制御するための機能を有していても良い。

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

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

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

制御システム１は、実際には、各論理ブロック１２〜１６、２２〜２６を、プログラムやデータベースなどの制御ソフトとして、複数の電子制御装置に振り分けて実装することにより具現化される。この場合、複数の電子制御装置は、論理ブロック１２〜１６、２２〜２６の連結関係を維持できるように、個別の通信線を介して接続されたり、各電子制御装置が共通のネットワークに接続され、連結関係に従う所望の電子制御装置同士が通信可能に構成されたりする。なお、必ずしも各論理ブロック１２〜１６、２２〜２６をそれぞれ別個の電子制御装置に実装する必要はなく、幾つかの論理ブロックを共通の電子制御装置に実装しても良い。

本実施形態に係る制御システム１は、複数の車載装置３０〜３５の機能に応じて予め複数のドメインに区分けされている。別の表現をすれば、各論理ブロック１２〜１６、２２〜２６が果たすべき機能のまとまりに応じて、予め複数のドメイン１０、２０に区分けされている。

複数の車載装置３０〜３５は、いずれかのドメイン１０、２０に割り振られる。そして、割り振られたドメイン１０、２０に属するドメイン制御部１１、２１が、各車載装置３０〜３５の制御目標値を算出して、車載装置３０に直接出力したり、車載装置３１〜３５の制御を司る車載装置制御部１５、１６、２４〜２６へ出力したりする。なお、図１に示すように、各ドメイン制御部１１、２１は、少なくとも１つの論理ブロックから構成される。

具体的には、図１に示す例では、制御システム１は、運動ドメイン１０とエネルギードメイン２０とに区分けされている。そして、運動ドメイン１０には、前後方向及び横方向における車両の挙動を制御する機能を担う運動ドメイン制御部１１が設けられている。また、エネルギードメイン２０には、車両を加速させたり、減速させたり、あるいは速度を一定に保つように、車両の動力を制御する機能を担うエネルギードメイン制御部２１が設けられている。

また、本実施形態に係る制御システム１では、図１に示すように、各ドメイン制御部１１、２１の下に、対応するドメイン制御部１１、２１からの指令（制御目標値）に従い、各車載装置３１〜３５の動作状態を制御する車載装置制御部１５、１６、２４〜２６が設けられている。これら車載装置制御部１５、１６、２４〜２６は、各車載装置３１〜３５の動作状態をドメイン制御部１１、２１からの制御目標値に近づけるための制御信号を生成し、各車載装置３１〜３５に出力する。

具体的には、図１に示す例では、運動ドメイン制御部１１の下に、ブレーキ装置３４を制御するブレーキ制御部１５及びステアリング装置３５を制御するステアリング制御部１６が設けられている。また、エネルギードメイン制御部２１の下に、エンジン３１を制御するエンジン制御部２４、トランスミッション３２を制御するトランスミッション（ＴＭ）制御部２５、及びモータジェネレータ３３を制御するＭＧ制御部２６が設けられている。

なお、モータジェネレータ３３は、車両の減速時などに回生エネルギーを発生する。ＭＧ制御部２６の上位の論理ブロックであるモータジェネレータコーディネータ（ＭＧＣ）２３は、その回生エネルギーの生成も管理する。このエネルギーは、インバータによってＤＣ変換され、図示しない高圧バッテリに蓄電される。

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

制御システム１には、各論理ブロック１２〜１６、２２〜２６が与えられた機能を発揮するために必要な各種の情報が入力される。例えば、図示しない各種のセンサによって、ハイブリッド車両の運転のため、運転者によって操作される各種の操作部（アクセルペダル、ブレーキペダル、シフトレバー、ステアリングホイールなど）の操作が検出され、その操作検出信号が制御システム１に入力される。また、車両の走行状態（例えば、速度、加速度、ヨーレートなど）や、各種の車載装置３０〜３５の動作状態（例えば、エンジン温度、エンジン回転数、トランスミッション変速比、インバータ温度、モータ回転数、ブレーキ油圧、操舵角など）を検出するセンサからの動作検出信号も、制御システム１に入力される。

上述した各種の信号は、制御システム１の各ドメイン制御部１１、２１や車載装置制御部１５、１６、２４〜２６に与えられる。

例えば、運動ドメイン制御部１１には、運転者による各種の操作部の操作を示す操作検出信号、及び車両の走行状態を検出するセンサからの動作検出信号が入力される。そして、運動ドメイン制御部１１は、原則として、車両が運転者による操作部の操作に応じた挙動を示すように、ブレーキ装置３４及びステアリング装置３５の制御目標値を算出する。
具体的には、車両挙動制御部１２が、車両の挙動を安定させつつ、運転者の操作に対応するように車両の挙動を制御すべく、前後挙動制御部１３に対して前後方向の目標加速度（目標減速度）を与えるとともに、左右挙動制御部１４に対して左右方向の目標加速度を与える。前後挙動制御部１３は、与えられた前後方向の目標加速度（目標減速度）を実現すべく、エネルギードメイン制御部２１のパワートレインコーディネータ（ＰＴＣ）２２に対して目標駆動トルク（加速トルク又は制動トルク）を出力するとともに、ブレーキ制御部１５に対して、ブレーキ装置３４の制御目標値である目標制動トルクを出力する。また、左右挙動制御部１４は、与えられた左右方向の目標加速度を実現すべく、ステアリング制御部１６に対して、ステアリング装置３５の制御目標値である目標アシストトルクを出力する。

なお、例えば、運動ドメイン制御部１１に、車両の走行車線を区画する白線の認識情報や、先行車両や障害物の情報など、車両の外部環境に関する情報を与えるようにしてもよい。これにより、運動ドメイン制御部１１において、例えば、白線によって区画される走行車線を逸脱しないように、ステアリング装置３５のアシスト力を調整する（レーンキープコントロール）ように制御目標値を算出することが可能となる。また、運動ドメイン制御部１１にて、例えば、先行車両や障害物との衝突を避けるように、ブレーキ装置３４やステアリング装置３５の制御目標値を算出することが可能となる。

また、エネルギードメイン制御部２１には、例えば、図示しない高圧バッテリの電圧や電流を検出するセンサ信号や、車両の走行状態を示すセンサ信号などが入力される。エネルギードメイン制御部２１のＭＧＣ２３は、それらのセンサ信号に基づいて、高圧バッテリの蓄電量を算出する。さらに、ＭＧＣ２３は、主として、高圧バッテリの蓄電量に基づいて、モータジェネレータ３３が発生可能な最大ＭＧトルクを算出して、ＰＴＣ２２に与える。ＰＴＣ２２は、運動ドメイン制御部１１から与えられた目標駆動トルク（加速トルク）を最も効率良く実現するために、モータジェネレータ３３が発生可能な最大ＭＧトルクや、車両の走行状態を考慮しつつ、エンジン３１が発生すべき目標エンジントルク、トランスミッション３２が実現すべき目標変速比、及びモータジェネレータ３３が発生すべき目標ＭＧトルクを算出する。算出された目標エンジントルク、目標変速比、及び目標ＭＧトルクは、それぞれ、制御目標値として、エンジン制御部２４、ＴＭ制御部２５、及びＭＧＣ２３に与えられる。また、ＴＭ制御部２５に対しては、クラッチの動作に関する制御目標値（クラッチの接続開始時期や、クラッチの接続完了までの時間など）も与えられる。

さらに、エネルギードメイン制御部２１のＭＧＣ２３は、車両の減速時等において、主として、高圧バッテリの蓄電量に基づいてモータジェネレータ３３が発生可能な回生電力量を算出する。この回生電力量に対応する回生制動トルクに関する情報は、ＭＧＣ２３から、ＰＴＣ２２を介して運動ドメイン制御部１１の前後挙動制御部１３に与えられる。

前後挙動制御部１３は、車両挙動制御部１２から目標減速度が与えられた場合、その目標減速度を実現するための目標制動トルクを算出する。そして、モータジェネレータ３３が回生制動トルクを発生可能である場合には、極力、その回生制動トルクを活用するように、ブレーキ装置３４による目標制動トルクと、回生ブレーキによる目標回生制動トルクとを定める。この目標回生制動トルクは、制御目標値として、ＰＴＣ２２を介して、エネルギードメイン制御部２１のＭＧＣ２３に与えられる。

また、ＰＴＣ２２は、上述した運動ドメイン１０における前後挙動制御部１３と協調したドメイン間連携制御、及び、ＭＧＣ２３、エンジン制御部２４、並びにＴＭ制御部２５と協調したドメイン内連携制御に加え、他の論理ブロック（電子制御装置）とは独立した単独制御である、冷却機構３０を用いた温度調節制御を実行する。

冷却機構３０は、ハイブリッド車両において、エンジン３１の冷却系と、ＭＧ３３のインバータの冷却系とを共通化し、同じ冷却水が、エンジン３１及びＭＧ３３のインバータとを循環するように構成されたものである。冷却機構３０は、温められた冷却水を空気と熱交換して冷却するためのラジエータの他、冷却水を循環させるためのポンプ、冷却水の温度を検出する水温センサ、冷却水の循環経路を切り換える３方弁などの流路切換弁などを備える。

ＰＴＣ２２には、例えば、冷却水温度、エンジン温度及びインバータ温度が入力される。そして、ＰＴＣ２２が、冷却水温度、エンジン温度及びインバータ温度に基づき、冷却機構３０のポンプ及び流路切換弁の制御目標値を算出するとともに、それぞれの動作状態が制御目標値に近づくように、ポンプ及び流路切り換え弁を制御する。具体的には、ＰＴＣ２２は、エンジン３１及びＭＧ３３のインバータの温度調節（冷却等）の必要性に応じて、冷却水がいずれも循環しない状態、冷却水がエンジン３１だけを循環する状態、冷却水がＭＧ３３のインバータだけを循環する状態、及び冷却水がエンジン３１及びインバータの双方を循環する状態のいずれかに切り換える。また、ＰＴＣ２２は、冷却水温度、エンジン温度及びインバータ温度に基づいて、ポンプの回転数により冷却水の流量を制御する。これにより、ＰＴＣ２２は、エンジン３１及び／又はインバータの発熱温度を適切に調節することが可能となる。

ブレーキ制御部１５は、前後挙動制御部１３から与えられたブレーキ装置３４の制御目標値である目標制動トルクに従い、ブレーキ装置３４を制御する。より具体的には、ブレーキ制御部１５は、ブレーキ装置３４が目標制動トルクを発生するようにブレーキフルード圧を制御するための制御信号を出力する。また、ステアリング制御部１６も、ステアリング装置３５が左右挙動制御部１４から与えられた目標アシストトルクを発生するように制御信号を出力して、ステアリング装置３５によるアシストトルクを制御する。

エンジン制御部２４は、ＰＴＣ２２から与えられた目標エンジントルクを実現するための制御信号をエンジン３１に出力する。より詳細には、エンジン制御部２４は、エンジン３１の運転状態を検出する各種のセンサ（回転数、温度、空気流量等）からのセンサ信号を入力する。そして、センサ信号から把握されるエンジンの運転状態から現状の発生トルクを算出する。エンジン制御部２４は、現状の発生トルクを目標エンジントルクに近づけるためのエンジン運転状態を算出し、その算出したエンジン運転状態を達成するための燃料噴射量と燃料噴射時期、及び点火時期を求め、これらに応じた噴射制御信号及び点火制御信号をエンジン３１に出力する。

ＴＭ制御部２５も、ＰＴＣ２２から目標変速比が与えられ、この与えられた目標変速比を実現するための制御信号をトランスミッション３２に出力する。また、ＴＭ制御部２５は、トランスミッション３２において変速比を変更する場合、クラッチの動作に関する制御目標値に従って、クラッチの動作を制御するための制御信号も出力する。

ＭＧ制御部２６は、ＭＧＣ２３から目標ＭＧトルクが与えられた場合には、その目標ＭＧトルクを発生させるように、モータジェネレータ３３のインバータへ制御信号を出力する。一方、ＭＧ制御部２６は、ＭＧＣ２３から目標回生制動トルクが与えられた場合には、その目標回生制動トルクに相当する制動力をモータジェネレータ３３が車軸に対して付与するように、モータジェネレータ３３のインバータへ制御信号を出力する。

上述した制御システム１におけるＰＴＣ２２のように、制御システム１のドメイン制御部１１，２１に適用される電子制御装置には、他の電子制御装置と連携した制御（ドメイン間連携制御、ドメイン内連携制御）を行うための連携制御用アプリケーションと、他の電子制御装置とは独立して、単独で制御（温度調節制御）を行うための単独制御用アプリケーションとを含むものがある。このため、状況によっては、電子制御装置は、マイクロコントローラにおいて、連携制御用アプリケーションと、単独制御用アプリケーションとを同時期に実行することが必要となることがある。なお、ＰＴＣ２２以外のドメイン制御部１１、２１に属するＥＣＵも、車載装置制御部を介することなく、単独で制御を行うべき車載装置が割り当てられた場合、同様の状況が発生し得る。

この際、連携制御用アプリケーションに含まれる処理であるか、それとも単独制御用アプリケーションに含まれる処理であるかをなんら考慮することなく、電子制御装置が、単に、それぞれの処理を行うことが必要となった時期に応じて順番に処理することとすると、それぞれの処理を適切に処理できない状況が生じたり、また、効率的な処理を行い得ない虞が生じる。例えば、より重要な処理が後回しになってしまい、その重要な処理に関連する制御全体に遅れが生じてしまったり、一方の処理が終了するまで、他方の処理を待機することで、マイクロコントローラの能力を十分に活用できず、全体として処理の実行が非効率になってしまったり、といった問題が生じる虞がある。

ここで、連携制御用アプリケーションと、単独制御用アプリケーションとは、互いに依存関係にはなく、一方の処理の終了後に他方の処理を開始する必要はない。換言すれば、連携制御用アプリケーションの処理と、単独制御用アプリケーションの処理とは、電子制御装置のマイクロコントローラにおいて、並行処理を行うことが可能である。ただし、マイクロコントローラの処理能力の制約から、常に、連携用制御用アプリケーションの処理と、単独制御用アプリケーションの処理とを並行処理することができるとは限らない。

そこで、本実施形態の電子制御装置では、それぞれの処理内容に基づき、連携制御用アプリケーションの処理と、単独制御用アプリケーションの処理とのいずれを優先すべきか決定し、その決定された優先順位に従い、優先順位が高い処理から、その処理の実行に必要なマイクロコントローラのリソースを確保して、該当する処理に割り付けることとした。これにより、同時期に実行する処理のそれぞれの負荷が小さければ、それぞれの処理に対してマイクロコントローラのリソースを確保して割り付けることができ、各処理を並行処理することができる。従って、連携制御用アプリケーションの処理と、単独制御用アプリケーションの処理とを効率的に実行することができる。一方、同時期に実行する処理の負荷の合計が、マイクロコントローラの処理能力を超え、並行処理することができない場合には、優先順位の高い処理から順に、リソースを確保して割り付けを行っているので、より早期に処理すべき重要性の高い処理から確実に実行することができる。このように、連携制御用アプリケーションの処理と、単独制御用アプリケーションの処理とのいずれかしか実行できない状況において、適切な順序で処理を実行することが可能となる。

以下、このような機能を備えた電子制御装置について、図２〜図５に基づき、さらに詳細に説明する。なお、以後の説明において、連携制御用アプリケーションと単独制御用アプリケーションを実行する電子制御装置をマスタＥＣＵと呼び、同じドメイン内において、マスタＥＣＵから指示された制御目標値に従って車載装置を制御する電子制御装置をスレーブＥＣＵと呼ぶ。

図２は、主として、マスタＥＣＵ４０及びスレーブＥＣＵ５０ａ、５０ｂのソフトウエア構造と、マスタＥＣＵ４０とスレーブＥＣＵ５０ａ、５０ｂ間の接続を示しており、制御対象となる車載装置などの、その他の構成は省略している。マスタＥＣＵ４０及びスレーブＥＣＵ５０ａ、５０ｂは、各々、メモリを有しており、図２に示す構造のソフトウエアを、それぞれのメモリに記憶している。

マスタＥＣＵ４０及びスレーブＥＣＵ５０ａ、５０ｂは、図２に示すように、いわゆるＡＵＴＯＳＡＲ（AUTomotive Open System Architecture）に準拠するソフトウエア構造を有している。以下、マスタＥＣＵ４０を例として、ソフトウエア構造について説明する。なお、マスタＥＣＵ４０とスレーブＥＣＵ５０ａ、５０ｂとのソフトウエア構造は、基本的には類似しているが、後述するドメイン抽象化層４４は、マスタＥＣＵ４０のみに設けられ、スレーブＥＣＵ５０ａ、５０ｂには設けられない点で相違している。スレーブＥＣＵ５０ａ、５０ｂでは、ドメイン間連携制御用アプリケーション４１ａやドメイン内連携制御用アプリケーション４１ｂは実行されず、これらのアプリケーション４１ａ、４１ｂの処理との調停を図る必要がないので、ドメイン抽象化層は設けられないためである。

マスタＥＣＵ４０では、図２に示すように、ハードウエアであるマイクロコントローラ４８に、ソフトウエアが搭載され、そのソフトウエアは、大きくは、基本ソフトウエア４３〜４７、ランタイム環境（ＲＴＥ）４２、及び、アプリケーション層４１に含まれるアプリケーションソフトウエア４１ａ〜４１ｃに分けられる。また、マイクロコントローラ４８は、少なくとも１セットのマイクロプロセッシングユニットとキャッシュメモリとを備えている。

基本ソフトウエア４３〜４７は、マイクロコントローラ抽象化層４３、ドメイン抽象化層４４、ＥＣＵ抽象化層４５、サービス層４６に階層化され、階層が高くなるほど、抽象化度合が強くなり、各種のハードウエアから独立するようになっている。また、基本ソフトウエア４３〜４７は、複合ドライバ４７を含む。

マイクロコントローラ抽象化層４３は、基本ソフトウエア４３〜４７の最下層に位置し、マイクロコントローラドライバ、メモリドライバ、通信ドライバ、Ｉ／Ｏドライバなどを有する。このマイクロコントローラ抽象化層４３は、マイクロコントローラ４８のハードウエア構成に依存する部分であるが、このマイクロコントローラ抽象化層４３によって、マイクロコントローラ４８とその周辺機器とが抽象化されるため、これより上位の階層は、マイクロコントローラ４８及び周辺機器から独立することになる。

ドメイン抽象化層４４は、マイクロコントローラ抽象化層４３の上位に位置している。このドメイン抽象化層４４は、連携制御用アプリケーション（ドメイン間連携制御用アプリケーション４１ａ、ドメイン内連携制御用アプリケーション４１ｂ）に含まれる処理と、単独制御用アプリケーション４１ｃに含まれる処理とをそれぞれ受け付けて、それらの処理を同時期に実行する必要が生じたとき、それぞれの処理の内容に基づき、いずれを優先するべきかを決定する機能を有する。さらに、ドメイン抽象化層４４は、決定された優先順位に従い、優先順位が高い処理から、その処理の実行に必要なリソースを確保して、該当する処理に割り付ける機能を有する。ドメイン抽象化層４４に関しては、後に詳細に説明する。

ＥＣＵ抽象化層４５は、ドメイン抽象化層４４の上位に位置しており、マスタＥＣＵ４０の基本コンポーネントを抽象化することにより、上位のソフトウエア層を、マスタＥＣＵ４０のハードウエアから独立させるものである。このＥＣＵ抽象化層４５は、搭載機器抽象化、メモリハードウエア抽象化、通信ハードウエア抽象化、Ｉ／Ｏハードウエア抽象化などを含む。

サービス層４６は、その一部が、ＥＣＵ抽象化層４５の上位に位置し、アプリケーションのための基本的なサービスを提供するためのものである。具体的には、サービス層４６は、ＯＳ、車両ネットワークの通信と管理、メモリサービス、診断サービス、ＥＣＵ状態管理などのサービスを提供する。このサービス層４６は、大部分がハードウエアから独立しているが、ＯＳなどマイクロコントローラ４８に依存する部分も有している。

複合ドライバ４７は、複雑なセンサやアクチュエータを操作するための特殊な機能やタイミング要求を満たすような、他のレイヤにはない複雑な機能が必要な場合に使用されるものである。この複合ドライバ４７は、例えば、燃料を噴射するインジェクタを駆動制御する場合などに使用される。

そして、ＲＴＥ４２は、上述した各層からなる基本ソフトウエア４３〜４７の上位に位置し、アプリケーション層４１に含まれる各種のアプリケーション４１ａ〜４１ｃが、マスタＥＣＵ４０に依存しないようにするためのものである。そのため、ＲＴＥ４２は、アプリケーション４１ａ〜４１ｃ間の通信や、アプリケーション４１ａ〜４１ｃと基本ソフトウエア４３〜４７との通信を提供する。

このように、ＡＵＴＯＳＡＲに準拠したソフトウエア構造を採用することで、アプリケーション４１ａ〜４１ｃは、マイクロコントローラ４８やマスタＥＣＵ４０のハードウエアに依存せずに済むので、アプリケーション４１ａ〜４１ｃの再利用性を高めることができる。

次に、ドメイン抽象化層４４について、詳しく説明する。図２、図３に示すように、ドメイン抽象化層４４は、ドメイン間抽象化層４４ａとドメイン内抽象化層４４ｂとを有している。ドメイン間抽象化層４４ａは、ドメイン間連携制御用アプリケーション４１ａからの処理要求を受け付ける。また、ドメイン内抽象化層４４ｂは、ドメイン内連携制御用アプリケーション４１ｂからの処理要求を受け付ける。一方、単独制御用アプリケーション４１ｃからの処理要求は、従来通り、サービス層４６、ＥＣＵ抽象化層４５を介して、ドメイン抽象化層４４に与えられる。

このように、ドメイン抽象化層４４は、これらのアプリケーション４１ａ〜４１ｃからの処理要求を受け付けて、マイクロコントローラ抽象化層４３に対して、各処理へのマイクロコントローラ４８のリソース（マイクロプロセッシングユニット、キャッシュメモリなど）の割り付けを指示する。具体的には、単一のアプリケーション４１ａ〜４１ｃのみから処理要求を受け付けた場合、ドメイン抽象化層４４は、その要求を受け付けた処理の実行に必要なリソースの割合を決定し、その決定した割合のリソースを、該当する処理に割り付けるよう、マイクロコントローラ抽象化層４３に指示する。また、複数の種類のアプリケーション４１ａ〜４１ｃから同時期に処理要求を受け付けた場合には、ドメイン抽象化層４４は、まず、それぞれの処理の内容に基づき、いずれを優先するべきかを決定する、次いで、ドメイン抽象化層４４は、決定された優先順位に従い、優先順位が高い処理から順番に、該当する処理の実行に必要なリソースの割合を決定して、その決定した割合のリソースを、該当する処理に割り付けるよう、マイクロコントローラ抽象化層４３に指示する。

この際、ドメイン抽象化層４４は、相対的に優先順位が低い処理の実行に必要なリソースの割合を決定したときに、その優先順位が低い処理を実行するために必要なリソースが残されていないと判断した場合には、リソースが利用可能となるまで、マイクロコントローラ抽象化層４３にリソースの割り付けの指示を行わない。このため、相対的に優先順位が高い処理に多くのリソースが必要で、その結果、相対的に優先順位が低い処理についてリソース不足が発生した場合には、リソースが利用可能となるまで、相対的に優先順位が低い処理の実行が待機される。あるいは、相対的に重要度の低い処理が既に実行開始されている場合には、その実行が一時中断される。

さらに、ドメイン抽象化層４４は、相対的に優先順位の低い処理についてリソース不足が判明した時点で、その優先順位の低い処理を、より少ないリソースにて処理可能なサブ処理に分割し、その分割したサブ処理に対してリソースを確保して割り付けるようにしても良い。

ここで、ドメイン抽象化層４４による、各処理に対するリソースの割り振りについて説明する。ドメイン抽象化層４４は、例えば、該当する処理を実行するために必要なリソースの割合を、単位時間におけるマイクロプロセッシングユニットの使用時間を示す使用率によって定めることができる。つまり、キャッシュメモリの使用容量は、マイクロプロセッシングユニットの使用率と相関する傾向にあるため、マイクロプロセッシングユニット及びキャッシュメモリ含むリソースについて、マイクロプロセッシングユニットの使用率から、該当処理の実行に必要なリソースの割合を定めることができる。あるいは、ドメイン抽象化層４４は、マイクロプロセッシングユニットと、キャッシュメモリとで別個に定めても良い。この場合、例えば、該当する処理を実行するために必要なリソース割合を、マイクロプロセッシングユニットに関しては見込まれる使用率によって定め、キャッシュメモリに関しては見込まれる使用容量によって定めることができる。

そして、相対的に優先順位が低い処理を実行するために必要なリソースが残されているか否かは、少なくともマイクロプロセッシングユニットに関しては、単位時間におけるマイクロプロセッシングユニットの未使用率と、相対的に優先順位が低い処理によるマイクロプロセッシングユニットの見込み使用率とに基づいて判断することができる。

また、マイクロコントローラ４８が、複数のマイクロプロセッシングユニットを含む場合には、ドメイン抽象化層４４は、相対的に優先順位が低い処理を実行するために必要なリソースが残されているか否かを、処理が割り付けられていないマイクロプロセッシングユニットが残されているか否かに基づき判断するようにしても良い。

次に、ドメイン抽象化層４４における具体的な処理内容について、図４及び図５のフローチャートを参照して説明する。

まず、図４のフローチャートのステップＳ１００では、各種のアプリケーション４１ａ〜４１ｃからの処理要求を受け付ける。続くステップＳ１１０では、受け付けた処理要求が複数種類のアプリケーション４１ａ〜４１ｃからによるものであるか否かを判定する。ステップＳ１１０において、複数種類のアプリケーション４１ａ〜４１ｃから処理要求を受け付けたと判定した場合には、ステップＳ１２０の処理に進み、単一のアプリケーション４１ａ〜４１ｃから処理要求を受け付けた又は処理要求の受付は無かったと判定した場合には、ステップＳ１４０の処理に進む。

ステップＳ１２０では、複数種類のアプリケーション４１ａ〜４１ｃから受け付けた各処理の内容に基づいて、各処理の優先順位を決定する。この優先順位の決定方法は、後に、図５のフローチャートに基づき詳細に説明する。続くステップＳ１３０では、決定された優先順位に従い、優先順位が高い処理から順番に、該当する処理の実行に必要なリソースを割り付ける。その実行後、処理は、再びステップＳ１００に戻る。これにより、マイクロコントローラ４８において、割り付けられたリソースを用いて、該当する処理が実行される。

ステップＳ１４０では、ステップＳ１００において、単一のアプリケーション４１ａ〜４１ｃからの処理要求を受け付けたか、それとも、処理要求の受付は無かったかを判定する。この際、単一のアプリケーション４１ａ〜４１ｃから処理要求を受け付けたと判定した場合には、ステップＳ１５０に進み、該当する処理の実行に必要なリソースの割合を決定し、その決定した割合のリソースを、該当する処理に割り付ける。これにより、マイクロコントローラ４８において、割り付けられたリソースを用いて、該当する処理が実行される。一方、ステップＳ１４０において、処理要求の受付は無かったと判定した場合には、ステップＳ１００の処理に戻る。

次に、図５のフローチャートに基づき、複数種類のアプリケーション４１ａ〜４１ｃから同時期に処理要求を受け付けた場合における、各処理の優先順位の決定方法について説明する。

まず、ステップＳ２００では、複数種類のアプリケーション４１ａ〜４１ｃから受け付けた処理要求に、単独制御用アプリケーション４１ｃからの処理要求が含まれているか否かを判定する。この判定処理において、単独制御用アプリケーション４１ｃからの処理要求が含まれていると判定した場合には、ステップＳ２４０の処理に進み、単独制御用アプリケーション４１ｃからの処理要求が含まれていないと判定した場合には、ステップＳ２１０の処理に進む。

ステップＳ２１０に処理が進んだ場合、複数の処理要求は、ドメイン間連携制御用アプリケーション４１ａからの処理要求と、ドメイン内連携制御用アプリケーション４１ｂからの処理要求とを含んでいる。ステップＳ２１０では、ドメイン内連携制御用アプリケーション４１ｂから要求された処理が、即時に実行することが必要な処理であるか否かを判定する。例えば、本実施形態に係る電子制御装置が、図１のＰＴＣ２２に適用された場合、ＰＴＣ２２が、エンジン３１が所定回転角度変化する毎に、エンジン制御部２４に対して、制御目標値を指示するドメイン内連携処理を実施する場合がある。このような場合、ＰＴＣ２２は、エンジンの回転角度変化に応答して、遅滞なく、制御目標値を出力する必要があるので、ＰＴＣは、このドメイン内連携処理を最優先で処理する必要がある。また、例えば、エンジン３１の回転角度に応じたトルク変動を抑制するためのトルク補正をＭＧ３３に発生させる場合も、ＰＴＣ２２は、エンジン回転角度に応じて遅滞無くＭＧＣ２３に対してトルク補正量を指示するドメイン内連携処理を実施する必要がある。ステップＳ２１０では、ドメイン内連携制御用アプリケーション４１ｂの処理が、このような即時に実行する必要がある処理であるか否かを判定する。そして、即時に実行する必要がある処理と判定した場合にはステップＳ２２０の処理に進み、即時に実行する必要がある処理ではないと判定した場合にはステップＳ２３０の処理に進む。

ステップＳ２２０では、ドメイン内連携制御用アプリケーション４１ｂの処理に最も高い優先順位を付与する。そして、ドメイン間連携制御用アプリケーション４１ａの処理に対して、ドメイン内連携制御用アプリケーション４１ｂよりも低い優先順位を付与する。一方、ステップＳ２３０では、ドメイン間連携制御用アプリケーション４１ａの処理に最も高い優先順位を付与する。そして、ドメイン内連携制御用アプリケーション４１ｂの処理に対しては、ドメイン間連携制御用アプリケーション４１ａよりも低い優先順位を付与する。

このように、ドメイン間連携制御用アプリケーション４１ａの処理と、ドメイン内連携制御用アプリケーション４１ｂの処理とに関しては、原則として、ドメイン間連携制御用アプリケーション４１ａの処理に対して、より高い優先順位を付与する。上述したように、ドメイン間連携制御用アプリケーション４１ａの処理の結果として、それぞれのドメイン１０、２０に割り当てられた車載装置３１〜３５の制御目標値が決定される。このため、時々刻々と変化する車両の状況に応じた適切な制御を行うためには、ドメイン内連携制御用アプリケーション４１ｂの処理よりも、ドメイン間連携制御用アプリケーション４１ａの処理を優先して行うべきだからである。

ただし、ドメイン内連携制御用アプリケーション４１ｂの処理には、上述したように、即時に実行することが必要な処理が含まれることがある。このように即時に実行することが必要な処理に関しては、ドメイン間連携制御用アプリケーション４１ａの処理よりも優先して実行することが望ましい。そのため、本実施形態では、ドメイン内連携制御用アプリケーション４１ｂの処理が、即時に実行することが必要な処理であるか否かを判定する。そして、即時に実行することが必要な処理と判定したときに限り、ドメイン内連携制御用アプリケーション４１ｂの処理の優先順位を、ドメイン間連携制御用アプリケーション４１ａの優先順位よりも高くしているのである。

一方、複数種類のアプリケーション４１ａ〜４１ｃから受け付けた処理要求に、単独制御用アプリケーション４１ｃからの処理要求が含まれていると判定した場合に実行されるステップＳ２４０では、単独制御用アプリケーション４１ｃから要求された処理が、割込みにて実行することが必要な割込処理や、ある事象に同期して実行することが必要な同期処理であるか否かを判定する。例えば、図１に示す例では、上述したように、ＰＴＣ２２は、冷却水温度、エンジン温度及びインバータ温度に基づき、冷却機構３０のポンプ及び流路切換弁を制御する。この場合、例えば、エンジン温度或いはインバータ温度が所定の上限温度を超えたことが検出された場合、ＰＴＣ２２は、それ以上の温度上昇を防ぐため、即座に、その上限温度を超えた装置を対象として、最大の流量にて冷却水を循環させるようポンプ及び流路切換弁を制御する。また、例えば、温度センサ、ポンプ、流路切換弁の異常を検出した場合なども、ＰＴＣ２２は、即座に、その異常の発生を運転者に報知するとともに、他の制御部に対して、温度上昇を抑制するため、退避走行や、出力制限などを指示する。これらの処理は、異常発生時において、最優先で処理すべきものであるため、割込処理や同期処理として実行される。ステップＳ２４０において、単独制御用アプリケーション４１ｃの処理が、割込処理又は同期処理であると判定した場合には、ステップＳ２５０の処理に進む。一方、単独制御用アプリケーション４１ｃの処理が、割込処理又は同期処理ではないと判定した場合には、ステップＳ２７０に進む。

ステップＳ２５０では、単独制御用アプリケーション４１ｃに加え、ドメイン間連携制御用アプリケーション４１ａとドメイン内連携制御用アプリケーション４１ｂとの両方からも処理要求を受け付けたか否かを判定する。ステップＳ２５０において、ドメイン間連携制御用アプリケーション４１ａとドメイン内連携制御用アプリケーション４１ｂとの両方から処理要求を受け付けたと判定した場合、ステップＳ２９０の処理に進む。一方、いずれか一方のみから処理要求を受け付けたと判定した場合、ステップＳ２６０の処理に進む。

ステップＳ２６０では、単独制御用アプリケーション４１ｃの処理に最も高い優先順位を付与する。また、処理要求を受け付けたドメイン間連携制御用アプリケーション４１ａとドメイン内連携制御用アプリケーション４１ｂとの一方の処理に対しては、それよりも低い優先順位を付与する。上述したように、単独制御用アプリケーション４１ｃの処理が、例えば異常発生時の処理として、最優先で実行されることが望ましいためである。

ステップＳ２９０では、ステップＳ２１０の処理と同様に、ドメイン内連携制御用アプリケーション４１ｂの処理が、即時に実行することが必要な処理であるか否かを判定する。この判定処理において、ドメイン内連携制御用アプリケーション４１ｂの処理が、即時に実行することが必要な処理であると判定した場合、ステップＳ３００の処理に進む。一方、即時に実行することが必要な処理ではないと判定した場合、ステップＳ３１０の処理に進む。

ステップＳ３００では、単独制御用アプリケーション４１ｃの処理に最も高い優先順位を付与する。ドメイン内連携制御用アプリケーション４１ｂの処理に次に高い優先順位を付与する。そして、ドメイン間連携制御用アプリケーション４１ａの処理に対して、最も低い優先順位を付与する。一方、ステップＳ３１０では、単独制御用アプリケーション４１ｃの処理に最も高い優先順位を付与する。ドメイン間連携制御用アプリケーション４１ａの処理に次に高い優先順位を付与する。そして、ドメイン内連携制御用アプリケーション４１ｂの処理に対して、最も低い優先順位を付与する。

ステップＳ３００、Ｓ３１０の優先順位付けの理由は、以下の通りである。まず、単独制御用アプリケーション４１ｃの処理に最も高い優先順位を付与する理由は、単独制御用アプリケーション４１ｃの処理が、異常発生時の処理として、最優先で実行されることが望ましいためである。また、ドメイン内連携制御用アプリケーション４１ｂの処理が即時に実行することが必要な処理である場合、ドメイン間連携制御用アプリケーション４１ａの処理よりも優先されることが望ましい。そのため、ステップＳ３００では、ドメイン内連携制御用アプリケーション４１ｂの処理の優先順位を、ドメイン間連携制御用アプリケーション４１ａよりも高くしている。一方、ドメイン内連携制御用アプリケーション４１ｂの処理が、即時に実行することが必要な処理以外の処理である場合には、ドメイン間連携制御用アプリケーション４１ａの処理を優先することが望ましい。そのため、ステップＳ３１０では、ドメイン間連携制御用アプリケーション４１ａの処理の優先順位を、ドメイン内連携制御用アプリケーション４１ｂよりも高くしている。

一方、単独制御用アプリケーション４１ｃの処理が、割込処理又は同期処理ではないと判定した場合に実行されるステップＳ２７０では、ステップＳ２５０と同様に、単独制御用アプリケーション４１ｃに加え、ドメイン間連携制御用アプリケーション４１ａとドメイン内連携制御用アプリケーション４１ｂとの両方から処理要求を受け付けたか否かを判定する。ステップＳ２７０において、ドメイン間連携制御用アプリケーション４１ａとドメイン内連携制御用アプリケーション４１ｂとの両方から処理要求を受け付けたと判定した場合、ステップＳ３２０の処理に進む。一方、いずれか一方のみから処理要求を受け付けたと判定した場合、ステップＳ２８０の処理に進む。

ステップＳ２８０では、処理要求を受け付けたドメイン間連携制御用アプリケーション４１ａとドメイン内連携制御用アプリケーション４１ｂとの一方の処理に最も高い優先順位を付与する。そして、単独制御用アプリケーション４１ｃの処理に、それよりも低い優先順位を付与する。

ステップＳ３２０でも、ステップＳ２１０及びＳ２９０の処理と同様に、ドメイン内連携制御用アプリケーション４１ｂの処理が、即時に実行することが必要な処理であるか否かを判定する。この判定処理において、ドメイン内連携制御用アプリケーション４１ｂの処理が、即時に実行することが必要な処理であると判定した場合、ステップＳ３３０の処理に進む。一方、即時に実行することが必要な処理ではないと判定した場合、ステップＳ３４０の処理に進む。

ステップＳ３３０では、ドメイン内連携制御用アプリケーション４１ｂの処理に最も高い優先順位を付与する。ドメイン間連携制御用アプリケーション４１ａの処理に次に高い優先順位を付与する。そして、単独制御用アプリケーション４１ｃの処理に最も低い優先順位を付与する。一方、ステップＳ３４０では、ドメイン間連携制御用アプリケーション４１ａの処理に最も高い優先順位を付与する。ドメイン内連携制御用アプリケーション４１ｂの処理に次に高い優先順位を付与する。そして、単独制御用アプリケーション４１ｃの処理に、最も低い優先順位を付与する。

ステップＳ３３０、Ｓ３４０の優先順位付けの理由は、以下の通りである。まず、単独制御用アプリケーション４１ｃの処理が、異常発生時の処理として、最優先で実行される割込処理や同期処理以外の処理である場合、通常、その実行に、高い応答性は求められない。そのため、ステップＳ３３０、Ｓ３４０では、単独制御用アプリケーション４１ｃの処理に最も低い優先順位を付与している。また、ドメイン内連携制御用アプリケーション４１ｂの処理が即時に実行することが必要な処理である場合、ドメイン間連携制御用アプリケーション４１ａの処理よりも優先されることが望ましい。そのため、ステップＳ３３０では、ドメイン内連携制御用アプリケーション４１ｂの処理の優先順位を最上位にしている。一方、ドメイン内連携制御用アプリケーション４１ｂの処理が、即時に実行することが必要な処理以外の処理である場合には、ドメイン間連携制御用アプリケーション４１ａの処理を優先することが望ましい。そのため、ステップＳ３４０では、ドメイン間連携制御用アプリケーション４１ａの処理の優先順位を最上位にしている。

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

例えば、上述した実施形態では、マスタＥＣＵ４０に、ドメイン抽象化層４４を設け、このドメイン抽象化層４４において、複数種類のアプリケーション４１ａ〜４１ｃから同時期に処理要求を受け付けた場合に、各処理の優先順位の決定、及びマイクロコントローラ４８のリソースの割り付けを行った。しかしながら、図６に示すように、ドメイン抽象化層４４ではなく、サービス層４６のオペレーティングシステムを用いて、各処理の優先順位の決定、及びマイクロコントローラ４８のリソースの割り付けを行うことも可能である。

以下、サービス層４６のオペレーティングシステムによって、優先順位の決定及びリソースの割り付けを行う場合の一例を、図６に基づき説明する。図６に示すように、サービス層４６には、オペレーティングシステムとして、マイクロプロセッシングユニット毎に設けられ、各マイクロプロセッシングユニットにおける処理をスケジューリングする個別オペレーティングシステム４６ｃ、４６ｅと、個別オペレーティングシステム４６ｃ、４６ｅの処理を統括する統合オペレーティングシステム４６ａを有する。

このような構成において、統合オペレーティングシステム４６ａが、各処理の優先順位を決定し、その決定した各処理の優先順位に基づき、各個別オペレーティングシステムに対して実行すべき処理を指示することにより、上述した実施形態と同様の作用効果を奏することができる。

なお、図６において、統合ステートマネージャ４６ｂは、統合オペレーティングシステム４６ａの起動、停止を制御し、個別ステートマネージャ４６ｄ，４６ｆは、個別オペレーティングシステム４６ｃ、４６ｅの起動、停止を制御する。

また、サービス層４６のオペレーティングシステムと、ドメイン抽象化層４４とが協働して、各処理の優先順位の決定及びリソースの割り付けを行うように構成することも可能である。この場合、オペレーティングシステムとドメイン抽象化層４４とに、図４及び図５のフローチャートに示した各機能を、適宜、割り振れば良い。例えば、ドメイン抽象化層４４が、優先順位の高い処理に対してリソースを割り付けた場合におけるマイクロプロセッシングユニットの未使用率を算出する。そして、オペレーティングシステムが、その未使用率と、次に優先順位が低い処理の見込使用率とに基づいて、当該優先順位の低い処理の実行に必要なリソースが確保可能か否かを判定するようにしても良い。

より具体的な例を説明すると、例えば、優先順位の高い処理を、複数のマイクロプロセッシングユニットに分散させて処理する場合、１つのマイクロプロセッシングユニットにおける処理結果を、他のマイクロプロセッシングユニットにおける処理に用いることもあり得る。この場合、マイクロプロセッシングユニット間で処理結果の受渡しが必要になり、他のマイクロプロセッシングユニットにおける待ち時間発生の原因にもなる。このようなマイクロプロセッシングユニットにおける待ち時間（未使用率）をドメイン抽象化層４４にて把握する。ドメイン抽象化層４４は、マイクロプロセッシングユニットの待ち時間（未使用率）を簡単に把握することができる。そして、オペレーティングシステムにより、優先順位が低い処理が、そのマイクロプロセッシングユニットにおける待ち時間（未使用率）に収まるかどうかを判定する。オペレーティングシステムは、このような判定処理を簡単に行うことができる。このようにすれば、ドメイン抽象化層４４とオペレーティングシステムとの特徴を活かしつつ、各処理の優先順位の決定及びリソースの割り付けを行うことが可能となる。

また、上述した実施形態では、制御システム１が複数のドメイン１０、２０に区分された例について説明したが、制御システム１は、必ずしも複数のドメイン１０、２０に区分されたものである必要はない。単一のドメインしか有さない場合、ドメイン間連携制御用アプリケーション４１ａは設けられないため、マスタＥＣＵ４０は、ドメイン内連携制御用アプリケーション４１ｂの処理と、単独制御用アプリケーション４１ｃの処理との優先順位付け、及びリソースの割り付けを行うことになる。

１ 制御システム、１１ 運動ドメイン制御部、１２ 車両挙動制御部、１３ 前後挙動制御部、１４ 左右挙動制御部、１５ ブレーキ制御部、１６ ステアリング制御部、２１ エネルギードメイン制御部、２２ パワートレインコーディネータ、２３ モータジェネレータコーディネータ、２４ エンジン制御部、２５ ＴＭ制御部、２６ ＭＧ制御部、３０ 冷却機構、３１ エンジン、３２ トランスミッション、３３ モータジェネレータ、３４ ブレーキ装置、３５ ステアリング装置

Claims (13)

1. アプリケーションソフトを記憶する記憶部（４１）と、
   前記アプリケーションソフトには、他の電子制御装置と連携した制御を行うための連携制御用アプリケーション（４１ａ、４１ｂ）と、前記他の電子制御装置とは独立して、単独で制御を行うための単独制御用アプリケーション（４１ｃ）とが含まれており、
   前記連携制御用アプリケーションに含まれる処理及び前記単独制御用アプリケーションに含まれる処理をそれぞれ実行するものであり、リソースとして、少なくともマイクロプロセッシングユニットを備えたマイクロコントローラ（４８）と、
   前記連携制御用アプリケーションに含まれる処理と、前記単独制御用アプリケーションに含まれる処理とを同時期に実行する必要が生じたとき、それぞれの処理の内容に基づき、いずれを優先するべきかを決定する決定部（Ｓ１２０）と、
   前記決定部によって決定された優先順位に従い、優先順位が高い処理から、その処理の実行に必要な前記リソースを確保して、該当する処理に割り付けるリソース割付部（Ｓ１３０）と、を備える電子制御装置。
2. 前記リソース割付部は、単位時間における前記マイクロプロセッシングユニットの未使用率と、優先順位が低い処理の見込使用率とに基づいて、当該優先順位の低い処理の実行に必要な前記リソースが確保可能か否かを判定する請求項１に記載の電子制御装置。
3. 前記マイクロコントローラは、複数のマイクロプロセッシングユニットを含み、
   前記リソース割付部は、処理が割り付けられていないマイクロプロセッシングユニットが残されているか否かに基づき、優先順位が低い処理の実行に必要な前記リソースが確保可能か否かを判定する請求項１に記載の電子制御装置。
4. 前記リソース割付部により前記リソースが確保できない処理は、前記リソースが利用可能となるまで、実行が待機される請求項２又は３に記載の電子制御装置。
5. 前記リソース割付部は、前記リソースが確保できない処理を、より少ないリソースにて処理可能なサブ処理に分割し、その分割したサブ処理に対して前記リソースを確保して割りつける請求項２に記載の電子制御装置。
6. ソフトウエア構造として、
   前記電子制御装置の基本動作を実現する基本ソフトウエア（４３〜４７）と、当該基本ソフトウエアと前記アプリケーションソフト間の通信を提供するランタイム環境（４２）とを有し、
   前記基本ソフトウエアは、前記マイクロコントローラを抽象化するマイクロコントローラ抽象化層（４３）と、前記マイクロコントローラ抽象化層の上位に位置付けられ、前記電子制御装置の基本コンポーネントを抽象化するＥＣＵ抽象化層（４５）と、オペレーティングシステムを含むサービス層（４６）とを含み、
   前記マイクロコントローラ抽象化層とＥＣＵ抽象化層との間に、前記決定部及び前記リソース割付部として機能するドメイン抽象化層（４４）を設けた請求項１乃至５のいずれかに記載の電子制御装置。
7. ソフトウエア構造として、
   前記電子制御装置の基本動作を実現する基本ソフトウエア（４３〜４７）と、当該基本ソフトウエアと前記アプリケーションソフト間の通信を提供するランタイム環境（４２）とを有し、
   前記基本ソフトウエアは、前記マイクロコントローラを抽象化するマイクロコントローラ抽象化層（４３）と、前記マイクロコントローラ抽象化層の上位に位置付けられ、前記電子制御装置の基本コンポーネントを抽象化するＥＣＵ抽象化層（４５）と、オペレーティングシステムを含むサービス層（４６）とを含み、
   前記マイクロコントローラ抽象化層とＥＣＵ抽象化層との間に、前記決定部及び前記リソース割付部として機能するドメイン抽象化層（４４）を設け、
   前記ドメイン抽象化層は、優先順位の高い処理に対して前記リソースを割り付けた場合における前記マイクロプロセッシングユニットの未使用率を算出し、前記オペレーティングシステムが、その未使用率と、優先順位が低い処理の見込使用率とに基づいて、当該優先順位の低い処理の実行に必要な前記リソースが確保可能か否かを判定することで、前記ドメイン抽象化層および前記オペレーティングシステムが協働して前記リソース割付部として機能する請求項２に記載の電子制御装置。
8. ソフトウエア構造として、
   前記電子制御装置の基本動作を実現する基本ソフトウエア（４３〜４７）と、当該基本ソフトウエアと前記アプリケーションソフト間の通信を提供するランタイム環境（４２）とを有し、
   前記基本ソフトウエアは、前記マイクロコントローラを抽象化するマイクロコントローラ抽象化層（４３）と、前記電子制御装置の基本コンポーネントを抽象化するＥＣＵ抽象化層（４５）と、オペレーティングシステム（４６ａ、４６ｃ、４６ｅ）を含むサービス層（４６）とを含み、
   前記サービス層のオペレーティングシステムが、前記決定部及び前記リソース割付部としての機能を含む請求項１乃至５のいずれかに記載の電子制御装置。
9. 前記オペレーティングシステムは、前記マイクロプロセッシングユニット毎に設けられ、各マイクロプロセッシングユニットにおける処理をスケジューリングする個別オペレーティングシステム（４６ｃ、４６ｅ）と、前記個別オペレーティングシステムの処理を統括する統合オペレーティングシステム（４６ａ）とを有し、
   統合オペレーティングシステムが、各処理の優先順位に基づき、前記個別オペレーティングシステムに対して実行すべき処理を指示する請求項８に記載の電子制御装置。
10. 前記電子制御装置は、車両に搭載された複数の車載装置（３０〜３５）を制御する制御システム（１）に適用されるものであり、
    前記制御システムは、前記複数の車載装置の機能に応じて予め複数のドメイン（１０、２０）に区分けされ、それら複数のドメインにおいて、それぞれ、前記車載装置を制御するためのスレーブＥＣＵ（１５、１６、２４〜２６）と、前記スレーブＥＣＵを統括するマスタＥＣＵ（１３，１４、２２、２３）とに階層化され、
    前記電子制御装置は、各ドメインのマスタＥＣＵとして利用されるものである請求項１乃至９のいずれかに記載の電子制御装置。
11. 前記連携制御用アプリケーションは、同じドメインに属するスレーブＥＣＵへの制御指令値を作成して出力するためのドメイン内連携制御用アプリケーション（４１ｂ）と、異なるドメインに属するマスタＥＣＵとの間で協調制御を行うためのドメイン間連携制御用アプリケーション（４１ａ）とを含み、
    前記決定部は、前記ドメイン内連携制御用アプリケーションに含まれる処理と、前記ドメイン間連携制御用アプリケーションに含まれる処理とを同時期に実行する必要が生じたとき、前記ドメイン内連携制御用アプリケーションに含まれる処理が即時に実行することが必要な種類の処理以外の場合、前記ドメイン間連携制御用アプリケーションに含まれる処理を優先すべきと決定する請求項１０に記載の電子制御装置。
12. 前記決定部は、前記ドメイン内連携制御用アプリケーションに含まれる処理が、即時に実行することが必要な種類の処理である場合には、前記ドメイン内連携制御用アプリケーションに含まれる処理を優先すべきと決定する請求項１１に記載の電子制御装置。
13. 前記単独制御用アプリケーションは、割込み処理と同期処理との少なくとも一方の処理を含み、
    前記決定部は、前記単独制御用アプリケーションに含まれる処理と、前記連携制御用アプリケーションに含まれる処理とを同時期に実行する必要が生じたとき、前記単独制御用アプリケーションに含まれる処理が、前記割込み処理又は前記同期処理である場合、前記単独制御用アプリケーションに含まれる処理を優先すべきと決定し、前記割込み処理又は前記同期処理以外の処理である場合、前記連携制御用アプリケーションに含まれる処理を優先すべきと決定する請求項１乃至請求項１２のいずれかに記載の電子制御装置。

Images