JP2017105362A - 制御システム - Google Patents

Abstract

【課題】階層構造を有する制御システムにおいて、アプリケーションの作成負荷を増加させずに、通信データに対して必要な処理を実施することが可能な制御システムを提供する。【解決手段】制御システムでは、ドメイン制御部としてのＰＴＣアプリケーション４１ａが実装された電子制御装置４０において、ＰＴＣアプリケーション４１ａの各サブアプリケーションが、個別に、通信データ処理用のプログラムを有するのではなく、通信ＩＦアプリケーション４１ｂ、一元的に、通信データに対して必要な通信ＩＦサービスを実行するように構成した。このため、電子制御装置４０において、ＰＴＣアプリケーション４１ａの作成負荷を増加させずに、通信データに対して必要な処理を実施することができる。【選択図】図２

Description

本発明は、車両に搭載された複数の車載機器を制御する制御システムに関する。

例えば、特許文献１には、車両構成が変更される場合に、車両モードに応じた制御手段による制御対象に対する挙動制御の変更が容易な車両制御装置（イントラボックス）について記載されている。

この特許文献１の車両制御装置は、車両モード毎に、機能ドメインＥＣＵ及びサブドメインＥＣＵが制御対象に対して実行する挙動制御を、車両構成に応じてモード情報として記憶している。そして、車両制御装置は、車両が置かれた車両環境に基づき設定される車両モードに応じて、記憶しているモード情報に基づき、各機能ドメインＥＣＵ及び各サブドメインＥＣＵが制御対象に対して実行する挙動制御を管理する。

特開２０１０‐２４１２９８号公報

上述した特許文献１に記載されたように、車両制御システムとして、車両制御装置、機能ドメインＥＣＵ、及びサブドメインＥＣＵなどからなる階層化された構造が採用される場合、各構成間での通信が複雑化することになる。例えば、上記した階層構造の場合、機能ドメインＥＣＵは、車両制御装置、他の機能ドメインＥＣＵ、サブドメインＥＣＵ、及び車外の設備などと通信を行うこととなり、種々の目的で、多数の相手と通信を行うことが必要になる。

ここで、各通信相手、及びその通信相手との通信目的、すなわち、通信相手とどのような種類のデータを通信するかに応じて、通信データに対して種々の処理を実行することが考えられる。例えば、車両制御装置と通信する場合には、第三者によるデータの盗用などを防止するため、その車両制御装置が正規の通信相手であるか否かのセキュリティチェックを行ったりすることが考えられる。また、例えば、サブＥＣＵとの通信では、機能ドメインＥＣＵから送信するデータに、送信時期を示すタイムスタンプを付与したりすることが考えられる。

このような通信データに対する種々の処理は、送信されるデータを作成したり、受信したデータを利用したりする各アプリケーションによって個別に実施することが可能である。しかしながら、階層化された構造により通信が複雑化した場合には、送受信されるデータを作成したり、利用したりするアプリケーションも増加する。そのため、各アプリケーション毎に、送受信されるデータに対して実行すべき処理のためのプログラムを個別に作成することが必要となり、その分、アプリケーションの作成負荷が増加してしまうという問題がある。

本発明は、上述した点に鑑みてなされたものであり、階層構造を有する制御システムにおいて、アプリケーションの作成負荷を増加させずに、通信データに対して必要な処理を実施することが可能な制御システムを提供することを目的とする。

上記目的を達成するために、本発明による制御システムは、車両に搭載された複数の車載機器（３０〜３５）を制御するためのものであって、
当該制御システムは、複数の車載機器の機能に応じて予め複数のドメインに区分けされ、さらに、それら複数のドメインにおいて、それぞれ、車載機器を制御するための機器制御部（７０、８０）と、機器制御部を統括するドメイン制御部（４０）とに階層化され、
ドメイン制御部は、他のドメインに属するドメイン制御部（５０）と通信を行うとともに、同じドメインに属する機器制御部（７０、８０）と通信を行うものであり、その通信データには、送信元、受信先、及び、データの種類を示す情報が含まれており、
少なくともドメイン制御部に対して設けられ、送信元又は受信先から把握される通信相手の階層と、通信されるデータの種類に応じた通信インターフェースサービスを選択し、通信相手から受信される通信データ又は通信相手に送信される通信データに対して、選択した通信インターフェースサービスを適用する通信インターフェース（４１ｂ）を備える。

