JP2006142994A - 車両用ネットワークシステムおよび電子制御装置 - Google Patents

Abstract

【課題】 複雑な大規模システム開発を行う際にも開発期間の短縮化が図れる車両用ネットワークシステムおよびそれに用いられる電子制御装置を提供する。
【解決手段】 分散制御プラットフォーム構成を複数の階層、例えば３つの層に分けた基本構造で構築し、各階層で個別の役割を担うことで、分散制御プラットホームを実現する。すなわち、機能再利用性、拡張性、独立性を有する機能構成と等価な構造フレームワークを提供すると共に、機能的意味を有するＩ／Ｆを提供するアプリケーション層４と、システム開発全体で共有すべきリソースをルールに基づいて一元管理するシステムインフラ層５と、ＥＣＵ、センサ、アクチュエータの電気特性などに加え、ネットワーク１まで含んだハードウェアシステム全体を抽象化するハードウェア抽象化層６とによって電子制御装置２を構成する。
【選択図】 図２

Description

本発明は、例えば、演算処理装置が実装された複数の電子制御装置（以下ＥＣＵともいう）を有し、複数の電子制御装置が通信バスを通じて接続されることで、複数の電子制御装置間でデータの送受信を行うように構成された車両用ネットワークおよびそれに用いられる電子制御装置に関するものである。

従来より、車両内において、各種データ等の送受信を行うために、車両用電子制御装置が用いられている。この種の車両用電子制御装置では、様々な制御等に対応した演算処理を行うＥＣＵ間を通信バスで接続してネットワークシステムが構築されており、近年の制御仕様の複雑化に伴い、ネットワークシステムを通じて、ＥＣＵ間で相互に情報交換を行いながら協調して、車両全体を適切に制御するという形態が採られてきている。

これに伴い、近年では、それぞれのＥＣＵを開発する場合には、複雑な通信制御仕様に対応して、各種の制御処理を行う制御アプリケーション（制御プログラム）や通信処理（通信のコントロール）を行う通信プログラム等からなるソフトウェアを作成する必要がある。

しかしながら、車両の制御に用いられるＥＣＵには様々なものがあり、これらＥＣＵが様々な会社、部署で開発されることになる。このため、ソフトウェアを作成するに当たり、各ＥＣＵに備えられる機能間のインターフェイス（以下、Ｉ／Ｆという）が個別制御機能実現に対してのみ注力され、機能構造が複雑化している。さらには、同一処理を各機能単位で実施しており、ソフトウェア開発規模の増大という問題もある。

また、個々の機能単位で設計された機能間Ｉ／Ｆでシステム開発を行っているため、車種、仕向けごとにＩ／Ｆを大きく変更せざるを得ず、その結果、システム開発の更なる複雑化を招き、品質低下などの問題を引き起こしている。

このような背景の下、特許文献１において、ネットワークに接続される演算処理装置に用いられる高品質のソフトウェアを容易に開発することができる電子制御装置が提案されている。

この電子制御装置では、ネットワークを通じて伝達されるフレーム中に様々なデータが含まれているが、そのフレーム中に含まれた全部のデータの意味を認識することが困難であることから、共通通信プログラムにて、フレーム中から必要なデータのみを取り出せるようにすることで、全部のデータの意味を認識しなくても済むようにしている。

そして、各演算処理装置に、複数の演算処理装置間で共通して使用可能な共通通信プログラムとして備えることで、多種類の通信プログラムを作成しなくても良くなり、ソフトウェア開発規模の縮減、ネットワークのシステム開発の簡素化が図れるようにしている。
特開２００２−２０４２３８号公報

しかしながら、上述した特許文献１に示される電子制御装置は、単に、フレーム内における必要なデータのみを取り出せるようにして、通信手段を隠蔽する手段しか提供していない。

したがって、複雑な大規模システム開発を行う上で、開発期間の短縮化、また、様々な車種に対応できるようなバリエーション対応を行っても、開発期間の短縮化が図れる仕組み（ソフトウェア）が必要である。

また、大規模システム開発を行う場合、システム中のどこかで機能故障が発生した際にも、その原因の究明が困難となり、品質・信頼性を確保することが難しい。このため、機能故障が発生した際に、その原因を究明し易い品質・信頼性が確保できる仕組み（ソフトウェア）も必要である。

本発明は上記点に鑑みて、複雑な大規模システム開発を行う際にも開発期間の短縮化が図れる車両用ネットワークおよびそれに用いられる電子制御装置を提供することを目的とする。

また、様々な車種に対応できるようなバリエーション対応を行っても、開発期間の短縮が行える車両用ネットワークおよびそれに用いられる電子制御装置を提供することも目的とする。

さらに、複雑な大規模システム開発を行う際にも品質・信頼性確保できる車両用ネットワークおよびそれに用いられる電子制御装置を提供することも目的とする。

上記目的を達成するために、本発明者らは、複雑な大規模システム開発を行う上での開発期間の短縮化、品質・信頼性確保、および、バリエーション対応を行う上での開発期間の短縮化に対応できるように、「システム構築のし易さ」を備え持ったシステム開発環境（以下、分散制御プラットホームという）の実現について検討を行った。

まず、大規模システム開発を行う上で開発期間の短縮化を図るためには、役割分担を明確化し、分業・協業をし易くすることが必要になる。これを実現するためには、開発プロセスに対応したインフラ（ソフトウェア、ツール）を構築すること、機能の疎結合化により機能の独立性を図ること、汎用機能（ソフトウェア）を共有すること、が求められる。

また、大規模システム開発を行う上で品質・信頼性を図るためには、複雑な相互依存関係を削除し、設計、実装指針を確実に実践すること、が求められる。

例えば、疎結合化によって機能階層構造を作り上げることで、機能単位での並行開発のし易さ、結合のし易さが向上し、さらに、機能単位での品質保証を確実に実行することで、システム全体での品質保証を行うことが可能となる。

一方、バリエーション対応を行う上での開発期間の短縮化を図るためには、機能（ソフトウェア）の拡張性を得ること、実績有る機能（ソフトウェア）を再利用すること、が挙げられる。

このため、本発明者らは、個別機能単位での機能間Ｉ／Ｆ策定から車両システム全体での機能間Ｉ／Ｆ策定を行うこと、さらには、個別機能の性能に依存しない機能間Ｉ／Ｆ、制御可観測量の標準化の実現により、大規模システム開発、および、バリエーション対応を行う上での開発期間の短縮化を実現できると考えた。

また、本発明者らは、機能間Ｉ／Ｆと共に用意された各機能の有効性情報を元に機能性を有する品質管理を行うこと、さらには、制御可観測量と併せて提供される正確性情報を元に故障部位を明確化することにより、機能故障に対する原因を究明し易くすることができると考えた。

以上の検討に基づき、本発明者らは、分散制御プラットフォーム構成を複数の階層、例えば３つの層に分けた基本構造で構築し、各階層で個別の役割を担うことで、分散制御プラットホームを実現することにした。

上記目的を達成するため、請求項１に記載の発明では、車両用ネットワークにおいて、制御ロジック（７）が差し込まれることで、この制御ロジック（７）に示された制御内容を実現する機能構成フレームワーク（４ａ）と、機能構成に含まれる各機能の能力、状態に応じた制御要求を発行すると共に、各機能構成における機能の実行順序や実行スケジューリングを決定するシステムコーディネータ（５ｃ）と、複数の電子制御装置により実現される機能に関するデータを記憶していると共に、機能の中から最適な機能を抽出し、これを機能構成として管理するシステム構造管理部（５ａ）と、複数の電子制御装置（２）で用いられる可観測状態量のデータを管理し、そのデータから可観測状態量に関するデータをセンサ信号として出力する仮想センサ（５ｂ）と、電子制御装置（２）を含むハードウェアシステム全体を抽象化し、システム構造管理部（５ａ）および仮想センサ（５ｂ）に対して、ハードウェアシステム全体を１つの仮想巨大電子制御装置として見せかけるハードウェア抽象化部（６）とを有した構成として電子制御装置（２）を構成することを特徴としている。

機能構成フレームワーク（４ａ）に制御ロジック（７）を差し込むだけで、システムを実現できる構造とすることができる。そして、制御ロジック（７）以外の部分に関しては、各電子制御装置（２）間で共通となっている。このため、役割分担を明確化でき、分業・協業をし易くすることが可能となる。

