特表 2022-513948 シリアルバスシステム用の加入局およびシリアルバスシステムでの通信方法

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

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

(11)【公表番号】

(43)【公表日】2022-02-09

(54)【発明の名称】シリアルバスシステム用の加入局およびシリアルバスシステムでの通信方法

(51)【国際特許分類】

   H04L 12/413 20060101AFI20220202BHJP

【ＦＩ】

H04L12/413

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2021534662

(86)(22)【出願日】2019-12-17

(85)【翻訳文提出日】2021-08-16

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

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

(87)【国際公開日】2020-06-25

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

(32)【優先日】2018-12-17

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

(81)【指定国・地域】

(71)【出願人】

【識別番号】591245473

【氏名又は名称】ロベルト・ボッシュ・ゲゼルシャフト・ミト・ベシュレンクテル・ハフツング

【氏名又は名称原語表記】ＲＯＢＥＲＴ ＢＯＳＣＨ ＧＭＢＨ

(74)【代理人】

【識別番号】100118902

【弁理士】

【氏名又は名称】山本 修

(74)【代理人】

【識別番号】100196508

【弁理士】

【氏名又は名称】松尾 淳一

(74)【代理人】

【識別番号】100147991

【弁理士】

【氏名又は名称】鳥居 健一

(74)【代理人】

【識別番号】100201743

【弁理士】

【氏名又は名称】井上 和真

(72)【発明者】

【氏名】ムッター，アルトゥール

(72)【発明者】

【氏名】ハートビヒ，フロリアン

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

5K032

【Ｆターム（参考）】

5K032AA01

5K032BA06

5K032CA08

5K032CB01

5K032CC09

5K032EA05

5K032EC03

(57)【要約】

シリアルバスシステム（１）用の加入局（１０；３０）およびシリアルバスシステム（１）での通信方法が提供される。加入局（１０；３０）は、バスシステム（１）の加入局（１０；３０）と少なくとも１つの他の加入局（１０；２０；３０）との間の通信を制御するための通信制御デバイス（１１；３１）と、通信制御デバイス（１１；３１）によって生成された送信信号（ＴＸＤ）をバスシステム（１）のバス（４０）上に送信して、バスシステム（１）の加入局（１０、２０、３０）間で交換されるメッセージ（４５）に関して、バス（４０）に第１の通信フェーズ（４５１）で送信される信号のビット時間（ｔ＿ｂｔ）が、第２の通信フェーズ（４５２）で送信される信号のビット時間（ｔ＿ｂｔ）とは異なるようにするための送信／受信デバイス（１２；３２）とを備え、通信制御デバイス（１１；３１）が、フレーム（４５０；４５０＿１；４５００）に従って送信信号（ＴＸＤ）を生成するように構成され、フレーム（４５０；４５０＿１；４５００）内に、ヘッダチェックサム（Ｈ＿ＣＲＣ）に関するフィールドとフレームチェックサムに関するフィールド（Ｆ＿ＣＲＣ）とが与えられ、通信制御デバイス（１１；３１）が、固定数のビットの後に固定スタッフビットを挿入すべき固定ビットスタッフィング規則に従ってフレーム（４５０；４５０＿１；４５００）のヘッダに挿入された固定スタッフビットを除いて、メッセージ（４５）のために形成されたフレーム（４５０；４５０＿１；４５００）のヘッダのすべてのビットからヘッダチェックサム（Ｈ＿ＣＲＣ）を計算するように構成される。

【特許請求の範囲】

【請求項1】

シリアルバスシステム（１）用の加入局（１０；３０）であって、
バスシステム（１）の加入局（１０；３０）と少なくとも１つの他の加入局（１０；２０；３０）との間の通信を制御するための通信制御デバイス（１１；３１）と、
前記通信制御デバイス（１１；３１）によって生成された送信信号（ＴＸＤ）を前記バスシステム（１）のバス（４０）上に送信して、前記バスシステム（１）の加入局（１０、２０、３０）間で交換されるメッセージ（４５）に関して、前記バス（４０）に前記第１の通信フェーズ（４５１）で送信される信号のビット時間（ｔ＿ｂｔ）が、前記第２の通信フェーズ（４５２）で送信される信号のビット時間（ｔ＿ｂｔ）とは異なるようにするための送信／受信デバイス（１２；３２）とを備え、
前記通信制御デバイス（１１；３１）が、フレーム（４５０；４５０＿１；４５００）に従って前記送信信号（ＴＸＤ）を生成するように構成され、前記フレーム（４５０；４５０＿１；４５００）内に、ヘッダチェックサム（Ｈ＿ＣＲＣ）に関するフィールドとフレームチェックサムに関するフィールド（Ｆ＿ＣＲＣ）とが与えられ、
前記通信制御デバイス（１１；３１）が、前記バス（４０）上で前記交換されるメッセージ（４５）を送信するための優先順位を示す識別子を前記フレーム（４５０；４５０＿１；４５００）に与えるように構成され、
前記通信制御デバイス（１１；３１）が、前記フレーム（４５０；４５０＿１；４５００）に、少なくとも１つのさらなる識別子を与えるように構成され、
前記少なくとも１つのさらなる識別子が、メッセージ識別情報（ＭＳＧＩＤ）として、前記交換されるメッセージ（４５）のデータフィールド内のデータの内容を示し、または送信元識別情報（ＴＸＩＤ）として、前記交換されるメッセージ（４５）に関する前記送信側加入局を示し、または仮想ネットワーク識別情報（ＶＬＡＮＩＤ）として、前記交換されるメッセージ（４５）に関する転送情報を示すものである、
加入局（１０；３０）。

【請求項2】

前記少なくとも１つのさらなる識別子が、前記データフィールドの一部であり、データ長コード（ＤＬＣ）が、前記少なくとも１つのさらなる識別子の長さを考慮に入れて前記データフィールドの長さを示すものである、請求項１に記載の加入局（１０；３０）。

【請求項3】

前記少なくとも１つのさらなる識別子が、前記データフィールドの一部ではなく、データ長コード（ＤＬＣ）が、前記少なくとも１つのさらなる識別子の長さを考慮に入れずに前記データフィールドの長さを示すものである、請求項１に記載の加入局（１０；３０）。

【請求項4】

前記メッセージ識別情報（ＭＳＧ ＩＤ）の長さ、前記送信元識別情報（ＴＸ ＩＤ）の長さ、または仮想ネットワーク識別情報（ＶＬＡＮ）の長さが、前記通信制御デバイス（１１；３１）においてビット毎に設定可能である、請求項１から３のいずれか一項に記載の加入局（１０；３０）。

【請求項5】

前記メッセージ（４５）用に形成された前記フレーム（４５０；４５０＿１）が、ＣＡＮＦＤと互換性があるように構成される、請求項１から４のいずれか一項に記載の加入局（１０；３０）。

【請求項6】

前記第１の通信フェーズ（４５１）において、前記バスシステム（１）の前記加入局（１０、２０、３０）のうちのいずれかが、後続の第２の通信フェーズ（４５２）で、前記バス（４０）への少なくとも一時的に排他的で衝突のないアクセスを取得するかが交渉される、請求項１から５のいずれか一項に記載の加入局（１０；３０）。

【請求項7】

