特許 7462044 シリアルバスシステム用の加入局およびシリアルバスシステムでの通信方法

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-03-27

(45)【発行日】2024-04-04

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

(51)【国際特許分類】

   H04L 1/00 20060101AFI20240328BHJP

【ＦＩ】

H04L1/00 A

H04L1/00 B

【請求項の数】 8

(21)【出願番号】P 2022532780

(86)(22)【出願日】2020-12-01

(65)【公表番号】

(43)【公表日】2023-01-27

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

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

(87)【国際公開日】2021-06-10

【審査請求日】2022-07-28

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

(32)【優先日】2019-12-02

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

(73)【特許権者】

【識別番号】591245473

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

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

(74)【代理人】

【識別番号】100118902

【弁理士】

【氏名又は名称】山本 修

(74)【代理人】

【識別番号】100196508

【弁理士】

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

(74)【代理人】

【識別番号】100147991

【弁理士】

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

(74)【代理人】

【識別番号】100201743

【弁理士】

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

(72)【発明者】

【氏名】ゼンガー，クリスティアン

(72)【発明者】

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

(72)【発明者】

【氏名】ホルスト，クリスティアン

(72)【発明者】

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

【審査官】谷岡 佳彦

(56)【参考文献】

【文献】特表２０１７－５３２８５２（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１７／０２８９３２１（ＵＳ，Ａ１）

【文献】特開２０１１－０８３００６（ＪＰ，Ａ）

【文献】VECTOR GERMANY，CAN - Still Room for Improvement[online]，2019年11月，p.7,9,11-17,19-22，［令和５年７月１２日検索］、インターネット＜URL:https://cdn.vector.com/cms/content/events/2019/VTT19/presentations/VTT19_24102019_CAN_XL_Room_for_Improvement.pdf＞

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ １／００

(57)【特許請求の範囲】

【請求項1】

シリアルバスシステム（１）用の加入局（１０；３０）であって、
前記バスシステム（１）の前記加入局（１０；３０）と少なくとも１つの他の加入局（１０；２０；３０）との通信を制御するための通信制御デバイス（１１；３１）と、
前記通信制御デバイス（１１；３１）によって生成された送信信号（ＴＸＤ）を前記バスシステム（１）のバス（４０）にシリアル送信するように構成されており、かつ前記バスシステム（１）の前記バス（４０）からの信号をシリアル受信するように構成されている送信／受信デバイス（１２；３２）と、
を備え、
前記通信制御デバイス（１１；３１）は、フレーム（４５０）に従って前記送信信号（ＴＸＤ）を生成し、前記フレーム（４５０）にヘッダチェックサム（ＨＣＲＣ）を挿入するように構成されており、前記ヘッダチェックサム（ＨＣＲＣ）には、前記フレーム（４５０）での使用データ用に提供されているデータフィールド（４５５）の前に配置されているフレームヘッダのビットのみが含まれており、
前記通信制御デバイス（１１；３１）は、前記フレームヘッダに動的スタッフビットを挿入するように構成されており、５つの同一ビットの後に続いて、前記フレーム（４５０）のビットストリームに反転スタッフビットが挿入され、
前記通信制御デバイス（１１；３１）は、前記ヘッダチェックサム（ＨＣＲＣ）の計算のために所定の開始値（Ｒ＿Ｓ）および所定のチェックサム多項式（ＣＲＣ＿Ｐ）を使用するように構成されており、前記所定の開始値（Ｒ＿Ｓ）および前記所定のチェックサム多項式（ＣＲＣ＿Ｐ）により、動的スタッフビットが使用される前記フレームヘッダの部分に関する前記ヘッダチェックサム（ＨＣＲＣ）の前記計算の中間結果がヌルベクトルにならない、加入局（１０；３０）において、
前記所定のチェックサム多項式（ＣＲＣ＿Ｐ）が、ｘ ^１３ ＋ｘ ^１２ ＋ｘ ^１１ ＋ｘ ^８ ＋ｘ ^７ ＋ｘ ^６ ＋ｘ ^５ ＋ｘ ^２ ＋ｘ ^１ ＋１であり、
前記所定の開始値（Ｒ＿Ｓ）が、（１，０，０，０，０，０，０，０，０，０，０，０，０）、または、（０，０，１，１，０，０，０，０，０，０，０，０，０）である、
加入局（１０；３０）。

【請求項2】

前記通信制御デバイス（１１；３１）は、前記ヘッダチェックサム（ＨＣＲＣ）の前記計算のために、電気回路（１５２１）の少なくとも１つのスイッチング素子（Ｆ０～Ｆ１２）を使用するように構成されており、前記スイッチング素子（Ｆ０～Ｆ１２）が、前記所定の開始値（Ｒ＿Ｓ）に設定可能であり、前記少なくとも１つのスイッチング素子（Ｆ０～Ｆ１２）が、所定のチェックサム多項式（ＣＲＣ＿Ｐ）を実装する、請求項１に記載の加入局（１０；３０）。