このため、複雑な大規模システム開発を行う上での開発期間の短縮化、品質・信頼性確保、および、バリエーション対応を行う上での開発期間の短縮化に対応することが可能となる。

このような車両用ネットワークシステムでは、電子制御装置（２）を、例えば、請求項２に示されるように、機能構成フレームワーク（４ａ）によって構成されるアプリケーション層（４）と、システム構造管理部（５ａ）、仮想センサ（５ｂ）およびシステムコーディネータ（５ｃ）によって構成されるシステムインフラ層（５）と、ハードウェア抽象化部（５）からなるハードウェア抽象化層（６）の３層によって構成することができる。

請求項３に記載の発明では、機能構成フレームワーク（４ａ）は、階層化された機能構造を有しており、その各階層には、オーダ／リクエスト信号を作成するコーディネータ（５０）と、オーダ／リクエスト信号を受けて所定の機能を実現すると共に、その機能を実現可能か否かもしくは実現可能な範囲を示した機能状態量・機能許容量を表すAvailability信号を作成する機能的コンポーネント（５１）と、が備えられ、コーディネータ（５０）は、Availability信号および仮想センサ（５ｂ）が発するセンサ信号に基づいて、オーダ／リクエスト信号を作成しており、コンポーネント（５１）は、仮想センサ（５ｂ）が発するセンサ信号に基づいて、Availability信号を作成するようになっていることを特徴としている。

このような構成によれば、上流から下流にかけて多岐に渡って機能構成フレームワーク（４ａ）を構築して、各機能構成でオーダ／リクエスト信号、Availability信号、および、センサ信号を管理することができる。

このように、オーダ／リクエスト信号で示される制御指示量・制御要求量とAvailability信号で示される機能許容量・機能状態量を制御機能開発の枠組みとして有し、さらに、センサ信号で示される制御可観測状態量を制御アルゴリズムとは分離された基盤制御ソフトウェア内で算出し、制御開発に提供する機能を有したものとしている。

請求項４に記載の発明では、ハードウェア抽象化部（６）は、複数の電子制御装置を含むハードウェアシステムに含まれるハードウェアの状態量をシステム構造管理部（５ａ）に通知するようになっており、システム構造管理部（５ａ）は、ハードウェアの状態量に基づいて、機能の中から最適な機能を抽出して機能構成を決定するようになっていることを特徴としている。

このように、システム構造管理部（５ａ）は、ハードウェアの状態量に基づいて、機能の中から最適な機能を抽出して機能構成を決定する。

請求項５に記載の発明では、仮想センサ（５ｂ）は、ハードウェアシステムに含まれる実在センサ（８）の検知信号から求められた物理量や、その物理量から求められた実在センサ（８）では求められない物理量を可観測状態量として、該可観測状態量のデータを管理するものであることを特徴としている。例えば、仮想センサ（５ｂ）は、実在センサで計測した物理量から物理現象に着目し、計算で可観測状態量を求めることができる。

このように、仮想センサ（５ｂ）は、実在センサ（８）の検知信号から求められた物理量だけでなく、その物理量から求められた実在センサ（８）では求められない物理量も可観測状態量とし、該可観測状態量のデータを管理する。これにより、あたかも各可観測状態量を求めることができるセンサが実在するかのように、その可観測状態量のデータを管理することができる。

請求項６に記載の発明では、システムコーディネータ（５ｃ）は、機能構成フレームワーク（５ａ）によって階層化された機能構造に含まれる機能を実現すべく、各階層毎に、オーダ／リクエスト信号および実行スケジューリングを作成するコーディネータ（６１、８１、８５）と、オーダ／リクエスト信号および実行スケジューリングを受けて所定の機能を実現すると共に、その機能を実現可能か否かもしくは実現可能な範囲を示した機能状態量・機能許容量を表すAvailability信号を作成するコンポーネント（６２、８２〜８４、８６〜８８）とを備えており、コーディネータ（６１、８１、８５）は、Availability信号および仮想センサ（５ｂ）が発するセンサ信号に基づいて、オーダ／リクエスト信号を作成すると共に、コンポーネント（６２、８２〜８４、８６〜８８）の実行スケジューリングを行い、コンポーネント（６２、８２〜８４、８６〜８８）は、仮想センサ（５ｂ）が発するセンサ信号に基づいて、Availability信号を作成すると共に、実行スケジューリングに基づいて所定機能を実現するようになっていることを特徴としている。

このような構成によれば、上流から下流にかけて多岐に渡って機能構成フレームワーク（４ａ）を構築し、各機能構成でオーダ／リクエスト信号、Availability信号、および、センサ信号を管理することができる。

このように、オーダ／リクエスト信号で示される制御指示量・制御要求量とAvailability信号で示される機能許容量・機能上耐量を制御機能開発の枠組みとして有し、さらに、センサ信号で示される制御可観測状態量を制御アルゴリズムとは分離された基盤制御ソフトウェア内で算出し、制御開発に提供する機能を有したものとしている。

また、このような構成の場合、請求項７に示されるように、ハードウェアシステムのいずれかの箇所で故障が発生した場合に、Availability信号のうち故障を示すデータが含まれているものを記憶しておくことにより、故障箇所の追跡を行うことが可能となる。

この場合、例えば、請求項８に示されるように、通信バス（３）にテスタが接続されたときに、故障を示すデータが含まれるAvailability信号に基づき、故障箇所がテスタに示されるようにすることができる。

請求項９に記載の発明では、システムコーディネータ（５ｃ）では、階層のいずれかに備えられたコーディネータ（６１、８１、８５）が故障した場合に、その階層中に含まれるコンポーネント（６２、８２〜８４、８６〜８８）は、これら各コンポーネント（６２、８２〜８４、８６〜８８）が構成する階層に備えられるコーディネータで自律的に実行スケジューリングを行うようになっていることを特徴としている。

このようにすれば、１つの箇所で故障が発生しても、他の機能を停止させずに、自律的に機能を実行させることができる。

上記請求項１ないし９においては、本発明を車両用ネットワークシステムとして示したが、本発明は、請求項１０に示されるように、車両用ネットワークシステムに備えられる車両用電子制御装置として捉えることも可能である。

なお、上記各手段の括弧内の符号は、後述する実施形態に記載の具体的手段との対応関係を示すものである。

（第１実施形態）
本発明の第１実施形態について説明する。図１は、本実施形態が適用される車両用ネットワーク１の概略を示した図である。また、図２は、図１に備えられる個々の電子制御装置２の基本構造を示したブロック図である。

図１に示されるように、複数の電子制御装置２、例えばエンジンの制御を行うブレーキＥＣＵ、エンジンＥＣＵ、車体運動制御ＥＣＵ、ステアリングＥＣＵ等が通信バス３を介して接続されることで車両用ネットワーク１が構築されている。そして、各電子制御装置２では、個々の機能を実現するために、各電子制御装置２に記憶された制御プログラムに従って各種演算・制御を実行するようにようになっている。

図２に示されるように、各電子制御装置２は、アプリケーション層４、システムインフラ層５およびハードウェア抽象化層６の３つの階層を基本構造としている。

ここで、アプリケーション層４とは、機能再利用性、拡張性、独立性を有する機能構成と等価な構造フレームワークを提供すると共に、機能的意味を有するＩ／Ｆを提供するものである。システムインフラ層５は、システム開発全体で共有すべきリソースをルールに基づいて一元管理するものである。ハードウェア抽象化層６は、ＥＣＵ、センサ、アクチュエータの電気特性などに加え、ネットワーク１まで含んだハードウェアシステム全体を抽象化するものである。

以下、上記３つの階層の具体的なブロック構成について説明する。

［（１）アプリケーション層４について］
アプリケーション層４は、機能構成フレームワーク４ａによって構成されている。この機能構成フレームワーク４ａは、制御内容が組み込まれる部分であり、システム構成で定義された機能・サービス構造、Ｉ／Ｆをフレームワークとして提供する部分である。この機能構成フレームワーク４ａに制御ロジック７を差し込むだけで、システムを実現することが可能となる。

機能構成が変更される場合は、その機能構成に応じた機能構成フレームワーク４ａを用意することで対応する。

