JP2017128308A

JP2017128308A - 車両用制御システム

Info

Publication number: JP2017128308A
Application number: JP2016010889A
Authority: JP
Inventors: 敏彦武田; Toshihiko Takeda
Original assignee: Denso Corp
Current assignee: Denso Corp
Priority date: 2016-01-22
Filing date: 2016-01-22
Publication date: 2017-07-27
Anticipated expiration: 2036-01-22
Also published as: DE102017200286B4; JP6504065B2; DE102017200286A1

Abstract

【課題】第１の電子制御装置及び第２の電子制御装置にそれぞれ設けられたＯＳプログラムにより、第１の電子制御装置と第２の電子制御装置との連携処理を効率的にサポートすること。【解決手段】マスターＥＣＵが保有する第１ＯＳプログラムは、スレーブＥＣＵが保有する第２ＯＳプログラムが分担する役割についての情報を取得Ｓ１００し、その第２ＯＳプログラムが分担する役割を示す情報に基づき、当該第２ＯＳプログラムと協調して動作することができるように、第１ＯＳプログラムの分担する役割を決定Ｓ１２０する。従って、例えば、スレーブＥＣＵの能力などに起因して第２ＯＳプログラムの役割分担が変動しても、その役割分担の変動に応じて、第１ＯＳプログラムが、第２ＯＳプログラムと協調して動作することができるように、自動的に、分担する役割を変化させることができる。【選択図】図４

Description

本発明は、車両に搭載された車載機器を制御するために、第１の電子制御装置と第２の電子制御装置とが連携した処理を行う車両用制御システムに関する。

例えば、特許文献１には、階層的に配置された複数の制御ユニットから構成される車載電子機器制御システムについて記載されている。この車載電子機器制御システムは、例えば、リヤデフォッガーとデフロスターとの動作制御に適用される。車載電子機器制御システムは、リヤデフォッガーの基本制御系の制御ユニットＥＣＵ_１１と、その上位に位置付けられる自動化拡張機能系の制御ユニットＥＣＵ_２１とを有する。また、車載電子機器制御システムは、デフロスターの基本制御系の制御ユニットＥＣＵ_１２と、その上位に位置する自動化拡張機能系の制御ユニットＥＣＵ_２２とを有する。さらに、車載電子機器制御システムは、リヤデフォッガーの自動化拡張機能系の制御ユニットＥＣＵ_２１及びデフロスターの自動化拡張機能系の制御ユニットＥＣＵ_２２の上位に位置付けられる、連携制御ユニットＥＣＵ_３１を有している。

このような構成において、リヤデフスイッチがオン操作されると、基本制御系の制御ユニットＥＣＵ_１１がリヤデフォッガーに通電制御する。このとき、自動化拡張機能系の制御ユニットＥＣＵ_２１は、リヤデフォッガーの動作継続時間をタイマー計測し、タイムアップしたときに、リヤデフォッガーをオートオフする自動制御を行う。

また、フロントデフスイッチがオン操作されると、基本制御系の制御ユニットＥＣＵ_２１が、エアコンの吹出しモードとして、デフロスターを選択する。そして、自動化拡張機能系の制御ユニットＥＣＵ_２２は、外気温センサが検出する外気温と、ユーザによるフロントデフスイッチの操作履歴を記録し、窓曇り条件を累積学習する。自動化拡張機能系の制御ユニットＥＣＵ_２２は、次回、検出された外気温が窓曇り条件を充足した場合、フロントデフスイッチが操作されずとも、デフロスターをオートオンする自動制御を行う。

さらに、連携制御ユニットＥＣＵ_３１は、リヤデフォッガーとデフロスターとの動作履歴を記録し、連携動作学習を行う。例えば、デフロスターの動作時に、リヤデフォッガーが一定頻度以上で同時に動作する学習結果となっている場合、デフロスターが動作開始したときに、連携制御ユニットＥＣＵ_３１は、リヤデフォッガーの自動化拡張機能系の制御ユニットＥＣＵ_２１に対し、リヤデフォッガーをオートオンする指令を出力する。

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

上述した特許文献１に記載された車載電子機器制御システムのように、制御システムが複数の電子制御装置（制御ユニット）により構成され、各電子制御装置によって連携した制御が行われることがある。このような連携した制御を行うために、例えば、予め電子制御装置間でやり取りされる信号や処理手順などを厳密に定め、それに応じた連携処理用アプリケーションプログラムを作成したとする。この場合、制御システムが、いわゆる専用品となってしまい、例えば車両のグレードや車種に応じた低機能から高機能までのバリエーションに対応したり、電子制御装置を構成するハードウエアの変更に対応したりすることが困難になってしまう。

そこで、第１の電子制御装置と第２の電子制御装置とが連携した処理を行う場合に、連携処理用アプリケーションの他に、それら連携処理用アプリケーションプログラムを協調して実行させるためのベーシックソフトウエアとしての役割を果たすＯＳプログラムを、第１及び第２の電子制御装置にそれぞれ設けることが考えられる。

例えば、ＯＳプログラムが、各電子制御装置間の通信データの検証、データの変換、同期メカニズム、リソースの配分等をサポートすることにより、第１及び第２の電子制御装置における連携処理用アプリケーションプログラムは、それぞれの制御機能に特化して作成することができ、制御機能の追加、変更などにも容易に対応可能となる。また、各ＯＳプログラムが、各電子制御装置のハードウエアを抽象化することができるので、この点においても、連携処理用アプリケーションの汎用性を高めることができる。

ただし、第１及び第２の電子制御装置による連携処理をサポートするＯＳプログラムを、第１及び第２の電子制御装置にそれぞれ設ける場合、それらのＯＳプログラムは、定められた役割分担の下に協調して動作する必要がある。しかしながら、その役割分担が常に一定であるとすると、例えば、用いられる電子制御装置の能力の相違などに起因して、必ずしもそれぞれの電子制御装置の能力に見合った役割とはならず、連携処理のサポートを効率的に行いえない虞がある。

本発明は、上述した点に鑑みてなされたものであり、第１の電子制御装置及び第２の電子制御装置にそれぞれ設けられたＯＳプログラムにより、第１の電子制御装置と第２の電子制御装置との連携処理を効率的にサポートすることが可能な車両用制御システムを提供することを目的とする。