【請求項3】

前記通信制御デバイス（１１；３１）は、前記フレームヘッダの第１の部分にのみ動的スタッフビットを挿入するように構成されている、請求項１または２に記載の加入局（１０；３０）。

【請求項4】

前記通信制御デバイス（１１；３１）は、前記動的スタッフビットの数が符号化されている少なくとも１つのフィールド（ＳＢＣ）を前記フレーム（４５０）に挿入するように構成されており、
前記通信制御デバイス（１１；３１）は、前記フレーム（４５０）の使用データが挿入される前記データフィールド（４５５）の前に前記少なくとも１つのフィールド（ＳＢＣ）を挿入するように構成されている、
請求項１～３のいずれか一項に記載の加入局（１０；３０）。

【請求項5】

前記送信／受信デバイス（１２；３２）は、前記バスシステム（１）の加入局（１０、２０、３０）間で交換されるメッセージ（４５）に関して、第１の通信フェーズ（４５１）で前記バス（４０）に送信される信号のビット時間（ｔ＿ｂｔ）と、第２の通信フェーズ（４５２）で送信される信号のビット時間（ｔ＿ｂｔ）とを区別することができるように、前記通信制御デバイス（１１；３１）によって生成された送信信号（ＴＸＤ）を前記バスシステム（１）のバス（４０）でシリアル送信するように構成されている、請求項１～４のいずれか一項に記載の加入局（１０；３０）。

【請求項6】

前記メッセージ（４５）用に生成された前記フレーム（４５０）が、ＣＡＮ－ＦＤと互換性があるように構成されており、
第１の通信フェーズ（４５１）において、前記バスシステム（１）のどの加入局（１０、２０、３０）が、後続の第２の通信フェーズ（４５２）で前記バス（４０）への少なくとも一時的に排他的で衝突のないアクセスを得るかが交渉される、請求項５に記載の加入局（１０；３０）。

【請求項7】

バスシステム（１）であって、
バス（４０）と、
少なくとも２つの加入局（１０；２０；３０）と、
を備え、
前記加入局（１０；２０；３０）が、互いにシリアル通信することができるように前記バス（４０）を介して互いに接続されており、前記加入局のうちの少なくとも１つの加入局（１０；３０）が、請求項１～６のいずれか一項に記載の加入局（１０；３０）である、バスシステム（１）。

【請求項8】

通信制御デバイス（１１；３１）および送信／受信デバイス（１２；３２）を有する前記バスシステム（１）の加入局（１０；３０）によって実施される、シリアルバスシステム（１）での通信方法であって、
前記通信制御デバイス（１１；３１）によって、前記バスシステム（１）の前記加入局（１０；３０）と少なくとも１つの他の加入局（１０；２０；３０）との通信を制御するステップと、
前記送信／受信デバイス（１２；３２）によって、前記通信制御デバイス（１１；３１）によって生成された送信信号（ＴＸＤ）を前記バスシステム（１）のバス（４０）に送信するステップであって、前記送信／受信デバイス（１２；３２）がさらに、前記バスシステム（１）の前記バス（４０）からの信号をシリアル受信するように構成されている、ステップと、
前記通信制御デバイス（１１；３１）によって、フレーム（４５０）に従った前記送信信号（ＴＸＤ）を生成するステップと、
を備え、
前記通信制御デバイス（１１；３１）が、前記フレーム（４５０）にヘッダチェックサム（ＨＣＲＣ）を挿入し、前記ヘッダチェックサム（ＨＣＲＣ）には、前記フレーム（４５０）での使用データ用に提供されているデータフィールド（４５５）の前に配置されているフレームヘッダのビットのみが含まれており、
前記通信制御デバイス（１１；３１）が、前記フレームヘッダに動的スタッフビットを挿入し、５つの同一ビットの後に続いて、前記フレーム（４５０）のビットストリームに反転スタッフビットが挿入され、
前記通信制御デバイス（１１；３１）が、前記ヘッダチェックサム（ＨＣＲＣ）の計算のために所定の開始値（Ｒ＿Ｓ）および所定のチェックサム多項式（ＣＲＣ＿Ｐ）を使用し、前記所定の開始値（Ｒ＿Ｓ）および前記所定のチェックサム多項式（ＣＲＣ＿Ｐ）により、動的スタッフビットが使用される前記フレームヘッダの部分に関する前記ヘッダチェックサム（ＨＣＲＣ）の前記計算の中間結果がヌルベクトルにならない、方法において、
前記所定のチェックサム多項式（ＣＲＣ＿Ｐ）が、ｘ ^１３ ＋ｘ ^１２ ＋ｘ ^１１ ＋ｘ ^８ ＋ｘ ^７ ＋ｘ ^６ ＋ｘ ^５ ＋ｘ ^２ ＋ｘ ^１ ＋１であり、
前記所定の開始値（Ｒ＿Ｓ）が、（１，０，０，０，０，０，０，０，０，０，０，０，０）、または、（０，０，１，１，０，０，０，０，０，０，０，０，０）である、
方法。

