特表 2023-551945 イーサネットネットワークを介してセンサノードを急速にフラッシュさせる方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2023-12-13

(54)【発明の名称】イーサネットネットワークを介してセンサノードを急速にフラッシュさせる方法

(51)【国際特許分類】

   H04L 12/28 20060101AFI20231206BHJP

【ＦＩ】

H04L12/28 200B

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2023533897

(86)(22)【出願日】2021-11-30

(85)【翻訳文提出日】2023-06-02

(86)【国際出願番号】 DE2021200227

(87)【国際公開番号】W WO2022117167

(87)【国際公開日】2022-06-09

(31)【優先権主張番号】102020215329.9

(32)【優先日】2020-12-03

(33)【優先権主張国・地域又は機関】DE

(81)【指定国・地域】

(71)【出願人】

【識別番号】522388073

【氏名又は名称】コンチネンタル オートモーティヴ テクロノジーズ ゲー・エム・ベー・ハー

【氏名又は名称原語表記】Ｃｏｎｔｉｎｅｎｔａｌ Ａｕｔｏｍｏｔｉｖｅ Ｔｅｃｈｎｏｌｏｇｉｅｓ ＧｍｂＨ

【住所又は居所原語表記】Ｖａｈｒｅｎｗａｌｄｅｒ Ｓｔｒ． ９， ３０１６５ Ｈａｎｎｏｖｅｒ， Ｇｅｒｍａｎｙ

(74)【代理人】

【識別番号】100114890

【弁理士】

【氏名又は名称】アインゼル・フェリックス＝ラインハルト

(74)【代理人】

【識別番号】100098501

【弁理士】

【氏名又は名称】森田 拓

(74)【代理人】

【識別番号】100116403

【弁理士】

【氏名又は名称】前川 純一

(74)【代理人】

【識別番号】100134315

【弁理士】

【氏名又は名称】永島 秀郎

(74)【代理人】

【識別番号】100162880

【弁理士】

【氏名又は名称】上島 類

(72)【発明者】

【氏名】ヘルゲ ツィナー

(72)【発明者】

【氏名】ダニエル ホプフ

【テーマコード（参考）】

5K033

【Ｆターム（参考）】

5K033AA03

5K033CA12

5K033CB06

5K033DA01

5K033DA13

5K033DB20

(57)【要約】

本発明は、ヘッドノード及び複数の関連ノードを有するイーサネットネットワークを介してセンサノードを急速にフラッシュさせる方法であって、ａ）ヘッドノードにより、アクティブノードの数を判定すること、ｂ）ヘッドノードにより、識別されたノードを２つ以上のノード分類に分類して、イーサネットネットワーク通信を優先させること、ｃ）ヘッドノードにより、複数のノードの少なくとも一部から予約要求を受信すること、ｄ）予約要求に応じて、その後の通信ウィンドウの時間スロットにおいて１つ以上のノードに割り当てることであって、割り当ては、ノード優先度に基づき、及び優先度は、ノードにその分類に従って割り当てられる、割り当てることを含み、アクティブノードの数が判定された後、必要なダウンロードデータレートが判定され、及び現在のバス利用率が確認され、バス利用率は、最後のビーコンの時間差及びノードの数を計算することによって確認され、及びイーサネットネットワークのバスサイクルは、必要なダウンロードデータレートに関して最適化される、方法に関する。

【特許請求の範囲】

【請求項1】

ヘッドノード及び複数の関連ノードを有するイーサネットネットワークを介してセンサノードを急速にフラッシュさせる方法であって、
ａ）ヘッドノードにより、アクティブノードの数を判定すること、
ｂ）前記ヘッドノードにより、前記識別されたノードを２つ以上のノード分類に分類して、イーサネットネットワーク通信を優先させること、
ｃ）前記ヘッドノードにより、前記複数のノードの少なくとも一部から予約要求を受信すること、
ｄ）予約要求に応じて、その後の通信ウィンドウの時間スロットにおいて１つ以上のノードに割り当てることであって、前記割り当ては、ノード優先度に基づき、及び前記優先度は、前記ノードにその分類に従って割り当てられる、割り当てること
を含む方法において、前記アクティブノードの数が判定された後、必要なダウンロードデータレートが判定され、及び現在のバス利用率が確認され、前記バス利用率は、最後のビーコンの時間差及び前記ノードの数を計算することによって確認され、及び前記イーサネットネットワークのバスサイクルは、前記必要なダウンロードデータレートに関して最適化されることを特徴とする方法。

【請求項2】

前記バス利用率は、連続的に監視されることを特徴とする、請求項２に記載の方法。

【請求項3】