上記目的を達成するために、本発明による車両用制御システムは、
車両に搭載された車載機器（３１〜３３）を制御するために、第１の電子制御装置（４０）と第２の電子制御装置（６０、７０、８０）とが連携した処理を行うものであって、
第１の電子制御装置と第２の電子制御装置とは、それぞれ、連携処理を行うための連携処理用アプリケーションプログラム（４１ａ、６１ａ、７１ａ、８１ａ）を有するとともに、それら連携処理用アプリケーションプログラムを協調して実行させるためのベーシックソフトウエアとしての役割を果たす、所定の役割分担の下に協調して動作する第１ＯＳプログラム（４１ｂ）と第２ＯＳプログラム（６１ｂ、７１ｂ、８１ｂ）とをそれぞれ有しており、
第２の電子制御装置が保有する第２ＯＳプログラムは、分担する役割が異なる複数の中から選定されたものであり、
第１の電子制御装置が保有する第１ＯＳプログラムは、分担する役割を変更可能に構成され、それにより、分担する役割が異なる複数の中のいずれの第２ＯＳプログラムとも協調した動作を行うことが可能であって、
第１の電子制御装置は、
第２の電子制御装置から、第２ＯＳプログラムが分担する役割についての情報を取得する取得部（Ｓ１００）と、
取得部により取得した、第２ＯＳプログラムが分担する役割を示す情報に基づき、当該第２ＯＳプログラムと協調して動作することができるように、第１ＯＳプログラムの分担する役割を決定する決定部（Ｓ１２０）と、を備える。

このように、本発明による車両用制御システムによれば、第１の電子制御装置が保有する第１ＯＳプログラムは、第２ＯＳプログラムが分担する役割についての情報を取得し、その第２ＯＳプログラムが分担する役割を示す情報に基づき、当該第２ＯＳプログラムと協調して動作することができるように、第１ＯＳプログラムの分担する役割を決定する。従って、例えば、第２の電子制御装置の能力に起因して第２ＯＳプログラムの役割分担が変動しても、その役割分担の変動に応じて、第１ＯＳプログラムが、第２ＯＳプログラムと協調して動作することができるように、自動的に、分担する役割を変化させることができる。その結果、第１の電子制御装置及び第２の電子制御装置に設けられたＯＳプログラムにより、第１の電子制御装置と第２の電子制御装置との連携処理を効率的にサポートすることが可能になる。

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

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

実施形態に係る車両用制御システムの構成を示す構成図である。運動ドメイン制御部のＰＴＣが、電子制御装置にＰＴＣアプリケーションとして実装され、その電子制御装置のアプリケーションソフトの１つとしてＯＳプログラムを設けた例を示す図である。ＯＳプログラムが提供するサービスの一覧の例を示す図である。マスターＥＣＵにおける第１ＯＳプログラムの具体的な処理内容を示すフローチャートである。スレーブＥＣＵにおける第２ＯＳプログラムの具体的な処理内容を示すフローチャートである。マスターＥＣＵの第１ＯＳプログラムの役割を軽くし、スレーブＥＣＵにおける第２ＯＳプログラムの役割を重くした例を示す図である。マスターＥＣＵの第１ＯＳプログラムの役割を重くし、スレーブＥＣＵにおける第２ＯＳプログラムの役割を軽くした例を示す図である。マスターＥＣＵの第１ＯＳプログラムが、第２ＯＳプログラムへの伝達情報の変更が必要と判定するいくつかの例を説明するための説明図である。マスターＥＣＵの第１ＯＳプログラムが、スレーブＥＣＵの第２ＯＳプログラムから動作条件の変更要求を受けるいくつかの例を説明するための説明図である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

上述したように、車両用制御システム１を構成する各論理ブロック１２〜１６、２２〜２６は、複数の論理ブロック１２〜１６、２２〜２６により連携した制御処理を行うことで、各車載機器３１〜３５を制御する。例えば、ＰＴＣ２２は、運動ドメイン１０における前後挙動制御部１３と協調したドメイン間連携制御、及び、ＭＧＣ２３、エンジン制御部２４、並びにＴＭ制御部２５と協調したドメイン内連携制御を実行する。

ここで、上述した車両用制御システム１において、各論理ブロック１２〜１６、２２〜２６が実装される電子制御装置間でやり取りされる信号や処理手順などを厳密に定め、それに応じた連携処理用アプリケーションプログラムを作成することも可能である。しかしながら、この場合、車両用制御システム１が、いわゆる専用品となってしまい、例えば車両のグレードや車種に応じた低機能から高機能までのバリエーションに対応したり、電子制御装置を構成するハードウエアの変更に対応したりすることが困難になってしまう。

そこで、各論理ブロック１２〜１６、２２〜２６が実装される複数の電子制御装置が連携した処理を行う場合に、連携処理用アプリケーションの他に、それら連携処理用アプリケーションプログラムを協調して実行させるためのベーシックソフトウエアとしての役割を果たすＯＳプログラムを、各電子制御装置に設けることが考えられる。

例えば、ＯＳプログラムが、各電子制御装置間における通信データの検証、データの変換、同期メカニズム、リソースの配分等をサポートすることにより、各電子制御装置における連携処理用アプリケーションプログラムは、それぞれの制御機能に特化して作成することができ、制御機能の追加、変更などにも容易に対応可能となる。また、各ＯＳプログラムが、各電子制御装置のハードウエアを抽象化することができるので、この点においても、連携処理用アプリケーションの汎用性を高めることができるようになる。

ただし、各電子制御装置による連携処理をサポートするＯＳプログラムを、各電子制御装置にそれぞれ設ける場合、それらのＯＳプログラムは、定められた役割分担の下に協調して動作する必要がある。しかしながら、その役割分担が常に一定であるとすると、例えば、用いられる電子制御装置の能力の相違に起因して、必ずしもそれぞれの電子制御装置の能力に見合った役割とはならず、連携処理のサポートを効率的に行いえない虞がある。

