JP7482135B2 - 搭載システムの電子アーキテクチャ - Google Patents

Description

本発明は、搭載システムの電子アーキテクチャに関する。特に、本発明は、動力車の機能を管理するためのシステムに適用される。本発明は、特に全ての種類の動力車に適用され、より一般的には、任意の分散型サイバー／物理的システムに適用される。

動力車の電子アーキテクチャの主な目的は、車両の特徴、即ち車両の機能（ユーザから見えるかどうかに関わらず）を正しく実行できるようにすることである。簡単に言うと、各機能は、１つ又は複数のセンサ又はコンピュータによって送信される入力データ、及びそれらのデータを処理するための手段を必要とし、また、出力データを生成して、１つ若しくは複数のアクチュエータを制御するか又は１つ若しくは複数のコンピュータに使用する。アクチュエータもデータを送信することがあり、センサがデータを受け取ることがあることに、留意されたい。機能の数は、安全性、快適さ、又は例えば信頼性のために、初期の動力車以降、急激に増加している。更に、これらの機能は、必要とされる計算の観点であろうと又は処理されるデータの観点であろうと、非常に異なる性質のものであり得る。例えば、１つの機能が、単純に運転者によってセンサが押されたときにモーターを応答させることから構成されることがあるが、一方で、車両の前方の障害物を検出するために、複数の高速カメラストリームを使用することがある複雑な運転支援システムも存在する。

１つの非常に重要な点としては、安全性及びセキュリティに関して、それらの機能は同じ感度を有している訳ではないという事がある。従って、一部の機能は、車両が正しく機能するために重要ではない一方で、他の機能の故障は、乗員の命を危険にさらすことがある（例えば、高速道路でエアバッグをトリガーすることなど）。従って、データの取得、計算、及びアクチュエータへのコマンド配信、に関する時間の管理は、この情報のセキュリティと同様に、非常に重要な側面である。

車両への組み込みに関連した幾つかのポイントも、考慮に入れる必要がある。第一に、システムのサイズ及び重量は、重大な問題である。それらは、管理しやすいエネルギー消費量とし且つ車両を妥当なサイズに保つために、出来る限り小さいことが必要である。システムのサイズに関する別のポイントは、センサ、アクチュエータ、及びコンピュータ資源の相互接続に関する。即ち、配線の量を、同じ理由により、出来る限り少なく保たなければならない。第二に、アーキテクチャの経済的コストを考慮しなくてはならない。車両の価格が著しく高くならないように、アーキテクチャは、出来る限り正確にサイズ決定されなくてはならない。しかしながら、製造コストのこの最適化は、車両に組み込まなければならない将来の機能の性能ニーズを、アーキテクチャが満たせなくなること、並びに将来のセンサ及びアクチュエータ（例えば、高解像度カメラ等）の組み込みを妨げること、のないようにすべきである。実際、ゼロからアーキテクチャを再開発することは、非常に高くつく。

アーキテクチャの開発における別の非常にコストのかかる側面は、車両に組み込まれることになる機能の発見が遅れる事に関する。

要約すると、対処すべき技術的な課題とは、車両の現在の及び将来の機能を進化させ且つ確実に実行することができる電子アーキテクチャを提供し、従って、十分な相互接続手段及び計算力、並びにセキュリティ、安全性、及び時間管理特性を提供することができることである。これらの有利な特性は、管理可能な複雑さ及びまとまりで提供されなくてはならない。

現在の解決策は、自動車開発の様々な時代を反映している。以降では、主な動作タイプに従って完全なアーキテクチャを提示するために、先行技術を示す。

動力車の初期の頃には、機能の数ははるかに少なく、それらの機能は主として機械的に且つ手動で実行されていた（例えば、エンジンの始動など）。１９００年代の始めの、電子エンジン点火の導入が、長い旅路の最初のステップであった。これは、乗客の快適性及び安全性を向上させることを目的として、次第に複雑になる機能を導入するために、車両に電子システムを追加することにつながった。

これらのシステムの標準化により、１９７０年代の終わりにＥＣＵ（電子制御ユニット）の指定が導入された。各ＥＣＵは、コンピュータ資源（プロセッサ又はマイクロコントローラ）から構成され、このコンピュータ資源は、一般的に、メモリ、入力部／出力部が、コスト面の理由により、出来る限りスリム化されるように適合されている。従って、車両内に多数の電子システムが登場して以来、動力車の機能の実行は、互いにリンクされた、且つ相互接続ネットワーク／ケーブルを介してセンサ／アクチュエータにリンクされた、自律的搭載システムの使用に、非常に大きく依存してきた。本発明は、現在の全ての車両を表す、ＥＣＵを使用した車両アーキテクチャのカテゴリーに分類される。

実用的には、１９７０年代以来、この分野でのイノベーションは、有利な車両動作特性を提供することを可能にした技術的進歩のおかげで、新たなアーキテクチャを導入することにより、達成されてきた。以下では、自動車アーキテクチャの様々な時代の概要が、これを背景として本発明を位置付けるために、提示される。

最初の電子アーキテクチャは、完全に分散型であった。それらのアーキテクチャは、センサ、アクチュエータ、コンピュータ、及び相互接続ケーブルを含めて、車両機能毎に専用のサブシステムを導入することから構成されていた。

機能の数が増えるにつれ、且つ機能が次第に互いに依存するようになる（特にデータ共有）につれ、複雑さの制御を保つために、適切な電子アーキテクチャを実装することが必要になった。しかしながら、（リソース間の専用リンクに基づく）これらのアーキテクチャにより生成されたネットワークは、非常に複雑になり、（特に、統合するうえでの複雑さ、過剰な重量の点で）もはや車両内で耐えられない過剰な配線をもたらした。

１９８０年代／１９９０年代には、信号の多重化を可能にするプロトコル及びバスの到来が、許容可能なレベルの複雑さに戻るための、重要なポイントになった。これらの技術により、同じ通信手段を複数のＥＣＵで使用して、複数の異なるデータを送信することが可能になり、従って、ケーブルの数（及び、特に重量）が大幅に低減された。センサは、もはや、そのセンサを使用する電子システムの全てに直接的に接続する必要はなくなった。センサは、１つの電子システムのみに接続され、このデータは、多重化されたバスを介して、他の電子システムに伝達された。サイズ決定が適切に行われた場合、プログラムされることになるＥＣＵの機能、及び多重化バスの使用により、余分にコストをかけることなく、追加の機能を稼働させることが可能になる。しかしながら、新規の機能を追加するには、通常、ネットワークに別のＥＣＵを追加することが必要である。

技術の進歩のおかげで、今なお、多重化技術により、現在の自動車システムを製造することが可能になる。時間の経過とともに、特に、共有の必要性に起因して、又はビットレート、時間管理、若しくは信頼性要件などの特定の制約に起因して、ネットワークの特殊化が発生した。従って、現代の車では、異なる規格による複数のバスが共存しているのを見ることは珍しくない。

マルチメディアデータのためのビットレートの増加により、より高速のビットレートへの切替が必要になった。従って、イーサネットなどの、コンピュータの世界で試みられ試験された標準相互接続技術を使用することが、過去数年間の間に、徐々に確立されてきた。分散したＥＣＵ間で様々な種類のマルチメディアデータを送信することから、データをストリーミングするための、特に画像及び音を同期させるための技術を定義する必要が生じた。

同時に、特に圧縮していないビデオ画像を送信するための、専用リンクが出現した。リンクは、異なるチャネルを介して、ビデオ、オーディオ、イーサネット・トラフィック、及び通信プロトコルを送信するためにも利用可能である。