シリアルバスシステム（１）での通信方法であり、通信制御デバイス（１１；３１）と送信／受信デバイス（１２；３２）とを備えた前記バスシステム（１）の加入局（１０；３０）で行われる方法であって、
前記通信制御デバイス（１１；３１）によって、前記バスシステム（１）の前記加入局（１０；３０）と少なくとも１つの他の加入局（１０；２０；３０）との間の通信を制御するステップと、
前記送信／受信デバイス（１２；３２）によって、前記前記通信制御デバイス（１１；３１）によって生成された送信信号（ＴＸＤ）を前記バスシステム（１）のバス（４０）上に送信して、前記バスシステム（１）の加入局（１０、２０、３０）間で交換されるメッセージ（４５）に関して、前記バス（４０）に前記第１の通信フェーズ（４５１）で送信される信号のビット時間（ｔ＿ｂｔ）が、前記第２の通信フェーズ（４５２）で送信される信号のビット時間（ｔ＿ｂｔ）とは異なるようにするステップとを含み、
前記通信制御デバイス（１１；３１）が、フレーム（４５０；４５０＿１；４５００）に従って前記送信信号（ＴＸＤ）を生成し、前記フレーム（４５０；４５０＿１；４５００）内に、ヘッダチェックサム（Ｈ＿ＣＲＣ）に関するフィールドとフレームチェックサムに関するフィールド（Ｆ＿ＣＲＣ）とが与えられ、
前記通信制御デバイス（１１；３１）が、前記バス（４０）上で前記交換されるメッセージ（４５）を送信するための優先順位を示す識別子を前記フレーム（４５０；４５０＿１；４５００）に与えるように構成され、
前記通信制御デバイス（１１；３１）が、前記フレーム（４５０；４５０＿１；４５００）に、少なくとも１つのさらなる識別子を与えるように構成され、
前記少なくとも１つのさらなる識別子が、メッセージ識別情報（ＭＳＧＩＤ）として、前記交換されるメッセージ（４５）の前記データフィールド内のデータの内容を示し、または送信元識別情報（ＴＸＩＤ）として、前記交換されるメッセージ（４５）に関する前記送信側加入局を示し、または仮想ネットワーク識別情報（ＶＬＡＮＩＤ）として、前記交換されるメッセージ（４５）に関する転送情報を示すものである、
方法。

【請求項8】

前記少なくとも１つのさらなる識別子が、前記データフィールドの一部であり、データ長コード（ＤＬＣ）が、前記少なくとも１つのさらなる識別子の長さを考慮に入れて前記データフィールドの長さを示すものである、請求項７に記載の方法。

【請求項9】

前記少なくとも１つのさらなる識別子が、前記データフィールドの一部ではなく、データ長コード（ＤＬＣ）が、前記少なくとも１つのさらなる識別子の長さを考慮に入れずに前記データフィールドの長さを示すものである、請求項７に記載の方法。

【請求項10】

前記メッセージ識別情報（ＭＳＧ ＩＤ）の長さ、前記送信元識別情報（ＴＸ ＩＤ）の長さ、または仮想ネットワーク識別情報（ＶＬＡＮ）の長さが、前記通信制御デバイス（１１；３１）においてビット毎に設定可能である、請求項７から９のいずれか一項に記載の方法。

【請求項11】

前記メッセージ（４５）用に形成された前記フレーム（４５０；４５０＿１）が、ＣＡＮＦＤと互換性があるように構成される、請求項７から１０のいずれか一項に記載の方法。

【請求項12】

前記第１の通信フェーズ（４５１）において、前記バスシステム（１）の前記加入局（１０、２０、３０）のうちのいずれかが、後続の第２の通信フェーズ（４５２）で、前記バス（４０）への少なくとも一時的に排他的で衝突のないアクセスを取得するかが交渉される、請求項７から１１のいずれか一項に記載の方法。

【発明の詳細な説明】

【技術分野】

【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】

【図1】第１の例示的実施形態によるバスシステムの簡略ブロック図である。

【図2】第１の例示的実施形態による、バスシステムの加入局が送信することができるメッセージの構造を説明するための図である。

【図3】第１の例示的実施形態によるバスシステムの加入局の簡略概略ブロック図である。

【図4】第１の例示的実施形態による、加入局におけるバス信号ＣＡＮ－ＦＸ＿ＨおよびＣＡＮ－ＦＸ＿Ｌの時間プロファイルを示す図である。

【図5】第１の例示的実施形態による、加入局におけるバス信号ＣＡＮ－ＦＸ＿ＨおよびＣＡＮ－ＦＸ＿Ｌの差動電圧ＶＤＩＦＦの時間プロファイルを示す図である。

【図6】第２の例示的実施形態による、バスシステムの加入局が送信することができるメッセージの構造を説明するための図である。

【図7】第３の例示的実施形態による、バスシステムの加入局が送信することができるメッセージの構造を説明するための図である。

【図8】本発明のさらなる態様、すなわちＣＡＮ ＦＸフレームでのいくつかの識別子の導入を説明するための図である。図８では、この態様は、図２からの前述した第１の例示的実施形態に基づいて示される。対応して、本発明のこの態様は、図６に示される第２の例示的実施形態および図７に示される第３の例示的実施形態にも適用することができる。

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

【0033】

図面中、特に指示のない限り、同一または機能的に同一の要素には同じ参照符号が付されている。
例示的実施形態の説明

【0034】

図１は、例としてバスシステム１を示し、バスシステム１は、特に基本的には、以下に述べるように、ＣＡＮバスシステム、ＣＡＮＦＤバスシステム、ＣＡＮ ＦＸバスシステム、および／またはそれらの変形システムのために構成される。バスシステム１は、特に自動車や航空機などの車両、または病院などで使用することができる。

【0035】

図１では、バスシステム１は、多数の加入局１０、２０、３０を有し、多数の加入局１０、２０、３０は、それぞれが、第１のバスワイヤ４１および第２のバスワイヤ４２を有するバス４０に接続されている。バスワイヤ４１、４２は、ＣＡＮ＿ＨおよびＣＡＮ＿ＬまたはＣＡＮ－ＦＸ＿ＨおよびＣＡＮ－ＦＸ＿Ｌとも呼ぶことができ、送信状態での信号に関して、ドミナントレベルのカップリング後またはレセシブレベルの生成後に電気信号伝送に使用される。バス４０を介して、信号の形式でのメッセージ４５、４６を個々の加入局１０、２０、３０間でシリアル伝送可能である。図１のギザギザの黒いブロック矢印によって示されるように、バス４０での通信中にエラーが発生した場合、任意選択でエラーフレーム４７（エラーフラグ）を送信することができる。加入局１０、２０、３０は、例えば自動車の制御機器、センサ、表示装置などである。

【0036】

図１に示されるように、加入局１０は、通信制御デバイス１１、送信／受信デバイス１２、およびチェックサムユニット１５を有する。加入局２０は、通信制御デバイス２１、送信／受信デバイス２２、およびチェックサムユニット２５を有する。加入局３０は、通信制御デバイス３１、送信／受信デバイス３２、およびチェックサムユニット３５を有する。加入局１０、２０、３０の送信／受信デバイス１２、２２、３２は、図１には図示されていないが、それぞれバス４０に直接接続されている。

【0037】

通信制御デバイス１１、２１、３１は、それぞれの加入局１０、２０、３０と、バス４０に接続されている加入局１０、２０、３０のうちの少なくとも１つの他の加入局とのバス４０を介した通信をそれぞれ制御する働きをする。

【0038】

通信制御デバイス１１、３１は、例えば修正されたＣＡＮメッセージ４５である第１のメッセージ４５の作成および読取りを行う。ここで、修正されたＣＡＮメッセージ４５は、図２を参照してより詳細に述べるＣＡＮＦＸフォーマットに基づいて構成されており、ＣＡＮ ＦＸフォーマットでは、それぞれのチェックサムユニット１５、３５が使用される。さらに、通信制御デバイス１１、３１は、必要に応じて、ＣＡＮＦＸメッセージ４５またはＣＡＮ ＦＤメッセージ４６を送信／受信デバイス３２に対して供給する、または送信／受信デバイス３２から受信するように設計することができる。ここでも、それぞれのチェックサムユニット１５、３５が使用される。したがって、通信制御デバイス１１、３１は、第１のメッセージ４５または第２のメッセージ４６の作成および読取りを行い、第１および第２のメッセージ４５、４６は、それらのデータ伝送規格が異なり、すなわちこの場合にはＣＡＮＦＸまたはＣＡＮ ＦＤである。

【0039】

通信制御デバイス２１は、ＩＳＯ１１８９８－１：２０１５に準拠した従来のＣＡＮコントローラのように、すなわちＣＡＮＦＤ許容の従来型ＣＡＮ ＣＡＮコントローラまたはＣＡＮ ＦＤコントローラのように設計することができる。通信制御デバイス２１は、第２のメッセージ４６、例えばＣＡＮ ＦＤメッセージ４６の作成および読取りを行う。ＣＡＮ ＦＤメッセージ４６には、０～６４データバイトが含まれることがあり、これらはさらに、従来型ＣＡＮメッセージよりも明らかに速いデータレートで伝送される。特に、通信制御デバイス２１は、従来のＣＡＮＦＤコントローラのように設計される。