このように、本発明による制御システムでは、少なくともドメイン制御部において、送信されるデータを作成したり、受信したデータを利用したりする各アプリケーションが、個別に、通信データ処理用のプログラムを有するのではなく、ドメイン制御部に対して設けられた通信インターフェースが、一元的に、通信データに対して必要な通信インターフェースサービスを実行するように構成した。このため、ドメイン制御部において、アプリケーションの作成負荷を増加させずに、通信データに対して必要な処理を実施することができる。

なお、本発明において、ドメイン制御部と通信相手との間でやり取りされる通信データは、送信元、受信先、及び、データの種類を示す情報を含んでいる。このため、通信インターフェースは、送信元又は受信先を示す情報から通信相手の階層を把握することができる。従って、通信インターフェースは、送信元又は受信先を示す情報から把握される通信相手の階層と、通信データの種類を示す情報とに基づき、その通信データに対して実行すべき適切な通信インターフェースサービスを選択して適用することができる。

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

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

実施形態に係る制御システムの構成を示す構成図である。 運動ドメイン制御部のＰＴＣが、電子制御装置にＰＴＣアプリケーションとして実装され、その電子制御装置に通信インターフェースアプリケーションを設けた例を示す図である。 通信ＩＦアプリケーションの具体的な処理内容を示すフローチャートである。 、通信ＩＦアプリケーションが提供する通信ＩＦサービスの具体例を説明するための説明図である。 実施形態の変形例について説明するための説明図である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ここで、上述した制御システム１において、例えば、ＰＴＣ２２は、自身が属するエネルギードメイン２０とは異なる運動ドメイン１０に属するドメイン制御部１１の前後挙動制御部１３と通信したり、同じエネルギードメイン２０内のドメイン制御部２１のＭＧＣ２３と通信したりする必要がある。また、ＰＴＣ２２は、機器制御部であるエンジン制御部２４やＴＭ制御部２５と通信したり、車載機器である冷却機構３０とも通信したりする必要がある。さらに、図１には示していないが、ＰＴＣ２２は、冷却機構３０の制御状態を把握するために、冷却水温度、エンジン温度及びインバータ温度を検出するセンサ装置からのデータを受信することも必要となる。

このように、制御システム１が、複数の論理ブロックからなり、さらにそれらの論理ブロックを階層化した構造を採用する場合、特に、各ドメイン１０、２０において、各機器制御部１５、１６、２４〜２６を統括するドメイン制御部１１、２１を構成する論理ブロックにおける通信が複雑化する傾向にある。このように複雑化する通信に対して、その通信において送受信されるデータを作成したり、利用したりする各アプリケーション自身が、先述したような通信に伴う付加的な処理を実行するように構成したとすると、アプリケーションの作成負荷が増加してしまうという問題が生じる。

そのため、本実施形態に係る制御システム１では、ドメイン制御部（例えば、ＰＴＣ２２）において、送信されるデータを作成したり、受信したデータを利用したりする各アプリケーションが、個別に、通信データ処理用のプログラムを有するのではなく、ドメイン制御部に対して設けられた通信インターフェースが、一元的に、通信データに対して必要な処理を実行するように構成した。このため、ドメイン制御部において、アプリケーションの作成負荷を増加させずに、通信データに対して必要な処理を実施することができる。

以下、図２〜図４を参照して、制御システム１に、通信インターフェースを設ける場合の構成の一例を説明するとともに、通信インターフェースにおける処理内容や、通信インターフェースが実施する処理の具体例を説明する。