図１は、動力車を管理するための現在の電子アーキテクチャのハイレベルの概要を示す。様々なＥＣＵ１が、多重化されたＣＡＮ（コントローラ・エリア・ネットワーク）バス１１、１２、１Ｎ上で一緒にグループ化され、専用のＥＣＵ１０（ＣＡＮゲートウェイ）が、時間制約を監視しながら、あるＣＡＮバスから別のＣＡＮバスへの移動を可能にする。しかしながら、この通常のアーキテクチャは、例えばＣＡＮで可能なビットレートよりも高いビットレートを必要とする機能を追加することにより、障害が生じる。従って、例えば、破線２は、２つのＥＣＵを互いに接続する直接リンクを示す。

従って、多重化による制御の下でもたらされる複雑さが、再度問題になる。現在、ハイエンドの車両では７０を超えるＥＣＵが存在し、それらは、異種のサブネットワークから構成される、益々複雑になるネットワークによって相互接続され、結果的にケーブルのもつれを生じさせる。これは、コスト、追加の重量、及び複雑な維持保守を発生させる。

多重化の出現によりアーキテクチャの複雑さが低減可能になったように、自動車分野の中で新たな技術を採用することにより、将来世代とみなされる、新しいカテゴリーのアーキテクチャ、即ち、ドメインの存在に基づくアーキテクチャの出現が可能になった。機能ドメインに基づくアーキテクチャの一例が、図２に示されている。全体的な発想は、図１の概要を再使用するものの、同じ機能ドメインに属するＥＣＵ１を、そのドメインの制約に適合された、専用の多重化バス２１の周りに一緒に強力にグループ化することであり、ＥＣＵ及びバスは、ドメインコントローラユニット２２（ＤＣＵ）によって、ドメイン毎に駆動される。ドメイン、ドメインコントローラ、及びドメインをマルチメディア側面、接続性にリンクさせるためのアプリケーションサーバ／ゲートウェイ２４ごとに階層レベルを導入すること、これは、製造メーカー及び機器製造メーカーによって現在探求されている道筋である。

これまで、機能ドメインに基づくアーキテクチャには、大きな重点は置かれてこなかった。ドメインの概要は有利である、というのも、全く同一の機能ドメインの機能（従ってＥＣＵ）は、少なくともデータ交換の観点で、同様の特性を有するものとみなすことができ、従って、ドメインのＥＣＵを相互接続するネットワークを最適化することができるからである。この概念の長所の１つは、ＡＤＡＳ（先進運転支援システム）ドメインをそれ以外から分離できることである、というのも、ＡＤＡＳドメインは、マルチメディアの側面と共に、現在最も求められているドメインだからである。

例えば、図２では、マルチメディアドメイン２３のＥＣＵは、１Ｇｂｉｔｓ／ｓのファストイーサネットネットワークに接続されており、一方、他のドメインは、２Ｍｂｉｔｓ／ｓのＣＡＮ ＦＤネットワークのみを必要としていることが分かる。

しかしながら、実際には、弱点が既にみられる。例えば、この分配は、車両内のＥＣＵ、センサ、及びアクチュエータの位置を考慮に入れていない。従って、ある機能ドメインのセンサ及びアクチュエータは、配線を伴う、そのドメインのＥＣＵの地理的に近くにある、という保証はない。同様に、ドメインコントローラは、別のＥＣＵを追加する。最適化されたアーキテクチャという文脈では、物理的なアーキテクチャが、機能の変更に適合するように十分に柔軟性がある、という保証はない。別の問題点は、実際には、機能ドメインのＥＣＵ上で実行される機能は、特に、安全性レベル、感度レベル、又は処理若しくはデータのタイプの観点で、現に非常に異質である、という事に関係している。これらの状況の下では、起こり得る「最悪の場合」を低減することにより、ＥＣＵ間の相互接続を最適化することとは別に、コンピュータを一段と最適化すること、及び共有によりコンピュータの数を減らすこと、は両方とも、非常に複雑である。

既に提案されているアーキテクチャの一部では、弱点の１つは、特に、ロジック及びソフトウェア機能のハードウェアＥＣＵへの割り当てが固定化しているという事、及びその機能に対するこのＥＣＵの最適化、にある。従って、アーキテクチャの何らかの修正は容易ではない。例えば、ドメインを追加すること、又は、あるドメインに、そのドメインに属していないセンサからの出力若しくはアクチュエータの制御を必要とする、新規の機能を追加することは、複雑な通信を実装することを必要とする。

ＲＡＣＥ（Ｒｏｂｕｓｔ ａｎｄ Ｒｅｌｉａｂｌｅ Ａｕｔｏｍｏｔｉｖｅ Ｃｏｍｐｕｔｉｎｇ Ｅｎｖｉｒｏｎｍｅｎｔ ｆｏｒ Ｆｕｔｕｒｅ ｅＣａｒｓ）と呼ばれるより先進的なアーキテクチャが、特に、Ｓｏｍｍｅｒら著の、ＩＥＥＥ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｅｌｅｃｔｒｉｃ Ｖｅｈｉｃｌｅ Ｃｏｎｆｅｒｅｎｃｅ（ＩＥＶＣ）、サンタクララ、カリフォルニア州、２０１３年、の「ＲＡＣＥ：Ａ Ｃｅｎｔｒａｌｉｚｅｄ Ｐｌａｔｆｏｒｍ Ｃｏｍｐｕｔｅｒ Ｂａｓｅｄ Ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ Ａｕｔｏｍｏｔｉｖｅ Ａｐｐｌｉｃａｔｉｏｎｓ」という文献で提示されている。ＲＡＣＥアーキテクチャは、リングトポロジーを開示している欧州特許第２ ６７０ ０８７号明細書中に特に記載されているように、動作面の安全性特性を確保できるトポロジーに従って、イーサネットネットワークによって互いにリンクされた１つ又は複数のＶＣＣ（ｖｅｈｉｃｌｅ ｃｏｎｔｒｏｌ ｃｏｍｐｕｔｅｒｓ）から構成されるＣＰＣ（ｃｅｎｔｒａｌｉｚｅｄ ｐｌａｔｆｏｒｍ ｃｏｍｐｕｔｅｒ）と呼ばれる中央集中型コンピュータに基づいている。ＲＡＣＥの原理の１つは、車両のセンサ及びアクチュエータはスマートでなければならない、即ち、それら自体が、ローカル処理に関係したデータを使用し管理する、という事である。従って、ＣＰＣは、イーサネットネットワークを介して、それら自体を管理することができるスマートなセンサ／アクチュエータにリンクされる。ＲＡＣＥアーキテクチャは、機能ドメインに基づくアーキテクチャと似ているが、ドメインが車両中でよりローカライズされ、ハイレベルな機能によって一緒にグループ化されていない、という点が異なる。ＲＡＣＥアーキテクチャは、制御レベルに大いに階層性が残っており、センサ／アクチュエータ制御ループを含めてドメインを管理する、これらの新しいスマートセンサ／アクチュエータの存在を前提としている。ＲＡＣＥアーキテクチャの利点の１つは、特定のドメインへのハードウェアの割当ては小さいという意味で、ソフトウェアとハードウェアとの間に実質的に大幅な分離が存在することである。しかしながら、スマートセンサ／アクチュエータで動作するローカル制御ループと、車両内のそれらの位置との間には、強い結合が残されたままである。従って、アーキテクチャは完全に中央集中型ではなく、制御の重要な部分はローカルである。その結果、（センサ／アクチュエータ、ソフトウェア等のレベルでの）アーキテクチャの修正には、例えばＣＰＣレベルでの管理のために、複雑なメッセージ／データルートを伴う複数の制御ループを修正することが必要である。同様に、センサ／アクチュエータに知能を追加するには、コンピュータ資源をローカルに追加することが必要であり、これは、車両の電子アーキテクチャのコストを大幅に増加させる。

欧州特許第２ ６７０ ０８７号明細書