前記必要なダウンロードデータレートが判定されると、前記イーサネットネットワークの最後のバスサイクルにおける前記イーサネットネットワーク内の現在の空きデータレート（Ｄ_ｆｒｅｉ）が判定され、及び１バスサイクルあたりの必要なデータレート（Ｄ_ｚｕｓ）が判定され、前記イーサネットネットワークの前記最後のバスサイクルにおける前記イーサネットネットワーク内の前記空きデータレート（Ｄ_ｆｒｅｉ）が１バスサイクルあたりの前記必要なデータレート（Ｄ_ｚｕｓ）以上である場合、次のバスサイクルにおいて変更が行われず、及び前記イーサネットネットワークの前記最後のバスサイクルにおける前記イーサネットネットワーク内の前記空きデータレート（Ｄ_ｆｒｅｉ）が１バスサイクルあたりの前記必要なデータレート未満である場合、前記次のバスサイクルにおいて変更が行われることを特徴とする、請求項１又は２に記載の方法。

【請求項4】

イーサネットネットワークのための制御ユニットであって、第１のノードとして、
－ 前記イーサネットオンボードネットワークの第２の制御ユニットに信号を送信し、且つ前記第２の制御ユニットから前記信号を受信することと、
－ 前記第２の制御ユニットに対する接続経路上の前記信号の遅延時間を判定することと、
－ 前記遅延時間に基づいて前記接続経路の最大速度を判定することと、
－ 前記最大速度に基づいて前記接続経路の送信媒体のタイプを判定することと
を行うための制御ユニットとして設計され、
－ マイクロプロセッサ、
－ 揮発性メモリ及び不揮発性メモリ、
－ 少なくとも２つの通信インタフェース、
－ 同期可能なタイマ
を少なくとも含み、及び前記不揮発性メモリは、前記マイクロプロセッサによって実行されると、請求項１～３のいずれか一項に記載の方法の少なくとも１つの実施形態が実施及び実行されることを可能にするプログラム命令を含む、制御ユニット。

【請求項5】

自動車のためのイーサネットネットワークであって、第１の制御ユニットと第２の制御ユニットとを有し、前記制御ユニットは、少なくとも１つの接続経路を介して互いに接続され、及び前記第１の制御ユニットは、請求項４に記載の形態である、イーサネットネットワーク。

【請求項6】

第３の制御ユニット（５）を含み、前記第３の制御ユニット（５）は、前記第１の制御ユニット（３）に間接的にのみ接続され、且つ第３の接続経路を介して前記第２の制御ユニットに直接接続され、前記第３の制御ユニットは、前記第３の接続経路上の第３の信号の遅延時間を判定するように設計され、前記第１の制御ユニットは、前記第３の制御ユニットへのサービスメッセージにより、前記第３の信号の前記遅延時間の前記判定をトリガするように設計されることを特徴とする、請求項５に記載のイーサネットオンボードネットワーク。

【請求項7】

コンピュータプログラム製品であって、コンピュータによってプログラムが実行されると、請求項１～３のいずれか一項に記載の方法（２００）を前記コンピュータに行わせる命令を含むコンピュータプログラム製品。

【請求項8】

請求項７に記載のコンピュータプログラム製品が格納されているコンピュータ可読媒体。

【請求項9】

イーサネットオンボードネットワークを含む、請求項４に記載の複数の制御ユニットを有する車両。

【発明の詳細な説明】

【背景技術】

【0001】

１００Ｍビット／秒、１０００Ｍビット／秒及び進行中のマルチギガビット標準化に加えて、１０Ｍビット／秒（ＩＥＥＥ８０２．３ｃｈ）による自動車アプリケーションのための別のイーサネット標準が利用可能になる。

【0002】

イーサネット及び無線技術は、自動車への適用が見出され始めたばかりであり、そのオープン且つ標準化されたプロトコルにより、外部から車を攻撃することも初めて可能になる。攻撃者が無線を介して車両へのアクセスを管理して取得し、したがって重要な車両機能にもアクセスすることができたという、車両への攻撃に関する報告が増加している。

【0003】

新標準の１つの変形例は、ＣＳＭＡ／ＣＤベースのマルチドロップモードである。これは、イーサネットをよりコスト効率的に設計し、それによってよりシンプルな制御装置に対処することも目的とするため、他のイーサネット標準（１０Ｍビット／秒超）と大きく異なる。この標準は、いかなるスイッチ（スイッチＩＣ）も必要とせず、むしろ（ＣＡＮと同様に）バスとして設計される。これにより、必要なＰＨＹ（送受信機）の数を約半分にする。このように、イーサネットは、システムコストを大幅に削減することができるため、ＣＡＮ／ＣＡＮ－ＦＤ及びＦｌｅｘＲａｙの重大な競合相手となりつつある。更に、コントローラと物理送受信機（ＰＨＹ）との間の通信のために、ｘＭＩＩの代わりにＳＰＩなどの典型的な自動車用インタフェースも可能である。

