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

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

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

(11)【特許番号】

(24)【登録日】2024-01-17

(45)【発行日】2024-01-25

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

(51)【国際特許分類】

   H04L 1/00 20060101AFI20240118BHJP

【ＦＩ】

H04L1/00 A

【請求項の数】 8

(21)【出願番号】P 2022532794

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

(65)【公表番号】

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

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

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

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

【審査請求日】2022-06-01

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

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

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

(73)【特許権者】

【識別番号】591245473

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

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

(74)【代理人】

【識別番号】100118902

【弁理士】

【氏名又は名称】山本 修

(74)【代理人】

【識別番号】100196508

【弁理士】

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

(74)【代理人】

【識別番号】100195408

【弁理士】

【氏名又は名称】武藤 陽子

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

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

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

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

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

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

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

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

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

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

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

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

【0028】

図面中、特に指示のない限り、同一または機能的に同一の要素には同じ参照符号が付されている。
図１は、例としてバスシステム１を示し、バスシステム１は、特に基本的には、以下に述べるように、ＣＡＮバスシステム、ＣＡＮ ＦＤバスシステム、ＣＡＮ ＸＬバスシステム、および／またはそれらの変形システムのために設計されている。バスシステム１は、特に自動車や航空機などの車両、または病院などで使用することができる。

【0029】

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

【0030】

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

【0031】

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

【0032】

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

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

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

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】