Ｓ．Ｓｏｍｍｅｒ ｅｔ ａｌ "ＲＡＣＥ：Ａ Ｃｅｎｔｒａｌｉｚｅｄ Ｐｌａｔｆｏｒｍ Ｃｏｍｐｕｔｅｒ Ｂａｓｅｄ Ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ Ａｕｔｏｍｏｔｉｖｅ Ａｐｐｌｉｃａｔｉｏｎｓ"，ＩＥＥＥ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｅｌｅｃｔｒｉｃ Ｖｅｈｉｃｌｅ Ｃｏｎｆｅｒｅｎｃｅ（ＩＥＶＣ），Ｓａｎｔａ Ｃｌａｒａ，ＣＡ，２０１３

本発明の目的は、前述の欠点を克服することである。この目的のために、本発明はシステムの機能の管理を実行する前述のシステムに埋め込まれた電子アーキテクチャに関し、前述の機能はセンサ及びアクチュエータの組を介して実現され、前述のアーキテクチャは、少なくとも、
－ 中央コンピュータと、
－ リアルタイム通信ネットワークと、
－ 前述のシステムの地理的領域にそれぞれ割り当てられたインターフェースモジュールの組と、を含み、各モジュールは、
ｏ それに割り当てられた領域の前述のセンサのうちの少なくとも１つからの信号を集め、前述の信号を前述の通信ネットワークを介して前述の中央コンピュータに送信し、
ｏ 且つ／又は、それに割り当てられた領域の前述のアクチュエータのうちの少なくとも１つに制御信号を配信し、
前述の中央コンピュータは、前述のセンサからの信号に従って前述のアクチュエータを駆動し、前述のアクチュエータの制御信号は、前述の通信ネットワークを介して前述のインターフェースモジュールに送信される。

前述のインターフェースモジュールの少なくとも１つは、複数の機能ドメインのセンサからの信号を集め、且つ／又は複数の機能ドメインのアクチュエータにコマンドを配信し、前述のセンサ及びアクチュエータは、前述の少なくとも１つのモジュールに割り当てられた地理的領域の中に配置される。

例えば、前述のインターフェースモジュールのうちの少なくとも１つは、また、前述のアクチュエータのうちの少なくとも１つからの信号を集め、且つ／又は信号を前述のセンサのうちの少なくとも１つに配信する。

１つの特定の実施形態では、前述の中央コンピュータはマザーボード及びコンピュータサブシステムから構成され、各サブシステムは１つ又は複数のプロセッサを含み、プロセッサはプライベートメモリに結合され、複数のソフトウェアパーティションを実行することができ、前述のサブシステムは、前述のマザーボードに実装された相互接続インフラストラクチャーによって、互いに及び前述の通信ネットワークと通信する。

前述のアーキテクチャは、例えば、データを管理するための中央集中型機能ブロックを含み、それにより、コンピュータ及び前述のモジュールに存在するメモリのデータへのアクセスが可能になり、前述の機能ブロックは、前述のアーキテクチャの様々なコンポーネントに、前述のシステム内に分散したセンサ及びアクチュエータに関連したデータ、並びに前述のコンピュータサブシステムによって生成されたデータ、への一元化されたアクセスを提供する。

前述の機能ブロックは、例えば、前述のコンピュータと前述のモジュールとの間で仮想的に共有される分散型メモリサービスによって実装され、その結果、前述の中央コンピュータと前述のセンサ及びアクチュエータとの通信の全ては、前述の仮想メモリを通過するようになり、且つ、前述のアーキテクチャ並びにセンサ及びアクチュエータの全てに分散したメモリは、前述の中央コンピュータからは単一の共有メモリとして見えるようになる。

前述の機能ブロックにより、データに関連した属性の使用を介して、データへのアクセスを保護することが可能になる。

前述のアーキテクチャは、例えば、前述のコンピュータサブシステム間の同期をもたらす機能ブロックを含む。

前述のアーキテクチャは、例えば、前述のシステムの動作信頼性と結びついたサービスを提供し支援する機能ブロックを含む。

１つの特定の実施形態では、前述のインターフェースモジュールは、少なくとも、
－ 通信プロセッサと、
－ 前述のプロセッサとアクチュエータ及び／又はセンサとの間の通信インターフェースと、
－ 前述のプロセッサと前述の通信ネットワークとの間の通信インターフェースと、を含み、
前述の通信プロセッサは、前述のセンサからのデータを、前述の通信ネットワークを介して前述の中央コンピュータに送信するために、且つ、前述の中央コンピュータからのコマンドデータを、前述の通信ネットワークを介して前述のアクチュエータに配信するために、前述のセンサからのデータをパケットに整える機能を有する。

前述のプロセッサと前述のアクチュエータ及び／又はセンサとの間の前述の通信インターフェースは、異なるタイプのものであり、前述のプロセッサは、単一のプロトコルに従って前述のデータを前述の中央コンピュータと交換するために、例えば、前述のインターフェースの通信プロトコルを変換する。

前述のアーキテクチャは、例えば、前述の通信ネットワークを少なくとも１つの他の通信ネットワークに接続することができる、少なくとも１つのゲートウェイを含む。

このアーキテクチャは、例えば、前述のゲートウェイ（３５）によって、前述の通信ネットワークと通信する二次コンピュータを含み、前述の二次コンピュータは、前述の他のネットワークに接続される機能を駆動する。

このアーキテクチャは、例えば、複数のソフトウェアパーティションを実行することに加えて、技術の組み合わせを含み、前述の組み合わせは仮想ドメインを形成し、各仮想ドメインは、センサ及びアクチュエータのグループのインターフェースモジュール（３３）を処理する前述のパーティションのうちの少なくとも１つをカバーする。前述の組み合わせは、例えば、前述のリアルタイム通信ネットワークにおけるデータ伝送分離機構の組み合わせを含む。前述の組み合わせは、例えば、前述のインターフェースモジュールによって据えられるデータ属性に基づいている。

前述の中央コンピュータと前述のインターフェースモジュールとの間の通信は、例えば、前述のコンピュータによって制御される。

前述のアーキテクチャは、例えば、高い伝送速度で入力信号及び出力信号を管理するためのサブシステムを含み、このサブシステムは、前述のマザーボードの相互接続インフラストラクチャーに接続され、前述のサブシステムは、１つ又は複数のドーターボードから構成され、高い伝送速度を備えたセンサ及び／又はアクチュエータと、前述の中央コンピュータとの間でインターフェースモジュールの機能を実行する。

前述の通信ネットワークは、時間確定性イーサネット（ｄｅｔｅｒｍｉｎｉｓｔｉｃ Ｅｔｈｅｒｎｅｔ）タイプのものであり、例えば、ＴＳＮイーサネットタイプのものである。

本発明の他の特徴及び利点が、添付の図面を参照しながら与えられる、以下の説明から明らかになるであろう。

既に説明したが、現在の動力車で可能な電子アーキテクチャのハイレベルの概要を示す。 既に説明したが、ドメインに基づくアーキテクチャの一例を示す。 それぞれ、従来技術によるアーキテクチャ及び本発明によるアーキテクチャを示す。 それぞれ、従来技術によるアーキテクチャ及び本発明によるアーキテクチャを示す。 動力車の様々な可能な機能に対処する、本発明によるアーキテクチャをより詳細に示す。 本発明によるアーキテクチャの中で使用される中央コンピュータの１つの例示的な実施形態を示す。 異質なセンサ／アクチュエータを中央コンピュータに接続するために、それらの異質なセンサ／アクチュエータのそれぞれを集約するインターフェースモジュールを用いた、本発明によるアーキテクチャを示す。 本発明によるアーキテクチャの中で使用されるインターフェースモジュールの１つの例示的な実施形態を示しており、このインターフェースモジュールは、車両内に分散したセンサ及びアクチュエータと交換される信号を集める。 本発明によるアーキテクチャにおける仮想リンクを使用するおかげで実現される、仮想ドメインを示す。 様々な貢献者と共に、本発明によるアーキテクチャにおける仮想ドメインを示す。 図９が、高速入力及び出力を管理するためのサブシステムを含んでいる様子を示す。