そこで、本実施形態に係る車両用制御システム１では、各電子制御装置による連携処理をサポートするＯＳプログラムの役割を変更可能に構成した。具体的には、連携した処理を行う少なくとも２つの電子制御装置において、一方をマスターＥＣＵ、他方をスレーブＥＣＵとした場合に、まず、マスターＥＣＵが保有する第１ＯＳプログラムは、スレーブＥＣＵが保有する第２ＯＳプログラムが分担する役割についての情報を取得する。そして、第１ＯＳプログラムは、第２ＯＳプログラムが分担する役割を示す情報に基づき、当該第２ＯＳプログラムと協調して動作することができるように、第１ＯＳプログラムの分担する役割を決定する。従って、例えば、スレーブＥＣＵの能力に起因して第２ＯＳプログラムの役割分担が変動しても、その役割分担の変動に応じて、第１ＯＳプログラムが、第２ＯＳプログラムと協調して動作することができるように、自動的に、分担する役割を変化させることができる。その結果、マスターＥＣＵ及びスレーブＥＣＵに設けられた各ＯＳプログラムにより、マスターＥＣＵとスレーブＥＣＵとの連携処理を効率的にサポートすることが可能になる。

まず、図２を参照して、各電子制御装置にＯＳプログラムを設ける場合の構成の一例を説明するとともに、ＯＳプログラムが連携処理をサポートするために実施する処理内容などの具体例を説明する。

図２は、エネルギードメイン制御部２１のＰＴＣ２２が、電子制御装置４０にＰＴＣアプリケーション４１ａとして実装され、その電子制御装置４０にアプリケーションの１つとしてＯＳプログラム４１ｂを設けた場合の構成を示している。なお、図２には、ＰＴＣ２２と直接的に通信を行って連携処理を実行する論理ブロック（前後挙動制御部１３、ＭＧＣ２３、エンジン制御部２４、ＴＭ制御部２５）として機能するアプリケーション５１ａ、６１ａ、７１ａ、８１ａをそれぞれ実装した電子制御装置５０、６０、７０、８０の構成も示している。これら電子制御装置５０、６０、７０、８０においても、アプリケーションの１つとして、それぞれＯＳプログラム５１ｂ、６１ｂ、７１ｂ、８１ｂが設けられている。

なお、ＰＴＣアプリケーション４１ａ、前後挙動制御アプリケーション５１ａ、ＭＧＣアプリケーション６１ｂ、ＴＭ制御アプリケーション７１ａ、ＥＭＳ制御アプリケーション８１ａが、それぞれ連携処理用アプリケーションに相当する。

また、図２には、各電子制御装置４０、５０、６０、７０、８０が、それぞれ１つのＯＳプログラム４１ｂ、５１ｂ、６１ｂ、７１ｂ、８１ｂを有するように示されているが、各電子制御装置４０、５０、６０、７０、８０は、通信相手毎に、異なるＯＳプログラムを有する。通信相手が異なることにより、連携処理をサポートするために提供すべきサービス内容も異なるためである。例えば、ＰＴＣアプリケーション４１ａが実装された電子制御装置４０は、上位のドメイン制御部である前後挙動制御部１３としての電子制御装置５０との連携処理をサポートするためのＯＳプログラム、同じエネルギードメイン制御部２１に属するＭＧＣ２３としての電子制御装置６０との連携処理をサポートするためのＯＳプログラム、下位の機器制御部であるＴＭ制御部２５としての電子制御装置７０との連携処理をサポートするためのＯＳプログラム、及びエンジン制御部２４としての電子制御装置８０との連携処理をサポートするためのＯＳプログラムをそれぞれ有している。

ただし、ＰＴＣ２２としての電子制御装置４０は、機器制御部に分類されるＴＭ制御部２５、エンジン制御部２４がそれぞれ実装された電子制御装置７０及び電子制御装置８０との連携処理をサポートするためのＯＳプログラムを共通化しても良い。この場合、電子制御装置７０及び電子制御装置８０のＯＳプログラムの役割や動作条件が相違していてもそれらの相違を包含するデータやサービスを提供するように、電子制御装置４０のＯＳプログラムを設定することで、ＯＳプログラムを共通化することができる。

そして、原則として、上位の電子制御装置がマスターＥＣＵとなり、下位の電子制御装置がスレーブＥＣＵとなる。なお、同位の電子制御装置の場合、いずれか一方がマスターＥＣＵとなり、他方がスレーブＥＣＵとなる。

電子制御装置４０〜８０は、それぞれ、メモリを有しており、図２に示す構造のソフトウエアを、それぞれのメモリに記憶している。各電子制御装置４０〜８０は、図２に示すように、いわゆるＡＵＴＯＳＡＲ（AUTomotive Open System ARchitecture）に準拠するソフトウエア構造を有している。そこで、ＰＴＣアプリケーション４１ａを実装した電子制御装置４０を代表例として、各電子制御装置４０〜８０のソフトウエア構造について説明する。

電子制御装置４０では、図２に示すように、ハードウエアであるマイクロコントローラ４７に対して、ソフトウエアが搭載され、そのソフトウエアは、大きくは、基本ソフトウエア４３〜４６、ランタイム環境（ＲＴＥ）４２、及び、アプリケーション層に含まれるアプリケーションソフトウエアに分けられる。その中で、ＰＴＣアプリケーション４１ａは、アプリケーション層に実装され、このＰＴＣアプリケーション４１ａが実行されることにより、電子制御装置４０は、ＰＴＣ２２としての機能を発揮する。ＰＴＣアプリケーション４１ａは、実際には、ＰＴＣ２２としての各種の機能ごとに、複数のサブアプリケーションに分割されている。また、ＯＳプログラム４１ｂも、一つのアプリケーションソフトウエアとして、アプリケーション層に実装されている。

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

マイクロコントローラ抽象化層４３は、基本ソフトウエア４３〜４６の最下層に位置し、マイクロコントローラドライバ、メモリドライバ、通信ドライバ、Ｉ／Ｏドライバなどを有する。このマイクロコントローラ抽象化層４３は、マイクロコントローラ４７のハードウエア構成に依存する部分である。しかし、このマイクロコントローラ抽象化層４３によって、マイクロコントローラ４７とその周辺機器とが抽象化されるため、これより上位の階層は、マイクロコントローラ４７及び周辺機器から独立することになる。なお、マイクロコントローラ抽象化層４３は、通信ドライバとして、複数の種類の通信ドライバ（例えば、ＣＡＮ（登録商標）ドライバ、ＬＩＮドライバ、ＦｌｅｘＲａｙ（登録商標）ドライバなど）を有している。そして、電子制御装置４０は、例えば、通信相手の電子制御装置がドメイン内か、ドメイン外かなどにより、異なる通信ドライバ、すなわち異なる通信ネットワークを使用して通信を行う。

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

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

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

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

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