【0004】

図１は、スイッチドイーサネット及びＩＥＥＥ標準ＩＥＥＥ Ｐ８０２．３ｃｇで定義される「バスイーサネット」（マルチドロップ）の本質的な機能を比較したものである。最も重要な違いは、バスアクセスというリソースがスイッチドイーサネットで排他的に利用可能であることであり、これは、いかなるイーサネットノード（ＥＣＵ）も、そのプロセスにおいて衝突が発生することなく任意の時点で送信できることを意味する。マルチドロップモードでの新しいイーサネットバスの実装形態では、共有媒体が使用され、すなわちこのリソースが利用可能になるまでバスアクセスを保留する必要がある。

【0005】

ＩＥＥＥ Ｐ８０２．３ｃｇ標準では、バスアクセス中の衝突を回避してフェアアクセスを実施するために、とりわけ特に新しく定義されたメカニズム（ＰＬＣＡ － 物理層衝突回避）を使用する。この場合、正確に１つのＰＨＹ（物理送受信機）のみが一度にバスに対するアクセスを受信する。これにより、衝突を回避することが可能になる。アクセスは、ラウンドロビン方式と呼ばれるものに基づく。バス上の各ＥＣＵ（ノード）は、定義されたサイクル（又はシーケンス）内で１回送信する機会を有する。

【0006】

この場合、ネットワークコントローラの機能を担う、ヘッドノードとして知られているものがサイクルを判定し、バス上で繰り返し「ビーコン」を送信する。このように、ノードは、事前に定義された識別ＩＤに基づいてタイマを開始し、送信が許可される時点についての順番を判定し、そのタイマが満了して、ノードが次であると認識された後に送信を許可される。

【0007】

図２は、イーサネットバス上の通信の基本的なシーケンスを示す。ビーコンが送信された後、次にノード０が送信され、これがその送信を終了すると、次のノードが送信を許可される（通常、それぞれの場合に単一のイーサネットフレームのみがスロットにおいて送信され得る）。

【0008】

図３は、スタブによるイーサネットバスの物理的な表現を示す。

【0009】

欧州特許出願公開第２ ５８５ ９４０Ａ１号明細書は、管理されたネットワークにおけるネットワーク通信をスケジューリングするためのシステム及び方法が、複数のネットワークノードを認識するネットワークコントローラを含み得ることを記載しており、ネットワークコントローラは、ノードレベルでネットワーク通信を優先させるために、認識されたネットワークノードを２つ以上のノード分類に分類し、ネットワークコントローラは、複数のネットワークノードの少なくとも一部から予約要求を受信し、この予約要求は、その後の通信ウィンドウにおいてそれぞれのネットワークノードのための１つ以上の時間スロットを要求し、ネットワークコントローラは、予約要求に応じて、その後の通信ウィンドウにおいて時間スロットを１つ以上のネットワークノードに割り当て、この割り当ては、ネットワークノードの優先度に基づき、この優先度は、ノード分類に従って割り当てられる。この特許出願は、ネットワークコントローラが周期的な媒体アクセスプラン（ＭＡＰ）を作成し、ネットワークノードのアクセス動作が各サイクルで定義されることを記載している。その基礎は、ネットワークコントローラがＭＡＰを作成するための必要とされるサービスの品質、それぞれのノードからの予約要求及びノードの優先度／より低い優先度である。ネットワークコントローラは、予約要求なしでＭＡＰメッセージを自動的に送信することもできる。

【0010】

米国特許出願公開第２００５ ２１３ ５０３ Ａ１号明細書では、説明された特定の実装形態に従い、調整装置が、以前に満たされていない帯域幅割り当て要求からの情報に基づいて帯域幅割り当て手順を実行し、現在の帯域幅割り当て要求に応答する。現在の帯域幅割り当て要求は、複数のストリームに対して現在要求されている帯域幅の量を指定し、現在の帯域幅割り当て要求は、複数のストリームにより複数のエンティティから受信され得る。以前に満たされていない帯域幅割り当て要求からの情報は、現在要求されている帯域幅量に対して複数のストリーム間又は複数のエンティティ間で使用可能な帯域幅を割り当てる際に考慮される。ネットワークノードのバスアクセスをプランニングする際、以前のサイクルからの「未サービス」アクセス予約もヘッドノードによって考慮される。

【0011】

（１００／１０００Ｍビット／秒などと同様の）スイッチドネットワークとは対照的に、前述の１０Ｍビット／秒では、バスに直ちにアクセスすることができず、それぞれの時間だけ待つ必要がある。他のイーサネットタイプと比較して、１０Ｍビットバスは、データレートが大幅に低いため、ここではデータ送信の効率及び送信の待ち時間（又はむしろアクセス時間も）を特に考慮する必要がある。セキュリティも１０Ｍビット／秒システムの一部になる場合、（現在のＣＡＮ－ＦＤ実装形態と同様に）ペイロードデータのためのデータレートは、ほとんど残らない。