本発明の以下の説明は、車両の搭載システムについて例として与えられる。しかしながら、本発明は、他の搭載システム、移動体、又はその他にも適用される。

図３ｂは、従来技術によるアーキテクチャを示す図３ａを参照しながら、本発明による動力車用の電子アーキテクチャの原理を示す。

より具体的には、図３ａは図２の従来技術によるアーキテクチャを真似ているが、ＥＣＵによって駆動される処理及び機能を示しており、車両３０におけるＥＣＵの地理的位置を示唆している。単一の多重化バス１１が示されており、その周りに、図示するＥＣＵ１の全てがグループ化されている。ＥＣＵによって駆動される機能は、１’と示されるボックス内で与えられる。

本発明の原理を示すために、図３ｂは例示的なアーキテクチャを示しており、このアーキテクチャは、本質的に図３ａの機能を再現している。本発明は、車両の機能を管理するために、中央集中型の共有されるコンピューティングアーキテクチャを提案する。特に、図３ａのＥＣＵ及び多重化バスは、中央物理的コンピュータ３１、及び、センサからの信号を集め制御信号を配信するインターフェースモジュール３３を接続するリアルタイムネットワーク、と置き換えられている。メインコンピュータの管轄ではない機能、特にあまり重要ではない機能には、１つ又は複数の二次コンピュータを提供することが可能である。

図３ｂのアーキテクチャは、例として、二次コンピュータ３２を含む。中央コンピュータ３１は、車両自体の管理に割り当てられる。二次コンピュータ３２は、接続性及びマルチメディアの管理に割り当てられる。これら２つの機能ドメインは、重要性及び脆弱性が異なっており、従って、信頼性及び安全性を高めるために、分離されることがある。例えば、車両の安全性機能を担当する第１のコンピュータ３１は冗長性を必要とするが、マルチメディアを担当する第２のコンピュータ３２は、冗長性を必要としない。中央コンピュータに対してのみ冗長性を持たせることにより、節約が有利にも行われる。安全性のために、第２のコンピュータは、例えばマルチメディアドメインなどの、外部に対して公開されている機能を扱い、従って、メインコンピュータを、特に、これら２つのコンピュータの間で先進的な保護技術を使用することにより、侵入の危険性から保護する。

アクチュエータを駆動し、センサからのデータを処理し、図３ａのＥＣＵによって実行される、機能１’は、中央コンピュータ３１及び二次コンピュータ３２によって実行される。これらのコンピュータ３１、３２は、のちに、「物理的コンピューティングユニット」、ＰＣＵと呼ばれることがある。

様々なモジュール３３とＰＣＵとを接続する通信ネットワーク３６は、例えば、ＴＳＮ（「時間的制約のあるネットワーキング」）イーサネットタイプのものであるが、他のタイプのリアルタイム通信ネットワークも、時間確定性であれそれ以外であれ、可能である。この段階では、本発明により、モジュール３３は、従来技術ではＥＣＵに直接的に接続されていたセンサ及びアクチュエータからの信号の全てを集めることを、規定することができる。それらは、配線を低減するために、より高速の物理リンク（イーサネット）を共有する。この共有は可能である、というのも、通信ビットレート及びこの物理リンクの待ち時間は、車両の機能の制御に適合した時間内に、集約モジュール３３に接続されたセンサ／アクチュエータから中央コンピュータにデータを転送するのに、十分であるからである。

ネットワーク内部に１つ又は複数のスイッチ３４を提供することが可能であり、各スイッチは、１つ又は複数の集約モジュール／ＰＣＵを扱う。図３ｂの例示的なアーキテクチャは、３つのスイッチを含んでいる。

この例では、集約モジュール３３の地理的分布の利点を見てとることができる。特に、車両の前部と後部との間のリンクは、ここでは、従来技術のような複数のケーブルの代わりに、リアルタイムネットワークを介した共有物理リンクによってもたらされている。安全上の理由から、例えば、二重化又は冗長化などの特定の技術が、車両内の相互接続３６に適用されることがある。

それらの技術に関しては、２つの共有されたコンピュータ３１、３２は車両管理の実施を担当しており、この管理は、特に図３ａによって示される従来技術の解決策では、分散したＥＣＵに委譲されていた。

このアーキテクチャは、ローカルネットワークを他のネットワーク、例えばインターネットに、完全に安全に接続するために、相互接続ネットワーク３６を補うゲートウェイ３５を備えることがある。これらの他のネットワークは、システムの内部のネットワークでもあり得る。

図４は、図３ｂのアーキテクチャをより詳細に示している。特に、これらのモジュールに接続されたセンサ／アクチュエータからの信号に応じた機能が、例として、モジュール３３毎に明示されている。特に、この図は、信号を集めコマンドを配信するためのモジュール３３も明示しており、そのそれぞれが、それらのモジュールが駆動するセンサ又はアクチュエータ１’’を備えている。これらのセンサ及びアクチュエータの全てを介して、車両の様々な機能（推進、ブレーキ、照明、空調、娯楽報道番組、等）が実装されている。より正確には、センサ及びアクチュエータは、機能の実行に関与し、コンピューティングはＰＣＵ３１において、場合によっては１つ又は複数の二次コンピュータ３２において行われる。

これらのモジュール３３は、のちに、ＰＩＵ（「物理インターフェースユニット」）と呼ばれることがある。これらのＰＩＵの全てが、リアルタイムネットワークによって相互接続されており、これにより、特に、システム全体の同期信号を送信する際の待ち時間を制御下に保つことが可能になり、何よりも、センサからのデータ及びアクチュエータ向けのデータ／コマンドを包含するパケットを送信する際の待ち時間を制御下に保つことが可能になる。上記の説明に従って、ネットワークは、スイッチ３４から構成され、且つ、ポータル又はゲートウェイから構成されることがあり、これにより、ネットワークのデータパケットをルーティングすることが可能になり、システムのアーキテクチャと外部の世界との間の接続（例えば、マルチメディア接続性）を安全にすることができる。その目的のために、図３ｂ及び図４の例では、マルチメディアドメインに割り当てられたＰＣＵは、ゲートウェイ３５を介してネットワークにアクセスし、ゲートウェイ３５は、ＰＩＵを介してネットワークとインターフェースする。

従って、このアーキテクチャは、例えば、動力伝達系を駆動すること、バッテリー又は特にＡＤＡＳ安全性システムを監視することなどの、重要性の高い機能を実行することができる。同時に、このアーキテクチャは、例えば空調、並びに他のタイプのサービスなどの重要性の低い機能を駆動することができる。これらの機能の全てが、例えばハイパーバイザなどの、コンピュータ資源を共有するための技術のおかげで、全く同一のＰＣＵ３１によって実行されることがある。

図５は、コンピュータ３１、３２の構成を示している。ＰＣＵは、マザーボード５０、及び１つ又は複数のコンピュータサブシステム５１、５２、５３、５４から構成される、低消費電力の、モジュラーシステムである。それらのサブシステムは、互いに完全に異質であることがあり、即ち、サブシステムは、異なるタイプの及び／又は異なる特殊性のプロセッサ５１１、５２１、５３１、５４１を含むことがある。これらのサブシステムは、マザーボードに統合されることがあるか、又は図５の例に示すように、ドーターボードとして利用可能である（統合される）ことがある。この例では、４つのドーターボード５１、５２、５３、５４が、マザーボード５０に接続されている。

これらのサブシステムは、マザーボードに組み込まれた時間確定性通信インフラストラクチャー５５のおかげで、マザーボード及びシステムの残りの部分と通信する。