ここで、車両用ネットワーク１に備えられる機能構成について、図３に示す機能構成概略図を参照して説明する。

図３に示されるように、車両用ネットワーク１に備えられる機能構成としては、例えば、最上流に車両コーディネータ１１があり、この車両コーディネータ１１によって車両挙動コンポーネント１２やパワートレインコンポーネント１３などが管理される。この車両コーディネータ１１によって管理される階層が車両ドメイン１０である。

また、車両挙動の管理は、車両挙動コーディネータ２１が車輪速やヨーレート、車両縦方向加速度、車両横方向加速度などの挙動参照値２２に基づいて車両安定性を管理することで行われ、パワートレインの管理は、パワートレインコーディネータ３１がトランスミッションの出力軸トルクなどの車両推進力参照値３２に基づいて、スタータ制御コンポーネント３３、クラッチ制御コンポーネント３４、トランスミッション制御コンポーネント３５、エンジン制御コンポーネント３６、ＩＳＧ（アイドルストップ）制御コンポーネント３７を管理することで行われる。これら車両挙動コーディネータ２１およびパワートレインコーディネータ３１によって管理される階層が、それぞれ、車両挙動ドメイン２０とパワートレインドメイン３０である。

さらに、車両安定化の管理は、車両安定化コーディネータ４１がディファレンシャル制御コンポーネント４２、ブレーキ制御コンポーネント４３、全輪駆動制御コンポーネント４４、ステアリング制御コンポーネント４５を管理することで行われる。そして、ここでは図示していないが、パワートレインの管理を行うために管理されるスタータ制御コンポーネント３３、クラッチ制御コンポーネント３４などの管理についても、さらに下流に存在する機能構成のコーディネータを管理することにより行われる。この車両安定化コーディネータ４１によって管理される階層が車両安定化ドメイン４０である。そして、パワートレインドメイン３０や車両安定化ドメイン４１内の各コンポーネントが更にドメインに分岐される等のように、最上流から下流にかけて多岐に渡って機能構成が階層化されることで、機能構成フレームワーク４ａが構築されている。

ここで示される各コンポーネントが構成するドメインは、それぞれが図４のように示される基本構造を有していることになる。すなわち、各コンポーネントが構成するドメインは、コーディネータ５０と更に下流のコンポーネント５１が含まれ、これらコーディネータ５０と更に下流のコンポーネント５１に後述する仮想センサ５ｂからセンサ信号が入力されるようになっている。そして、このような基本構造において、各コンポーネントは、オーダ／リクエスト信号、Availability信号、および、センサ信号を管理し、それらを信号ごとに分別することで、仮にどこかで故障が発生したとしても、その故障が示されているであろう信号を確認すれば、その故障箇所を特定できるようにしている。

オーダ／リクエスト信号とは、下流のコンポーネント５１間の制御指示量・制御要求量に対するＩ／Ｆのことを示す。Availability信号とは、下流のコンポーネント５１の能力や状態、つまり機能許容量・機能状態量を通知するためのＩ／Ｆのことを示す。このAvailability信号に関しては、後で詳細に説明する。センサ信号とは、後述するように、仮想センサ５ｂに蓄積された可観測量を公開するためのＩ／Ｆのことを示す。

コーディネータ５０は、センサ信号およびAvailability信号に基づいて、下流のコンポーネント５１間の処理要求量を決定し、それをオーダ／リクエスト信号として出力する。このオーダ／リクエスト信号が下流のコンポーネント５１に伝えられると、下流のコンポーネント５１は、そのオーダ／リクエスト信号が示す処理要求量を実現するために、個々の制御を行う。このとき、下流のコンポーネント５１の状態やどこまでの制御が実行可能かという能力がAvailability信号としてコーディネータ５０に伝えられると共に、このときの制御によって車両状態が変化すると、それに伴って変動した可観測量が仮想センサ５ｂに蓄積され、それがまたセンサ信号としてコーディネータ５０にフィードバックされるようになっている。

このように、各コンポーネントが構成するドメインも、コーディネータ５０と更に下流のコンポーネント５１というように階層化されている。そして、階層化された各部の信号が区分けして認識できるようになっている。

なお、図４では、例示的に下流の機能構成を１つしか示していないが、複数存在する場合もある。

［（２）システムインフラ層５について］
システムインフラ層５は、システム構造管理部５ａ、仮想センサ５ｂおよびシステムコーディネータ５ｃによって構成されている。

システム構造管理部５ａは、後述するハードウェア抽象化層６から提供される各電子制御装置２や車両用ネットワーク１等の各ハードウェアの状態量から最適な機能構成を決定するものである。このシステム構造管理部５ａは、各電子制御装置２がどの機能を実現するものであるか等のデータを記憶していると共に、各電子制御装置２の動作状態に応じて、処理が可能な状態（実行可能）の機能のみを抽出し、これを機能構成としてシステムコーディネータ５ｃに通知するようになっている。

例えば、車両用ネットワーク１や電子制御装置２などの故障や電源投入時における立ち上がりのズレ、オプションの追加等、ハードウェアシステム状態が変化すると車両機能の構成も変化する。このような機能構成の変化に応じて機能を動作させないと、予定しない車両挙動を示す可能性がある。このため、システム構造管理部５ａでは、電子制御装置２の動作状態に応じて機能構成を決定する。

また、イグニッションＯＦＦ等によって機能を停止させる場合、論理的な機能の停止に合わせて、電子制御装置２をスリープさせるが、機能が車両用ネットワーク１にまたがって複数の電子制御装置２内に分配配置されているため、車両用ネットワーク１上で停止する機能と動作を継続する機能が混在するような状況が考えられる。この場合、車両用ネットワーク１に実装されているすべての機能が停止している場合はスリープできるが、そうでない場合にはスリープできないので、車両用ネットワーク１をスリープさせるかどうかの判断を行う必要がある。

そこで、システム構造管理部５ａが機能の停止に応じてスリープする電子制御装置２、システムを決定する。逆に、ウェイクアップも同様に起動する機能に応じてシステム構造管理部５ａがウェイクアップする電子制御装置２、システムを決定する。

このように、システム構造管理部５ａは、論理的な機能の構造や停止などといった状態と、ハードウェア（電子制御装置２）の状態との整合を取る役割を果たすようになっている。

仮想センサ５ｂは、各電子制御装置２に入力される実在センサ８の検知信号から求められた物理量やその物理量から求められた実在センサ８では求められない物理量を可観測状態量として、あたかも各可観測状態量を求めることができるセンサが実在するかのように、その可観測状態量のデータを管理するものである。

すなわち、このような仮想センサ５ｂを設けることにより、可観測状態量を各機能単位で特定のセンサの検出信号から算出して制御ロジック７に渡すのではなく、制御アプリケーションとは独立した基盤ソフトウェア内で各機能の制御対象（車輪制御レベルから車両運動制御レベルまで、さらに走行環境との調和に関する運転支援、衝突安全まで含んだもの）に対応した可観測状態量をハード物理的構成と対応した構造単位で物理現象に着目して算出し、その可観測状態量を車両システム全体で共有する（標準化する）仕組みを提供することができる。

なお、算出した可観測状態量を車両用ネットワーク１を使って、全電子制御装置２または関係する電子制御装置２に送信し、それら全体で共有することが可能である。

具体的には、仮想センサ５ｂは、制御アプリケーションのフィードバック制御などで必要な物理量を管理し、その物理量をシステムコーディネータ５ｃに通知したり、機能的コンポーネントに公開したりする。

例えば、仮想センサ５ｂに入力される実在センサの検知信号から求められた物理量としては、車輪速度、加速度、ヨーレート、操舵角などが挙げられ、実在センサから直接観測できない物理量としてはタイヤ接地荷重などが挙げられる。

図５は、複数の電子制御装置２間での可観測状態量のデータの通信形態の一例を示したものである。なお、本図中の上方には、各電子制御装置２で記憶しているデータ内容を示してある。