次に、ＯＳプログラム４１ｂについて、詳しく説明する。図２に示すように、ＯＳプログラム４１ｂは、アプリケーションソフトの１つとして具現化される。このＯＳプログラム４１ｂは、ＰＴＣアプリケーション４１ｂの各サブアプリケーションが、他の電子制御装置５０〜８０と連携した処理を行う際に、その連携処理をサポートするための各種のサービスを提供する。なお、図２に示す例では、現状のＡＵＴＯＳＡＲに準拠した基本ソフトウエアを前提とし、ＥＣＵ間連携を実現するＯＳプログラムは、アプリケーションソフトとして、ＲＴＥを介し基本ソフトウエアと結合されている。しかし、ＯＳプログラムは、アプリケーションソフトとして具現化する以外に、基本ソフトウエア内に組み入れることも可能である。

図３に、ＯＳプログラム４１ｂが提供するサービスの一覧の例を示す。なお、図３においては、ＯＳプログラム４１ｂにより提供される各種のサービスを、ＤＶＦＢ（Domain Virtual Function Bus）、ドメインシステムＯＳ（Domain System OS）、ドメインシステム抽象化（Domain System Abstraction）の３つの階層に分類して示している。ＯＳプログラム４１ｂは、図３に示すサービスの一部を提供するものであっても良いし、逆に、図３に示すサービスは一例であって、図３に示すサービス以外のサービスをも含むものであっても良い。

ＤＶＦＢに分類されるドメイン外内抽象化（Domain External-Internal Abstraction）サービスは、例えば、マスターＥＣＵからスレーブＥＣＵに、連携処理を行うためのデータ（制御目標データやセンサ検出データなど）が送信される場合に、マスターＥＣＵとドメインＥＣＵにおいて実行されるＯＳプログラムの各サービスの処理順を設定したり、そのサービスが実行される時間に関する整合を図ったりするものである。また、ＤＶＦＢに分類される意味解釈ゲートウェイ（Semantic Gateway）サービスは、ドメイン外内にてデータが異なる場合に、対応するデータに翻訳するものである。

ドメインシステムＯＳに分類されるリソース調停（Resource Arbitration）サービスは、例えば、マスターＥＣＵとスレーブＥＣＵとが同じ電子制御装置に実装され、メモリやコアなどのリソースを共用する場合に、そのリソースの配分や調整を行うものである。システムモード（System Mode）サービスは、マスターＥＣＵにおける制御モードと、スレーブＥＣＵにおける制御モードとが整合した制御モードとなるように、モード管理を行うものである。イベント管理（Event Manager）サービスは、例えばマスターＥＣＵとスレーブＥＣＵとで同期した処理を行わせるトリガとなるイベントの生成と配信を行うものである。スケジューラ（Scheduler）サービスは、マスターＥＣＵでの連携処理のスケジュールに基づいて、スレーブＥＣＵでの連携処理のスケジュールを定めるものである。同期メカニズム（Synchronized Mechanism）サービスは、イベントもしくは時間での制御の同期を図るためのものである。クロック（Clock）サービスは、マスターＥＣＵとスレーブＥＣＵとで共通の時刻を生成するとともに、必要に応じて、データにタイムスタンプを行うものである。セキュリティ（Security）サービスは、例えばＩＤデータに基づいて正規の通信相手を認証したり、パリティチェックなどにより通信データの正常性を確認したりするためのものである。診断（Diagnostic）サービスは、例えば、マスターＥＣＵ及びスレーブＥＣＵの異常診断を行うとともに、必要に応じてフェールセーフ処理を実行するものである。安全機能メカニズム（Safety function Mechanism）サービスは、異常が重大である場合に、マスターＥＣＵとスレーブＥＣＵとの連携機能を停止するものである。

ドメインシステム抽象化に分類される機能分散抽象化（Function Distribution Abstraction）サービスは、上述した各種のサービスを実現する上で、マスター側の第１ＯＳプログラムと、スレーブ側の第２ＯＳプログラムとの役割分担の管理を行うものである。つまり、本実施形態では、マスター側の第１ＯＳプログラムとスレーブ側の第２ＯＳプログラムとが協調して動作することにより、上述した各種のサービスを実現する。その際、本実施形態では、マスター側の第１ＯＳプログラムとスレーブ側の第２ＯＳプログラムとの役割を変更可能に構成している。そのため、マスター側の第１ＯＳプログラムとスレーブ側の第２ＯＳプログラムとが、それぞれ、どのような役割を担っているかを管理することが必要となる。支配抽象化（Ownership Abstraction）サービスは、マスター側の第１ＯＳプログラムとスレーブ側の第２ＯＳプログラムとによる、制御対象機器やセンサ機器などに対する制御責任の分担の管理を行うものである。なお、制御責任とは、制御対象機器に対して制御信号を出力したり、センサ機器からの検出信号の受信処理を行ったり、制御対象機器やセンサ機器が正常に動作しているか監視したりする役割を担っていることをいう。

次に、図４及び図５のフローチャートを参照しつつ、マスター側の第１ＯＳプログラムとスレーブ側の第２ＯＳプログラムとが協調して動作可能とするための、設定方法について説明する。なお、第１ＯＳプログラム及び第２ＯＳプログラムの設定は、車両の製造ラインにおいて、車両用制御システムが構築された段階で実施される。また、機能向上のために、マスターＥＣＵやスレーブＥＣＵのアプリケーションソフトウエアが更新された場合にも実施される。

図４のフローチャートは、マスター側の第１ＯＳプログラムによって実行される処理を示し、図５のフローチャートは、スレーブ側の第２ＯＳプログラムによって実行される処理を示している。