図５の特定の例では、サブシステムのコンピュータ資源は、プライベートメモリ５１２、５２２、５３２、５４２に結合された１つ又は複数のプロセッサ５１１、５２１、５３１、５４１毎に組織され、それらのプロセッサは、１つ又は複数のソフトウェアパーティション５１３、５２３、５３３、５４３を実行することができる。例えば、これらのソフトウェアパーティションは、アプリケーション、プロセス（オペレーティングシステムのソフトウェア機構を使用して、分離が達成される）、又は更には、ハイパーバイザ機構を使用して分離された、オペレーティングシステム全体であり得る。

ＰＣＵは、アーキテクチャの特性を確保又は改善するための補助的な機能の実行をサポートできるようにする機能ブロックも含む。アプリケーション分離又はデータ保護タイプのサービスが、各コンピュータ資源におけるソフトウェアパーティションの実行をサポートするために使用される。例えば、ハイパーバイザが使用されることがある。

「データ管理モジュール」（ＤＭＭ）機能ブロック５０２は、車両内に分散したセンサ及びアクチュエータに関連したデータ、並びにサブシステムによって生成されたデータ、への一元化されたアクセスを、車両の様々なコンポーネントに提供することを可能にする。この機能ブロック５０２は、例えば、サブシステム間の通信を簡略化するのに、且つ車両のデータへのアクセスを容易にするために車両のデータの全てを保存し管理するのに使用される、仮想的に共有される分散型メモリサービス（ＤＳＭ－分散型共有メモリ）を介して、生成されることがある。このサービスは、例えば、ハイパーバイザ又はオペレーティングシステムからのサービスを介して行われることがある。この分散型サービスは、データを管理するためのハードウェア構成要素によってサポートされることがあり、これにより、ＰＩＵを介してセンサ及びアクチュエータへの、並びにコンピュータサブシステム５１、５２、５３、５４によって生成されたデータへの、時間確定性アクセスが可能になる。車両データの一元化された概観を、データアクセス時間を管理するための機構と組み合わせることにより、ＤＭＭ機能ブロック５０２は、特に、車両内に分散したデータにアクセスするための時間的な保証を提供するという利点を有する。

本発明によるアーキテクチャによって可能になる実質的な共有は、有利にも、特に、この機能ブロック５０２に基づいていることがある。この機能ブロック５０２は、センサ及びアクチュエータレベルでの、分散した資源に属する様々なメモリの一元化された概観を提供する。自動車システムに必要とされる有利な特性（時間管理、少ない待ち時間、等）を維持するために、機能ブロック５０２は、例えば、ハードウェアアクセラレータを用いて、例えば、一定の間隔でセンサデータを自律的に予めロードすることにより、システム内部のデータの一貫性を維持する。ＰＩＵを介したセンサ及びアクチュエータとの通信は全て、仮想メモリを通過し、これにより、システム内に分散したメモリ（センサ、アクチュエータ、ＰＩＵ、ＰＣＵ等のメモリ）を、単一の共有メモリマシンとして提示することが可能になる。メモリの一元化された概観が得られ、これは、全てのコンピュータからアクセスできる。この解決策の利点の１つは、データに属性が追加された場合に、中央集中化された効率的なアクセス制御システムが、車両データを厳重に保護し、以下に提示する全体的な仮想ドメインの概念を強化することができる、ということである。

「同期マネージャー」（ＳＭ）機能ブロック５０１は、車両内に分散している可能性がある、コンピュータサブシステム間の同期を確実にすることができる。機能ブロック５０１は、例えば、ＨＳＭ（ハードウェア同期マネージャー）と呼ばれるハードウェアアクセラレータによって、実装されることがある。ＤＭＭ及びＳＭ機能ブロックは、例えば、データに関連した同期を達成するために、結合される（又は更には、例えば、同じ機能ブロック内に実装される）ことがある。「安全性及び信頼性サポートモジュール」（ＳＳＲＭ）と呼ばれる機能ブロック５０３は、例えば、システムの冗長性を管理することにより、システムの安全な動作及びその信頼性に関連したサービスを確実にし且つサポートすることができる。この機能ブロックは、例えば、場合によってはハードウェアアクセラレータ又は二重化に特化したインターフェースによってサポートされる、分散したソフトウェアサービスによって、実装されることがある。

図５の例示的な実施形態では、上述した様々な機能は、各機能の専用の機能ブロックによって提供され、各ブロックは通信インフラストラクチャー５５を介してシステムの残りの部分と通信する。これらの機能の幾つかを、全く同じ機能ブロックに一緒にグループ化することも可能である。

このマザーボード－ドーターボード・アーキテクチャは、有利にも、柔軟性があり、結合させて構成可能である。このアーキテクチャは、異なる種類の車両をターゲットにしながらも、例えば、全自動運転アプリケーション又は複雑な娯楽報道番組アプリケーションなどの、現在の及び将来の機能を提供することができる、汎用的なシステムを構成している。重要な点の１つは、製造コストを削減するために、システムの様々なコンポーネントを最大数の車両で再使用できる可能性にある。

ドーターボードを使用すると、実行されることになる機能の特性に関して適切な資源を使用することが可能になる。例えば、画面又は画像処理を使用する機能は、ＧＰＵ（グラフィックス処理ユニット）を備えたＳｏＣを用いて、ボード上に一緒にグループ化されることがあり、一方、非常に重要な機能は、より優れた時間管理を伴って、ドーターボードに差し向けられることがある。従って、このアーキテクチャは、有利にも、同じ特性を有する機能を、それらの特性（計算のタイプ、セキュリティ／安全性、時間重要性、等）を提供するために最適化されたコンピュータサブシステムに一緒にグループ化することにより、コンピュータシステムを最適化することができる。

従って、設計中（又は、ハードウェアの更新の場合には、車両の耐用年数の間）、システムのまさにアーキテクチャは、機能の分割及び／又は分離により、且つ、（例えば、専用のアクセラレータを組み込んだ）、おそらくは非常に異質であり適合されたハードウェア資源（サブシステム）にまたがって、特性に従って機能を一緒にグループ化することにより、最適化されることがある。このようにサブシステム内部の機能／機能の部分を物理的に一緒にグループ化することにより（なお、機能はソフトウェアパーティションによって互いに分離される）、全てのサブシステムを出来る限りスリム化するようにあつらえることが可能になり、アーキテクチャは、例えばドーターボードによって、後天的に適合させるのに十分なほど柔軟になる。

更に、マザーボードに接続されたドーターボードを使用すると、必要に応じて、例えば生の画像の取得のために、高い帯域幅及び少ない待ち時間のインターフェースを使用することが可能になる。

マザーボードはネットワークのバックボーン機能を果たし、これにより、ドーターボードが互いに及びシステムの残りの部分と相互接続することが可能になり、システムの残りの部分とのこのインターフェースは、二重リンク（又は、いずれにせよ、冗長リンク。これらのリンクは、必ずしも同種である必要はない）、例えばギガビット・イーサネットリンク５０４によって、形成される。このマザーボードは、システムの健全性を監視する機能も含む。特定の機能、例えば、アクセスの調停や、複雑さ、異質性、又は温度、コンポーネントの経年劣化、若しくはエネルギー消費などの非機能的パラメータ、の保護若しくは管理などを追加することができる。

図６は、ＰＩＵ３３と通信するマザーボード５０及びドーターボード５１、５２、５３、５４から構成されるＰＣＵ３１を用いた、本発明によるアーキテクチャの図を示しており、これらのＰＩＵ３３は、イーサネットタイプのネットワークによって実装されるネットワーク３６を介して制御されるように、システム内に地理的に分散している。ＰＩＵは、様々な地理的ドメイン６１、６２、６３、６４、６５のセンサからの信号を集め、コマンドをこれらの同じドメインに送信する。これらのドメインは、例えば、車両の前部左、前部右、後部左、後部右、又は客室に対応することがある。より正確には、図６の場合では、各ＰＩＵは、地理的ドメインに結び付けられた複数のセンサ及び／又はアクチュエータを扱うことにより、複数の機能ドメイン（ブレーキ、動力伝達系、運転支援、等）に割り当てられる。言い換えると、ＰＩＵは、そもそも機能ドメインによってではなく、地理的ドメインによって割り当てられる。システムによっては、地理的ドメインごとの割当てが、機能ドメインごとの割当てと一致する、特別な実装ケースがあり得る。