図２は、運動ドメイン制御部２０のＰＴＣ２２が、電子制御装置４０にＰＴＣアプリケーション４１ａとして実装され、その電子制御装置４０にアプリケーションの１つとして通信インターフェース４１ｂを設けた場合の構成を示している。なお、図２には、ＰＴＣ２２と通信を行う論理ブロック（前後挙動制御部１３、ＭＧＣ２３、エンジン制御部２４、ＴＭ制御部２５）を対象として、各論理ブロックとして機能するアプリケーション５１ａ、６１ａ、７１ａ、８１ａをそれぞれ実装した電子制御装置５０、６０、７０、８０の構成も示している。また、ＰＴＣアプリケーション４１ａを実装した電子制御装置４０は、センサ装置９０及び冷却機構のアクチュエータ１００とも通信するため、図２には、センサ装置９０及び冷却機構のアクチュエータ１００も含まれているが、その他の車載機器などの構成は省略されている。

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

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

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

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

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

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

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

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

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

次に、通信ＩＦアプリケーション４１ｂについて、詳しく説明する。図２に示す例では、通信ＩＦアプリケーション４１ｂは、アプリケーションソフトの１つとして具現化されている。この通信ＩＦアプリケーション４１ｂは、ＰＴＣアプリケーション４１ｂの各サブアプリケーションが、他の電子制御装置５０〜８０やセンサ装置９０、あるいは冷却機構のアクチュエータ１００と通信を行う際、その通信に介在して、通信されるデータに対して各種の通信インターフェースサービス（以下、通信ＩＦサービス）を適用して、その通信データに付加的な処理を施すものである。以下に、通信ＩＦアプリケーション４１ｂの具体的な処理内容及び各種の通信ＩＦサービスについて、図３のフローチャート及び図４の図表を参照して説明する。

まず、図３のフローチャートのステップＳ１００では、通信ＩＦアプリケーション４１ｂは、ＰＴＣアプリケーション４１ａの各サブアプリケーションが、外部の電子制御装置５０〜８０、センサ装置９０、あるいは冷却機構のアクチュエータ１００との間で通信を行う際の通信データを受け付ける。この通信データには、ＰＴＣアプリケーション４１ａから外部へ送信される送信データ、及び外部からＰＴＣアプリケーション４１ａへ送信される受信データが含まれる。これら送信データ及び受信データには、ともに、データ本体の他、送信元、受信先、及びデータの種類を示す情報が含まれている。

続くステップＳ１１０では、受け付けた通信データにおける、送信元又は受信先を示す情報から、通信相手の階層を特定する。例えば、階層として、自身のドメイン外のドメイン制御部、同じドメイン内のドメイン制御部又は機器制御部、車載機器、センサ装置とに区分けし、通信相手がいずれの階層に属するかを特定する。

次に、ステップＳ１２０において、通信データに含まれるデータ種類を示す情報に基づき、通信データの種類を把握する。例えば、同じ通信相手であっても、ＰＴＣアプリケーション４１ａのサブアプリケーションから送信される種類のデータであるか、サブアプリケーションによって受信される種類のデータであるかに応じて、通信ＩＦアプリケーション４１ｂが適用すべき通信ＩＦサービス（すなわち、通信データに対して実施すべき付加的な処理）は異なる。また、同じ通信相手から送信されるデータであっても、そのデータの種類に応じて、適用すべき通信ＩＦサービスが異なる場合がある。例えば、機器制御部から、制御目標値の送信に対するアクノリッジを受信した場合と、機器制御部から車載機器の動作状態を示すセンサデータを受信した場合とでは、実施すべき通信ＩＦサービスは異なる。

このように、通信データの種類は、通信ＩＦアプリケーション４１ｂにおいて適用すべき通信ＩＦサービスを決定するための１つの情報として活用される。換言すれば、通信ＩＦアプリケーション４１ｂが、適用すべき通信ＩＦサービスを決定できる情報であれば、通信データの種類そのものを示す情報でなくとも、通信データの種類を示す情報と同等の情報として用いることができる。