まず、図４のフローチャートのステップＳ１００では、スレーブＥＣＵから、スレーブＥＣＵが保有する第２ＯＳプログラムが分担する役割情報を取得する。この役割情報として、マスターＥＣＵは、上述した各種サービスに関して、スレーブＥＣＵの第２ＯＳプログラムが担う役割を示す情報をそれぞれ取得しても良いし、第２ＯＳプログラムに、予め、各種サービスに関する第２ＯＳプログラムの役割の組み合わせを一義的に示す役割パターン情報を保有させておき、その役割パターン情報を取得しても良い。

このように、スレーブＥＣＵが保有する第２ＯＳプログラムは、上述した各種サービスに関して、第２ＯＳプログラムが分担する役割が異なる複数のパターンの中から選定されたものである。このため、車両用制御システムの構成や、スレーブＥＣＵの能力などに応じて、第２ＯＳプログラムの役割を適切に設定することが可能になる。

続くステップＳ１１０では、取得した第２ＯＳプログラムの各種サービスに関する役割が、マスターＥＣＵにおける第１ＯＳプログラムの現状の役割と整合しているか否かを判定する。すなわち、マスターＥＣＵの第１ＯＳプログラムは、平均的な第２ＯＳプログラムの役割に対応するように、予め設定されている。ステップＳ１１０では、このような第１ＯＳプログラムの基本設定で、既に第２ＯＳプログラムの役割に整合しているか否かを判定する。このようにすれば、続くステップＳ１２０での第１ＯＳプログラムの変更量を抑えることが可能になる。ただし、第１ＯＳプログラムを事前に設定せずに、取得した第２ＯＳプログラムに対応するように、すべてのサービス項目について、設定するようにしても良い。その場合、ステップＳ１１０の処理は省略可能である。

ステップＳ１２０では、各種サービスに関する第２ＯＳプログラムの役割と整合するように、第１ＯＳプログラムの役割を変更する。この際、第２ＯＳプログラムの役割と整合していないサービス項目に関してのみ、第１ＯＳプログラムの役割を変更すれば良いので、第１ＯＳプログラムの変更処理を簡便に行うことができる。

ここで、第１ＯＳプログラムと第２ＯＳプログラムとの役割が、各サービス項目に関して、どのように変化するかに関して、典型例を２例ほど示す。

図６は、マスターＥＣＵの第１ＯＳプログラムの役割を軽くし、スレーブＥＣＵにおける第２ＯＳプログラムの役割を重くした例を示している。

この場合、ドメイン外内抽象化サービスについて、マスターＥＣＵの第１ＯＳプログラムは、スレーブＥＣＵの第２ＯＳプログラムによる各サービスの処理順処理時間の設定には関与せず、スレーブＥＣＵの第２ＯＳプログラムが、当該第２ＯＳプログラムによるサービスの処理順や処理時間の設定を行う。また、意味解釈ゲートウェイサービスに関しては、マスターＥＣＵから送信されるデータの意味翻訳を、第２ＯＳプログラムにおいて実行する。

リソース調停サービスに関しては、マスターＥＣＵにおける連携処理を優先して実行するために、第１ＯＳプログラムが、その連携処理のためのリソースを確保する処理を行うが、残りリソースの利用調整は、第２ＯＳプログラムにおいて行う。システムモードサービスに関しては、第１ＯＳプログラムが連携処理のモードを生成し、第２ＯＳプログラムは、その連携処理モードを受信し、対応するローカルモードへの変換を行い、スレーブＥＣＵの制御モードを、変換したローカルモードに設定する。

イベント管理サービスに関しては、第１ＯＳプログラムは、連携処理に用いる連携イベントを生成するとともに、スレーブＥＣＵに配信する。そして、第２ＯＳプログラムは、配信された連携イベントを、スレーブＥＣＵにおいて取り扱うことが可能なローカルイベントに変換する。スケジューラサービスに関しては、第１ＯＳプログラムが連携処理のスケジュールを生成し、第２ＯＳプログラムが、その連携処理スケジュールをスレーブＥＣＵにおけるローカルスケジュールに変換する。同期メカニズムサービスに関しては、第１ＯＳプログラムが、同期手段として、所定のイベントによる同期指示を選択した場合、その所定のイベントによる同期を実現するための実現機能を第２ＯＳプログラムが選択する。例えば、第２ＯＳプログラムは、イベント管理サービスがローカルイベントを生成している場合には、そのローカルイベントを同期手段として選択する。

クロックサービスに関しては、第１ＯＳプログラムが連携時刻を生成し、第２ＯＳプログラムが、その連携時刻をスレーブＥＣＵにおけるローカル時刻に変換する。セキュリティサービスに関しては、第１ＯＳプログラムが、マスターＥＣＵの通信相手の認証と、受信データの正常性の確認を行い、第２ＯＳプログラムが、スレーブＥＣＵの通信相手の認証と、受信データの正常性の確認を行う。診断サービスに関しては、第１ＯＳプログラムが、マスターＥＣＵにおける連携処理の異常検知と、異常時のフェールセーフ処理を行い、第２ＯＳプログラムが、スレーブＥＣＵにおける連携処理の異常検知と、異常時のフェールセーフ処理を行う。安全機能メカニズムサービスに関しては、第１ＯＳプログラムが、マスターＥＣＵにおける連携機能の停止を司り、第２ＯＳプログラムが、スレーブＥＣＵにおけるローカル機能の停止を司る。

機能分散抽象化サービスに関しては、マスターＥＣＵの第１ＯＳプログラムは、マスター−スレーブ間の機能分担の管理に関与せず、スレーブＥＣＵの第２ＯＳプログラムが、その機能分担の管理を行う。同様に、支配抽象化サービスについても、マスターＥＣＵの第１ＯＳプログラムは、責任分担管理に関与せず、スレーブＥＣＵの第２ＯＳプログラムが、その責任分担の管理を行う。

一方、図７は、マスターＥＣＵの第１ＯＳプログラムの役割を重くし、スレーブＥＣＵにおける第２ＯＳプログラムの役割を軽くした例を示している。