【発明の詳細な説明】

【技術分野】

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

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

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

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

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

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

【図6】第２の例示的実施形態による、ヘッドチェックサムを計算するための電気回路の回路図である。

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

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

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

図６の回路１５２１は、ゲートＵ１、Ｕ２と、ＸＯＲゲートＸ^０～Ｘ^１２と、出力Ｑおよび反転出力

【数1】

を有するフリップフロップＦ０～Ｆ１２とを備える論理回路として構成される。ゲートＵ２との接続の表現を簡略化するために、図６のフリップフロップＦ０～Ｆ６は、図６のフリップフロップＦ７～Ｆ１２に対してミラー（鏡映）出力を有しているが、図６のフリップフロップＦ０～Ｆ１２はすべて同じように構成される。図６の上部にあるフリップフロップＦは、図６のフリップフロップＦ０～Ｆ６における入力Ｄおよびクロック入力の接続、ならびに次の出力を表すものである。

【数2】

【0124】

図６の下部にあるフリップフロップＦは、図６のフリップフロップＦ７～Ｆ１２における入力Ｄおよびクロック入力の接続、ならびにの次の出力を表すものである。

【数3】

【0125】

回路１５２１において、最初に信号ＣＲＣ＿ＩＮＩＴで、個々のフリップフロップＦ０～Ｆ１２は、フリップフロップＦ０～Ｆ１２からなるシフトレジスタが開始値Ｒ＿Ｓを含むように設定またはリセットされる。シリアルデータストリームが、信号ＣＲＣ＿Ｉとして回路１５２１に供給される。さらに、クロック信号Ｓ＿ＣＬＫおよび計算信号Ｓ＿ＣＣが、回路１５２１に供給される。計算信号Ｓ＿ＣＣは、回路が計算ステップを実行すべきか否かを示す。電気回路１５２１がフレーム４５０の送信元としての加入局１０によって使用されるとき、出力でＣＲＣ＿Ａ信号が出力され、この信号は、ヘッダチェックサムＨＣＲＣに関するＨＣＲＣフィールドに入力される。加入局１０から受信されたフレーム４５０のために電気回路１５２１が使用されるときにヘッダチェックサムＨＣＲＣの計算でエラーが発生した場合、第１の例示的実施形態に関して前述したように、信号Ｓ＿Ｅが出力される。

【0126】

ヘッダチェックサムＨＣＲＣを計算するために、フリップフロップＦ０～Ｆ１２は、ＣＲＣ＿ＩＮＩＴ信号を使用して開始位置にされ、より正確には開始値Ｒ＿Ｓに設定される。例えば、開始値Ｒ＿Ｓ＝（１，０，０，０，０，０，０，０，０，０，０，０，０）の場合、最下位ビット（ＬＳＢ）のためのフリップフロップＦ０のみが「１」に設定される。一方、他のすべてのフリップフロップＦ１～Ｆ１２は、値「０」に設定される。

【0127】

回路１５２１の動作ステップは、クロック信号Ｓ＿ＣＬＫと信号Ｓ＿ＣＣとのＡＮＤ演算によってトリガされる。ＡＮＤ演算は、ＡＮＤゲートＵ１を用いて実行される。ＣＲＣ計算に含まれないビットについては、動作ステップは実行されない。ヘッダチェックサムＨＣＲＣの場合、これらは、第１の例示的実施形態に関して上述したように、固定値を有するビットである。

【0128】

加入局１０がフレーム４５０の送信元であるとき、送信／受信デバイス１２は、ヘッダチェックサムフィールドＨＣＲＣの先頭から、信号ＣＲＣ＿Ａをバス４０に送信する。加入局１０がフレーム４５０の受信側でしかない、すなわち送信元ではない場合、信号ＣＲＣ＿Ａは送信されず、信号Ｓ＿Ｅを使用して、フレーム４５０のＨＣＲＣフィールドでのチェックサムにエラーがあるか否かを決定する。

【0129】

信号ＣＲＣ＿Ｅは、図６の回路では、フリップフロップの反転出力

【数4】

を結合する１３重のＮＡＮＤゲートＵ２によって生成される。信号ＣＲＣ＿Ｅは、ＨＣＲＣの完全な受信後、受信側加入局１０で評価される。

【0130】

エラーがない場合、ヘッダチェックサムフィールドＨＣＲＣの最後に、ＣＲＣ－ＦＦのすべてのＱ出力が値「０」になる。この場合、出力または信号ＣＲＣ＿Ｅは、値「０」を有する。

【0131】

反転出力

【数5】

が値「０」を有するとき、信号ＣＲＣ＿Ｅは値「１」を示し、通信制御デバイス１１にエラーを通知する。

【0132】

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

【0133】

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

【0134】

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

【0135】

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

【0136】

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

【0137】

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

【0138】

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

【0139】

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

【0140】

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

【0141】

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

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】