【0040】

送信／受信デバイス２２は、ＩＳＯ１１８９８－１：２０１５に準拠した従来のＣＡＮトランシーバ、またはＣＡＮＦＤトランシーバのように設計することができる。送信／受信デバイス１２、３２は、必要に応じて、関連する通信制御デバイス１１、３１に対してＣＡＮＦＸフォーマットに従ってメッセージ４５を供給する、もしくは現在のＣＡＮ ＦＤフォーマットに従ってメッセージ４６を供給するように、または関連する通信制御デバイス１１、３１からメッセージを受信するように設計することができる。

【0041】

２つの加入局１０、３０を用いて、ＣＡＮ ＦＸフォーマットでのメッセージ４５の作成および伝送、ならびにそのようなメッセージ４５の受信を実現可能である。

【0042】

図２は、メッセージ４５に関してＣＡＮ ＦＸフレーム４５０を示し、ＣＡＮ ＦＸフレーム４５０は、送信／受信デバイス１２用の通信制御デバイス１１によってバス４０への送信のために提供される。この場合、通信制御デバイス１１は、図２にも示されているように、この例示的実施形態ではＣＡＮＦＤと互換性があるものとしてフレーム４５０を作成する。同じことが、加入局３０の通信制御デバイス３１および送信／受信デバイス３２にも同様に当てはまる。

【0043】

図２によれば、バス４０でのＣＡＮ通信のためのＣＡＮ ＦＸフレーム４５０は、異なる通信フェーズ４５１、４５２、すなわち調停フェーズ４５１およびデータフェーズ４５２に分割される。フレーム４５０は、調停フィールド４５３、制御フィールド４５４、データフィールド４５５、チェックサムＦ＿ＣＲＣ用のチェックサムフィールド４５６、同期フィールド４５７、および確認フィールド（ＡＣＫフィールド）４５８を有する。

【0044】

調停フェーズ４５１において、調停フィールド４５３での識別子（ＩＤ）を用いて、どの加入局１０、２０、３０がメッセージ４５、４６を最高の優先順位で送信したいか、したがって後続の時間に関して後続のデータフェーズ４５２で送信するためにバスシステム１のバス４０への排他的アクセスを取得するかが、ビット毎に加入局１０、２０、３０間で交渉される。調停フェーズ４５１では、ＣＡＮおよびＣＡＮ－ＦＤと同様に物理層が使用される。物理層は、既知のＯＳＩモデル（オープンシステム相互接続モデル）のビット伝送層または層１に対応する。

【0045】

フェーズ４５１中の重要な点は、既知のＣＳＭＡ／ＣＲ法が使用されることであり、ＣＳＭＡ／ＣＲ法は、より優先順位の高いメッセージ４５、４６が破壊されることなく、加入局１０、２０、３０がバス４０に同時にアクセスすることを許可する。これにより、さらなるバス加入局１０、２０、３０をバスシステム１に比較的容易に追加することができ、これは非常に有利である。

【0046】

ＣＳＭＡ／ＣＲ法により、バス４０上にいわゆるレセシブ状態が存在することになり、レセシブ状態は、他の加入局１０、２０、３０がバス４０上でドミナント状態によって上書きすることができる。レセシブ状態では、個々の加入局１０、２０、３０で高抵抗挙動が生じており、これは、バス回路の寄生と組み合わさって、より長い時定数をもたらす。これにより、今日のＣＡＮＦＤ物理層の最大ビットレートは、実際の車両での使用では現在約２メガビット／秒に制限されている。

【0047】

データフェーズ４５２では、制御フィールド４５４の一部に加えて、ＣＡＮ－ＦＸフレームの使用データ、またはデータフィールド４５５からのメッセージ４５、およびチェックサムＦ＿ＣＲＣに関するチェックサムフィールド４５６が送信される。

【0048】

加入局１０が送信元として調停に勝ち、したがって加入局１０が送信元として送信のためにバスシステム１のバス４０への排他的アクセスを得たとき、メッセージ４５の送信元は、バス４０でのデータフェーズ４５２のビットの送信を開始する。

【0049】

ごく一般に、ＣＡＮまたはＣＡＮ ＦＤと比較して、ＣＡＮ ＦＸを用いるバスシステムでは以下の異なる特性を実現することができる。
ａ）ＣＡＮおよびＣＡＮ ＦＤのロバスト性と使いやすさに寄与する実証済みの特性の採用および場合によっては適応、特に識別子を用いたフレーム構造、およびＣＳＭＡ／ＣＲ法による調停。
ｂ）特に毎秒約１０メガビットへの正味データ伝送レートの増加。
ｃ）特に約４キロバイトへの、フレーム当たりの使用データのサイズの増加。

【0050】

図２に示されるように、加入局１０は、第１の通信フェーズとしての調停フェーズ４５１において、部分的に、特にＦＤＦビット（これを含む）まで、ＩＳＯ１１８９８－１：２０１５に従ってＣＡＮ／ＣＡＮ－ＦＤから知られているフォーマットを使用する。対照的に、加入局１０は、ＦＤＦビットから、第１の通信フェーズと、第２の通信フェーズであるデータフェーズ４５２とにおいて、以下で述べるＣＡＮＦＸフォーマットを使用する。

【0051】

この例示的実施形態では、ＣＡＮ ＦＸとＣＡＮ ＦＤとには互換性がある。ここで、ＣＡＮ ＦＤから知られているｒｅｓビット（以下、ＦＸＦビットと呼ぶ）は、ＣＡＮ ＦＤフォーマットからＣＡＮＦＸフォーマットに切り替えるために使用される。したがって、ＣＡＮ ＦＤとＣＡＮ ＦＸとのフレームフォーマットは、ｒｅｓビットまで同じである。ＣＡＮＦＸ加入局、すなわちここでは加入局１０、３０は、ＣＡＮ ＦＤもサポートする。

【0052】

１１ビットの識別子が使用される図２に示されるフレーム４５０の代替として、任意選択で、２９ビットの識別子が使用されるＣＡＮＦＸ拡張フレームフォーマットも可能である。ＣＡＮ ＦＸ拡張フレームフォーマットは、ＦＤＦビットまでは、ＩＳＯ１１８９８－１：２０１５からの既知のＣＡＮ ＦＤ拡張フレームフォーマットと同じである。

【0053】

図２によれば、フレーム４５０は、ＳＯＦビットからＦＤＦビット（これを含む）まで、ＩＳＯ１１８９８－１：２０１５に準拠したＣＡＮＦＤベースフレームフォーマットと同一である。したがって、既知の構造は、本明細書でさらには説明しない。図２において下側の線が太い線分で示されているビットは、フレーム４５０でドミナントとして送信される。図２において上側の線が太い線分で示されているビットは、フレーム４５０でレセシブとして送信される。

【0054】

一般に、フレーム４５０の生成には２つの異なるスタッフィング規則が使用される。ＣＡＮＦＤの動的ビットスタッフィング規則は、制御フィールド４５４でのＦＸＦビットまで適用され、したがって連続する５つの同一のビットの後に逆スタッフビットが挿入され得る。制御フィールド４５４でのＦＸビットの後には固定スタッフィング規則が適用され、したがって、固定数のビットの後に固定スタッフビットが挿入され得る。代替として、ただ１つのスタッフビットの代わりに、２つ以上のビットを固定スタッフビットとして挿入することもできる。

【0055】

フレーム４５０では、ＦＤＦビットの直後にＦＸＦビットが続き、ＦＸＦビットは、その位置から、前述したようにＣＡＮＦＤベースフレームフォーマットでの「ｒｅｓビット」に対応する。ＦＸＦビットは、１、すなわちレセシブとして送信されるとき、それによりフレーム４５０をＣＡＮＦＸフレームとして識別する。ＣＡＮ ＦＤフレームの場合、通信制御デバイス１１は、ＦＸＦビットを０、すなわちドミナントとして設定する。
ＦＸＦビットの後、フレーム４５０でｒｅｓＦＸビットが続き、ｒｅｓＦＸビットは、将来の使用のためのドミナントビットである。ｒｅｓＦＸは、フレーム４５０に関しては、０、すなわちドミナントとして送信されなければならない。しかし、加入局１０がｒｅｓＦＸビットを１、すなわちレセシブとして受信した場合、受信側加入局１０は、ＣＡＮＦＤメッセージ４６でｒｅｓ＝１に関して行われるのと同様に、例えばプロトコル例外状態に入る。ｒｅｓＦＸビットを真逆に定義することもでき、すなわち、１、すなわちレセシブとして送信されることになり、したがって受信側加入局は、ドミナントｒｅｓＦＸビットでプロトコル例外状態になる。