【0012】

制御装置のフラッシュ、すなわちソフトウェアの更新、新しい機能の提供、エラーの排除は、自動車産業にとって実際に新しいトピックではないが、それにもかかわらず、新しいモバイル通信標準５Ｇにより、今後数年間で更により重要になるであろう。一方では十分な帯域幅があり、他方では排他的なアクセス（ポイントツーポイント全二重接続）が利用可能であるため、イーサネット（１００Ｍビット／秒、１０００Ｍビット／秒など）にわたってフラッシュも全く問題にならない。

【0013】

新しい１０Ｍビット／秒マルチドロップバスでは、産業横断的な標準で考慮されていなかった新しい課題に対処する必要がある。これは、このバスでは並列の送受信が不可能であり、このバスでは各ノードが送信サイクルごとに１フレームのみを送信することができるためである。バス上のサブスクライバの効率的なフラッシュ又はソフトウェアのダウンロード若しくは診断クエリのための実際の時間に対する解決策は、現在のところ存在しない。約８個のノードを伴う残りのデータレートは、通常、１～２Ｍビット／秒のみになる。

【0014】

現在問題となっていることは、標準では１サイクルあたり１フレームのみ送信することができるために、バス上のサブスクライバ数が増加するにつれて、それぞれのノード（ここでは特にマスターノード又はヘッドノード）のための残りのデータレートが減少することである。

【0015】

ヘッドノードは、ヘッドユニット、ゲートウェイ、融合ユニット又は一般的にゾーンコントローラ、すなわち、通常、更新又は診断クエリがまた発せられるのと同じ制御装置上のいずれかに実装されることになる。

【0016】

バーストモードとしても既知である、ノードがそのサイクル中に最大２５５パケットを送信することができるモードを使用することが知られているが、このモードは、静的に事前設定されて維持される必要がある。

【0017】

半自動運転及び高度な自動運転では、現在の航空機又は産業オートメーションにおいて既にそうであるように、送信ネットワーク及びプロトコルからのハードリアルタイムサポートを必要とする車両に対する要求が高まっている。

【0018】

本発明の目的は、センサ又は他の制御装置のソフトウェア又は診断クエリのフラッシュ時間、特にダウンロード時間を最適化することを可能にすることである。

【0019】

この目的は、請求項１に記載の方法、請求項４に記載の制御装置及び請求項６に記載のイーサネットネットワークの特徴によって達成される。

【0020】

本発明は、コスト及び実装労力に関して、自動車で使用するために新しいイーサネット技術を有利に適応させる。

【0021】

本発明は、バスサイクルをヘッドノードのデータレート要件に適応させる方法を提案する。これは、必要に応じてより多くの帯域幅をヘッドノードに動的に割り当て得ることを意味する。本発明は、送信されるデータのサイズに応じて、送信時間に対するダウンロード／更新要件が侵害されないようにバスサイクルを適応させる方法を提案する。この場合、方法は、いずれの時点でどの程度の帯域幅を提供しなければならないかを計算する。しかしながら、プロセス中の方法は、常に標準を考慮し、他のノードに介入する必要はない。

【0022】

この提案は、ビーコンのサイクル時間がバス及びその構成にのみ依存するが、個々のノード又はその要件に依存しないという問題を解決する。新しいアーキテクチャの基本的な変革は、より少ないコンピューティングユニットにソフトウェアを集中させることによって特徴付けられる。これらのいわゆるサーバ又は中央コンピュータは、もはや１つのみのμＣ又はμＰで構成されているのではなく、複数のμＣ、μＰ、ＳＯＣ、更に多数のポートを有するイーサネットスイッチを含み、それぞれの場合に個別のソフトウェアを伴う独自のローカルネットワークを表す（これは、それぞれのソフトウェアコンポーネントが、例えば、同じハウジング内に位置するコンポーネントと通信していることを知らない（知ることができない）ことも意味する）。

【0023】

中央サーバを伴うゾーンアーキテクチャが知られている。ここでは、一方でサーバが多くの強力なプロセッサを含み、他方で多くのソフトウェア又はアプリケーションがその上で実行される。制御装置内の通信労力は、膨大である（これは、独自のローカルネットワークを表す）。将来的に、車両の全ソフトウェアがここで実行され、各コントローラは、異なるサプライヤから提供される独自のソフトウェアスタックを有する。

【0024】

機能及びアプリケーションを他の制御装置／プロセッサに（動的に）送信する、すなわちまたそれらを最適化するためのコンセプトが知られている。これは、ライブマイグレーション、再割り当て、マイグレーションと呼ばれる。他のＥＣＵ／プロセッサにソフトウェアを転送するためのシリーズアプリケーションが知られている。