この場合、ドメイン外内抽象化サービスについて、マスターＥＣＵの第１ＯＳプログラムは、スレーブＥＣＵの第２ＯＳプログラムによる各サービスの処理順、処理時間の設定を行い、その設定内容を示すデータを送信する。スレーブＥＣＵの第２ＯＳプログラムは、設定内容を示すデータを受信し、その受信されたデータに従って、各種のサービスを実行する。また、意味解釈ゲートウェイサービスに関しては、マスターＥＣＵの第１ＯＳプログラムが、データの意味翻訳を行うとともに、翻訳されたデータをスレーブＥＣＵに送信する。スレーブＥＣＵの第２ＯＳプログラムは、翻訳されたデータを受信し、処理に使用する。

リソース調停サービスに関しては、第１ＯＳプログラムが、マスターＥＣＵによる連携処理のためのリソースを確保する処理、さらに、残りリソースの配分処理も行う。第２ＯＳプログラムは、配分されたリソースを使用するように、リソース管理を行う。システムモードサービスに関しては、第１ＯＳプログラムが連携処理のモードを生成し、さらに、その連携イベントを対応するローカルモードに変換して、スレーブＥＣＵに送信する。第２ＯＳプログラムは、変換されたローカルモードを受信し、スレーブＥＣＵの制御モードを、受信したローカルモードに設定する。

イベント管理サービスに関しては、第１ＯＳプログラムは、連携処理に用いる連携イベントを生成するとともに、その連携イベントを、スレーブＥＣＵにおいて取り扱うことが可能なローカルイベントに変換する。第２ＯＳプログラムは、ローカルイベントを受信し、そのローカルイベントに基づく処理が行われるようにする。スケジューラサービスに関しては、第１ＯＳプログラムが連携処理のスケジュールを生成し、さらに、その連携処理スケジュールをスレーブＥＣＵにおけるローカルスケジュールに変換して、送信する。第２ＯＳプログラムは、ローカルスケジュールを受信し、そのローカルスケジュールに基づくスケジュール管理を行う。同期メカニズムサービスに関しては、第１ＯＳプログラムが、連携処理における同期手段に対応するローカル同期手段を選定して、送信する。第２ＯＳプログラムは、受信したローカル同期手段を受信し、以降の処理に使用する。

クロックサービスに関しては、第１ＯＳプログラムが連携時刻を生成し、さらに、その連携時刻をスレーブＥＣＵにおけるローカル時刻に変換して送信する。第２ＯＳプログラムは、ローカル時刻を受信し、処理に使用する。セキュリティサービスに関しては、第１ＯＳプログラムが、マスターＥＣＵ及びスレーブＥＣＵについて一括して管理する。例えば、第１ＯＳプログラムが、マスターＥＣＵ及びスレーブＥＣＵの通信相手の認証を行ったり、マスター−スレーブ間で送受信されるデータの正常性の確認を行ったりする。この場合、第２ＯＳプログラムは、セキュリティサービスは扱わない。診断サービスに関しては、第１ＯＳプログラムが、マスターＥＣＵにおける連携処理の異常検知と、異常時のフェールセーフ処理を行うとともに、異常検知結果をスレーブＥＣＵに通知する。第２ＯＳプログラムは、その異常検知通知を受信する。安全機能メカニズムサービスに関しては、第１ＯＳプログラムが、マスターＥＣＵにおける連携機能の停止を司るとともに、必要時にローカル機能の停止を指示する。第２ＯＳプログラムは、第１ＯＳプログラムからのローカル機能の停止指示に従い、スレーブＥＣＵにおけるローカル機能を停止させる。

機能分散抽象化サービスに関しては、マスターＥＣＵの第１ＯＳプログラムが、マスター−スレーブ間の機能分担の管理を行い、スレーブＥＣＵの第２ＯＳプログラムは、その機能分担の管理に関与しない。同様に、支配抽象化サービスについても、マスターＥＣＵの第１ＯＳプログラムが、責任分担管理を行い、スレーブＥＣＵの第２ＯＳプログラムは、その責任分担の管理に関与しない。

以上、第１ＯＳプログラムと第２ＯＳプログラムとの役割分担例を説明したが、この役割分担は、上述した２例以外に、マスターＥＣＵでの連携処理の処理応答と、スレーブＥＣＵでのローカル処理での処理応答との違い、マスターＥＣＵ及びスレーブＥＣＵの能力など種々の要因によって、各サービス毎に役割分担が変化しえるため、様々なバリエーションが考えられる。

再び、図４のフローチャートに戻って、説明を続ける。ステップＳ１２０までの処理により、第１ＯＳプログラムと第２ＯＳプログラムとが協調して連携処理をサポートできるように、第１ＯＳプログラムが設定される。しかし、場合によっては、マスター側からスレーブ側に伝達される情報の種類を変更したり、マスター側における動作条件を修正したりといった微調整を行うことで、第１ＯＳプログラムと第２ＯＳプログラムとが協調した処理をより円滑に行いうる場合がある。

そのため、図４のフローチャートのステップＳ１３０では、第２ＯＳプログラムへの伝達情報の変更が必要であるか否かを判定する。そして、伝達情報の変更が必要と判定した場合には、ステップＳ１４０において、第２ＯＳプログラムへの伝達情報の変更内容を通知する。さらに、ステップＳ１５０において、ステップＳ１４０での通知内容に応じた伝達情報の変更を、第１ＯＳプログラムに反映させる。

マスターＥＣＵの第１ＯＳプログラムが、第２ＯＳプログラムへの伝達情報の変更が必要と判定するいくつかの例を、図８を参照して説明する。

図８に示すように、伝達情報の変更が必要となる可能性がある対象サービスは、システムモードサービス、イベント管理サービス、スケジューラサービス、安全機能メカニズムサービスなど、いくつか考えられる。

例えば、システムモードサービスの場合、スレーブＥＣＵにおけるアプリケーションソフトのバージョンアップなどによりスレーブＥＣＵが変更された場合、マスターＥＣＵの連携処理モードに紐づくローカルモードが変化することが予測される。この場合には、マスターＥＣＵの第１ＯＳプログラムからローカルモードそのものの伝達に代えて、対応するモードの目的（起動、通常制御、停止など）を伝達するように変更する。これにより、スレーブＥＣＵの第２ＯＳプログラムは、連携制御モードに対応する適切なモードを選択することが可能になる。