この図に示されるように、車両用ネットワーク１には、ブレーキＥＣＵ２ａ、エンジンＥＣＵ２ｂ、ステアリングＥＣＵ２ｃ、車体運動制御ＥＣＵ２ｄが電子制御装置２として備えられている。この場合において、ブレーキＥＣＵ２ａでは、実在センサ８、具体的には車輪速度センサ８ａ、ヨーレートセンサ８ｂ、加速度（Ｇ）センサ８ｃからの検出信号に基づいて各輪の車輪速度やヨーレート、加速度が演算される。エンジンＥＣＵ２ｂでは、エンジン軸トルクが演算される。ステアリングＥＣＵ２ｃでは、操舵角センサ８ｄからの検出信号に基づいて操舵角が演算される。そして、車体運動制御ＥＣＵ２ｄでは、各ＥＣＵ２ａ〜２ｃで演算された各物理量に基づいて車体速度、ピッチング量、ロール量、タイヤ接地荷重などが演算される。

このような形態においては、各物理量が演算されると、それが通信バス３を通じて各ＥＣＵ２ａ〜２ｄに伝達され、この伝達された各物理量に基づいてどこかのＥＣＵ２ａ〜２ｄでさらに物理量が演算されると、それが通信バス３を通じて各ＥＣＵ２ａ〜２ｄに伝達されることで、すべてのＥＣＵ２ａ〜２ｄで各物理量を共有するという形態が採られている。

また、ここでいう物理量としては、車両周辺環境の状態量を含めることもできる。図６は、仮想センサ５ｂからのセンサ信号がシステムコーディネータ５ｃに通知される様子を示したものである。この図に示されるように、仮想センサ５ｂでは、例えば、車輪毎に外部入力（駆動、制動、操舵などの入力）に対するタイヤ点作用力が求められ、そこから車輪がＸ、Ｙ、Ｚ方向に路面を蹴る力の作用力が求められ、さらにバネ下モデルに基づいて、各車輪が路面から受ける前後・横・上下力が求められ、各車輪のバネした機構を通じてシャーシに伝播する力が求められる。一方、バネ上モデルとして、Ｘ、Ｙ、Ｚ方向並進運動や回転運動（ピッチング、ロール、ヨー）を求めることで車両重心点に作用するモーメントを求める。

また、このような可観測状態量に関しては、可観測状態量と併せて、可観測状態量に対する信頼性も提供することも可能である。ここでいう信頼性としては、可観測状態量として取り得る静的な範囲、要求に対する応答特性などの動的特性、時間的要因による精度（例えば更新されてからの時間経過）、さらには可観測状態量の組み合わせによる信頼性が挙げられる。

さらに、特定のセンサ故障、またはセンサが未装着の車両モデルにおいて、他の可観測状態量からセンサ値を推定し、可観測状態量として提供することも可能である。このような方法により、例えば、センサ故障時に制御アプリケーション側で明示的に別の可観測状態量を使って対処させるのではなく、推定された可観測状態量を使って対処するようにすれば、センサの正常・故障に依存することなく同じ処理アルゴリズムにすることが可能になる。

なお、可観測状態量は、各種センサの検知信号から求めた可観測状態量の組み合わせから求めたり、さらに、その求められた可観測状態量の組み合わせから求めることで、より抽象度が高いものとなるようにすることができる。

システムコーディネータ５ｃは、システム構造管理部５ａから通知される機能構成に基づいて、機能構成に含まれる各機能（コンポーネント）の能力、状態に応じた制御要求を発行すると共に、機能構成における各機能の実行順序や実行タイミング、つまりスケジューリングを決定するものである（以下、各機能構成の能力、状態に応じた制御要求を機能配分と言い、各機能構成における機能のスケジューリングを実行スケジューリングという）。

システムコーディネータ５ｃでは、機能配分の仕組みを構成としてプラットフォームに組み込むことで、正常／故障時で区別することの無い機能のロジック設計が可能となり、車両状態に応じて最適なパフォーマンスを発揮できるシステムが自然に構築できる。つまり、システムコーディネータ５ｃは、フェールセール思想が開発の初期段階から自然に織り込まれたシステムの構築を実現する。

また、システムコーディネータ５ｃでは、機能を単位とした実行スケジューリングを行う。つまり、従来のように、ソフトウェア部品単位だけでなく、機能構成を単位としたスケジューリングを行うことで、システム設計者はシステムの処理フローや応答性を開発の初期段階から把握することが可能となり、大規模システムの設計や検証が容易になる。換言すると、システムコーディネータ５ｃは、従来無かったシステム設計者の視点でのスケジューリングを実現する。

図７は、このシステムコーディネータ５ｃの機能を模式的に示したものである。この図に示されるように、システム構造管理部５ａで決定された最適な機能構成（例えばコンポーネントＡ〜Ｃ）のコンポーネントＡ〜Ｃに対してオーダ信号を送り、各コンポーネントＡ〜Ｃを制御して個々の機能を実現させる。これに対して、各コンポーネントＡ〜Ｃからシステムコーディネータ５ｃに対してAvailability信号が通知されるようになっており、このAvailability信号によって、システムコーディネータ５ｃが各コンポーネントＡ〜Ｃの能力、状態を認識し、さらにこれに応じたオーダ／リクエスト信号を発生させるようになっている。

このシステムコーディネータ５ｃでの管理単位について説明する。上述したように、大規模システムでは、いかに役割分担を明確化、つまり機能分割し、分業・協業をし易くするかがシステム開発効率・品質を考える上で重要となっている。これに対して、ここでは、ファンクショナルアーキテクチャにて、車両システムを抽象度に応じて階層的に機能分割する。その分割した単位が上述したドメインである。

例えば、上述した図３においては、車両コーディネータ１１が管理する階層が車両ドメイン１０、車両挙動コーディネータ２１が管理する階層が車両挙動ドメイン２０、パワートレインコーディネータ３１が管理する階層がパワートレインドメイン３０、車両安定化コーディネータ４１が管理する階層が車両安定化ドメイン４０というように、各ドメイン単位で区切られている。

システムコーディネータ５ｃは、ドメインで分割されたシステム設計に対応するために、機能配分と実行スケジューリングをドメイン単位で区切って分散処理を行う。すなわち、ファンクショナルアーキテクチャでは、各ドメイン内の役割を図８のように表すことができ、コーディネータ６１がドメイン６０内の各コンポーネント６２の機能配分や実行スケジューリングを管理する。このため、システムコーディネータ５ｃは、このコーディネータ６１の集合体に相当するものとなる。

このように、システムコーディネータ５ｃでは、システムをドメインで分割管理することで、分業・協業による並行開発のし易さや品質保証のし易さを向上させ、システム全体の開発効率の向上や高品質を実現することができる。

次に、このシステムコーディネータ５ｃによる機能分配で扱われるAvailability信号について説明する。

Availability信号とは、上述したように、下流のコンポーネントの能力や状態、つまり機能許容量・機能状態量を通知するためのＩ／Ｆのことを示す。

ここで、機能許容量は、実現可能な制御指示量・制御要求量の範囲を意味し、機能状態量は、下流のコンポーネントが故障していないか等の状態を意味している。つまり、Availability信号は、下流のコンポーネントの信頼性を示すデータとして扱われる。したがって、Availability信号で示される機能許容量・機能状態量に応じてオーダ／リクエスト信号が作成され、機能許容量・機能状態量の範囲内で制御指示量・制御要求量が決められることになる。

機能許容量には、システム設計で静的に実現可能なオーダ／リクエストの範囲を示す静的許容量（例えば、最大、最小エンジントルク）と、現時点から決められた時間内に実現可能もしくは実現を許可しているオーダ／リクエストの範囲を示す動的許容量（例えば、３００ｍｓ後に実現可能なエンジントルクの範囲）がある。

一方、機能状態量には、例えばシステム開始時の準備状態を示す初期状態、初期化が完了し円滑に処理が可能な通常状態、一時的に異常と判定された異常状態、長期的もしくは半永久的に異常と判定された故障状態、コンポーネントの処理を停止している停止状態等がある。

このAvailability信号は、下流のコンポーネントのAvailability信号、仮想センサ５ｂのセンサ値やセンサ品質情報を基にして、コンポーネント自身で算出され、所属しているドメインのコーディネータに通知される。例えば、エンジン制御コンポーネント３７のAvailability信号である実現可能なエンジントルクの範囲とエンジン制御コンポーネント３７の状態を算出する場合、噴射制御で噴射可能な燃料量とインジェクタの状態、スロットルが制御できる空気量とスロットルの状態、点火制御で点火可能な時期とイグナイタの状態などといったエンジン制御コンポーネント３７よりも下流のコンポーネントのAvailability信号と仮想センサ５ｂから取得できるエンジン回転数やエンジントルクなどから算出可能である。