【0025】

ハードウェアがより一般化するようになり、ソフトウェアがプラットフォームにより依存しなくなったために、新しいアーキテクチャにより、これまで全ての機能及びＥＣＵで可能ではなかったソフトウェアを異なるＥＣＵ上でも同様に実装できる可能性が初めて出てきた。したがって、いずれの制御装置（サーバ）上でどのようなソフトウェアが動作することになるかは、システム設計時に必ずしも確定しているわけではない。ソフトウェアにおけるシフトは、ＥＣＵ間の動作に限定されず、更に同じＥＣＵ内のコントローラ間の動作にも適用される。

【発明の概要】

【発明が解決しようとする課題】

【0026】

有利には、本発明は、フラッシュ時間、したがって例えば制御装置からのソフトウェアのダウンロードを大幅に最適化して短縮することができる。このコンセプトは、ハードウェアコストなどの追加の金銭的支出なしに、標準に準拠しながら実施することができる。電動車両において新しく導入されたイーサネットプロトコルの使用は、高価な実装形態及び更なる追加のハードウェアなしに行うことができるため、シンプルな技法及び技術の所与の特性を利用するメカニズムを必要とする。本発明によるネットワークシステムは、信頼性の点で改善されている。

【0027】

より正確で予測可能な遅延をアプリケーションごとに判定することの利点は、車両内の通信のスケジューリング及び実行を改善することにある。これは、既存のバスシステムをより効率的に使用することができ、且つ高価な技術（より高い帯域幅）へのジャンプを回避できることを意味する。これにより、必要とされるバッファストレージに対しても影響を与える可能性があり、その場合、バッファストレージは、なしにされ得る（又はより小さく作成される）。異なるデータ（例えば、超音波＋レーダ又はマイクロフォン）の融合は、それにより改善されて、より正確になり得る。更に、データのロギングを更に一層正確にすることができる。

【0028】

本発明は、ソフトウェアをより柔軟に設計し、あらかじめソフトウェアに恒久的にプログラムする必要なく、基本的なシステムを最大限に活用することを可能にする方法を提示する。本発明は、ソフトウェア開発者及びソフトウェア設計者が、より柔軟に且つより正確にアプリケーションケースの要件に合わせることができるソフトウェア／アプリケーションを提供することを可能にする。前述の方法をソフトウェアに組み込むことにより、それぞれの場合に制御装置内で最適化が生じることが可能にする。これは、ソフトウェアをよりプラットフォームに依存しない方法で開発できることを意味する。

【0029】

本発明は、１０Ｍビット／秒イーサネットバスシステムにおいて、先行技術で可能なものよりも約８倍速くソフトウェアをフラッシュすることができるという利点を提供する。これは、メモリの寸法をより小さくするか、又はメモリを他のアプリケーションに解放できることを意味する。

【0030】

ソフトウェアアップデートである場合、次いでより現実的な時間ウィンドウを、本発明を介して返答することができ、最悪のケースを想定する必要はない。したがって、そうでなければ決して開始されないか又は後に開始されることになるダウンロード／アップデートが可能である。

【0031】

新しい技術は、もはや電動車両のみにとどまり得ない。ＩＰ、ＡＶＢ及びＴＳＮなどのプロトコルには、何千ページもの仕様及びテストスイートがある。これらの新しいプロトコルが自動車で制御可能であることは、現在ところ既知の事実ではない。

【0032】

本発明の利点は、通常のハードウェアを変更する必要がなく、既存のハードウェアを使用し続けることができる点である。新しい方法は、既存の装置を損なうことなく、既存のネットワークに組み込むことができる。既存のプロトコルを使用することができるため、遵守すべき標準に抵触することはない。

【0033】

本発明による方法の使用は、産業オートメーションなど、１０Ｍビット／秒イーサネットを使用する他の産業分野においても使用することができる。

【課題を解決するための手段】

【0034】

この目的は、ヘッドノード及び複数の関連ノードを有するイーサネットネットワークを介してセンサノードを急速にフラッシュさせる方法によって有利に達成され、方法は、
ａ）ヘッドノードにより、アクティブノードの数を判定すること、
ｂ）ヘッドノードにより、識別されたノードを２つ以上のノード分類に分類して、イーサネットネットワーク通信を優先させること、
ｃ）ヘッドノードにより、複数のノードの少なくとも一部から予約要求を受信すること、
ｄ）予約要求に応じて、その後の通信ウィンドウの時間スロットにおいて１つ以上のノードに割り当てることであって、割り当ては、ノード優先度に基づき、及び優先度は、ノードにその分類に従って割り当てられる、割り当てること
を含み、アクティブノードの数が判定された後、必要なダウンロードデータレートが判定され、及び現在のバス利用率が確認され、バス利用率は、最後のビーコンの時間差及びノードの数を計算することによって確認され、及びイーサネットネットワークのバスサイクルは、必要なダウンロードデータレートに関して最適化される。