【0056】

ＦＸＦビットの後、フレーム４５０で、所定のビットシーケンスが符号化されるシーケンスＢＲＳＡＤが続く。このビットシーケンスは、調停フェーズ４５１の調停ビットレートからデータフェーズ４５２のデータビットレートへの単純で確実な切替えを可能にする。例えば、ＢＲＳＡＤのビットシーケンスは、レセシブ調停ビットと、それに続くドミナントデータビットとからなる。この例では、ビットレートは、上記の２つのビット間のエッジで切り替えることができる。

【0057】

シーケンスＢＲＳ ＡＤの後、フレーム４５０でＤＬＣフィールドが続き、ＤＬＣフィールドにはデータ長コード（ＤＬＣ＝Ｄａｔａ Ｌｅｎｇｔｈ Ｃｏｄｅ）が挿入され、データ長コードは、フレーム４５０のデータフィールド４５５内のバイト数を示すものである。データ長コード（ＤＬＣ）は、１からデータフィールド４５５の最大長またはデータフィールド長までの任意の値を取ることができる。最大データフィールド長が特に２０４８ビットである場合、ＤＬＣ＝０は１バイトのデータフィールド長を意味し、ＤＬＣ＝２０４７は２０４８バイトのデータフィールド長データフィールド長を意味すると仮定して、データ長コード（ＤＬＣ）は１１ビットを必要とする。代替として、例えばＣＡＮの場合のように、長さ０のデータフィールド４５５を許可することができる。この場合、ＤＬＣ＝０は、例えば、０バイトを有するデータフィールド長を符号化する。符号化可能な最大データフィールド長は、例えば１１ビットでは、（２＾１１）－１＝２０４７である。

【0058】

ＤＬＣフィールドの後、フレーム４５０でヘッダチェックサムＨ＿ＣＲＣが続く。ヘッダチェックサムは、フレーム４５０のヘッダを保護するためのチェックサムであり、すなわち、ＳＯＦビットでのフレーム４５０の開始からヘッダチェックサムＨ＿ＣＲＣの開始までのすべてのビット（ヘッダチェックサムＨ＿ＣＲＣの開始までのすべての動的スタッフビットおよび任意選択で固定スタッフビットを含む）である。ヘッダチェックサムＨ＿ＣＲＣ、したがって巡回冗長検査（ＣＲＣ）に従ったチェックサム多項式の長さは、所望のハミング距離に対応して選択され得る。ヘッダチェックサムＨ＿ＣＲＣによって保護することができるデータワードは、１１ビットのデータ長コード（ＤＬＣ）では、２７ビットよりも長い。したがって、ハミング距離６を達成するには、ヘッダチェックサムＨ＿ＣＲＣの多項式が少なくとも１３ビットの長さでなければならない。ヘッダチェックサムＨ＿ＣＲＣの計算については、以下でより詳細に述べる。

【0059】

ヘッダチェックサムＨ＿ＣＲＣの後、フレーム４５０でデータフィールド４５５（Ｄａｔａ Ｆｉｅｌｄ）が続く。データフィールド４５５は、１～ｎ個のデータバイトからなり、ここで、ｎは、例えば２０４８バイトもしくは４０９６バイトまたは他の任意の値である。代替として、０のデータフィールド長も考えられる。データフィールド４５５の長さは、前述したようにＤＬＣフィールドに符号化される。

【0060】

データフィールド４５５の後、フレーム４５０でフレームチェックサムＦ＿ＣＲＣが続く。フレームチェックサムＦ＿ＣＲＣは、フレームチェックサムＦ＿ＣＲＣのビットからなる。フレームチェックサムＦ＿ＣＲＣ、したがってＣＲＣ多項式の長さは、所望のハミング距離に従って選択され得る。フレームチェックサムＦ＿ＣＲＣは、フレーム４５０全体を保護する。代替として、任意選択で、データフィールド４５５のみが、フレームチェックサムＦ＿ＣＲＣで保護される。フレームチェックサムＦ＿ＣＲＣの計算については、以下でより詳細に述べる。

【0061】

Ｆ＿ＣＲＣビットの後、フレーム４５０で、所定のビットシーケンスが符号化されるシーケンスＢＲＳ ＤＡが続く。このビットシーケンスは、データフェーズ４５２のデータビットレートから調停フェーズ４５１の調停ビットレートへの単純で確実な切替えを可能にする。例えば、ＢＲＳ ＤＡのビットシーケンスは、レセシブデータビットと、それに続くドミナント調停ビットとからなる。この例では、ビットレートは、上記の２つのビット間のエッジで切り替えることができる。

【0062】

シーケンスＢＲＳ ＤＡの後、フレーム４５０で同期フィールドが続き、同期フィールドでは同期パターン（Ｓｙｎｃ Ｐａｔｔｅｒｎ）が維持される。同期パターンは、データフェーズ４５２の後の調停フェーズ４５１の開始を受信側加入局１０、３０が認識できるようにするビットパターンである。同期パターンは、例えば誤ったヘッダチェックサムＨ＿ＣＲＣによりデータフィールド４５５の正しい長さを知らない受信側加入局１０、３０が同期することを可能にする。次いで、これらの加入局は「否定応答」を送信し、誤った受信を報告することができる。これは特に、ＣＡＮＦＸがデータフィールド４５５でエラーフレーム４７（エラーフラグ）をもはや許可しないときに非常に重要である。

【0063】

同期フィールドの後、フレーム４５０で確認フィールド（ＡＣＫフィールド）が続き、確認フィールドは、いくつかのビット、すなわち図２の例ではＡＣＫビット、ＡＣＫ－ｄｌｍビット、ＮＡＣＫビット、およびＮＡＣＫ－ｄｌｍビットからなる。ＮＡＣＫビットおよびＮＡＣＫ－ｄｌｍビットは、任意選択のビットである。受信側加入局１０、３０は、フレーム４５０を正しく受信したとき、ＡＣＫビットをドミナントとして送信する。送信側加入局は、ＡＣＫビットをレセシブとして送信する。したがって、フレーム４５０でバス４０に初めに送信されたビットを、受信側加入局１０、３０によって上書きすることができる。ＡＣＫ－ｄｌｍビットは、他のフィールドからの分離に使用されるレセシブビットとして送信される。ＮＡＣＫビットおよびＮＡＣＫ－ｄｌｍビットは、フレーム４５０の正しくない受信を受信側加入局がバス４０で信号通知することができるようにするために使用される。ビットの機能は、ＡＣＫビットおよびＡＣＫ－ｄｌｍビットの機能と同様である。

【0064】

確認フィールド（ＡＣＫフィールド）の後、フレーム４５０で終了フィールド（ＥＯＦ＝Ｅｎｄ ｏｆ Ｆｒａｍｅ）が続く。終了フィールド（ＥＯＦ）のビットシーケンスは、フレーム４５０の終了を特徴付けるために使用される。終了フィールド（ＥＯＦ）は、フレーム４５０の終了時に８つのレセシブビットが送信されることを保証する。これは、フレーム４５０内では生じ得ないビットシーケンスである。これにより、加入局１０、２０、３０によってフレーム４５０の終了を確実に認識することができる。

【0065】

終了フィールド（ＥＯＦ）は、ＮＡＣＫビットでドミナントビットが見られたか、それともレセシブビットが見られたかに応じて異なる長さを有する。送信側加入局がＮＡＣＫビットをドミナントとして受信したとき、終了フィールド（ＥＯＦ）は７つのレセシブビットを有する。そうでない場合には、終了フィールド（ＥＯＦ）は、５つだけのレセシブビットの長さである。

【0066】

終了フィールド（ＥＯＦ）の後、フレーム４５０で、フレーム間スペース（ＩＦＳ－Ｉｎｔｅｒ Ｆｒａｍｅ Ｓｐａｃｅ）が続く。このフレーム間スペース（ＩＦＳ）は、ＩＳＯ１１８９８－１：２０１５に対応したＣＡＮＦＤの場合と同様に構成される。