なお、コンポーネントが停止状態である場合には、コンポーネント自身でAvailability信号を通知することができない場合があるが、このような場合には、Availability信号の通知が行われていないことに基づいて、コンポーネントが停止状態であることを上流側のコーディネータが把握することができる。

また、各ドメインは、上流のドメインに所属するコンポーネントに相当しているので、各コーディネータは、所属するドメインのAvailability信号を算出し、上流のドメインに所属するコンポーネントのAvailability信号として通知することになる。

例えば、パワートレインコーディネータ３１は、エンジン制御コンポーネント３７やトランスミッション制御コンポーネント３５等のAvailability信号や機能構成からパワートレインドメイン３０で実現可能な車軸トルクの範囲とパワートレインドメイン３０の状態を算出し、パワートレインコンポーネント３０のAvailability信号として車両コーディネータ１１に通知するようになっている。

さらに、このAvailability信号は、どこかで故障した場合において、その故障箇所の特定を行うためにも用いられる。本車両用ネットワーク１のように、複数の電子制御装置２間で協調制御が行われるような状況下においては、一箇所の故障が複数の機能故障として現れることが考えられる。このような場合には、実際に故障した箇所を特定することが難しい。しかしながら、Availability信号が上記のように、各コンポーネントの能力や状態を通知するものであるため、このAvailability信号を監視、追跡することで、故障した箇所を特定することが可能となる。

このようなAvailability信号による故障箇所の特定は、各コンポーネントのAvailability信号を時刻と共にＥＥＰＲＯＭ等に保存しておくことにより行うことが可能である。この場合、Availability信号すべてを記憶しておくのでは、多大なデータ量を記憶しなければならなくなるため、Availability信号を常にチェックして、Availability信号に故障に関するデータが含まれていることがチェックされた場合に、その時刻前後の所定期間中のAvailability信号をチェックした時刻に関するデータと共に記憶させるようにすれば、比較的少ないデータ量を記憶するだけで済む。

図９に、故障箇所の追跡の模式図を示し、この図を参照して具体的な故障箇所の追跡手法について説明する。

この図に示されるように、例えば車両運動操安性管理を行うドメイン７０があった場合、そのドメイン７０内には、車両運動操安性管理用のコーディネータと操舵量管理、制動力管理および駆動力管理それぞれを行うコンポーネントが存在する。そして、操舵量管理のコンポーネントは、操舵量管理ドメイン７１として、操舵量管理用のコーディネータと操舵量可変ギアを管理するコンポーネント７２、ステアリング管理を行うコンポーネント７２に分岐する。制動力管理のコンポーネントは、制動力管理ドメイン７４として、駆動力管理用のコーディネータとＡＢＳ制御を行うコンポーネント７５とパーキングブレーキを管理するコンポーネント７６に分岐する。また、駆動力管理のコンポーネントは、駆動力管理のドメイン７７として、駆動力管理用のコーディネータとエンジン制御を行うコンポーネント７８とトランスミッション制御を行うコンポーネント７９に分岐する。

このような場合、ドメイン毎に、コーディネータからオーダ／リクエスト信号が下流のコンポーネントに対して送られ、下流のコンポーネントからAvailability信号が上流のコーディネータに対して送られる。

このとき、図９に示されるように、仮想センサ５ｂに備えられるセンサ情報ＤＢ内の操舵角（センサ値）が不正であったためにステアリング状態に異常が発生したとすると、ステアリング管理を行うコンポーネント７３からのAvailability信号に故障に関するデータが含まれていることから、操舵量管理ドメイン７１において、操舵量管理用のコーディネータがそのデータに基づいて操舵量に関する機能許容量や機能状態量を決めることになる。このため、操舵量管理を行うコンポーネントから更に上流の車両運動操舵性管理用のコーディネータに対してAvailability信号が通知されたときに、そのAvailability信号が操舵量の許容量の低下または操舵系の異常を示すデータを含むことになり、それが車両運動操舵性管理用のコーディネータで認識される。

したがって、車両用運動操舵性用のコーディネータが操舵量管理を行うコンポーネントから得たAvailability信号を調査し、さらに、操舵量管理用のコーディネータがステアリング管理を行うコンポーネント７３から得たAvailability信号を調査することで故障箇所の追跡が行われる。そして、ステアリング管理を行うコンポーネント７３が参照する操舵角の不正値を検出することで、ステアリングセンサが故障していると、故障箇所を特定することができる。

このように、上流のコンポーネントから下流のコンポーネントに順に、故障に関するデータが含まれるAvailability信号を追跡していくことで、故障箇所を無駄なく的確に特定することが可能となる。そして、このように、Availability信号をプラットフォームで管理すれば、故障診断情報の車種依存性を低下することも可能となる。

なお、このような故障箇所の追跡は、例えば、車両ディーラーがテスターを通信バス３に接続することで行われる。例えば、故障に関するデータを通信バス３に載せられるフレーム中にダイアグ信号として含めておき、テスターが通信バス３に接続されると、テスターに通信バス３に載せられたフレームからダイアグ信号が読み出され、故障箇所がテスターの表示画面に示されるようにすることができる。

続いて、Availability信号を用いた機能配分について説明する。システムコーディネータ５ｃは、Availability信号に応じて機能配分を行い、オーダ／リクエスト信号を発生させる。機能配分には、ＡＣＣ（Adaptive Cruise Control）やＥＳＣのようなドライバ状態や環境状態に応じて実施されるものと、フェールセーフ処理などシステム状態に応じて実施されるものがある。

前者はアプリケーションとして扱われ、コンポーネントのロジック設計で実現される。システムコーディネータ５ｃが扱う機能配分は後者であり、この機能配分量、つまりオーダ／リクエスト信号の値は、システム状態に依存して変化する。

そこで、システムコーディネータ５ｃでは、各コンポーネントにおけるコーディネータ内で機能配分を決定してオーダ／リクエスト信号を算出し、システム状態に応じた機能配分を実現できるようにしている。

具体的には、システムコーディネータ５ｃは、この機能配分の仕組みをアーキテクチャとしてプラットフォームに組み込むことで、従来、特別な処理として扱ってきた故障対処を正常時の処理フローと同様に扱うことができる。例えば、上述したように、故障が発生したコンポーネントでは、Availability信号が変化することになるが、このAvailability信号の変化から、システムコーディネータ５ｃがシステム状態を把握し、それに応じた機能配分を行うことになる。そして、各コンポーネントは、正常時と同様に、この機能配分で決定されたオーダ／リクエスト信号に示される内容を実現できるように処理を行う。

図１０は、システム状態の変化に応じた機能配分の変化の様子を示したものである。コーディネータは、コンポーネントＡ〜Ｃへのリクエスト信号を決定している。例えば、ブレーキ制御を行うコーディネータの場合、この図中に示したように、パーキングブレーキ、エンジンブレーキ、サービスブレーキの制御を行う各コンポーネントへのオーダ／リクエスト信号を決定する。そして、図１０（ａ）に示されるように、各コンポーネントＡ〜Ｃの機能が故障していない場合には、これらコンポーネントＡ〜Ｃという機能構成における機能許容量・機能状態量（Availability信号）に基づいて、それぞれに対して機能配分が決められることになるが、図１０（ｂ）に示されるように、そのうちの一つが故障した場合は、残ったコンポーネントに対して機能配分を行う。

このように、故障していないコンポーネントによって、故障したコンポーネントの機能の代替えを行うような機能配分が決定されるようになっている。これにより、仮に、どこかの箇所で故障が発生したとしても、それを代替するように機能配分が決定され、所望の制御が実現される。そして、このように故障していないコンポーネントによって故障したコンポーネントの機能の代替えを行ったとしても、故障していないコンポーネントに関しては、故障したコンポーネントが正常であるか故障しているかに関わらず、コーディネータから与えられたオーダ／リクエスト信号に応じた処理を実行しているにすぎない。

次に、システムコーディネータ５ｃにおけるスケジューリング管理について説明する。