続くステップＳ１３０では、ステップＳ１１０にて特定された通信相手の階層と、ステップＳ１２０にて把握された通信データの種類とに基づき、通信ＩＦアプリケーション４１ｂにて適用すべき通信ＩＦサービスを選択する。つまり、通信ＩＦアプリケーション４１ｂには、ＰＴＣアプリケーション４１ａが、各階層の通信相手と、各種のデータを通信する際に必要となる全ての通信ＩＦサービスが用意されており、通信相手の階層と通信データの種類とに基づき、必要な通信ＩＦサービスを選択するのである。なお、同じ通信データに対して、複数の通信ＩＦサービスが選択される場合もある。続くステップＳ１４０では、選択した通信ＩＦサービスを通信データに適用して、通信データに対し、通信に伴って必要となる付加的な処理を実施する。

以下に、図４を参照して、通信ＩＦアプリケーション４１ｂが提供する通信ＩＦサービスの具体例を説明する。

まず、通信ＩＦアプリケーション４１ｂは、通信ＩＦサービスの一つとして、セキュリティサービスを提供する。このセキュリティサービスは、主として、通信相手が正規の通信相手であるか否かを判定し、正規の通信相手であると判定したときに通信を許可するためのものである。また、セキュリティサービスは、通信データの誤りを検出して、送信元のアプリケーションへの通知も行う。

このセキュリティサービスとして、通信ＩＦアプリケーション４１ｂは、通信相手の階層に応じて、サービス内容を変更する。例えば、階層が自身のドメイン外のドメイン制御部、すなわち、通信相手が前後挙動アプリケーション５１ａを実装した電子制御装置５０である場合、電子制御装置５０と接続された通信ネットワークを介して通信データを受信したときに、受信した通信データに含まれる送信元を示す情報に基づき、通信相手が正規の通信相手であるか否かを判定する。

この判定により、正規の通信相手ではないと判定した場合には、図４に示すように、通信ＩＦアプリケーション４１ｂは、ファイヤーウォールとして、その正規でない通信相手から送信された通信データをＰＴＣアプリケーション４１ａに受け渡すことなく遮断する。これにより、例えば、悪意を持った第三者が、ドメイン間の通信ネットワークに侵入し、ドメイン制御部（例えば、電子制御装置４０）と通信を行って、当該ドメイン制御部を支配下に置こうとしても、そのような事態の発生を確実に防止することができる。

一方、正規の通信相手と判定した場合には、図４に示すように、通信ＩＦアプリケーション４１ｂは、自身のドメイン外のドメイン制御部（電子制御装置５０）から受信したデータに対して復号化処理を施した上で、ＰＴＣアプリケーション４１ａへ提供する。逆に、通信ＩＦアプリケーション４１ｂは、自身のドメイン外のドメイン制御部（電子制御装置５０）へ送信するデータに対して暗号化処理を施した上で、送信する。

図２に示すように、電子制御装置５０にも、通信ＩＦアプリケーション５１ｂが設けられている。この通信ＩＦアプリケーション５１ｂと通信ＩＦアプリケーション４１ｂとが協働して、ドメイン間の通信ネットワークに送出される通信データに対して暗号化処理を行うとともに、ドメイン間の通信ネットワークから受信する通信データの復号化処理を行うようになっている。これにより、ドメイン間を接続する通信ネットワークから通信データが傍受されたりする可能性を低減することができる。このような暗号化及び復号化処理は、すべての種類のデータに対して実施するのではなく、秘匿性の要求の高い種類のデータのみに対して行うようにしても良い。

なお、ドメイン間の通信ネットワークには、例えば、外部のデータセンターやプログラムの書き換えツールなど、車外のデータ通信装置が接続され、各ドメイン制御部などと通信を行う場合がある。このような場合にも、通信ＩＦアプリケーション４１ｂは、電子制御装置５０に対するセキュリティサービスと同様のセキュリティサービスを提供することができる。