【0035】

本方法の有利な実施形態では、バス利用率は、連続的に監視される。

【0036】

本方法の更に有利な実施形態は、必要なダウンロードデータレートが判定されると、イーサネットネットワークの最後のバスサイクルにおけるイーサネットネットワーク内の現在の空きデータレート（Ｄ_ｆｒｅｉ）が判定され、及び１バスサイクルあたりの必要なデータレート（Ｄ_ｚｕｓ）が判定され、イーサネットネットワークの最後のバスサイクルにおけるイーサネットネットワーク内の空きデータレート（Ｄ_ｆｒｅｉ）が１バスサイクルあたりの必要なデータレート（Ｄ_ｚｕｓ）以上である場合、次のバスサイクルにおいて変更が行われず、及びイーサネットネットワークの最後のバスサイクルにおけるイーサネットネットワーク内の空きデータレート（Ｄ_ｆｒｅｉ）が１バスサイクルあたりの必要なデータレート未満である場合、次のバスサイクルにおいて変更が行われることを特徴とする。

【0037】

特に有利であるのは、イーサネットネットワークのための制御ユニットによる実装形態であり、制御ユニットは、イーサネットオンボードネットワークの第２の制御ユニットに信号を送信し、且つ第２の制御ユニットから信号を受信することと、第２の制御ユニットに対する接続経路上の信号の遅延時間を判定することと、遅延時間に基づいて接続経路の最大速度を判定することと、最大速度に基づいて接続経路の送信媒体のタイプを判定することとを行うための制御ユニットとしての第１のノードの形態であり、制御ユニットは、マイクロプロセッサ、揮発性メモリ及び不揮発性メモリ、少なくとも２つの通信インタフェース、同期可能なタイマを少なくとも含み、不揮発性メモリは、マイクロプロセッサによって実行されると、本発明による方法の少なくとも１つの実施形態が実施及び実行されることを可能にするプログラム命令を含む。

【0038】

特に有利であるのは、自動車のためのイーサネットネットワークであって、第１の制御ユニットと第２の制御ユニットとを有し、制御ユニットは、少なくとも１つの接続経路を介して互いに接続され、及び第１の制御ユニットは、本発明による方法を実行するように設計される、イーサネットネットワークによる実装形態である。

【0039】

イーサネットオンボードネットワークの特に有利な実施形態は、イーサネットネットワークが第３の制御ユニットを含み、第３の制御ユニットが第１の制御ユニットに間接的にのみ接続され、且つ第３の接続経路を介して第２の制御ユニットに直接接続され、第３の制御ユニットが第３の接続経路上の第３の信号の遅延時間を判定するように設計され、第１の制御ユニットが、第３の制御ユニットへのサービスメッセージにより、第３の信号の遅延時間の判定をトリガするように設計される点で区別される。

【0040】

本発明が開示する方法を実施することにより、より高品質であり且つ耐久性のある、プラットフォームに依存しないソフトウェアを使用することができる。本発明は、クロック同期コンポーネントを有する他の通信システム及び組み込みシステムに採用され得る。

【0041】

本発明の例示的な実施形態が図面に描かれ、以下でより詳細に説明される。

【図面の簡単な説明】

【0042】

【図1】イーサネットバス（１０Ｍビット／秒）とスイッチドネットワークとの間の違いの簡略図を示す。

【図2】イーサネットバス上の基本的な通信の流れを示す。

【図3】スタブによるイーサネットバスの物理的表現を示す。

【図4】本発明による問題を簡略化して示す。

【図5】動的に変化するビーコンサイクル時間による本発明の一般的な解決策を示す。

【図6】ヘッドノードの帯域幅要件に対するビーコンサイクル時間の最適化を示す。

【図7】シンプルなサイクル最適化の実施形態を示す。

【図8】拡張された、公正なサイクル最適化の実施形態を示す。

【図9】ダウンロードデータレートを計算するための代替形態を示す。

【発明を実施するための形態】

【0043】

図１は、イーサネットバス（１０Ｍビット／秒）とスイッチドネットワークとの間の違いの簡略図を示す。

【0044】

図２は、イーサネットネットワークバス上の基本的な通信の流れを示す。ビーコンが送出されると、まずノード０の順番になり、その送信が終了すると、次のノードが送信され得る。通常、それぞれの場合に単一のイーサネットフレームのみがスロットにおいて送信され得る。

【0045】

図３は、スタブによるイーサネットバスのコンポーネントベースでの表現を示す。

【0046】