上述したように、システムコーディネータ５ｃでは、システム管理者の視点でのスケジューリングを実現するために、コンポーネントを単位とした実現スケジューリングを行う。

従来の車両制御システムの実行スケジューリングは、各ＥＣＵで閉じたソフトウェア部品（例えば、始動後の噴射時間算出処理、現在の変速段判定など）を単位としたものであった。しかし、車両統合制御では、機能間で協調制御を行うため、従来どおりソフトウェア部品という細かな単位でスケジューリングするには、自機能を構成するソフトウェア部品だけでなく、他機能を構成するソフト部品のスケジューリングも把握・管理する必要がある。これは、システム設計者に各ＥＣＵの内部処理のスケジューリングを複数ＥＣＵにまたがって設計させることになり、非常に複雑かつ困難である。

そこで、ここでは、システムのスケジューリング単位を、ソフトウェア部品より抽象度が高く、車両機能として意味の有る粒度で分割されたコンポーネントとしている。これにより、システム設計者は、システムの処理フローや応答性を開発の初期段階から把握することが可能となり、大規模システムの設計などが容易となる。以下、このコンポーネントを単位とした実行スケジューリングをコンポーネントスケジューリングと呼ぶ。

具体的には、システムコーディネータ５ｃは、ドメインで分割されたシステム設計に対応するために、スケジューリングをドメインで階層的に分割して管理し、システムコーディネータ５ｃのサブセットに相当するコーディネータがドメイン内のコンポーネントスケジューリングを管理する。

図１１−ａ、１１−ｂは、実行スケジューリングの一例を示したものである。図１１−ａは、故障が発生していない通常時の実行スケジューリングを示したものであり、図１１−ｂは、故障が発生した場合の実行スケジューリングを示したものである。

これらの図に示されるように、階層Ｎのドメインでは、コーディネータがコンポーネントＮ−Ａ、Ｎ−Ｂ、Ｎ−Ｃを管理し、その下流の階層Ｎ＋１では、コーディネータがコンポーネントＮ＋１−Ａ、Ｎ＋１−Ｂ、Ｎ＋１−Ｃを管理している。

このような構成においては、通常時には、図１１−ａに示されるように、階層Ｎのドメインのコーディネータ８１は、例えば１００ｍｓ周期で起動され、その期間中にさらに上流（階層Ｎ−１）のドメインのコーディネータ（図示せず）からのオーダ／リクエスト信号が入力されると、階層Ｎのドメイン内の各コンポーネント８２〜８４のスケジューリングＡ１〜Ａ３を管理する。

そして、階層Ｎ＋１のドメインのコーディネータ８５は、例えば５０ｍｓ周期で起動され、その期間に階層Ｎのドメインのコーディネータ８１からオーダ／リクエスト信号が入力されると、階層Ｎ＋１のドメイン内の各コンポーネント８６〜８８のスケジューリングＢ１〜Ｂ３を管理する。

そして、仮に、階層Ｎのドメインのコーディネータが故障して機能を果たせなくなった場合には、図１１−ｂに示されるように、階層Ｎのドメインではコーディネータ８１が各コンポーネント８２〜８４のスケジューリングを管理できなくなる。この場合には、階層Ｎのドメイン内の各コンポーネント８２〜８４は、その下流の階層Ｎ＋１のドメインにおいて、コーディネータ８５等が上位ドメインのコーディネータの故障を認識し、コンポーネント８６〜８８に対して、状態に応じた実行スケジューリングを行う。これにより、１つの箇所で故障が発生しても、他の機能を停止させずに、自律的に機能を実行させることができる。

例えば、図３を例に挙げて説明すると、車両ドメイン１０では、車両コーディネータ１１が車両挙動コンポーネント１２やパワートレインコンポーネント１３のスケジューリングを管理する。そして、例えばパワートレインコンポーネント１３がサブドメインのパワートレインドメイン３０となり、パワートレインコーディネータ３１がそのドメイン３０内の各コンポーネント３３〜３７のスケジューリングを管理することになる。

このように、コーディネータは、各ドメインの視点で見たコンポーネントのスケジューリングを行う。ドメイン間のスケジューリングについて例を挙げて説明すると、車両ドメインのパワートレインコンポーネントに与えられた時間内にオーダ／リクエスト信号で示される要求車軸トルクを実現できるように、パワートレインコーディネータはパワートレインドメイン内のコンポーネントのスケジューリングを管理する。このように、各ドメイン内の実行スケジューリングが取られる限り、ドメイン間は非同期でよく、必ずしも同期を取る必要はない。

なお、各ドメイン内の実行スケジューリングが守られる限り、ドメイン間のスケジューリングは非同期で良いが、システムの応答時間を早めるために、ドメイン間で同期が必要になる場合があると考えられる。同期したスケジューリングとは、下流のドメインが実行スケジューリングを開始するタイミングが上流のドメインでコンポーネントとして割り当てられた開始タイミングと同時であることを意味する。

このドメイン間で同期したスケジューリングを実現するには、上流のドメインと下流のドメインが共に、制御周期を一致させた上で、コーディネータ間で通信を行う必要がある。つまり、上流のドメインで割り当てられたコンポーネントの開始タイミングを下流のドメインのコーディネータに通知する必要があり、その時点から下流のドメインの実行スケジューリングを開始しなければならない。このような理由から、同期したスケジューリングを実現したい場合には、コンポーネントの開始タイミングをコーディネータに通知する機能を分散プラットフォームに用意する。

そして、このような同期したスケジューリングで設計された場合でも、上位のコーディネータの故障が原因でシステム全体が停止しないように、下位のコーディネータまたは、コンポーネントが上位の故障を検知したら、自分の時計でもって、自律的に起動する仕組みとするのが好ましい。

さらに、システムコーディネータ５ｃは、各コンポーネントのAvailability信号と併せて、システム構造管理部５ａが提供する機能構成に応じてオーダ／リクエスト信号を算出する必要もある。また、各コンポーネントの起動、停止情報をシステム構成管理部に公開することで、ネットワーク１のスリープ、ウェイクアップ制御を可能にする。

図１２は、システムコーディネータ５ｃとシステム構造管理部５ａとの関係を示した模式図である。以下、この図を参照して、システムコーディネータ５ｃが機能配分および実行スケジューリングに使用する機能構成について説明する。

機能構成とは、電子制御装置２の動作状態に応じて処理が可能（実行可能）な状態のコンポーネントのみで構成されたものであり、上述したようにシステム構造管理部５ａによって決定される。システム構造管理部５ａは、機能構成に入っていないコンポーネントは実行不能であると判定し、コンポーネントの持つ機能を発揮できない状態にあるとみなす。

このように、コンポーネントが自分自身の判断で作成されたAvailability信号だけでなく、システム構造管理部５ａによって決定された機能構成を参照することで、システムコーディネータ５ｃは、コンポーネントの能力や状態を、より正確に把握することが可能となっている。

一方、起動、停止情報とは、コンポーネントの状態に関する情報である。上述したように、コンポーネントの機能状態量の初期状態、通常状態、異常状態、故障状態は起動状態に相当し、残る停止状態と区別される。起動状態は、コンポーネントの処理が許可された状態、停止状態は、処理を停止した状態のことをそれぞれ意味しており、システムコーディネータ５ｃが発行する起動・停止に基づいて起動状態と停止状態との間で遷移する。

起動、停止情報とは、コンポーネントが起動状態と停止状態のどちらであるか示したものであり、この起動、停止情報を用いて、システム構造管理部５ａは、ネットワーク１のスリープ、ウェイクアップ要求の管理を行っている。

このように、システムコーディネータ５ｃは、システム構造管理部５ａが提供する機能構成に応じて機能配分および実行スケジューリングを変更し、システム構造管理部５ａが管理するスリープ、ウェイクアップ制御に必要なコンポーネントの起動、停止情報を提供している。

［（３）ハードウェア抽象化層６について］
ハードウェア抽象化層６は、電子制御装置２や、センサ８、アクチュエータの電気特性などに加え、車両用ネットワーク１まで含んだハードウェアシステム全体を抽象化することで、複雑なハードウェアネットワークシステムを１つの仮想巨大ＥＣＵのように上位層に見せかける仕組みである。そのため、ハードウェア抽象化層６は、上位の階層に対しては、実際の電子制御装置２への配置先に寄らないデータ収受機能といった位置透過な実行環境を実現する機能を提供すると共に、ネットワークシステムのウェイクアップ、スリープ制御などの車両用ネットワーク１の状況管理や各電子制御装置２の動作状態、電源状態管理等の実際のハードウェアの状態管理およびその状態情報の上位階層への通知を行う機能を実現するようになっている。