また、通信ＩＦアプリケーション４１ｂは、通信相手の階層が同じドメイン内の、ドメイン制御部又は機器制御部、すなわち、通信相手がＭＧＣアプリケーション６１ａ、ＴＭ制御アプリケーション７１ａ、エンジン制御アプリケーション８１ａをそれぞれ実装した電子制御装置６０〜８０である場合には、図４に示すように、セキュリティサービスとして、不正回路検知を実施する。この不正回路検知では、例えば、いずれかの電子制御装置が不正回路へ置換されているか、もしくは不正回路が追加挿入されているかなどを検知して、不正回路が検知された場合に通信を中止する。これにより、制御システム１の不正な改造などの抑制効果が得られる。

不正回路を検知するには、種々の方式が考えられる。例えば、データをやり取りしたときに、それらのデータ間で不整合が生じたことをもって不正回路を検知しても良い。また、制御データを送信してから、それに対するアクノリッジの返送までの時間が所定の基準時間よりも長くかかった場合に、不正回路が設置されていることを検知するようにしても良い。さらに、データを受信したときに、送信元を示す情報が、予め登録されている情報とは異なる場合に、不正回路が設置されていることを検知しても良い。

通信ＩＦアプリケーション４１ｂは、通信相手の階層が車載機器、すなわち、通信相手が冷却機構のアクチュエータ１００である場合、図４に示すように、セキュリティサービスとして、冷却機構のアクチュエータ１００に出力する制御指令としてのデータの誤りチェック（例えば、パリティチェック）を実施する。もし、データに誤りがある場合には、通信ＩＦアプリケーション４１ｂは、そのデータを冷却機構のアクチュエータ１００に向けて送信することなく、ＰＴＣアプリケーション４１ａへ誤りの発生についてフィードバックする。なお、図４に括弧書きで示すように、ＰＴＣアプリケーション４１ａが、センサ装置９０の動作チェックなどのためにセンサ装置９０にデータを送信する場合には、通信ＩＦアプリケーション４１ｂは、車載機器の場合と同様に、誤りチェックを実施しても良い。

通信ＩＦアプリケーション４１ｂは、上述したセキュリティサービスに加え、通信ＩＦサービスの１つとして、ＰＴＣアプリケーション４１ａから通信相手にデータを送信する際に、タイムスタンプやスケジューラーなどのディスパッチサービスを提供する。このディスパッチサービスに関しても、通信ＩＦアプリケーション４１ｂは、通信相手の階層に応じて、サービス内容を変更する。

例えば、階層が自身のドメイン外のドメイン制御部（すなわち、通信相手が電子制御装置５０）である場合には、通信ＩＦアプリケーション４１ｂは、図４に示すように、ディスパッチサービスとして、ドメイン制御部間で共用されるグローバル時間に基づく送信時刻を付加する（グローバル時間のタイムスタンプ）。これにより、そのデータを受信したドメイン制御部（電子制御装置５０）では、そのデータが生成、あるいは取得された時期を正しく認識することができる。このグローバル時間のタイムスタンプも、すべての種類のデータに対して実施するのではなく、生成、取得時期が重要となる種類のデータのみに対して行うようにしても良い。

また、通信ＩＦアプリケーション４１ｂは、図４に示すように、自身のドメイン外のドメイン制御部（電子制御装置５０）への送信データに対するディスパッチサービスとして、スケジューラーサービスを提供する。このスケジューラーサービスは、ＰＴＣアプリケーション４１ａの各サブアプリケーションにより、ほぼ同時期に、電子制御装置５０へ送信予定の複数のデータが生成等された場合に、データの種類から重要度を順位付けし、重要度の高いデータから順番に送信されるよう、各データの送信スケジュールを決定するものである。

さらに、通信ＩＦアプリケーション４１ｂは、ディスパッチサービスとして、意味変換サービスを提供しても良い。この意味変換サービスは、ドメイン内外で、同義ではあるが、名称が異なる情報が用いられる場合であって、その情報を送信する場合に、通信ＩＦアプリケーション４１ｂにより、受信先のドメインで使用される情報の名称に変換して、送信するものである。具体的には、通信ＩＦアプリケーション４１ｂは、各ドメインで使用される、同義ではあるが名称の異なる情報を関連付けた意味変換リストを有する。そして、通信ＩＦアプリケーション４１ｂは、この意味変換リストに含まれる情報を受け付けた場合、情報の名称を変換した上で、受信先のドメイン制御部等へ送信する。