図４は、本発明による目的の簡略化された表現を示す。

【0047】

図５では、本発明の一般的な解決策が、動的に変化するビーコンサイクル時間によって示され、ビーコン信号は、「Ｂ」として示される。本発明は、自動車用１０Ｍビット／秒バスにおけるデータ送信の効率を最適化し、且つヘッドノードのためのバスアクセス時間を短縮するための新しい方法を提案する。本発明の発想は、イーサネットネットワークのバスサイクルの適応を説明する。ＦｌｅｘＲａｙと異なり、これには、否定的な効果又は考慮不足の効果はない。ノードは、固定された明確な時間ウィンドウを有さず、事前設定された固有のノードＩＤに基づく送信順序に従うのみである。

【0048】

図６は、バスサイクルが最適化される基礎を示す。まず、ヘッドノードが、いずれのデータをいずれの時間単位で伝送しなければならないかを判定する。これは、ファイルのサイズ又はストリームの持続時間であり得る。データ送信のオーバーヘッド（イーサネットヘッダなど）を考慮して、バス上の絶対データレートは、このように判定される。

【0049】

バスサイクルの無駄な最適化又は適応を回避するために、この方法は、現在のバス利用率を判定することを提案する。現在の利用率は、最後のビーコンの時間差及び参加ノードの数によって判定され得る。バス利用率が低い場合、次のサイクルに向けて急激に増加することはないであろうと統計的に想定することができる。しかしながら、バス利用率を継続的に監視することが提案されるため、いかなる変化にも対応することが依然として可能である。

【0050】

最後のステップでは、必要なデータレートに応じてバスサイクルが適応される。これについては、後に２つの可能性が提案される。

【0051】

図７は、必要なデータレートを現在のバス容量と比較する方法の部分的なステップを示す。まず、必要なダウンロードデータレートを１０Ｍビットバスに関して計算する。次いで、アクティブノードの数がヘッドノードによって判定される。受動的なリスニングのみであるか、エラー状態にあるか又はスリープモードにあるかのいずれかの非アクティブサブスクライバのスロットが判定され、Ｄ_ｆｒｅｉと呼ばれるヘッドノードのための方法によって利用可能にされる。

【0052】

これにより、進行中の通信を能動的に妨害することなく、またノードをミューティングすることなく、直ちにバスの最適化がもたらされる。常に最悪のケースを想定する必要なく、実際のデータレートをアプリケーションに返答することもできる。これにより、メモリが節約され、アプリケーションに（場合によりドライバにも）リアルタイムのウィンドウバックが提供される。この方法は、サイクルを最適化することに向けての最初のステップとなる。

【0053】

通常のバス動作に従って利用できる帯域が十分でない場合でも、ヘッドノードがその必要なデータレートを提供できるように、バス上の他のサブスクライバ（当然のことながらヘッドノードを除く）のサブセット（又は全ても）が、ヘッドノードで計算された必要なデータレートに基づいて送信することを防止し、したがってダウンロード（又はセキュリティ更新）の目的のためのサイクル時間を短縮するための、別の最適化のステップが説明される。この目的のため、ヘッドノードが現在のサイクルにおいて依然として送信しなければならないデータ量が常に比較され、この値が、このサイクルで０を下回ってはならず、したがって次のビーコンが送信される前にサイクルが終了されることになる、限界値とされる。この方法では、特定の許容範囲内でのみ、必要なだけの帯域幅がヘッドノードのために使用されて、残りは後続のノードによる使用に対して依然として利用可能であるため、他のバスサブスクライバに対して可能な限りの高い公平性がもたらされる。各バスサブスクライバは、０（データを全く送信しない）、６４（最小のイーサネットフレームを送信する）及び１５２２バイト（最大のイーサネットフレームを送信する）の間にあるため、この残りの帯域幅により、１サイクルで依然として送信できるノードの数を正確に予測することができない。

【0054】

公平性を更に高めるために、ノードがもはや送信できなくなり、次のビーコンによってサイクルが終了した場合（そのスロット内の残りの必要なデータレートが潜在的な最大イーサネットフレームを下回るため）、「残りの帯域幅」を次のサイクルに繰り越し、次のサイクルで他のバスサブスクライバが使用できるように解放することが提案される。このように、ヘッドノードにおける帯域要件が満たされるにもかかわらず、一種の「クレジット」が蓄積され得る。

【0055】

しかしながら、クレジットが過度に増加して、多くの他のバスサブスクライバが大量のデータを支障なく送信することができるような大きいデータバーストを引き起こす可能性を防止するために、秒単位で設定可能な期間後にクレジットを飽和又はリセットすることによって時間的に又は設定可能な数のバスサイクル後にクレジットを飽和又はリセットするときにサイクルカウンタによってのいずれかでクレジットの増加を制限することも提案される。