ハードウェア抽象化層６は、抽象化のレベルにより、大きく２層に分けられ、下位の階層では電子制御装置２の単体レベルでのＥＣＵ本体、センサ、アクチュエータ等のハードウェアの抽象化や通信の抽象化を行い、上位の階層では電子制御装置２がネットワーク１で接続されたネットワークシステムの抽象化を行う。

具体的には、ハードウェア抽象化層６は、下位の階層に相当するＥＣＵハードウェア抽象化層６ａおよびコミュニケーション抽象化層６ｂと、上位の階層に相当するシステム抽象化層６ｃとによって構成されている。

ＥＣＵハードウェア抽象化層６ａは、ＥＣＵに載っている実在センサ等の電気的な信号を物理的な値に変換することで各物理量を求めるものである。例えば、図２中に示されるように、ＥＣＵハードウェア抽象化層６ａに所望のセンサ８（例えば、車輪速度センサ８ａやヨーレートセンサ８ｂ、加速度センサ８ｃ、操舵角センサ８ｄ等）が接続されているとすると、これら各センサ８ａ〜８ｄからはアナログのセンサ出力が入力されることになるため、これを物理的な値に変換する。そして、この物理的な値とされた物理量がシステム抽象化層６ｃや仮想センサ５ｂに通知されるようになっている。

コミュニケーション抽象化層６ｂは、通信プロトコルおよび通信に際して、各データが格納されるフレーム構成などを隠蔽し、上位の階層に対してシグナルベースのＩ／Ｆを提供するものである。

システム抽象化層６ｃは、複数の電子制御装置２がネットワーク１で接続されたハードウェアネットワークシステムのＥＣＵ構成などを隠蔽し、あたかも１つの仮想巨大ＥＣＵにみせかけるため、上位の階層が共通で必要とするコンポーネント通信といったサービスの提供や、ネットワークシステムのＢＵＳ制御（ウェイクアップ／スリープ）および車両用ネットワーク１上の通信ノードの検出、さらに他の階層でのハードウェア故障検出などに必要となる電源状態情報の提供などの機能を提供する。

このシステム抽象化層６ｃでは、コミュニケーション抽象化層６ｂからの情報とＥＣＵハードウェア抽象化層６ａからの情報とが区別すること無く、同じＩ／Ｆとして扱われる。例えば、上位の階層となるシステムインフラ層５から「車速に関する情報を得よ」という指令があった場合には、システム抽象化層６ｃは、コミュニケーション抽象化層６ｂから得た車速に関するデータであろうが、ＥＣＵハードウェア抽象化層６ａが自ら車速センサの検出信号を物理的な値としたデータであろうが、分け隔てなく、その車速に関するデータを上位の階層に通知する役割を果たす。なお、この場合において、その情報がコミュニケーション抽象化層６ｂからのものかＥＣＵハードウェア抽象化層６ａからのものかを情報にＩＤ等を付すことにより、上位の階層で認識できるようにすることは可能である。

そして、システム抽象化層６ｃは、ＥＣＵハードウェア抽象化層６ａおよびコミュニケーション抽象化層６ｂから得た情報に基づいて、各電子制御装置２や車両用ネットワーク１等の各ハードウェアの状態量をシステム構造管理部５ａに通知するようになっている。

このハードウェア抽象化層６が、上述した特許文献１に示される通信プログラム部やドライバ部に相当するものである。これら通信プログラム部やドライバ部に関しては、特許文献１において公知なものとなっているため、ここでは説明を省略する。

以上のような電子制御装置２によれば、ＥＣＵ内の構造をアプリケーション層４、システムインフラ層５、ハードウェア抽象化層６という３つの階層に分け、アプリケーション層４に備えられる機能構成フレームワーク４ａに制御ロジック７を差し込むだけで、システムを実現できる構造とすることができる。そして、制御ロジック７以外の部分に関しては、各電子制御装置２間で共通となっている。このため、役割分担を明確化でき、分業・協業をし易くすることが可能となる。

このため、複雑な大規模システム開発を行う上での開発期間の短縮化、品質・信頼性確保、および、バリエーション対応を行う上での開発期間の短縮化に対応することが可能となる。

さらに、アプリケーション層４およびシステムインフラ層５において、上流から下流にかけて多岐に渡って機能構成フレームワーク４ａを構築し、各機能構成でオーダ／リクエスト信号、Availability信号、および、センサ信号を管理している。

このように、オーダ／リクエスト信号で示される制御指示量・制御要求量とAvailability信号で示される機能許容量・機能上耐量を制御機能開発の枠組みとして有し、さらに、センサ信号で示される制御可観測状態量を制御アルゴリズムとは分離された基盤制御ソフトウェア内で算出し、制御開発に提供する機能を有したものとしている。

また、例えば、どこかで故障が発生したとしても、その故障が示されているであろうAvailability信号を確認することで、その故障を特定できるようにしている。このため、信頼性の高い電子制御装置２とすることができる。

また、各機能構成では、コーディネータにて、Availability信号および仮想センサ５ｂに蓄積された可観測状態量に基づいて、オーダ／リクエスト信号を作成している。このため、下流のコンポーネントの状態に応じた機能配分を行うことができる。すなわち、故障していないコンポーネントによって、故障したコンポーネントの機能の代替えを行うような機能配分とすることができる。

（他の実施形態）
上述したように、Availability信号で示される機能許容量・機能状態量に応じてオーダ／リクエスト信号が作成され、機能許容量・機能状態量の範囲内で制御指示量・制御要求量が決められる。逆に、Availability信号で示される機能許容量・機能状態量の範囲を超える制御指示量・制御要求量が設定されていることが各コンポーネント６２に伝えられた場合には、各コンポーネント６２で異常とみなすことができる。したがって、このような場合には、各コンポーネント６２で、コーディネータ６１からの要求を受け付けないもしくは後述するシステム調停部にて異常処理が実行されるようにしても良い。

例えば、図１３に示されるように、車両ドメイン１０に、各コンポーネント７２、７３、７５、７６、７８、７９、９０から送られてくるAvailability信号に含まれる機能許容量・機能状態量の情報からシステム状態を判定し、その結果に基づいて最適な機能要求量を決定するシステム調停部９１を制御機能とは独立して持たせるようにする。このような構造とすることで、従来、個別に故障処置などをしていた処理をシステム全体から最適化させることが容易となる。

また、上記のようなシステム調停部９１を車両システムに１つ用意するのではなく、機能構造の各階層に設け、階層単位でサブシステム調停を行うようにしても良い。例えば、図１４に示されるように、車両運動操安性管理ドメインにおいて、サブシステム調停部９２が設けられている場合において、そのドメイン内の任意のコンポーネント（図中では駆動力管理のコンポーネント）が故障した場合に、その故障した部分だけを切り離し、残された機能構成によって車両システムを実現するようにしても構わない。

上記実施形態では、各電子制御装置２に備えられる仮想センサ５ｂは、算出した可観測状態量を通信バス３を通じて、すべての電子制御装置２または関係する電子制御装置２に送信し、得られた可観測状態量を全体で共有する場合について説明した（図５参照）。しかしながら、これは単なる一例を示したものである。

例えば、必要な可観測状態量を算出するために必要な情報を通信バス３を使って、全電子制御装置２または関係する電子制御装置２に送信し、各電子制御装置２にて必要な可観測状態量を同一ロジック、または各電子制御装置２毎に用意されたロジックで算出することも可能である。

また、可観測状態量を算出するための中間演算値（もしくは複数の算出後の可観測状態量を圧縮したもの）を通信バス３を通じて、全電子制御装置２または関係する電子制御装置２に送信し、各電子制御装置２にて必要な可観測状態量を同一ロジック、または各電子制御装置２毎に用意されたロジックで算出することも可能である。