なお、この意味変換サービスは、ドメイン制御部と機器制御部との間で、上述した関係（同義の情報であるが、名称が異なる）が存在する場合、ドメイン制御部から、機器制御部などの同じドメイン内の制御部へ情報を送信する際に適用しても良い。

一方、通信ＩＦアプリケーション４１ｂは、通信相手の階層が同じドメイン内の、ドメイン制御部又は機器制御部、すなわち、通信相手が、ＭＧＣアプリケーション６１ａ、ＴＭ制御アプリケーション７１ａ、エンジン制御アプリケーション８１ａをそれぞれ実装した電子制御装置６０〜８０の場合も、図４に示すように、ディスパッチサービスとして、上述したタイムスタンプ及びスケジューラーのサービスを提供する。これにより、上述したのと同様の効果を得ることができる。但し、タイムスタンプに関しては、グローバル時間ではなく、同じドメイン内で共用されるローカル時間に基づく送信時刻を送信データに付加する。

さらに、通信ＩＦアプリケーション４１ｂは、通信相手の階層が同じドメイン内の、ドメイン制御部又は機器制御部（すなわち、電子制御装置６０〜８０）である場合、図４に示すように、ディスパッチサービスとして、ＰＴＣアプリケーション４１ａからの送信データに複数の受信先が示されていた場合、その指示された複数の通信相手にデータを送信する。この複数の通信相手への送信サービスは、自身のドメイン外のドメイン制御部も対象とすることが可能である。

さらに、通信ＩＦアプリケーション４１ｂは、上述したセキュリティサービス、ディスパッチサービスに加え、通信インターフェースサービスの１つとして、車載機器の動作状態を示すセンサデータなどの情報に対して、オーディタサービスを提供する。

例えば、電子制御装置５０が、センサ装置９０から直接的にセンサデータを受信する場合、通信ＩＦアプリケーション４１ｂは、図４に示すように、オーディタサービスの１つとして、センサ装置９０から送信されるデータの異常を監視する監視サービスを提供する。この監視サービスとしては、例えば、センサ装置９０は一定間隔でセンサデータを電子制御装置５０に送信するように構成しておき、前回のセンサデータの受信からの経過時間が、その一定間隔の時間を超えたにも係わらず、次のセンサデータを受信しない場合に、異常を判定するようにしても良い。あるいは、センサデータの値が変化しない時間が所定の時間を経過した場合に、異常を判定するようにしても良い。

また、通信ＩＦアプリケーション４１ｂは、オーディタサービスの１つとして、図４に示すように、センサ装置９０によって検出されたデータを受信する場合であって、そのデータに転送指示を示すデータが含まれている場合、センサ装置９０から送信されたデータを、他の通信先にも転送する。これにより、センサデータが必要な制御部へ確実にセンサデータを送信することができる。

なお、各種の車載機器の動作状態を検出するセンサからの信号は、機器制御部を構成する電子制御装置７０，８０に取り込まれ、ＰＴＣ制御部を構成する電子制御装置４０は、機器制御部７０，８０を構成する機器制御部からセンサデータを受信する場合がある。このような場合も、図４に示すように、通信ＩＦアプリケーション４１ｂは、オーディタサービスとして、他のドメインのドメイン制御部（電子制御装置５０）への転送を行うことも可能である。

さらに、ＰＴＣ制御部を構成する電子制御装置４０は、オーディタサービスとして、車両の挙動に関する情報などを、前後挙動制御部を構成する電子制御装置５０から受領する場合に、上述した意味変換サービスを提供しても良い。

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