【0056】

この拡張されたより公平なサイクル最適化のシーケンスを図８に示す。このタイプのサイクル最適化は、唯一の考えられるものではない。図７のような「公平性なし」と図８のような「最大可能な公平性あり」との間の中間解決策は、例えば、ヘッドノードのみが数サイクルにわたって送信を許可されて、それに応じて大きいクレジットが急速に蓄積される、よりシンプルな方法であり得る。特定の閾値後、次いで特定のサイクル数の間に全てのノードに送信する機会を与えてから再び「休止」させるサイクルを挿入することにより、これを一度に低減することができる。所望であれば、方法をシンプルにするために、クレジットを考慮することなく単にサイクル数に応じてこの変形例を実施することもできる（例えば、「９９サイクルでヘッドノードのみを送信し、その後、１サイクルで全てのノードを送信する」）。しかしながら、この場合、ヘッドノードのデータレートにおける特定のジッタ（分散）を排除することはできない。

【0057】

図９は、アクティブノードの数を判定した後、未使用の送信可能性を判定し、それによりヘッドノードのための絶対データレートを時間単位ごとに計算する、更なる代替の方法ステップを示す。

【0058】

以下では、本発明は、通信パートナ又はそのアプリケーションの信頼性を判定するための既に提示された方法について提案する。この信頼性が判定されることを条件として、機密データの交換を実行することができる。

【0059】

図３は、ＥＣＵ（サーバ）が車両の外部の更なるセンサ及びＥＣＵ並びにコンポーネントと接続され得る、全体的なシステムアーキテクチャの詳細も概略的に示す。例えば、サーバ上のヘッドノードは、通常、ＭＩＩ（媒体独立インタフェース）又はＰＣＩ Ｅｘｐｒｅｓｓを介してＰＣＢ（プリント回路基板）上に接続され、したがって送受信機（ＰＨＹ）なしで常に管理することができる。

【0060】

イーサネット送受信機（ＰＨＹ）は、３桁のナノ秒範囲の遅延を引き起こす。これは、些細なことのようであるが、レイヤ２（ＭＡＣ）の遅延は、測定の解像度がどの程度高いかに応じて、およそ１桁のナノ秒範囲又は０に向かいがちな値である。

【0061】

この方法は、まず、データを交換（受信、送信又はその両方）するアプリケーションのアドレスを判定する。

【0062】

方法は、次いで、このコンポーネントに対する遅延時間測定を開始する。例えば、ｇＰＴＰプロトコル（又は８０２．１ＡＳ）のＰＤｅｌａｙ＿Ｒｅｑｕｅｓｔ方式をここで使用することができる。応答として２つのレスポンスが返送され、ハードウェア時間スタンプを使用してメッセージの遅延時間を判定することができる。例えば、ハードウェア時間スタンプを伴うプロトコル－ＮＴＰの使用は、したがって、分解能があまりにも不正確であるために除外される。

【0063】

この計算された値を用いて、方法は、このサブスクライバまでの物理的距離を計算する。ここでは、距離は、メートル又はセンチメートルなどの単位で直接表現されないが、この遅延は、実際のケーブル上の遅延とは対照的に重要であるため、接続の一部であるコンポーネント（ＰＨＹ、スイッチ）の数に変換され得る。

【0064】

方法は、遅延時間測定（例えば、ＰＴＰプロトコルの一部）を開始し、且つそこからこのサブスクライバまでの距離を計算することにより、サブスクライバ／アドレスまでの遅延時間を測定する。

【0065】

測定された遅延時間は、位置の指標を提供するために最初に評価されなければならない。ソフトウェアは、同じＥＣＵ内にパートナが位置するか否か、又は理想的には特別なバージョンではなく一般的なＳＷが使用されているかどうかを知ることができず、加えて、ＩＰアドレスは、改竄又は変更され得る。ＭＩＩベース接続の遅延時間は、ＰＨＹ（送受信機）を必要としない。しかしながら、時間同期ソフトウェアも、この調査を委託している実際のアプリケーションもこれを知らない。ＰＨＹは、データを電気信号に変換して符号化するものであり、ＭＩＩベースのラインを介して２つのイーサネットＭＡＣが互いに通信する場合よりもはるかに時間がかかる。

【0066】

提示された方法は、要求するサブスクライバにサブスクライバが直接接続されているかどうかを認識する。そうでない場合、待ち時間に応じて適切なプロトコルが選択され得る。例えば、車両内で適用される待ち時間に対してＭＡＣ－Ｓｅｃ又はＩＰ－Ｓｅｃを使用し、待ち時間が非常に大きく、サブスクライバが間違いなく車両の外部にいる場合、他のＩＰ／ＴＣＰベースの方式を使用することができる。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【国際調査報告】