上述のように、ＰＩＵはセンサからデータを集める機能及びコマンドを再分配する機能しか持たない。ＰＩＵは、これらの処理動作が、自律的な意思決定を含まないという意味で、ハイレベルの処理は行わない。制御及び意思決定は、常に、中央コンピュータ３１又は場合によっては１つ又は複数の二次コンピュータ３２のレベルで行われる。

図７は、ＰＩＵの１つの例示的な実施形態を示す。ＰＩＵは、センサ及びアクチュエータを電子アーキテクチャの残りの部分だけでなく、ゲートウェイ３５及びネットワークの他の要素にも接続できるようにするネットワークコンポーネントである。図７の例では、図示するＰＩＵは、接続先のセンサ及びアクチュエータによって、３つの機能ドメイン、即ち、駆動装置７５、照明７６、及びブレーキ７７、を扱っている。このＰＩＵは、例えば、車両の前部左に配置され、従って、前部左の領域に配置されたセンサ及びアクチュエータに接続されることがある。

図７のＰＩＵのアーキテクチャは一般的である。特に、このアーキテクチャは、扱っている機能ドメインには依存せず、サイズ決定（コンピュータシステム、メモリ）又はインターフェースのみが依存することがある。これにより、特に、組み込みの困難さ並びに製造コストを低減することができる。より具体的には、図７はＰＩＵの一般的な構造を提示している。ＰＩＵの機能は、特に、センサからの信号をＰＣＵ（又は複数のＰＣＵ）に送信するために、センサからの信号をパケット化することと、ＰＣＵからのパケットを処理することにより、コマンドをアクチュエータに配信することである。

従って、ＰＩＵは、特に通信プロトコルを変換することにより、実際には非常に異質であり得るセンサからの（場合によってはアクチュエータからの）信号及びアクチュエータへの（場合によってはセンサへの）信号の一元化された概観をネットワーク３６、特にＰＣＵに提示することを担当する。従って、ＰＩＵによって管理されるセンサ及びアクチュエータとのインターフェース７１は、異なるタイプのもの、例えば、ＦｌｅｘＲａｙ、ＣＡＮ、ＰＷＭスイッチ、ＳＰＩ、ＱＳＰＩ、又はＡＤＣなどであり得る。ＰＣＵによるセンサ及びアクチュエータの一元化された概観は、実際には、センサ及び／又はアクチュエータとの通信のインターフェースに関わらず、（ＰＣＵ側から見た）ＰＩＵとの間でデータを通信するための単一のプロトコルに変換される。

従って、ＰＩＵは、センサ／アクチュエータから受け取ったデータを、ネットワーク３６を介して送信されるリアルタイム・イーサネット・パケットとしてフォーマットするために、且つ逆に、イーサネット・パケットの形式でＰＣＵから到来するコマンドを異なる規格で送信するために、これらの異なる規格と通信することができる。当然ながら、イーサネット以外のプロトコルを使用することもできる。

リアルタイム相互接続ネットワーク３６は、ＰＩＵとセンサ／アクチュエータとの間のインターフェースよりも広い帯域幅を有する。従って、これにより、この相互接続リンクを共有することにより、車両内のケーブルの数を低減することが可能になる。有利にも、ＰＩＵは、複数のセンサから異質な信号を取り出す一方で、（例えば、予め確立された変更可能な構成を介して）車両の動作と送信されるそれらの信号との時間的な整合性を保証し、特に、帯域幅を最大化し待ち時間を最小限に抑えるために、異なる信号のデジタルデータを単一のパケットに一緒にグループ化することにより、出来る限り送信されるパケットのそれぞれを埋める。逆に、コンピュータからのパケットは、ＰＩＵによって扱われるアクチュエータに向けられる、デジタル化されたコマンドデータを最大限に集約し、ＰＩＵは、これらのコマンドの再配信を担当し、一方、（例えば、予め確立された変更可能な構成を介して）車両の動作と送信されるそれらのコマンドとの時間的な整合性を保証し、従って時間管理を提供する。

例として、図７には、車両の３つのコンポーネント、電気モーター７５、ヘッドライト７６、及びブレーキシステム７７が示されている。図示していない１つ又は複数のアクチュエータ及びセンサが、これらのコンポーネントのそれぞれと関連付けられている。それらはアクチュエータによって制御され、アクチュエータ自体も、通信ネットワーク３６、通信プロセッサ７２、及び通信インターフェース７１を介して送信されたＰＣＵからのコマンドデータによって制御される。同様に、センサ（カメラ、スピードセンサ、温度センサ等）は、逆のルートを介してデータをＰＣＵに送信する。

機能ドメインの制約を考慮に入れるために、ＰＩＵは、安全性、セキュリティ（例えば、データの暗号化／復号化）、メッセージの完全性の制御、及び／又はメッセージの冗長性の管理、などの様々なサービスも担当する。パケット処理、プロトコル変換、並びにセキュリティ及び制御機能は、通信プロセッサ７２によって行われる。電力供給ブロック７３も提供される。これは、ＰＩＵに一体化されることも、そうでないこともある。従って、有利にも、システムの全体的な電力供給は、ＰＩＵ及び１つ又は複数のＰＣＵの地理的分布に類似して分配されることがある。完全なアーキテクチャには、この観点で利点がある。具体的には、電気シャフトはそれ自体のトポロジーを有する（又は、通信ネットワークの相互接続をなぞる）ことがあるが、制御は、有利にも、システムのコンピュータ制御ネットワークによって伝達される。

有利にも、電気消費を最適化することができる。具体的には、ＰＩＵには、必要な場合にのみ電力を供給することができる。電力供給ブロック７３、及びＰＩＵに接続されたセンサ／アクチュエータ用の電力供給をオンにするコマンドは、ネットワーク３４、３６、７４を通過する制御信号によって伝達されることがある。この目的のために、電力供給ブロックには適切なインターフェース、例えば、スマートＭＯＳタイプのトランジスタ又はスマートスイッチ、が組み込まれる。ＰＣＵによるアーキテクチャの概要、及び相互接続ネットワークを介してきめの細かい制御信号を送信する実現性のおかげで、非常に細かい電力供給の管理が可能になる。

このアーキテクチャの重要な側面の１つは、相互接続ネットワーク３６を共有する能力にある。必要とされるスピード及び待ち時間を考慮すると、これには、相当な帯域幅と、周期的又は非周期的なメッセージ送信能力とが必要である。例えば、通信を行うためにイーサネットリンク７４を使用すると、必要な帯域幅を獲得することができる。このリンクは、柔軟性ももたらし、異なる通信規格を使用することが可能になる。情報の伝搬時間を確実に制御する時間管理は、重要性が異なる情報の伝達をサポートする規格に基づいていることがある。

本発明による電子システムの注目すべき利点の１つは、機能ドメインに基づくアーキテクチャの場合のように、アーキテクチャの一部を特定のドメインに物理的に割り当てることなく、オンデマンドで仮想ドメインを生成するために、且つ例えば、重要なドメインを重要ではないドメインから分離するために、例えば、仮想リンク（ＶＬＡＮタイプ等）の使用を介した通信の分離を可能にするネットワーク、ひいては仮想プライベートネットワークを、有利にもサポートする能力である。