例えば、上述した実施形態では、セキュリティサービスの暗号化、復号化処理を、送信元の電子制御装置に設けられた通信ＩＦアプリケーションと、受信先の電子制御装置に設けられた通信ＩＦアプリケーションとが協働して行う例について説明した。さらに、通信サービスの機能の高度化を図るため、例えば図５に示すように、受信先の通信ＩＦアプリケーションもしくは受信先の電子制御装置が、送信元の電子制御装置に設けられた通信ＩＦアプリケーションのサービスをチェックし、必要なサービスが施されていない場合、例えば、データの受信処理を許可せずに、送信元の電子制御装置にデータの再送を指示するようにしても良い。

なお、図５に示すように、送信元の電子制御装置が通信ＩＦアプリケーションに対してデータの送信処理を依頼したとき、同時に受信先の電子制御装置への通知も行われるようにしても良い。これにより、受信先の電子制御装置は、通信ＩＦサービスの確認処理や、データ受信処理の事前準備を行うことが可能となり、データ受信処理に関する遅延を抑制することができる。

また、上述した実施形態では、ＰＴＣ２２としてのＰＴＣアプリケーション４１ａが実装された電子制御装置４０において、アプリケーションの１つとして、通信ＩＦアプリケーション４１ｂを設けた。しかしながら、上述した機能を備えた通信ＩＦ回路として、電子制御装置４０とは別個に設けても良い。

さらに、上述した実施形態では、通信ＩＦアプリケーションがセキュリティサービスを提供する例について説明した。この際、各ドメインや、各機器制御部の安全要求レベル（ＡＳＩＬ（Automotive Safety Integrity Level））に応じてセキュリティサービスのレベルを変更するようにしても良い。すなわち、より高い安全要求レベルが求められる通信相手に対しては、より強固なセキュリティが確保できるように、例えば、暗号化をより複雑なものとしたり、不正回路の検知手法も複数の手法を適用したりしても良い。

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

Claims (13)

1. 車両に搭載された複数の車載機器（３０〜３５）を制御する制御システム（１０）であって、
   前記制御システムは、前記複数の車載機器の機能に応じて予め複数のドメインに区分けされ、さらに、それら複数のドメインにおいて、それぞれ、前記車載機器を制御するための機器制御部（７０、８０）と、前記機器制御部を統括するドメイン制御部（４０）とに階層化され、
   前記ドメイン制御部は、他のドメインに属するドメイン制御部（５０）と通信を行うとともに、同じドメインに属する機器制御部（７０、８０）と通信を行うものであり、その通信データには、送信元、受信先、及び、データの種類を示す情報が含まれており、
   少なくとも前記ドメイン制御部に対して設けられ、送信元又は受信先から把握される通信相手の階層と、通信されるデータの種類に応じた通信インターフェースサービスを選択し、通信相手から受信される通信データ又は通信相手に送信される通信データに対して、選択した通信インターフェースサービスを適用する通信インターフェース（４１ｂ）を備える制御システム。
2. 前記通信インターフェースは、前記通信インターフェースサービスの１つとして、通信相手が正規の通信相手であるか否かを判定し、正規の通信相手であると判定したときに通信を許可するセキュリティサービスを提供するものであり、
   前記通信インターフェースは、通信相手が、他のドメインに属するドメイン制御部であり、かつ、当該他のドメインに属するドメイン制御部からデータを受信する場合であって、正規でない通信相手と判定した場合、前記セキュリティサービスとして、その正規でない通信相手から送信されたデータを遮断する請求項１に記載の制御システム。
3. 前記通信インターフェースは、他のドメインに属するドメイン制御部が、正規の通信相手と判定した場合、前記セキュリティサービスの一環として、他のドメインに属するドメイン制御部から受信したデータに対して復号化処理を施すとともに、他のドメインに属するドメイン制御部へ送信するデータに対して暗号化処理を施す請求項２に記載の制御システム。
4. 前記ドメイン制御部は、車両外のデータ通信装置とも通信を行うものであり、
   前記通信インターフェースは、通信相手が車両外のデータ通信装置である場合、他のドメインに属するドメイン制御部に対するセキュリティサービスと同様のセキュリティサービスを適用する請求項２又は３に記載の制御システム。