【0067】

図３は、通信制御デバイス１１、送信／受信デバイス１２、および通信制御デバイス１１の一部であるチェックサムユニット１５を備えた加入局１０の基本構造を示す。加入局３０は、図３に示されるのと同様に構成されるが、図１によるチェックサムユニット３５は、通信制御デバイス３１および送信／受信デバイス３２から独立して配置されている。したがって、加入局３０について個別には述べない。

【0068】

図３によれば、加入局１０は、通信制御デバイス１１および送信／受信デバイス１２に加えて、通信制御デバイス１１が割り当てられるマイクロコントローラ１３と、システムＡＳＩＣ１６（ＡＳＩＣ＝特定用途向け集積回路）とを有する。システムＡＳＩＣ１６は、代替として、加入局１０の電子回路アセンブリに必要な複数の機能が組み合わされたシステムベースチップ（ＳＢＣ）でよい。システムＡＳＩＣ１６には、送信／受信デバイス１２に加えて、送信／受信デバイス１２に電気エネルギーを供給するエネルギー供給デバイス１７が設置される。通常、エネルギー供給デバイス１７は、５Ｖの電圧ＣＡＮ＿Ｓｕｐｐｌｙを送達する。しかし、要件に応じて、エネルギー供給デバイス１７は、異なる値を有する異なる電圧を送達することができる。追加または代替として、エネルギー供給デバイス１７は、電源として構成することができる。

【0069】

チェックサムユニット１５は、ヘッダチェックサムブロック１５１およびフレームチェックサムブロック１５２を有し、これらのブロックについて以下でより詳細に述べる。ヘッダチェックサムブロック１５１には、開始値１５１１が少なくとも一時的に記憶される。

【0070】

送信／受信デバイス１２は、送信機１２１および受信機１２２をさらに有する。以下では常に送信／受信デバイス１２に言及するが、代替として、送信機１２１の外部の別個のデバイスに受信機１２２を提供することが可能である。送信機１２１および受信機１２２は、従来の送信／受信デバイス２２と同様に構成することができる。送信機１２１は、特に、少なくとも１つの演算増幅器および／または少なくとも１つのトランジスタを有することができる。受信機１２２は、特に、少なくとも１つの演算増幅器および／または少なくとも１つのトランジスタを有することができる。

【0071】

送信／受信デバイス１２は、バス４０、より正確に言うとＣＡＮ＿ＨまたはＣＡＮ－ＦＸ＿Ｈ用のバス４０の第１のバスワイヤ４１、およびＣＡＮ＿ＬまたはＣＡＮ－ＦＸ＿Ｌ用のバス４０の第２のバスワイヤ４２に接続される。少なくとも１つの接続端子４３を介して第１および第２のバスワイヤ４１、４２に電気エネルギー、特に電圧ＣＡＮ－Ｓｕｐｐｌｙを供給するためのエネルギー供給デバイス１７のための電圧供給が行われる。接地またはＣＡＮ＿ＧＮＤとの接続は、接続端子４４を介して実現される。第１および第２のバスワイヤ４１、４２は、終端抵抗４９で終端されている。

【0072】

第１および第２のバスワイヤ４１、４２は、送信／受信デバイス１２において、送信機１２１（トランスミッタとも呼ぶ）だけでなく、受信機１２２（レシーバとも呼ぶ）にも接続されている。見やすくするために図３にはこの接続を示していない。

【0073】

バスシステム１の動作時、送信機１２１は、通信制御デバイス１１の送信信号ＴＸＤまたはＴｘＤを、バスワイヤ４１、４２に関する対応する信号ＣＡＮ－ＦＸ＿ＨおよびＣＡＮ－ＦＸ＿Ｌに変換し、これらの信号ＣＡＮ－ＦＸ＿ＨおよびＣＡＮ－ＦＸ＿Ｌを、バス４０でＣＡＮ＿ＨおよびＣＡＮ＿Ｌ用の接続端子に送信する。

【0074】

受信機１２２は、図４によるバス４０から受信された信号ＣＡＮ－ＦＸ＿ＨおよびＣＡＮ－ＦＸ＿Ｌから、受信信号ＲＸＤまたはＲｘＤを生成し、図３に示されるように、これを通信制御デバイス１１に転送する。アイドルまたはスタンバイ状態（ｉｄｌｅまたはＳｔａｎｄｂｙ）を除いて、受信機１２２を備えた送信／受信デバイス１２は、通常動作では、送信／受信デバイス１２がメッセージ４５の送信元であるか否かに関係なく、バス４０でのデータまたはメッセージ４５、４６の伝送を常にリッスンする。

【0075】

図４の例によれば、信号ＣＡＮ－ＦＸ＿ＨおよびＣＡＮ－ＦＸ＿Ｌは、少なくとも調停フェーズ４５１において、ＣＡＮから知られているようにドミナントおよびレセシブバスレベル４０１、４０２を有する。バス４０に差分信号ＶＤＩＦＦ＝ＣＡＮ－ＦＸ＿Ｈ－ＣＡＮ－ＦＸ＿Ｌが生じ、これは図５に示されている。ビット時間ｔ＿ｂｔを有する信号ＶＤＩＦＦの個々のビットは、０．７Ｖの受信閾値で認識することができる。データフェーズ４５２では、信号ＣＡＮ－ＦＸ＿ＨおよびＣＡＮ－ＦＸ＿Ｌのビットは、調停フェーズ４５１よりも速く、すなわち短いビット時間ｔ＿ｂｔで送信される。したがって、信号ＣＡＮ－ＦＸ＿ＨおよびＣＡＮ－ＦＸ＿Ｌは、データフェーズ４５２で、少なくともそれらのビットレートが速いという点で、従来の信号ＣＡＮ＿ＨおよびＣＡＮ＿Ｌとは異なる。
図４での信号ＣＡＮ－ＦＸ＿Ｈ、ＣＡＮ－ＦＸ＿Ｌに関する状態４０１、４０２のシーケンス、およびそこから得られる図５の電圧ＶＤＩ ＦＦのプロファイルは、加入局１０の機能を説明する目的のものにすぎない。バス状態４０１、４０２に関するデータ状態のシーケンスは、必要に応じて選択可能である。

【0076】

言い換えると、図４による第１の動作モードでは、送信機１２１は、バス４０のバスラインの２つのバスワイヤ４１、４２に関して異なるバスレベルを有するバス状態４０２として第１のデータ状態を生成し、バス４０のバスラインの２つのバスワイヤ４１、４２に関して同じバスレベルを有するバス状態４０１として第２のデータ状態を生成する。

【0077】

さらに、送信機１２１は、データフェーズ４５２を含む第２の動作モードにおける信号ＣＡＮ－ＦＸ＿Ｈ、ＣＡＮ－ＦＸ＿Ｌの時間プロファイルのために、より高いビットレートでビットをバス４０に送信する。ＣＡＮ－ＦＸ＿ＨおよびＣＡＮ－ＦＸ＿Ｌ信号は、データフェーズ４５２でさらに、ＣＡＮＦＤの場合とは異なる物理層を用いて生成することもできる。それにより、データフェーズ４５２でのビットレートは、ＣＡＮＦＤの場合よりもさらに増加させることができる。

【0078】

図３のチェックサムユニット１５、特にそのヘッダチェックサムブロック１５１は、ヘッダチェックサムＨ＿ＣＲＣに関するフィールドにおいてチェックサムを計算および評価するために使用される。さらに、チェックサムユニット１５、特にそのフレームチェックサムブロック１５２は、フレームチェックサムＦ＿ＣＲＣに関するフィールドにおいてチェックサムを計算および評価するために使用される。

【0079】

前述したように、チェックサムは、フレーム４５０のヘッダ（Ｈｅａｄｅｒｓ）を保護するために形成され、すなわち、ＳＯＦビットでのフレーム４５０の開始からヘッダチェックサムＨ＿ＣＲＣの開始までのすべてのビット（ヘッダチェックサムＨ＿ＣＲＣの開始までのすべての動的スタッフビットおよび任意選択で固定スタッフビットを含む）である。

【0080】