また、イベント管理サービスの場合も、システムモードサービスの場合と同様に、スレーブＥＣＵが変更された場合、マスターＥＣＵの連携イベントに対応するローカルイベントが変化することが予測される。従って、この場合も、マスターＥＣＵの第１ＯＳプログラムからローカルイベントそのものの伝達に代えて、対応するイベントの目的（割込、定期、異常検知など）を伝達するように変更する。これにより、スレーブＥＣＵの第２ＯＳプログラムは、連携イベントに対応する適切なローカルイベントを生成することが可能になる。

さらに、スケジューラサービスの場合も、システムモードサービスの場合と同様に、スレーブＥＣＵが変更された場合、マスターＥＣＵの連携スケジュールに対応するローカルスケジュールが変化することが予測される。従って、この場合も、マスターＥＣＵの第１ＯＳプログラムからローカルスケジュールそのものの伝達に代えて、対応するスケジュールの目的（ＸＸの後処理など）を伝達するように変更する。これにより、スレーブＥＣＵの第２ＯＳプログラムは、連携スケジュールに対応する適切なローカルスケジュールを生成することが可能になる。

また、安全機能メカニズムサービスの場合、マスター側がスレーブ側の停止指示を行う場合であって、スレーブ側が、マスター側とは独立した機能も備えている場合には、マスター側から停止指示を与えてしまうと、スレーブ側の状況を無視することになる可能性がある。そのため、マスターＥＣＵの第１ＯＳプログラムは、スレーブの停止指示を目的で伝達する（制御終了、異常時停止など）。これにより、スレーブＥＣＵの第２ＯＳプログラムは、自身の処理状況を踏まえ、その停止目的に応じた対処を取ることが可能になる。

図４のフローチャートのステップＳ１６０では、スレーブＥＣＵの第２ＯＳプログラムからの変更要求を受けたか否かを判定する。変更要求を受けたと判定した場合には、ステップＳ１７０に進み、スレーブＥＣＵの第２ＯＳプログラムからの変更要求に応じて、第１ＯＳプログラムの動作条件の修正を行う。

マスターＥＣＵの第１ＯＳプログラムが、スレーブＥＣＵの第２ＯＳプログラムから動作条件の変更要求を受けるいくつかの例を、図９を参照して説明する。

図９に示すように、動作条件の変更が必要となる可能性がある対象サービスは、ドメイン外内抽象化サービス、リソース調停サービス、同期メカニズムサービス、機能分散抽象化サービス、支配抽象化サービス、安全機能メカニズムサービスなど、いくつか考えられる。

例えば、マスターＥＣＵに対して複数のスレーブＥＣＵがあり、それら複数のスレーブＥＣＵによる制御の応答時間に差があり、スレーブ側の個別の調整では、複数のスレーブＥＣＵによる制御の応答時間の差に対応することができない場合など、スレーブ側の処理時間の整合が困難になることがありえる。このような場合、ドメイン内外抽象化サービスに関して、スレーブ側からマスター側に、データ通知タイミングの変更を要求する。例えば、マスターＥＣＵが、ＰＴＣ２２が実装された電子制御装置４０であり、スレーブＥＣＵが、ＭＧＣ２３が実装された電子制御装置６０及びエンジン制御部２４が実装された電子制御装置８０である場合を想定する。この場合、ＭＧＣ２３が実装された電子制御装置６０のＯＳプログラム６１ｂ（第２ＯＳプログラム）、もしくはエンジン制御部２４が実装された電子制御装置８０のＯＳプログラム８１ｂ（第２ＯＳプログラム）は、ＰＴＣ２２が実装された電子制御装置４０のＯＳプログラム４１ｂ（第１ＯＳプログラム）に対して、エンジン制御部２４が実装された電子制御装置８０に対するよりも十分に遅くＭＧＣ２３が実装された電子制御装置６０に制御目標値（目標モータトルク）を通知するように要求する。これにより、エンジン３１とモータジェネレータ３３との応答時間の差を吸収することができ、エンジン３１とモータジェネレータ３３とにより、目標通りの駆動トルクを発生させることが可能となる。

また、スレーブＥＣＵが制御責任を負う制御対象機器やセンサ機器がある場合、スレーブＥＣＵが扱うデータの中で、それら制御対象機器やセンサ機器の異常状態の監視のためのデータと、その他のデータとでは安全要求が異なる場合がある。そのような場合には、リソース調停サービスに関して、スレーブ側からマスター側に、例えば共用メモリにおいて、スレーブＥＣＵで使用するデータの安全別にメモリ領域を確保するように要求する。これにより、安全要求に見合ったデータの取り扱いを行うことが容易になる。

また、同期メカニズムサービスに関して、スレーブ側で、同期を実現するための実現機能を選択することができない場合に、同期指示を出す条件をスレーブ側から指定しても良い。

さらに、複数のスレーブがある場合に、マスター−スレーブ間の機能分担管理、責任分担管理を行うのに都合が良いのはマスター側であるため、そのような状況では、機能分散抽象化サービス及び支配抽象化サービスに関して、スレーブ側からマスター側に、機能分担管理、責任分担管理を行うよう要求しても良い。

また、複数のスレーブがある場合、各スレーブでどのような手順で停止処理を行うのが適切であるか不明である状況では、安全機能サービスに関して、スレーブ側からマスター側に、各スレーブでのローカルの機能停止処理手順やその条件などを通知するよう要求しても良い。

図５のフローチャートは、上述したように、スレーブ側の第２ＯＳプログラムによって実行される処理を示しており、ステップＳ２００では、マスターＥＣＵに対して、スレーブＥＣＵが保有する第２ＯＳプログラムが分担する役割情報を提供する。

続くステップＳ２１０では、マスターＥＣＵから、伝達情報の変更要求があったか否かを判定する。変更要求ありと判定した場合には、ステップＳ２２０に進み、マスターＥＣＵからの変更要求に応じて、第２ＯＳプログラムが取得する情報を変更する。さらに、必要に応じて、変更後の情報の処理手順を定めておく。