図８は、仮想ドメインを使用して、物理的に分散したセンサ及びアクチュエータを論理的に一緒にグループ化し、それらを様々な独立した仮想領域に分離する、ことを可能にする方法を示す。より具体的には、図８は、システムの様々なコンポーネントと部品／部分組み立て品との間で仮想リンクを使用することにより実装される仮想ドメイン８１、８２、８３、８４、８５を示している。これらの仮想ドメインは、例えば、仮想的なローカルエリアネットワーク又はＶＬＡＮ、が重要な部分をなす分離技術の組み合わせである。例えば、仮想ドメイン８４は、複数のプロセッサ（ＣＰＵ）及びＰＣＵ３１の処理パーティション（仮想マシンを形成する）、並びに車両内に分散していることがあるセンサ及びアクチュエータのグループ８０のための集約及びコマンドインターフェース、をカバーする。これは、車両内に分散したセンサ及びアクチュエータを備えたエンジン／モータードメイン、及び対応する仮想マシン８００、を管理することを可能にする仮想ドメインであり得る。

より一般的には、本発明によれば、仮想ドメインは、特に、ＤＭＭ５０２での属性の管理の、相互接続ネットワーク３６を介した仮想リンクの、ＰＩＵ３３により据えられるデータ属性による技術の組み合わせ、又はハードウェアとソフトウェアの分離技術（例えば、ドメイン毎に１つのプロセッサなど）の組み合わせを使用して生成されることがあり、この場合、複数のドメインに対して１つのプロセッサを用いており、この分離は、オペレーティングシステムの基本機能を使用して、又はハイパーバイザを使用して得られるメモリ保護によって行われ、ハイパーバイザは、同じハードウェア資源で実行されている２つのオペレーティングシステムを分離することができる。ＰＩＵデータ属性を使用した技術に関しては、これは、特に、各グループに異なる属性を割り当てることにより、あるＰＩＵ上の異なるセンサ又はアクチュエータからのデータのグループを分離することで成り立つ。

このアーキテクチャでは、通信を初期化するのはアクチュエータ又はセンサではない。それは、ＰＣＵ３１、３２である。従って、この例示的な構成は、マスター／スレーブタイプのものであり、マスターはＰＣＵである。ＰＣＵがＰＩＵからのデータを要求するのは、１つの例示的な実施態様である。当然ながら、マスター／スレーブの文脈なしに、ＰＣＵによる通信の初期化なしで、ＰＩＵがＰＣＵにデータを送信する実施態様を提供することも可能である。

このネットワークでは、コンポーネントを互いに相互接続できるようにするスイッチは、帯域幅、少ない待ち時間、セキュリティ、及び安全性などの、システムの有利な特性をサポートするように設計される。ゲートウェイブロック３５は、このアーキテクチャを第２のＰＣＵ３２によって処理される外部通信から切り離すことにより、セキュリティを提供する。

図９は、様々なハードウェア及びソフトウェアの貢献者を反映して、本発明によるアーキテクチャにおける上述の仮想ドメインを示す。本発明は、有利にも、システムのコンポーネントの物理的搭載に関連した制約を、データの使用上の制約、及び車両の機能をコンピューティングコアに関して割り当てる制約から分離するように仮想ドメインを生成する。これらの仮想ドメインを、このアーキテクチャの特性を使用することにより、効率的に生成することができる。論理／仮想ドメインは、例えば、相互接続３４、３６によって提供される仮想リンク間の提携、ＤＭＭデータ管理機能ブロック５０２、このＤＭＭ機能ブロック５０２によって管理されるデータのセキュリティ属性を使用することにより、且つハイパービジョン又はオペレーティングシステム技術などの、アプリケーション／機能間のソフトウェア及び／又はハードウェアを分離するサービスの使用により、（場合によっては動的に）生成されることがある。これらのドメインは、例えば認証サービスを介して実装される、センサ／アクチュエータ又はサブシステムの認証のための技術によって、サポートされることもある。

図９の例は、分離技術の組み合わせを使用することにより、このアーキテクチャ上に生成された以下の４つの仮想ドメインを示す。
－ ブレーキドメイン９１の仮想ドメイン
－ 推進力ドメイン９２の仮想ドメイン
－ ヘッドライト（照明）ドメイン９３の仮想ドメイン
－運転支援システム（ＡＤＡＳ）用のカメラドメイン９４の仮想ドメイン

ＰＣＵ３１のコンピュータは、通信ネットワークを介して、車両内に分散したＰＩＵ３３と通信する。通信をＰＩＵに導くために、仮想リンク（例えば、ＶＬＡＮ）をサポートするスイッチ３４が分散している。図９は、物理部分と論理部分との二分法を明確に示している。互いに物理的に離れているテールライトとヘッドライトは、異なるＰＩＵにリンクされているが、同じ仮想ドメインの中にある（且つ、場合によっては同期している）。同じことが、前部ブレーキ及び後部ブレーキにも当てはまる。

図１０は、本発明によるアーキテクチャの代替の実施形態を示す。図１０の例では、図９で説明したシステムが、例えば、取得（１つ又は複数の高解像度カメラを介した生のストリームの取得）という観点と、スクリーンの制御という観点との両方で、高速信号を効率的に管理するためのサブシステム１０１を用いて補われている。１つ又は複数のドーターボードから構成されるこのサブシステムは、アーキテクチャ内での位置決めの観点から、特定のＰＩＵであるとみなされることがある。このサブシステム１０１の機能の１つは、特に、アーキテクチャ内に存在する高い伝送速度を備えたセンサ及びアクチュエータに対して責任を負うこと、及び、実際の処理を目的として、中央コンピュータＰＣＵに情報を再送信すること、（例えば、圧縮ノイズに敏感な特定の処理動作について、同期されている待ち時間の少ない生のストリームを送信する機能）である。例えば、そのようなサブシステムは、データ送信に必要なビットレートが、相互接続ネットワーク３６での最大の許容可能なビットレートを上回る場合に、使用される。このサブシステムを使用することは、相互接続ネットワーク３６の待ち時間が、アプリケーションの許容可能な待ち時間に対して長すぎる場合にも、有利であることがある。

しかしながら、必要とされるビットレートが潜在的に非常に高いことを踏まえると、ＰＣＵ３１とこのサブシステム１０１との間にリンクを張ることが好ましいことがある。例えば、高速入力／出力ブロック１０２を使用して、サブシステム１０１からＰＣＵ３１にリンクを張ることができる。このブロックは、サブシステム１０１をＰＣＵのドーターボードとして配置することができ、又は、サブシステム１０１が車両内で離れた場所にある場合、ワイヤによる高速シリアルリンクを介して、サブシステム１０１をＰＣＵに接続することができる。これにより、アーキテクチャのモジュール性の特性を維持することができ、また、車両が使用中である場合であっても（例えば、後付けでセンサを更新する場合）、サブシステムをセンサ又はアクチュエータのタイプに適合させる潜在能力を維持することができる。しかしながら、システムの機能的側面のレベルにおいては、このサブシステム１０１は、データ管理ブロック５０２及び特に同期ブロック５０１により、セキュリティ上の、データアクセス制御上の、及び管理上の有利な特性を保持するように、アーキテクチャの残りの部分と完全に一体化される。従って、有利ではあるものの、このリンクは、この入力及び出力サブシステムに関して、アーキテクチャ全体の特性を否定するものではない。図１０の例では、高速カメラ１０３は、運転支援のための信号の取得という文脈の中で、サブシステムに直接的にリンクされている。画像は、ドーターボード５１によって処理される。データは、属性ベースのデータ保護を用いて、ＤＭＭ５０２及びＳＭ５０１機能ブロックによって管理される。サブシステム１０１とＰＣＵ３１との間のリンクは、例えば、イーサネット又は他のタイプのリンクに接続されているＰＩＵとは異なり、マザーボード－ドーターボード・リンクという文脈の中で、認証された自動車コネクタを通過するプロトコルを使用する高速リンクである。しかしながら、これらのタイプのリンクは両方とも、時間確定性通信ネットワークであるＰＣＵのマザーボードの通信インフラストラクチャー５５に到達することに留意されたい。アーキテクチャ全体により、様々な要素間の同期の特性を維持することが可能になる。