この例示的実施形態では、通信制御デバイス１１、特にそのチェックサムユニット１５またはヘッダチェックサムブロック１５１は、ヘッダチェックサムＨ＿ＣＲＣを計算するときに、タイプＢと呼ばれるエラーを排除するための予防措置を講じる。そのようなエラーは、フレーム４５０のＦＸＦビットまで生じ得る動的スタッフビットにより生じる可能性がある。このエラーは、チェックサムＣＲＣの現在の中間結果が値０を有する間、グリッチによって引き起こされたエラー同期によりスタッフビットが誤って挿入または削除されたときに発生する。

【0081】

したがって、通信制御デバイス１１、特にそのチェックサムユニット１５またはヘッダチェックサムブロック１５１は、ビットシーケンスが既知のスタッフエラーなくＦＸＦビットまで処理される間は、ＣＲＣジェネレータレジスタのビットがすべて「０」になることがないように、ヘッダチェックサムＨ＿ＣＲＣを計算するための開始値を選択する。したがって、ＦＸＦビットが処理されるまで、ヘッダチェックサムＨ＿ＣＲＣの計算の一時的な値は、０・・・０になり得ない。すなわち、ヘッダチェックサムＨ＿ＣＲＣにおいてＦＤＦビットまでは値０・・・０が生じ得ないように、開始値は、０・・・０ではない特別な値に設定され得る。

【0082】

ヘッダチェックサムＨ＿ＣＲＣを計算するための開始値を決定するとき、通信制御デバイス１１、特にそのチェックサムユニット１５またはヘッダチェックサムブロック１５１は、ＣＡＮＦＸ加入局１０、３０がＦＸＦビットまでは任意の各ビットシーケンスを送信することができないことを考慮に入れる。したがって、通信制御デバイス１１、特にそのチェックサムユニット１５またはヘッダチェックサムブロック１５１は、以下の境界条件の下で開始値を決定する。すなわち、次のとおりである。
－ 動的スタッフビットによって６個以上のドミナントまたは６個以上のレセシブビットを連続してもはや送信することができないこと、および
－ フレーム４５０の特定のビットが、前述したように固定値を有し、したがって可変ではないこと。

【0083】

したがって、所定の開始値は、通信制御デバイス１１によって、特にチェックサムユニット１５またはヘッダチェックサムブロック１５１内のソフトウェアによって動的に構成することができる。

【0084】

代替として、通信制御デバイス１１または他の装置のいずれかによって開始値が一度決定された後、所定の開始値を通信制御デバイス１１に恒久的に記憶することができる。代替として、所定の開始値は、開始値が０・・・０に等しくないという条件で、オペレータが選択することができる。

【0085】

これにより、加入局１０で、タイプＢエラーがもはや生じることはあり得ない。

【0086】

開始値を計算するための上述した手順の大きな利点は、フレーム４５０に追加のビットが導入されないことである。これにより、フレーム４５０のデータオーバーヘッドおよびフレーム４５０の評価の複雑さが低減される。

【0087】

さらに、適切なＨ＿ＣＲＣ開始値を見つけることができるように、ヘッダチェックサムＨ＿ＣＲＣの長さ、したがってＣＲＣ多項式の次数を増やす必要があり得る。したがって、ヘッダチェックサムＨ＿ＣＲＣは、エラーにより意図せずにビット状態が変化する特定数の通常のビットフリップの認識に必要な長さよりも長くなる。

【0088】

さらに、通信制御デバイス１１、特にそのチェックサムユニット１５またはヘッダチェックサムブロック１５１は、ヘッダチェックサムＨ＿ＣＲＣに関して、１１ビットの識別子（ＩＤ）を使用するフレーム４５０において、２９ビットの識別子（ＩＤ）を使用するフレーム４５０とは異なる多項式を使用することができる。これは、ヘッダチェックサムＨ＿ＣＲＣによるデータオーバーヘッド（Ｏｖｅｒｈｅａｄ）が、１１ビットの識別子（ＩＤ）を使用するフレーム４５０において、２９ビットの識別子（ＩＤ）を使用するフレーム４５０よりも小さいという利点を有する。

【0089】

さらに、チェックサムユニット１５、特にそのフレームチェックサムブロック１５２は、前述したように、フレームチェックサムＦ＿ＣＲＣを形成する。ここで、チェックサムユニット１５は、言及するオプションの１つを使用することができる。ここで、フレームチェックサムＦ＿ＣＲＣは、それぞれ以下のオプション１および２に従って、フレームチェックサムＦ＿ＣＲＣまでフレーム４５０全体を保護する。

【0090】

オプション１：フレームチェックサムＦ＿ＣＲＣは、フレーム４５０全体にわたって計算される。したがって、フレームチェックサムＦ＿ＣＲＣの計算に、ＳＯＦビット（これを含む）からフレームチェックサムＦ＿ＣＲＣの開始までのすべてのビットが算入される。さらに、動的スタッフビット、および任意選択で固定スタッフビットも計算に算入される。ヘッダチェックサムＨ＿ＣＲＣが、すでにフレーム４５０のヘッダ（Ｈｅａｄｅｒ）をタイプＢエラーから保護しているので、フレームチェックサムＦ＿ＣＲＣを再度行う必要はない。

【0091】

オプション２：フレームチェックサムＦ＿ＣＲＣは、ヘッダチェックサムＨ＿ＣＲＣおよびデータフィールド４５５にわたって計算される。したがって、ヘッダチェックサムＨ＿ＣＲＣの最初のビット（これを含む）からのすべてのビットが、フレームチェックサムＦ＿ＣＲＣの計算に算入される。任意選択で、固定スタッフビットも計算に入れられる。ヘッダチェックサムＨ＿ＣＲＣがすでにフレーム４５０のヘッダ（Ｈｅａｄｅｒ）を保護しているので、フレーム４５０全体を保護するために、ヘッダチェックサムＨ＿ＣＲＣをＦ＿ＣＲＣ計算に含めれば十分である。

【0092】

オプション３：フレームチェックサムＦ＿ＣＲＣは、データフィールド４５５のみを保護する。したがって、ヘッダチェックサムＨ＿ＣＲＣ後の最初のビットからフレームチェックサムＦ＿ＣＲＣの開始までのすべてのビットが、フレームチェックサムＦ＿ＣＲＣの計算に算入される。任意選択で、固定スタッフビットも計算に入れられる。したがって、フレームチェックサムＦ＿ＣＲＣは、データフィールド４５５のみを保護する。ヘッダチェックサムＨ＿ＣＲＣがすでにフレーム４５０のヘッダ（Ｈｅａｄｅｒ）を保護しているので、これで十分である。フレームチェックサムＦ＿ＣＲＣとヘッダチェックサムＨ＿ＣＲＣとが、フレーム４５０全体を一緒に保護する。

【0093】

図６は、ＣＡＮ ＦＸとＣＡＮＦＤとに互換性がある、第２の例示的実施形態によるフレーム４５０＿１を示す。この例示的実施形態では、フレーム４５０＿１、したがってＣＡＮＦＸフレームフォーマットは、以下で述べるように、図２のフレーム４５０とは異なる。ここでは、図６のフレーム４５０との相違点のみを述べる。なお、２つの例示的実施形態のフレーム４５０、４５０＿１は同じである。

【0094】

フレーム４５０＿１では、ヘッダチェックサムＨ＿ＣＲＣの前にＳ＿Ｃフィールドが挿入される。Ｓ＿Ｃフィールドでは、送信される動的スタッフビットの数（スタッフカウント）が伝送される。Ｓ＿Ｃフィールドは、１～ｎビットを有することができる。この場合、すなわちフレーム４５０＿１に関して、最大３つの動的スタッフビットがあり、すなわち、ｎは２として選択することができる。代替として、伝送され得るビットの数を減らすために、「Ｘを法とする動的スタッフビットの数」の伝送も可能である。Ｘは、例えば２でよい。

【0095】

しかし、この変形形態により、フレーム４５０＿１のデータオーバーヘッドは、図２のフレーム４５０と比較して大きい。

【0096】