上記実施形態では、各電子制御装置２が３つの階層によって構成されている例を挙げて説明したが、これは電子制御装置２が３つの階層のみによって構成されているという意味ではない。例えば、３つ以上の階層によって構成されていても良いし、３つの階層のいずれかが統合されて２つの階層となっていても構わない。

本発明の第１実施形態における車両用ネットワークの概略図である。 図１に備えられる個々の電子制御装置の基本構造を示したブロック図である。 車両用ネットワークに備えられる機能構成の概略図である。 各コンポーネントが構成するドメインの基本構造を示した図である。 複数の電子制御装置２間での可観測状態量のデータの通信形態の一例を示した図である。 仮想センサからのセンサ信号がシステムコーディネータに通知される様子を示した図である。 システムコーディネータの機能を模式的に示した図である。 各ドメイン内の役割を示した図である。 故障箇所の追跡の模式図である。 システム状態の変化に応じた機能配分の変化の様子を示した図である。 故障が発生していない通常時の実行スケジューリングを示した図である。 故障が発生した場合の実行スケジューリングを示した図である。 システムコーディネータとシステム構成管理部との関係を示した模式図である。 車両システムにシステム調停部を設けた場合のブロック構成を示した模式図である。 車両システムにおける各階層にサブシステム調停部を設けた場合のブロック構成を示した模式図である。

符号の説明

１…車両用ネットワーク、２…電子制御装置、３…通信バス、４…アプリケーション層、４ａ…機能構成フレームワーク、５…システムインフラ層、５ａ…システム構造管理部、５ｂ…仮想センサ、５ｃ…システムコーディネータ、６…ハードウェア抽象化層、６ａ…ＥＣＵハードウェア抽象化層、６ｂ…コミュニケーション抽象化層、６ｃ…システム抽象化層、７…制御ロジック、８…センサ、１０…車両ドメイン、１１…車両コーディネータ、１２…車両挙動コンポーネント、１３…パワートレインコンポーネント、２０…車両挙動ドメイン、２１…車両挙動コーディネータ、２３…車両安定化コンポーネント、３０…パワートレインドメイン、３１…パワートレインコーディネータ、３３…スタータ制御コンポーネント、３４…クラッチ制御コンポーネント、３５…トランスミッション制御コンポーネント、３６…アイドルストップ制御コンポーネント、３７…エンジン制御コンポーネント、４０…車両安定化ドメイン、４１…ディファレンシャル制御コンポーネント、４３…ブレーキ制御コンポーネント、４４…全輪駆動制御コンポーネント、４５…ステアリング制御コンポーネント。

Claims (10)

1. 制御機能が実装された複数の電子制御装置（ＥＣＵ）（２）を有し、該複数の電子制御装置（２）が通信バス（３）を通じて接続されることで、前記複数の制御機能間でデータの送受信を行うように構成された車両用ネットワークであって、
   前記電子制御装置（２）は、
   制御内容が示された制御ロジック（７）が差し込まれることで、この制御ロジック（７）に示された制御内容を実現する機能構成フレームワーク（４ａ）と、
   機能構成に含まれる各機能の能力、状態に応じた制御要求を発行すると共に、各機能構成における機能の実行スケジューリングを決定するシステムコーディネータ（５ｃ）と、
   前記複数の電子制御装置により実現される機能に関するデータを記憶していると共に、前記機能の中から最適な機能を抽出し、これを前記機能構成として管理するシステム構造管理部（５ａ）と、
   前記複数の電子制御装置（２）で用いられる可観測状態量のデータを管理し、そのデータから前記可観測状態量に関するデータをセンサ信号として出力する仮想センサ（５ｂ）と、
   前記電子制御装置（２）を含むハードウェアシステム全体を抽象化し、前記システム構造管理部（５ａ）および前記仮想センサ（５ｂ）に対して、前記ハードウェアシステム全体を１つの仮想巨大電子制御装置として見せかけるハードウェア抽象化部（６）とを有していることを特徴とする車両用ネットワークシステム。
2. 前記機能構成フレームワーク（４ａ）によって構成されるアプリケーション層（４）と、
   前記システム構造管理部（５ａ）、前記仮想センサ（５ｂ）および前記システムコーディネータ（５ｃ）によって構成されるシステムインフラ層（５）と、
   前記ハードウェア抽象化部（５）からなるハードウェア抽象化層（６）の３層によって構成されていることを特徴とする請求項１に記載の車両用ネットワークシステム。
3. 前記機能構成フレームワーク（４ａ）は、階層化された機能構造を有しており、その各階層には、オーダ／リクエスト信号を作成するコーディネータ（５０）と、前記オーダ／リクエスト信号を受けて所定の機能を実現すると共に、その機能を実現可能か否かもしくは実現可能な範囲を示した機能状態量・機能許容量を表すAvailability信号を作成する機能的コンポーネント（５１）と、が備えられ、
   前記コーディネータ（５０）は、前記Availability信号および前記仮想センサ（５ｂ）が発するセンサ信号に基づいて、前記オーダ／リクエスト信号を作成しており、
   前記コンポーネント（５１）は、前記仮想センサ（５ｂ）が発するセンサ信号に基づいて、前記Availability信号を作成するようになっていることを特徴とする請求項１または２に記載の車両用ネットワークシステム。
4. 前記ハードウェア抽象化部（６）は、前記複数の電子制御装置を含むハードウェアシステムに含まれるハードウェアの状態量を前記システム構造管理部（５ａ）に通知するようになっており、
   前記システム構造管理部（５ａ）は、前記ハードウェアの状態量に基づいて、前記機能の中から最適な機能を抽出して機能構成を決定するようになっていることを特徴とする請求項１ないし３のいずれか１つに記載の車両用ネットワークシステム。
5. 前記仮想センサ（５ｂ）は、前記ハードウェアシステムに含まれる実在センサ（８）の検知信号から求められた物理量や、その物理量から求められた前記実在センサ（８）では求められない物理量を可観測状態量として、該可観測状態量のデータを管理するものであることを特徴とする請求項１ないし４のいずれか１つに記載の車両用ネットワークシステム。
6. 前記システムコーディネータ（５ｃ）は、前記機能構成フレームワーク（５ａ）によって階層化された機能構造に含まれる機能を実現すべく、各階層毎に、オーダ／リクエスト信号および実行スケジューリングを作成するコーディネータ（６１、８１、８５）と、前記オーダ／リクエスト信号および前記実行スケジューリングを受けて所定の機能を実現すると共に、その機能を実現可能か否かもしくは実現可能な範囲を示した機能状態量・機能許容量を表すAvailability信号を作成するコンポーネント（６２、８２〜８４、８６〜８８）とを備えており、
   前記コーディネータ（６１、８１、８５）は、前記Availability信号および前記仮想センサ（５ｂ）が発するセンサ信号に基づいて、前記オーダ／リクエスト信号を作成すると共に、前記コンポーネント（６２、８２〜８４、８６〜８８）の実行スケジューリングを行い、
   前記コンポーネント（６２、８２〜８４、８６〜８８）は、前記仮想センサ（５ｂ）が発するセンサ信号に基づいて、前記Availability信号を作成すると共に、前記実行スケジューリングに基づいて前記所定機能を実現するようになっていることを特徴とする請求項１ないし５のいずれか１つに記載の車両用ネットワークシステム。
7. 前記ハードウェアシステムのいずれかの箇所で故障が発生した場合には、前記Availability信号のうち前記故障を示すデータが含まれているものが記憶されるようになっていることを特徴とする請求項６に記載の車両用ネットワークシステム。
8. 前記通信バス（３）にテスタが接続されたときに、前記故障を示すデータが含まれるAvailability信号に基づき、故障箇所が前記テスタに示されるようになっていることを特徴とする請求項７に記載の車両用ネットワークシステム。
9. 前記システムコーディネータ（５ｃ）では、前記階層のいずれかに備えられたコーディネータ（６１、８１、８５）が故障した場合に、その階層中に含まれる前記コンポーネント（６２、８２〜８４、８６〜８８）は、これら各コンポーネント（６２、８２〜８４、８６〜８８）が構成する階層に備えられるコーディネータで自律的に実行スケジューリングを行うようになっていることを特徴とする請求項６ないし８のいずれか１つに記載の車両用ネットワークシステム。
10. 請求項１ないし９のいずれか１つに記載の車両用ネットワークシステムに備えられた電子制御装置。
    

Images