Claims (16)

1. システムの機能の管理を実行する前記システムに埋め込まれた電子アーキテクチャであって、前記機能はセンサ及びアクチュエータの組を介して実現される、電子アーキテクチャにおいて、前記電子アーキテクチャは、少なくとも、
   －中央コンピュータ（３１、３２）と、
   －リアルタイム通信ネットワーク（３４、３６）と、
   －前記システムの地理的領域にそれぞれ割り当てられたインターフェースモジュール（３３）の組と、を含み、各モジュールは、
   ｏそれに割り当てられた前記領域の前記センサのうちの少なくとも１つからの信号を集め、前記信号を前記通信ネットワークを介して前記中央コンピュータに送信し、
   ｏ且つ／又は、それに割り当てられた前記領域の前記アクチュエータのうちの少なくとも１つに制御信号を配信し、
   前記中央コンピュータは前記センサからの前記信号に従って前記アクチュエータを駆動し、前記アクチュエータに対する前記制御信号は前記通信ネットワークを介して前記インターフェースモジュール（３３）に送信され、前記インターフェースモジュール（３３）のうちの少なくとも１つは、複数の機能ドメインのセンサからの前記信号を集め、且つ／又はコマンドを複数の機能ドメインのアクチュエータに配信し、前記センサ及びアクチュエータは、前記少なくとも１つのモジュール（３３）に割り当てられた前記地理的領域内に配置され、
   前記中央コンピュータ（３１、３２）はマザーボード（５０）及びコンピュータサブシステム（５１、５２、５３、５４、５５）から構成され、各サブシステムは１つ又は複数のプロセッサ（５１１、５２１、５３１、５４１）を含み、前記プロセッサは、プライベートメモリ（５１２、５２２、５３２、５４２）に結合され、複数のソフトウェアパーティション（５１３、５２３、５３３、５３４）を実行することができ、前記サブシステムは、前記マザーボードに実装された相互接続インフラストラクチャー（５５）によって、互いに及び前記通信ネットワーク（３４、３６）と通信し、
   前記アーキテクチャは、データを管理するための中央集中型機能ブロック（５０２）を含み、それにより、前記コンピュータ（３１、３２）及び前記モジュール（３３）に存在する前記メモリの前記データへのアクセスが可能になり、前記機能ブロック（５０２）は、前記アーキテクチャの様々なコンポーネントに、前記システム内に分散した前記センサ及びアクチュエータに関連した前記データ、並びに前記コンピュータサブシステムによって生成された前記データ、への一元化されたアクセスを提供する、ことを特徴とする、アーキテクチャ。
2. 前記インターフェースモジュールのうちの少なくとも１つは、また、前記アクチュエータのうちの少なくとも１つからの信号を集め、且つ／又は信号を前記センサのうちの少なくとも１つに配信する、ことを特徴とする、請求項１に記載のアーキテクチャ。
3. 前記機能ブロック（５０２）は、前記コンピュータ（３１、３２）と前記モジュール（３３）との間で仮想的に共有される分散型メモリサービスによって実装され、それにより、前記中央コンピュータ（３１、３２）と前記センサ及びアクチュエータとの通信の全ては、前記仮想メモリを通過するようになり、且つ、前記アーキテクチャ並びに前記センサ及びアクチュエータの全てに分散している前記メモリは、前記中央コンピュータからは単一の共有メモリとして見えるようになる、ことを特徴とする、請求項１に記載のアーキテクチャ。
4. 前記機能ブロック（５０２）により、前記データに関連した属性の使用を介して、前記データへのアクセスを保護することが可能になる、ことを特徴とする、請求項３に記載のアーキテクチャ。
5. 前記アーキテクチャは、前記コンピュータサブシステム間の同期を提供する機能ブロック（５０１）を含む、ことを特徴とする、請求項１～４の何れか一項に記載のアーキテクチャ。
6. 前記アーキテクチャは、前記システムの動作上の信頼性に結びついたサービスを提供しサポートする機能ブロック（５０３）を含む、ことを特徴とする、請求項１～５の何れか一項に記載のアーキテクチャ。
7. インターフェースモジュール（３３）は、少なくとも、
   －通信プロセッサ（７２）と、
   －前記プロセッサ（７２）とアクチュエータ及び／又はセンサとの間の通信インターフェース（７１）と、
   －前記プロセッサと前記通信ネットワーク（３４、３６）との間の通信インターフェース（７４）と、を含み、
   前記通信プロセッサは、前記センサからの前記データを、前記通信ネットワークを介して前記中央コンピュータ（３１、３２）に送信するために、且つ、前記中央コンピュータからのコマンドデータを、前記通信ネットワークを介して前記アクチュエータに配信するために、前記センサからの前記データをパケットに整える機能を有する、ことを特徴とする、請求項１～６の何れか一項に記載のアーキテクチャ。
8. 前記プロセッサと前記アクチュエータ及び／又はセンサとの間の前記通信インターフェース（７１）は、異なるタイプのものであり、前記プロセッサ（７２）は、単一のプロトコルに従って前記データを前記中央コンピュータと交換するために、前記インターフェースの通信プロトコルを変換する、ことを特徴とする、請求項７に記載のアーキテクチャ。
9. 前記アーキテクチャは、前記通信ネットワーク（３４、３６）を少なくとも１つの他の通信ネットワークに接続することができる少なくとも１つのゲートウェイ（３５）を含む、ことを特徴とする、請求項１～８の何れか一項に記載のアーキテクチャ。
10. 前記アーキテクチャは、前記ゲートウェイ（３５）によって、前記通信ネットワーク（３４、３６）と通信する二次コンピュータ（３２）を含み、前記二次コンピュータ（３２）は、前記他のネットワークに接続される機能を駆動する、ことを特徴とする、請求項９に記載のアーキテクチャ。
11. 前記アーキテクチャは、複数のソフトウェアパーティションを実行することに加えて、技術の組み合わせを含み、前記組み合わせは仮想ドメイン（８１、８２、８３、８４、８５、９１、９２、９３、９４）を形成し、各仮想ドメインは、センサ及びアクチュエータのグループの前記インターフェースモジュール（３３）を処理する前記パーティションのうちの少なくとも１つをカバーする、ことを特徴とする、請求項１～１０の何れか一項に記載のアーキテクチャ。
12. 前記組み合わせは、前記リアルタイム通信ネットワーク（３４、３６）におけるデータ伝送分離機構の組み合わせを含む、ことを特徴とする、請求項１１に記載のアーキテクチャ。
13. 前記組み合わせは、前記インターフェースモジュール（３３）によって据えられるデータ属性に基づいている、ことを特徴とする、請求項１１又は１２の何れか一項に記載のアーキテクチャ。
14. 前記中央コンピュータ（３１）と前記インターフェースモジュール（３３）との間の通信は、前記コンピュータ（３１）によって制御される、ことを特徴とする、請求項１１～１３の何れか一項に記載のアーキテクチャ。
15. 前記アーキテクチャは、高い伝送速度で入力信号及び出力信号を管理するためのサブシステム（１０１）を含み、前記サブシステムは、前記マザーボードの前記相互接続インフラストラクチャー（５５）に接続され、前記サブシステムは、１つ又は複数のドーターボードから構成され、高い伝送速度を備えたセンサ及び／又はアクチュエータと、前記中央コンピュータ（３１）との間のインターフェースモジュール（３３）の機能を実行する、ことを特徴とする、請求項１～１２の何れか一項に記載のアーキテクチャ。
16. 前記通信ネットワークは時間確定性イーサネットタイプのものであることを特徴とする、請求項１～１５の何れか一項に記載のアーキテクチャ。
    
    

Images