フレーム４５０＿１の変形では、Ｓ＿Ｃフィールドに、送信される動的スタッフビットの数（スタッフカウント）の代わりにスタッフコンペンセータが挿入される。スタッフコンペンセータは、０～ｍビットを有し、ここで、ｍは、ＦＤＦビットまでに存在し得る動的スタッフビットの最大数に対応する。ここで、動的スタッフビットとスタッフコンペンセータビットとの合計は、常にｍに等しい。

【0097】

スタッフコンペンセータは、フレーム４５０＿１のフレームヘッドの長さが一定であることを保証する。例えば、識別子（ＩＤ）に関して１１ビットの場合、最大３つの動的スタッフビットが生じることがある。したがって、１１ビットの識別子（ＩＤ）の場合、ｍ＝３である。１つの動的スタッフビットを有するフレーム４５０＿１では、スタッフコンペンセータは２ビットの長さである（３－１＝２ビット）。それにより、データフィールド４５５は、常に、フレームの開始から固定数のビットの後に始まる。

【0098】

図７は、ＣＡＮ ＦＸとＣＡＮＦＤとに互換性がない、第３の例示的実施形態によるフレーム４５００を示す。この例示的実施形態では、フレーム４５００、したがってＣＡＮＦＸフレームフォーマットは、以下で述べるように、図２のフレーム４５０とは異なる。ここでは、図２のフレーム４５０との相違点のみを述べる。なお、２つの例示的実施形態のフレーム４５０、４５００は同じである。

【0099】

一般に、この例示的実施形態によるフレーム４５００の生成時、固定スタッフィング規則のみが使用され、したがって、固定数のビットの後に固定スタッフビットが挿入され得る。代替として、ただ１つのスタッフビットの代わりに、２つ以上のビットを固定スタッフビットとして挿入することもできる。データ長コード（ＤＬＣ）の値がわかっている場合、これは一定のフレーム長またはフレーム４５００の一定の長さをもたらす。これにより、動的スタッフビットによって引き起こされる様々な問題が防止される。

【0100】

この例示的実施形態によるフレーム４５００では、識別子（ＩＤ）は、ＣＡＮＦＤの場合のように１１ビットまたは２９ビットにもはや制限されない。識別子（ＩＤ）のビットの数ｋは自由に選択することができる。しかし、代替として、数ｋは、固定値に固定することもできる。正味データレートが高い場合、ｋ＝８ビットのＩＤが好適である。これは、バスシステム１の各加入局１０、２０、３０に十分に多くのバスアクセス優先順位を与えるのに十分である。しかし、当然、バスシステム１での要件および様々な優先順位の数に応じて、ｋに関して別の値を選択可能である。

【0101】

図２のフレーム４５０のビットＲＲＳ、ＩＤＥ、ＦＤＦ、ＦＸＦは、フレーム４５００では不要になり、省略される。これにより４ビットが節約され、したがってフレームオーバーヘッドが低減される。これにより、バスシステム１での正味データレートが増加される。

【0102】

終了フィールド（ＥＯＦ）は、ＮＡＣＫビットがドミナントであるとき、フレーム４５００でさらに５ビットだけを有する。一方、ＮＡＣＫビットがレセシブであるとき、終了フィールド（ＥＯＦ）は３ビットを有する。終了フィールド（ＥＯＦ）は、フレーム４５０の終了時に６つのレセシブビットが送信されることを保証する。この数のレセシブビットは、調停フェーズ４５１において５つの同一ビットの後に固定スタッフビットが挿入されるとき、有効なフレーム４５００では他のどこにも生じ得ない。代替として、７ビット以上でもよい。特に、ＥＯＦビットの数は、固定スタッフビットが挿入される前のビットの数に適合させる必要がある。

【0103】

フレーム間スペース（ＩＦＳ）は、フレーム４５００で最小長さを必要としない。特に、フレーム間スペース（ＩＦＳ）は長さ０を有することができる。そのような場合、２つのフレーム４５００が、順次にシームレスに送信される。しかし、例えば１ビットを有するフレーム間スペース（ＩＦＳ）は、前述した場合と比較してバスシステム１のロバスト性を高めるためにも好適である。２つのフレーム４５００間のここでは７つのレセシブビットによって、新たな加入局は、バス４０でより確実に同期することができる。

【0104】

したがって、フレーム４５００には動的スタッフビットは生じない。その結果、上述したエラータイプＢに対する保護を提供する必要はない。したがって、エラータイプＢの認識に使用される図６からのフィールドＳ＿Ｃは不要であり、したがってフレームオーバーヘッドがさらに低減される。任意選択で、ヘッダチェックサムＨ＿ＣＲＣを省略することもでき、それによりフレームオーバーヘッドがさらに低減される。これにより、バスシステム１での正味データレートがさらに増加する。

【0105】

したがって、フレーム４５００では、フレームチェックサムＦ＿ＣＲＣは、ＣＡＮＦＤ互換性が存在する第１の例示的実施形態を参照して述べたように、オプション１～３の１つに従って計算することができる。

【0106】

加入局１０、２０、３０、バスシステム１、およびそこで実施される方法の前述したすべての構成は、個別に、またはすべての可能な組合せで使用することができる。特に、上述した例示的実施形態のすべての特徴および／またはそれらの変形形態は、任意に組み合わせることができる。追加としてまたは代替として、特に以下の変形形態が考えられる。

【0107】

ＣＡＮバスシステムの例で本発明を前述してきたが、本発明は、異なる通信フェーズのために生成されるバス状態が異なる、２つの異なる通信フェーズが使用される各通信ネットワークおよび／または通信方法で使用することができる。特に、本発明は、イーサネットおよび／または１００Ｂａｓｅ－Ｔ１イーサネット、フィールドバスシステムなどの他のシリアル通信ネットワークの開発に使用可能である。

【0108】

特に、例示的実施形態によるバスシステム１は、データを２つの異なるビットレートでシリアル伝送可能である通信ネットワークでよい。バスシステム１において、共通のチャネルへの加入局１０、２０、３０の排他的で衝突のないアクセスが少なくとも特定の期間にわたって保証されていることは、有利であるが、必須の前提条件ではない。

【0109】

例示的実施形態のバスシステム１における加入局１０、２０、３０の数および配置は任意である。特に、バスシステム１での加入局２０は省略することができる。加入局１０または３０のうちの１つまたは複数がバスシステム１に存在することが可能である。バスシステム１内のすべての加入局が同一に構成される、すなわち加入局１０のみまたは加入局３０のみが存在することも考えられる。

【0110】

上述した発明は、以下のように、かつ図８に示されるように、異なる識別子の導入に関してさらに発展させることができる。

【0111】

「メッセージ」と「フレーム」という概念は、本明細書では同義として使用される。

【0112】

図８に、図２からのフレームフォーマットに基づく異なる識別子によるさらなる発展形態を表す。それに対応して、異なる識別子によるさらなる発展形態は、図６または図７に示されるフレームフォーマットにも完全に同様に適用することができる。

【0113】

ＣＡＮ ＦＸフレームには以下の複数の識別子が導入される。

【0114】

優先順位ＩＤ：
優先順位ＩＤは、メッセージまたはフレーム４５０、４５０＿１、または４５００の調停フィールド４５３におけるすでに上述した識別子ＩＤの代わりとなる、またはそのような識別子ＩＤに対応する。優先順位ＩＤは、調停の過程で、バスアクセスの優先順位に関して優先的に使用される。

【0115】

ＭＳＧ ＩＤ：
データフィールド４５５で伝送することができるメッセージ識別情報ＭＳＧＩＤは、メッセージまたはフレームの内容を識別する。メッセージ識別情報ＭＳＧ ＩＤは任意選択である。

【0116】

ＴＸ ＩＤ：
データフィールド４５５で伝送することができる送信元識別情報ＴＸ ＩＤは、メッセージまたはフレームの送信元を識別する。送信元識別情報ＴＸ ＩＤは任意選択である。

【0117】

ＶＬＡＮ ＩＤ：
データフィールド４５５で伝送することができる仮想ネットワーク識別情報ＶＬＡＮＩＤは、メッセージまたはフレームに関する転送情報を含む。仮想ネットワーク識別情報ＶＬＡＮＩＤは任意選択である。

【0118】

利点：
提示したいくつかの識別情報の導入は、ＣＡＮ ＦＤでの従来の識別子に比べて以下の利点を有する。

【0119】