5. 前記通信インターフェースは、前記通信インターフェースサービスの１つとして、通信相手が正規の通信相手であるか否かを判定し、正規な通信相手であると判定したときに通信を許可するセキュリティサービスを提供するものであり、
   前記通信インターフェースは、通信相手が、同じドメインに属する機器制御部であり、かつ、当該同じドメインに属する機器制御部との間でデータを送受信する場合であって、正規でない通信相手と判定した場合、前記セキュリティサービスとして、その正規でない通信相手との通信を中止する請求項１乃至４のいずれかに記載の制御システム。
6. 前記通信インターフェースは、前記通信インターフェースサービスの１つとして、前記ドメイン制御部から通信相手に対してデータを送信する際に、ディスパッチサービスを提供するものであり、
   前記通信インターフェースは、通信相手が他のドメインに属するドメイン制御部である場合、前記ディスパッチサービスとして、送信するデータに、ドメイン制御部間で共用されるグローバル時間に基づく送信時刻を付加する請求項１乃至５のいずれかに記載の制御システム。
7. 前記通信インターフェースは、前記通信インターフェースサービスの１つとして、前記ドメイン制御部から通信相手に対してデータを送信する際に、ディスパッチサービスを提供するものであり、
   前記通信インターフェースは、通信相手が同じドメインに属する機器制御部である場合、前記ディスパッチサービスとして、送信するデータに、その同じドメイン内で共用されるローカル時間に基づく送信時刻を付加する請求項１乃至６のいずれかに記載の制御システム。
8. 前記通信インターフェースは、前記ドメイン制御部からのデータに、複数の通信相手に送信することを指示するデータが含まれている場合、前記ディスパッチサービスとして、その指示された複数の通信相手にデータを送信する請求項６又は７に記載の制御システム。
9. 前記通信インターフェースは、同じ通信相手に送信すべきデータが複数発生した場合に、前記ディスパッチサービスとして、それら複数の送信すべきデータの送信順序を決定し、その決定した送信順序に従ってデータを送信する請求項６又は７に記載の制御システム。
10. 前記通信インターフェースは、前記通信インターフェースサービスの１つとして、前記ドメイン制御部から通信相手に対してデータを送信する際に、ディスパッチサービスを提供するものであり
    前記ドメイン制御部と前記通信相手との間で、同義の情報に対して異なる名称が用いられる場合、前記通信インターフェースは、前記ディスパッチサービスとして、前記通信相手において使用される情報の名称に変換して、データを送信する請求項１乃至９のいずれかに記載の制御システム。
11. 前記ドメイン制御部は、前記車載機器の動作状態を検出するセンサ装置とも通信を行うものであり、
    前記通信インターフェースは、前記ドメイン制御部が前記センサ装置と通信を行い、前記センサ装置によって検出されたデータを受信する場合、前記通信インターフェースサービスの１つとして、前記センサ装置から送信されるデータの異常を監視する監視サービスを提供するものである請求項１乃至１０のいずれかに記載の制御システム。
12. 前記ドメイン制御部は、前記車載機器の動作状態を検出するセンサ装置によって検出されたセンサデータを受信するものであり、
    前記通信インターフェースは、受信したセンサデータに転送指示を示すデータが含まれている場合、前記通信インターフェースサービスの１つとして、前記センサ装置から送信されるデータを、他の通信先にも転送する転送サービスを提供するものである請求項１乃至１１のいずれかに記載の制御システム。
13. 前記ドメイン制御部と前記通信相手との間で、同義の情報に対して異なる名称が用いられる場合であって、同義ではあるが名称が異なる情報を含む通信データを前記通信相手から受信した場合に、前記通信インターフェースは、前記通信インターフェースサービスの１つとして、前記ドメイン制御部において使用される情報の名称に変換して、前記ドメイン制御部へ提供する請求項１乃至１２のいずれかに記載の制御システム。

Images