そして、ステップＳ２３０では、マスターＥＣＵの第１ＯＳプログラムの動作条件の変更が必要であるか否かを判定する。動作条件の変更が必要であると判定した場合には、ステップＳ２４０において、マスターＥＣＵに対して、第１ＯＳプログラムの動作条件の変更依頼を行う。そして、ステップＳ２５０において、依頼した第１ＯＳプログラムの動作条件の変更内容を、第２ＯＳプログラムに反映させるよう、第２プログラムを修正する。

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

例えば、上述した実施形態では、マスターＥＣＵに対して複数のスレーブＥＣＵがあり、スレーブ側の個別の調整では、スレーブ側の処理時間の整合が困難な場合、ドメイン内外抽象化サービスに関して、スレーブ側からマスター側に、データ通知タイミングの変更を要求した。しかしながら、スレーブＥＣＵ同士が通信可能に構成されている場合には、スレーブＥＣＵの第２ＯＳプログラム同士の通信によって、スレーブ側の処理時間の整合を図っても良い。例えば、一方のスレーブＥＣＵの第２ＯＳプログラムによる処理手順や処理時間の情報に基づいて、他方のスレーブＥＣＵの第２ＯＳプログラムにおける、処理手順や処理時間を相互に整合するように調整する。このように、スレーブＥＣＵ同士が協調すれば、互いの処理の時間整合等も容易に図ることが可能になる。

１制御システム、１１運動ドメイン制御部、１２車両挙動制御部、１３前後挙動制御部、１４左右挙動制御部、１５ブレーキ制御部、１６ステアリング制御部、２１エネルギードメイン制御部、２２パワートレインコーディネータ、２３モータジェネレータコーディネータ、２４エンジン制御部、２５ＴＭ制御部、２６ＭＧ制御部、３１エンジン、３２トランスミッション、３３モータジェネレータ、３４ブレーキ装置、３５ステアリング装置、４０電子制御装置、４１ａＰＴＣアプリケーション、４１ｂＯＳプログラム、４２ＲＴＥ、４３マイクロコントローラ抽象化層、４４ＥＣＵ抽象化層、４５サービス層、４６複合ドライバ、４７マイクロコントローラ

Claims

車両に搭載された車載機器（３１〜３３）を制御するために、第１の電子制御装置（４０）と第２の電子制御装置（６０、７０、８０）とが連携した処理を行う車両用制御システムであって、
前記第１の電子制御装置と前記第２の電子制御装置とは、それぞれ、連携処理を行うための連携処理用アプリケーションプログラム（４１ａ、６１ａ、７１ａ、８１ａ）を有するとともに、それら連携処理用アプリケーションプログラムを協調して実行させるためのベーシックソフトウエアとしての役割を果たす、所定の役割分担の下に協調して動作する第１ＯＳプログラム（４１ｂ）と第２ＯＳプログラム（６１ｂ、７１ｂ、８１ｂ）とをそれぞれ有しており、
前記第２の電子制御装置が保有する第２ＯＳプログラムは、分担する役割が異なる複数の中から選定されたものであり、
前記第１の電子制御装置が保有する第１ＯＳプログラムは、分担する役割を変更可能に構成され、それにより、分担する役割が異なる複数の中のいずれの第２ＯＳプログラムとも協調した動作を行うことが可能であって、
前記第１の電子制御装置は、
前記第２の電子制御装置から、前記第２ＯＳプログラムが分担する役割についての情報を取得する取得部（Ｓ１００）と、
前記取得部により取得した、前記第２ＯＳプログラムが分担する役割を示す情報に基づき、当該第２ＯＳプログラムと協調して動作することができるように、第１ＯＳプログラムの分担する役割を決定する決定部（Ｓ１２０）と、を備える車両用制御システム。
オペレーティングシステムの役割として複数の項目があり、前記第１ＯＳプログラムと前記第２ＯＳプログラムとは、前記複数の項目について、それぞれ役割分担が定められており、
前記第１の電子制御装置は、
前記第２の電子制御装置に対して、特定の項目に関して伝達する情報の変更を通知する変更通知部（Ｓ１４０）と、
前記変更通知部の変更指示に対応するように、前記特定の項目に関して前記第１ＯＳプログラムが伝達する情報を変更する変更部（Ｓ１５０）と、を有する請求項１に記載の車両用制御システム。
オペレーティングシステムの役割として複数の項目があり、前記第１ＯＳプログラムと前記第２ＯＳプログラムとは、前記複数の項目について、それぞれ役割分担が定められており、
前記第２の電子制御装置は、
前記第１の電子制御装置に対して、特定の項目の動作条件の変更要求を行う変更指示部（Ｓ２４０）を有し、
前記第１の電子制御装置は、前記変更指示部からの変更指示に応じて、前記特定の項目の前記第１ＯＳプログラムの動作条件を変更する動作条件変更部（Ｓ１７０）を有する請求項１に記載の車両用制御システム。
前記車両用制御システムは、複数の車載機器を制御するための複数の機器制御部（２４〜２６）と、複数の前記機器制御部の制御を統括するドメイン制御部（２１〜２３）とに階層化され、
前記第１の電子制御装置は、前記ドメイン制御部が実装されたものであり、
前記第２の電子制御装置は、前記機器制御部が実装されたものである請求項１乃至３のいずれかに記載の車両用制御システム。
前記車両用制御システムは、複数の車載機器を制御するための複数の機器制御部（２４〜２６）と、複数の前記機器制御部の制御を統括するドメイン制御部（２１〜２３）とに階層化され、
前記ドメイン制御部は、少なくとも２つの電子制御装置により構成され、
前記第１の電子制御装置及び前記第２の電子制御装置は、前記ドメイン制御部を構成する少なくとも２つの電子制御装置である請求項１乃至３のいずれかに記載の車両用制御システム。
前記車両用制御システムは、複数の車載機器を制御するための複数の機器制御部（２４〜２６）と、複数の前記機器制御部の制御を統括するドメイン制御部（２１〜２３）とに階層化され、
さらに、前記ドメイン制御部の上位に位置付けられ、当該ドメイン制御部に対して制御指示を行う上位制御部（１３）を備え、
前記第１の電子制御装置は、前記上位制御部が実装されたものであり、
前記第２の電子制御装置は、前記ドメイン制御部が実装されたものである請求項１乃至３のいずれかに記載の車両用制御システム。