列挙した各識別情報はそれぞれ、必要な特徴または機能を最適に満たすために最適な長さを有する。同時に、高い正味データレートが達成され、これは、一方では、調停に必須のビットのみが低速の調停フェーズで伝送されるからであり、他方では、任意選択の識別情報タイプ（ＭＳＧＩＤ、ＴＸ ＩＤ、ＶＬＡＮ ＩＤ）のうち、それぞれの用途に必要とされるものだけを使用することができるからである。

【0120】

データフィールド内の任意選択の識別情報ＭＳＧ ＩＤ、ＴＸ ＩＤ、およびＶＲＮＡ ＩＤの順序は、上述して図８に示した順序とは異なるように選択することもできる。

【0121】

図８でのフレームにおける、本発明のこの態様に関連する部分の説明は以下のとおりである。

【0122】

－ 優先順位ＩＤ
・このＩＤは、ＣＡＮ ＦＤでのフレームＩＤに対応する。
・これは、主にバスアクセス優先順位を示すので、ＣＡＮ ＦＸ優先順位ＩＤと呼ばれる。優先順位が高いほど、フレームは、バスでの調停に勝ちやすい。
・図８に示される例では、ＣＡＮ ＦＸフレームは、ＣＡＮ ＦＤフレームと互換性がある。これにより、優先順位ＩＤの長さが１１ビットまたは２９ビットに制限される。ＣＡＮＦＤと互換性のないＣＡＮ ＦＸフレームでは、優先順位ＩＤは、任意の長さ、例えば５ビットを有することができ、特に低いオーバーヘッドを生成する。これはすでに、図２および図７からの例示的実施形態に関連して説明した。

【0123】

－ ＤＬＣ：データ長コード
・これは、データフィールド（図２、図６、および図７のデータフィールド４５５に対応する）内のバイトの数を示すデータ長コードＤＬＣである。
・ここで、ＤＬＣを使用するための以下の２つの代替形態がある。

【0124】

Ａ）データフィールド（Ｄａｔａ Ｆｉｅｌｄ）での任意選択の識別情報ＭＳＧＩＤ、ＴＸ ＩＤ、およびＶＬＡＮ ＩＤは、データフィールドの一部でよく、すなわちＤＬＣは、データフィールドでの任意選択の識別情報ＭＳＧ ＩＤ、ＴＸ ＩＤ、およびＶＬＡＮ ＩＤを含むデータフィールドの長さを示すものである。言い換えると、これは、データフィールドの最初のバイトがＩＤを含むことを意味する。この場合が図８に示されている。しかし、必ずしも最初のバイトである必要はない。この場合、アプリケーションは、データフィールド（Ｄａｔａ Ｆｉｅｌｄ）で使用可能な識別情報（ＩＤ）とその長さを認識していなければならない。

【0125】

Ｂ）任意選択の識別情報ＭＳＧ ＩＤ、ＴＸ ＩＤ、およびＶＬＡＮ ＩＤは、データフィールドの一部ではなく、ＤＬＣは、任意選択の識別情報ＭＳＧ ＩＤ、ＴＸＩＤ、およびＶＬＡＮ ＩＤなしのユーザデータの長さを示すものである。任意選択の識別情報ＭＳＧＩＤ、ＴＸ ＩＤ、およびＶＬＡＮ ＩＤのうちのいずれかがフレーム内に存在するか、およびそれらがどの長さを有しているかは、通信制御デバイスの構成によって示すことができる。

【0126】

－ 追加の識別子（データフィールドの一部として、または個別に）
・ＭＳＧ ＩＤ
・メッセージＩＤは、メッセージまたはフレームの内容を識別する。このＩＤにより、受信ノードは、このフレームにどの情報があるかを認識することができる。例えば、ＭＳＧＩＤ＝０ｘ１０は、車速を表す。
・このＩＤは任意選択であり、すなわち長さ０を有することもできる。
・ＩＤの長さは、理想的には、通信制御デバイスでビット毎に設定可能である。例えば、長さに関して取り得る値は、１６ビット続く。

【0127】

・ＴＸ ＩＤ
・ＴＸ ＩＤは、メッセージまたはフレームの送信元を識別する。すなわち、各送信ノードは、１つ（または複数）の排他的に割り当てられたＩＤを使用し、送信時にこれをフレームに挿入する。
・このＩＤは任意選択であり、すなわち長さ０を有することもできる。
・ＩＤの長さは、理想的には、通信制御デバイスでビット毎に設定可能である。例えば、長さに関して取り得る値は、８ビット続く。

【0128】

・ＶＬＡＮ ＩＤ
・ＶＬＡＮ ＩＤは、このメッセージまたはこのフレームが見えているべきであるサブネットワーク、またはこのメッセージまたはこのフレームが転送されるべきであるサブネットワークを識別する。例えば、ゲートウェイは、このＶＬＡＮＩＤを評価し、そこから、このメッセージまたはこのフレームの転送先となる他のネットワークを導出することができる。
・このＩＤは任意選択であり、すなわち長さ０を有することもできる。
・ＩＤの長さは、理想的には、通信制御デバイスでビット毎に設定可能である。例えば、長さに関して取り得る値は、４ビット続く。

【0129】

様々な識別子の適用は以下のとおりである。

【0130】

－ 優先順位ＩＤ
・各バス加入者（以下、ノードとも呼ぶ）には、少なくとも１つの専用優先順位ＩＤが排他的に割り当てられる。
・理想的には、各ノードには最大Ｋ個の優先順位ＩＤが排他的に割り当てられる。最大Ｋ個の優先順位ＩＤは、最大Ｋ個の異なる優先順位（優先順位クラス）を定義することを可能にする。ノードが送信する各メッセージ／各フレームは、メッセージ／フレームの優先順位に対応する優先順位ＩＤを取得する。
・４ノード、およびノード当たり最大Ｋ＝３個の優先順位ＩＤを有するバスシステムに関する例は次のとおりである。

【0131】

【表1】

【0132】

・任意選択で、各ノードは、優先順位クラスで複数の優先順位ＩＤを取得する。すなわち、例えば、ノード１は、「中優先順位」に関して優先順位ＩＤ２０、２４、２８を取得し、ノード２は、優先順位ＩＤ２１、２５、２９を取得する。ここで、優先順位クラスでの各ノードが、特定の規則に従って、またはランダムに、例えばラウンドロビン法に従ってＩＤを選択するとき、例えばノード１が、中優先順位クラスでのノード２に常に勝つとは限らず、すなわちノード１は、常に高い優先順位を有するとは限らない。これにより、優先順位クラス内で公平性が実現される。

【0133】

・任意選択で、メッセージまたはフレームがすでに調停に何度も負けているとき、特定の規則に従って、このメッセージまたはこのフレームに関する優先順位ＩＤを、より優先順位の高い優先順位ＩＤと交換することもでき、それによりメッセージが調停に勝つ可能性が高くなる。すなわち、言い換えると、優先順位ＩＤをメッセージに動的に割り当てることができる。

【0134】

－ ＭＳＧ ＩＤ
・バスシステムを介して伝送すべき各情報には、１つまたは複数のＭＳＧＩＤが割り当てられる。
・ＭＳＧ ＩＤは、ノード毎に排他的である必要はない。しかし、特定のＭＳＧＩＤを異なる情報に使用してはならない。
・ＭＳＧ ＩＤが１つのノードに関して排他的に与えられている場合、ＭＳＧＩＤが暗黙的に送信元も識別するため、原則として、アプリケーションはＴＸ ＩＤの伝送を省くことができる。

【0135】

－ ＴＸ ＩＤ
・各ノードは、そのノードに対して一意の少なくとも１つのＴＸ ＩＤを割り当てられる。２つの異なるノードが同じＴＸ ＩＤを得てはならない。
・ノードに割り当てられたＴＸ ＩＤが、メッセージに挿入される。

【0136】

－ ＶＬＡＮ ＩＤ
・送信ノードは、ＶＬＡＮ ＩＤによって、接続されている他のどのネットワークにそれぞれのメッセージが転送されるべきかを決定する。さらに、例えば、特定のＶＬＡＮＩＤ、例えば値０のＶＬＡＮ ＩＤは、ブロードキャスト、すなわち接続されているすべてのネットワークへの転送を意味することもある。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【国際調査報告】