(57)【特許請求の範囲】
【請求項１】
１つの送信側から少なくとも１つの受信側へ、バスライン（３）を介してフレーム（６０００；６００１；６００２）をシリアル伝送する方法であって、
付加的な信号エッジを発生させるために、複数の先行ビットの値に応じて、前記送信側により前記フレーム（６０００；６００１；６００２）にスタッフビット（５２）を挿入し、
前記フレーム（６０００；６００１；６００２）の前記送信側は、複数の先行ビットの値に応じて挿入される前記スタッフビット（５２）を計数し、
計数された前記スタッフビット（５２）の個数に関する情報を、送信フレーム（６０００；６００１；６００２）内で共に伝送する、
バスライン（３）を介してフレーム（６０００；６００１；６００２）をシリアル伝送する方法。
【請求項２】
計数された前記スタッフビット（５２）の個数に関する前記情報に加えて、計数された前記スタッフビット（５２）の個数に関するさらに別の安全保護情報を、前記送信フレーム（６０００；６００１；６００２）内で共に伝送する、
請求項１に記載の方法。
【請求項３】
前記フレーム（６０００；６００１；６００２）の受信側は、複数の先行ビットの値に応じて前記スタッフビット（５２）を計数し、計数された前記スタッフビット（５２）の個数に関して前記送信フレーム（６０００；６００１；６００２）内で共に伝送される前記情報と比較し、
前記受信側により受信フレーム（６０００；６００１；６００２）内で計数された前記スタッフビット（５２）が、計数された前記スタッフビット（５２）の個数に関して前記送信フレーム（６０００；６００１；６００２）内で共に伝送される前記情報と等しくなければ、前記受信側は前記受信フレーム（６０００；６００１；６００２）を破棄する、
請求項１または２に記載の方法。
【請求項４】
前記フレーム（６０００；６００１；６００２）の第１の部分では、複数の先行ビットの値に応じてスタッフビット（５２）を挿入し、
前記フレーム（６０００；６００１；６００２）の第２の部分では、固定スタッフビットとして決められたポジションにスタッフビット（５２）を挿入し、
前記フレーム（６０００；６００１；６００２）の送信側は、固定スタッフビット方式に切り替わる領域の前に位置する前記スタッフビット（５２）を計数し、
計数された前記スタッフビット（５２）の個数に関する情報を、前記送信フレーム（６０００；６００１；６００２）内で共に伝送する、
請求項１から３までのいずれか１項に記載の方法。
【請求項５】
前記フレーム（６０００；６００１；６００２）は、ヘッダパート（６１，６２，６３）と、データパート（６４）と、ターミネーションパート（６５）とを有しており、
前記ヘッダパート（６１，６２，６３）はアイデンティファイヤ（６２）を含み、
前記フレーム（６０００；６００１；６００２）はＣＲＣチェックサム（６５）を含み、
計数された前記スタッフビット（５２）に関する前記情報を、前記送信フレーム（６０００；６００１；６００２）の前記ターミネーションパート（６５）内で前記ＣＲＣチェックサムの前に共に伝送する、
請求項１から４までのいずれか１項に記載の方法。
【請求項６】
計数された前記スタッフビット（５２）の個数に関する前記情報を、前記ＣＲＣチェックサムの計算に共に含める、
請求項５に記載の方法。
【請求項７】
計数された前記スタッフビット（５２）の個数に関する前記情報と、前記ＣＲＣチェックサムとの間に、１つの固定スタッフビットを挿入し、当該固定スタッフビットはパリティビットとして、計数された前記スタッフビット（５２）の個数に関する安全保護情報を含む、
請求項５または６に記載の方法。
【請求項８】
前記スタッフビットの計数のために３ビットカウンタを使用する、
請求項１から７までのいずれか１項に記載の方法。
【請求項９】
バスシステム（１）のための加入者局（１０；２０；３０）であって、
前記バスシステム（１）の別の加入者局へフレーム（６０００；６００１；６００２）を送信するための、および／または、前記バスシステム（１）の別の加入者局からフレーム（６０００；６００１；６００２）を受信するための、送／受信装置（１３；２３；３３）と、
前記フレーム（６０００；６００１；６００２）に挿入された複数のスタッフビット（５２）を安全保護するための安全保護装置（１２；２２；３２）と、
を備えており、
前記送／受信装置（１３；２３；３３）により前記フレーム（６０００；６００１；６００２）を、シリアル伝送によってバスライン（３）を介して、１つの送信側から少なくとも１つの受信側へ伝送可能であり、
前記送／受信装置（１３；２３；３３）は、フレーム（６０００；６００１；６００２）を送信する前に、当該フレーム（６０００；６００１；６００２）に、予め定められたルールに従い付加的な信号エッジを発生させるために、複数の先行ビットの値に応じて、スタッフビット（５２）を挿入するように構成されており、および／または、前記送／受信装置（１３；２３；３３）は、受信フレーム（６０００；６００１；６００２）を評価する際に前記スタッフビット（５２）を再び除去するように構成されており、
前記安全保護装置（１２；２２；３２）は、複数の先行ビットの値に応じて挿入される前記スタッフビット（５２）を計数し、計数された前記スタッフビット（５２）の個数に関する情報を、当該情報が送信フレーム（６０００；６００１；６００２）内で共に伝送されるように、前記フレーム（６０００；６００１；６００２）に挿入するように構成されている、
加入者局（１０；２０；３０）。
【請求項１０】
バスライン（３）と、少なくとも２つの加入者局（１０；２０；３０）を含むバスシステム（１）であって、
前記少なくとも２つの加入者局（１０；２０；３０）は、互いに通信可能であるように前記バスライン（３）を介して相互接続可能であり、
前記少なくとも２つの加入者局（１０；２０；３０）のうち少なくとも１つの加入者局は、請求項９に記載の加入者局（１０；２０；３０）である、
バスシステム（１）。
【発明の詳細な説明】
【技術分野】
【０００１】
車両特に自動車におけるセンサと制御装置との間の通信のために、たとえばＣＡＮバスシステムを使用することができる。ＣＡＮバスシステムの場合、ＣＡＮプロトコルおよび／またはＣＡＮ  ＦＤプロトコルによってフレームが伝送される。ＣＡＮ  ＦＤについてはＩＳＯ１１８９８−１の最新の委員会原案に記載されており、またはＣＡＮ  ＦＤを含むＣＡＮプロトコル規格として、規格書「ＣＡＮ  ｗｉｔｈ  Ｆｌｅｘｉｂｌｅ  Ｄａｔａ−Ｒａｔｅ規格バージョン１．０（２０１２年４月１７日発表）」に記載されている。
【背景技術】
【０００２】
ＣＡＮ  ＦＤフレームまたはメッセージは、フレームの開始を合図するドミナントレベルの先頭のスタートオブフレームビット（ＳＯＦ−Ｂｉｔ）に続いて、ＣＡＮ  ＦＤフレームの識別子またはアイデンティファイヤのために、ビット２８〜ビット１８を含み、場合によってはさらにビット１７〜ビット０を含む。このことから、これらのビット２８〜ビット０は、ＩＤ２８，ＩＤ２７などとも呼ばれる。
【０００３】
ＣＡＮ  ＦＤメッセージまたはフレームのＣＲＣ方式（ＣＲＣ＝Ｃｙｃｌｉｃ  Ｒｅｄｕｎｄａｎｃｙ  Ｃｈｅｃｋ＝巡回冗長検査）では、１つのレセシブが含められた。このレセシブは、４つのドミナントビットで始まるアイデンティファイヤを含むＣＡＮ  ＦＤフレームにのみに該当する。これら４つのドミナントビットは、ドミナントのスタートオブフレームビットと合わさって、スタッフ条件（ｓｔｕｆｆ  ｃｏｎｄｉｔｉｏｎ）を生じさせ、この条件に基づき、第４アイデンティファイヤビットと第５アイデンティファイヤビットとの間に、１つのレセシブスタッフビットが挿入される。スタッフビット挿入のために予め規定されたこのルールによって阻止することができるのは、５つよりも多い個数の同じビットを含むビットシーケンスが、たとえばフレーム終端の「エンドオブフレーム」の合図であると誤って解釈されること、または、ビットとビットの間において信号エッジまたはレベル変化が欠落することでバス加入者局が同期を失うこと、である。なぜならばＣＡＮおよびＣＡＮ  ＦＤの場合、信号エッジまたはレベル変化が加入者局の同期合わせに用いられるからである。
【０００４】
４つのドミナントビットという上述のケースでは、それらに先行するドミナントのスタートオブフレームビットが（ローカルで受信側において）レセシブビットによって書き換えられると、この受信側は最初のドミナントのアイデンティファイヤビットを、スタートオブフレームビットと解釈する。この場合、受信側がレセシブスタッフビットを受信しても、受信側ではスタッフ条件が存在せず、その結果、受信側はレセシブスタッフビットを第４のアイデンティファイヤビットとして受け入れる。次のビットは第５のアイデンティファイヤビットとして受け入れられ、受信側は再び送信側と同相状態になる。
【０００５】
このようなレセシブによれば、このケースではＣＲＣ検査によっても変更された第４のアイデンティファイヤビットは捕捉されず、送信されたたとえば０ｘ００１のアイデンティファイヤは、０ｘ０８１として受信される。このことが該当するのは、アイデンティファイヤが４つのドミナントの’０’ビットで始まり、ドミナントのスタートオブフレームビットが書き換えられる場合である。その結果として、第４のアイデンティファイヤビットは’０’ではなく’１’として受信されることになる。このことは、基本フォーマット（ｂａｓｅ  ｆｏｒｍａｔ）のＣＡＮ  ＦＤフレームの場合のように１１ビットのアイデンティファイヤも、拡張フォーマット（ｅｘｔｅｎｄｅｄ  ｆｏｒｍａｔ）のＣＡＮ  ＦＤフレームの場合のように２９ビットのアイデンティファイヤも該当するし、１７ビットのＣＲＣを有するＣＡＮ  ＦＤフレームも、２１ビットのＣＲＣを有するＣＡＮ  ＦＤフレームも該当する。
【０００６】
ＣＲＣ方式のレセシブは、ＣＲＣジェネレータのための‘０００００００００００００００００’の初期化ベクトルによって生じる。アービトレーションフィールドにおける最初のレセシブビット（送信されたスタッフビット、このビットは受信側ではビット誤りにより４番目のアイデンティファイヤビットとみなされる）よりも前で１ビットだけ少なければ、１番目の先頭の‘０’ビットによってもＣＲＣジェネレータレジスタは変更されず、したがってこれはビットはＣＲＣ検査によっても検出されない。しかもフレーム開始点において欠落したビットは、フォーマットエラーとして検出されない。その理由は、スタッフビットが欠落したアイデンティファイヤビットとして受け入れられるからである。
【０００７】
これらの点をまとめると以下のとおりとなる：
古典的なＣＡＮの場合、スタッフビットはＣＲＣ生成のために考慮されない。ビット誤り発生条件とスタッフ除去条件のペアによってのみ、ハミング距離（ＨＤ）を２まで低減することができる。
【０００８】
もっと長いＣＲＣチェックサム（ＣＲＣ−１７およびＣＲＣ−２１）を有するＣＡＮ  ＦＤの場合、スタッフビットはＣＲＣ発生に含まれる。受信側によりスタートオブフレームビットが誤って書き換えられると、問題が発生する可能性がある。
【０００９】
以下の２つのケースにおいて、ＣＡＮ  ＦＤフレームのＣＲＣによっても、誤って書き換えられたアイデンティファイヤが検出されない、という事態が発生する可能性があり、つまりこのことは、誤って書き換えられたフレームを受信側は有効なフレームとして受け入れる、ということを意味する。
【００１０】
ケース１ａ：送信側はＩＤ２８〜ＩＤ２５＝“００００”を送信する。
【００１１】
切り捨てられたスタートオブフレームビットを受信側が検出した場合、ＩＤ２８〜ＩＤ２５＝“００００”で始まるアイデンティファイヤが、ＩＤ２８〜ＩＤ２５＝“０００１”に誤って書き換えられる可能性がある。その理由は、受信側がスタートオブフレームを識別しないか、または識別が遅くなりすぎ、そのためＩＤ２８がスタートオブフレームとして解釈されることによる。したがって最初の４つのアイデンティファイヤビットが、送信側によりＩＤ２５の後に挿入されたスタッフビットゆえに、ＩＤ２８〜ＩＤ２５＝“０００１”に誤って書き換えられ、以降のすべてのアイデンティファイヤビットは正しく受信される。送信側は、スタートオブフレームビットをバスから読み直しても、誤りを識別しない。
【００１２】
必然的に生じるこのような短縮は、送信側と受信側との間のＣＡＮクロック周波数の関係に依存する。詳細について具体例を参照されたい。
【００１３】
誤って書き換えられたバス信号は、受信側のＣＡＮノードによりそれらが検出されないかぎり、ドミナントの妨害パルスを含む可能性がある。送信側により送信されたスタートオブフレームビットよりも前のビットが、受信側のＣＡＮノードによりドミナントでサンプリングされるかぎり、誤って書き換えられたバス信号がレセシブ妨害パルスを含む可能性がある。この点については、あとで図７および図８を参照しながら、さらに詳しく説明する。
【００１４】
たとえば、各加入者局または各ノードのＣＡＮクロックがｆＲＸ＿ノード＝＝ｆＴＸ＿ノードであるならば、“ｐｈａｓｅ＿ｓｅｇ２＋ε”のスタートオブフレームビットの短縮／信号誤りで、十分に問題が引き起こされる。１Ｍｂｉｔ／ｓで８０％のサンプルポイント（Ｓａｍｐｌｅ  Ｐｏｉｎｔ  ＝  ＳＰ）であれば、２０５ｎｓだけ切り捨てられると十分に問題が発生する。この点については、あとで図７および図８を参照しながら、さらに詳しく説明する。
【００１５】
ケース１ｂ：送信側はＩＤ２８〜ＩＤ２５＝“０００１”を送信する。
【００１６】
他方、送信されたスタートオブフレームビットが到着する前に、受信側がたとえばドミナントの妨害パルスによってビットタイム内でドミナントビットを検出すると、ＩＤ２８〜ＩＤ２５＝“０００１”で始まるアイデンティファイヤが、ＩＤ２８〜ＩＤ２５＝“００００”に誤って書き換えられる可能性がある。その理由は、送信側から送信されたスタートオブフレームビットを、受信側はＩＤ２８として識別することによる。これによって受信側は“１”をスタッフビットと誤って解釈し、このビットを除去してしまう。これに伴って最初の４つのアイデンティファイヤビットが、ＩＤ２８〜ＩＤ２５＝“００００”に誤って書き換えられる。以降のすべてのビットは、正しく受信される。
【００１７】
以上の点をまとめて表１に示す。この表には、アイデンティファイヤビットＩＤ２８〜ＩＤ２５の“００００”および“０００１”という２つのクリティカルな値が、受信側に至る経路上でどのように信号誤りが生じて、受信側のＣＲＣによっても誤りが識別されないようになってしまうのかが示されている。
【００１８】
【表１】
0006324618.tif 000002
【００１９】
同じ問題は、ＣＡＮ  ＦＤフレーム内でも発生する可能性があり、これは、ＣＲＣジェネレータレジスタのすべてのビットがゼロになっているときに、１つのフレーム内のポジションにおいて４つまたは５つのドミナントビットから成るシーケンスがスタートした場合である。換言すれば、同等の問題がＣＡＮ  ＦＤフレーム内でも発生するのは、以下の場合である。すなわち、送信された４つのドミナントビットから成る１つのシーケンス後の１つのレセシブビットが、１ビットの短縮に起因して、または加入者局同士の同期合わせのずれに起因して、受信側によりスタッフビットと誤って解釈され、これと同時にテンポラリＣＲＣレジスタ値が偶然に“０．．．０”と等しい場合である。テンポラリＣＲＣレジスタ値は、そのために設けられたＣＲＣレジスタ内にそのつど生じているＣＲＣチェックサムの現在の値である。送信側もしくは受信側において、ＣＲＣフィールドよりも前に送信もしくは受信される各ビットを用い、そのつど適用されるＣＲＣ多項式の規則に従って、ＣＲＣレジスタの内容が新たに計算される。ついで、データフィールドの最後のビットのところで生じたレジスタの現在の内容が、このフレームのＣＲＣフィールドにおいて、検査のために送信側から受信側へ送信される。
【００２０】
このことは、古典的なＣＡＮフレームでは該当しない。なぜならばその場合には、スタッフビットがＣＲＣ計算から除外されているからである。
【００２１】
独国特許出願公開第１０２０１１０８０４７６号明細書（ＤＥ１０２０１１０８０４７６Ａ１）には、送信側により少なくともフレームの一部分において、１つまたは複数のビットから成る固定スタッフビットシーケンスをフレームに挿入する方法が開示されている。固定スタッフビットシーケンスの最初に挿入されるビット（もしくは１つだけ挿入されるビット）は好ましくは、先行ビットに対し反転した値を有する。固定スタッフビットシーケンス（もしくは固定スタッフビット）は、フレームの予め定められたポジションに現れる。これに対し古典的なＣＡＮの場合、スタッフビットは、複数の先行ビットの値に応じて挿入されるので、決められたポジションを有していない。
【先行技術文献】
【特許文献】
【００２２】
【特許文献１】独国特許出願公開第１０２０１１０８０４７６号明細書
【非特許文献】
【００２３】
【非特許文献１】規格書「ＣＡＮ  ｗｉｔｈ  Ｆｌｅｘｉｂｌｅ  Ｄａｔａ−Ｒａｔｅ規格バージョン１．０（２０１２年４月１７日発表）」
【発明の概要】
【発明が解決しようとする課題】
【００２４】
発明の開示
以上のことから本発明の課題は、バスシステムを介して１つの送信側から少なくとも１つの受信側へフレームをシリアル伝送する方法、およびバスシステムのための加入者局において、かかる方法およびかかる加入者局によってこれまでに挙げた問題点が解決されるようにすることである。特に、バスシステムを介して１つの送信側から少なくとも１つの受信側へフレームをシリアル伝送する方法、およびバスシステムのための加入者局において、バスシステムの各加入者局間のデータ伝送の安全性が、従来の方法よりもさらに高められるのが望ましい。
【課題を解決するための手段】
【００２５】
この課題は、請求項１の特徴を備えた、バスラインを介して１つの送信側から少なくとも１つの受信側へフレームをシリアル伝送する方法によって解決される。
【００２６】
本発明によれば、付加的な信号エッジを発生させるために、複数の先行ビットの値に応じて、送信側によりフレームにスタッフビットを挿入し、フレームの送信側は、複数の先行ビットの値に応じて挿入されるスタッフビットを計数し、計数されたスタッフビットの個数に関する情報を、送信フレーム内で共に伝送する。本発明による方法によれば、従来技術において説明したようなビット誤りすなわちＣＲＣ手順によっても発見できないビット誤りの発生を、どのようにして識別できるようにするのか、という点に関して実現可能な手法が提供される。
【００２７】
本発明による方法によれば、ＣＡＮ  ＦＤによる実装においてスタッフビットが計数され、カウンタステータスがフレーム内で伝送され、ついでそのカウンタステータスが受信側によって検査される。
【００２８】
本発明による方法の利点は、識別されたＣＲＣ手順のレセシブが、付加的な検査手法によって補償調整される、という点にある。本発明による方法は、他で提案されている解決手法とは異なり、有効データレートに対し最小限の影響しか及ぼさない。
【００２９】
ここで説明する方法の適用は、ＣＡＮプロトコルコントローラのデータシート／ハンドブックによって提供することができる一方、ネットワークもしくはバスシステムにおけるコントローラもしくは通信制御装置の動作によって提供することができる。ここで説明するＣＡＮ  ＦＤプロトコルのバリエーションは、ＣＡＮネットワークおよびＴＴＣＡＮネットワークのために使用されるのが望ましい。
【００３０】
従属請求項には、本発明による方法のさらに別の有利な実施形態が示されている。
【００３１】
ここで考えられるのは、計数されたスタッフビットの個数に関する情報に加えて、計数されたスタッフビットの個数に関するさらに別の安全保護情報を、送信フレーム内で共に伝送することである。
【００３２】
フレームの受信側は、複数の先行ビットの値に応じてスタッフビットを計数し、計数されたスタッフビットの個数に関して送信フレーム内で共に伝送される情報と比較し、受信側により受信フレーム内で計数されたスタッフビットが、計数されたスタッフビットの個数に関して送信フレーム内で共に伝送された情報と等しくなければ、受信側は受信フレームを破棄する。
【００３３】
好ましくは、フレームの第１の部分では、複数の先行ビットの値に応じてスタッフビットを挿入し、フレームの第２の部分では、固定スタッフビットとして決められたポジションにスタッフビットを挿入することができ、フレームの送信側は、固定スタッフビット方式に切り替わる領域の前に位置するスタッフビットを計数し、計数されたスタッフビットの個数に関する情報を、送信フレーム内で共に伝送する。
【００３４】
さらに実現可能な態様として、フレームは、ヘッダパートとデータパートとターミネーションパートとを有しており、ヘッダパートはアイデンティファイヤを含み、フレームはＣＲＣチェックサムを含み、計数されたスタッフビットに関する情報を、送信フレームのターミネーションパート内でＣＲＣチェックサムの前に共に伝送する。
【００３５】
好ましくは、計数されたスタッフビットの個数に関する情報を、ＣＲＣチェックサムの計算に共に含めることができる。
【００３６】
本発明による方法の１つの特別な実施形態によれば、計数されたスタッフビットの個数に関する情報と、ＣＲＣチェックサムとの間に、１つの固定スタッフビットを挿入することができ、この固定スタッフビットはパリティビットとして、計数されたスタッフビットの個数に関する安全保護情報を含んでいる。
【００３７】
本発明による方法のさらに別の特別な実施形態によれば、スタッフビットを計数するために３ビットカウンタを用いる。
【００３８】
さらに既述の課題は、請求項９に記載のバスシステムのための加入者局によって解決される。この加入者局には、バスシステムの別の加入者局へフレームを送信するための、および／または、バスシステムの別の加入者局からフレームを受信するための、送／受信装置と、フレームに挿入された複数のスタッフビットを安全保護するための安全保護装置とが含まれている。この場合、送／受信装置によりフレームを、シリアル伝送によってバスラインを介して１つの送信側から少なくとも１つの受信側へ伝送可能であり、送／受信装置は、フレームを送信する前に、このフレームに、予め定められたルールに従い付加的な信号エッジを発生させるために、複数の先行ビットの値に応じて、スタッフビットを挿入するように構成されており、および／または、送／受信装置は、受信フレームを評価する際にスタッフビットを再び除去するように構成されている。さらに安全保護装置は、複数の先行ビットの値に応じて挿入されるスタッフビットの個数を計数し、計数されたスタッフビットの個数に関する情報を、この情報が送信フレーム内で共に伝送されるように、フレームに挿入するように構成されている。
【００３９】
この加入者局を、以下のようなバスシステムの一部分とすることができる。すなわちこのバスシステムはさらに、バスラインと、少なくとも２つの加入者局を含み、これら少なくとも２つの加入者局は、互いに通信可能であるようにバスラインを介して相互接続可能であり、少なくとも２つの加入者局のうち少なくとも１つの加入者局は、上述の加入者局である。
【００４０】
本発明のその他の実現可能な形態には、既述のまたは以下で実施例を参照しながら説明する特徴または実施形態の明示的に挙げてない組み合わせも含まれる。その際に当業者であれば、本発明による個々の基本形態に対する改善または補足として、個別の態様も追加するであろう。
【００４１】
次に、添付の図面を参照しながら実施例に基づき、本発明について詳しく説明する。
【図面の簡単な説明】
【００４２】
【図１】第１の実施例によるバスシステムの簡略ブロック図。
【図２】図１によるバスシステムにおけるフレーム構造を概略的に示す図。
【図３】ＣＡＮ  ＦＤフレームのフォーマットを、ＩＳＯ１１８９８−１の最新の委員会原案による最初の４つのアイデンティファイヤビット（ＩＤ２８〜ＩＤ２５）の配置と共に示す図。
【図４】ＣＡＮ  ＦＤフレームのフォーマットを、ＩＳＯ１１８９８−１の最新の委員会原案による最初の４つのアイデンティファイヤビット（ＩＤ２８〜ＩＤ２５）の配置と共に示す図。
【図５】ＣＡＮ  ＦＤフレームのフォーマットを、ＩＳＯ１１８９８−１の最新の委員会原案による最初の４つのアイデンティファイヤビット（ＩＤ２８〜ＩＤ２５）の配置と共に示す図。
【図６】ＣＡＮ  ＦＤフレームのフォーマットを、ＩＳＯ１１８９８−１の最新の委員会原案による最初の４つのアイデンティファイヤビット（ＩＤ２８〜ＩＤ２５）の配置と共に示す図。
【図７】図１によるバスシステムで伝送されるフレームの開始時点における送信側と受信側との間におけるクロックの関係の時間推移を示す図。
【図８】図１によるバスシステムで伝送されるフレームの開始時点における送信側と受信側との間におけるクロックの関係の時間推移を示す図。
【図９】第１の実施例によるフレームの一例を示す図。
【図１０】バスシステムで伝送されるフレームの内部における送信側と受信側との間におけるクロックの関係の時間推移を示す図。
【図１１】第４の実施例によるフレームの一例を示す図。
【図１２】第５の実施例によるフレームの一例を示す図。
【発明を実施するための形態】
【００４３】
図中、別途記載がないかぎり、同じ要素または機能的に同等の要素には同じ参照符号が付されている。
【００４４】
第１の実施例
図１には、第１の実施例としてバスシステム１が示されており、このバスシステム１をたとえばＣＡＮ  ＦＤバスシステムとすることができる。このバスシステム１を車両、特に自動車、航空機等において用いることができ、または病院などで用いることができる。
【００４５】
図１によればバスシステム１は、多数の加入者局１０，２０，３０が接続されたバスライン３を有する。バスライン３を介して、フレーム４０を信号の形態で個々の加入者局１０，２０，３０間において伝送することができる。加入者局１０，２０，３０をたとえば、自動車のコントローラ、センサ、ディスプレイ等としてもよいし、または産業用制御装置としてもよい。
【００４６】
図１に示されているように加入者局１０には、通信制御装置１１と、安全保護装置１２と、ＣＲＣジェネレータ１３Ａを含む送／受信装置１３とが設けられている。当然ながら安全保護装置１２を、通信制御装置１１の一部分としてもよい。これとは異なり加入者局２０には、通信制御装置２１と、ＣＲＣ評価ユニット２２Ａおよび挿入ユニット２２Ｂを含む安全保護装置２２と、ＣＲＣジェネレータ２３Ａを備えた送／受信装置２３とが設けられている。さらに加入者局３０には、通信制御装置３１と、安全保護装置３２と、この安全装置３２およびＣＲＣジェネレータ３３Ａを含む送／受信装置３３とが設けられている。図１には示されていないけれども、加入者局１０，２０，３０の送／受信装置１３，２３，３３は、それぞれ直接、バスライン３に接続されている。
【００４７】
通信制御装置１１，２１，３１は、個々の加入者局１０，２０，３０と、バスライン３に接続された複数の加入者局１０，２０，３０のうち他の１つの加入者局との、バスライン３を介した通信を、それぞれ制御する役割を果たす。通信制御装置１１，２１，３１をそれぞれ、慣用のＣＡＮコントローラまたはＴＴＣＡＮコントローラまたはＣＡＮ  ＦＤコントローラのように実装することができる。また、これらの通信制御装置１１，２１，３１をそれぞれ、やはり個々の加入者局１０，２０，３０に含まれているマイクロコントローラの一部として構成してもよい。さらに送／受信装置１３，２３，３３をそれぞれ、慣用のＣＡＮトランシーバまたはＴＴＣＡＮトランシーバまたはＣＡＮ  ＦＤトランシーバのように実装することができる。
【００４８】
安全保護装置１２，２２，３２を、加入者局で実行されるソフトウェアの一部分を成すソフトウェアモジュールとして実装することもできる。このケースでは本発明による方法は、完全にソフトウェアとして記述される。
【００４９】
図２にはフレーム４０の構造が、このフレーム４０の直前にバスライン３を介して伝送されるスタートオブフレームビット（ＳＯＦ）を除いて、概略的に示されている。フレーム４０を、ＣＡＮフレームまたはＴＴＣＡＮフレームとすることができる。
【００５０】
図２によればフレーム４０には、ヘッダパート４１，４１Ａ，４２と、データフィールド４３，４４，４５と、フレーム終端を成すターミネーションパート４６とが含まれている。ヘッダパート４１，４１Ａ，４２は第１のパートセクション４１において、アイデンティファイヤ（ＩＤ）４１，４１Ａの最初の４つのビットを含み、第２のパートセクション４１Ａにおいて、アイデンティファイヤ４１，４１Ａの残りのビットと、コントロールフィールド４２とを含む。データフィールド４３，４４，４５は、第１のパート４３において１つのバイト０を含み、第２のパート４４において別の複数のバイトを含み、さらに第３のパート４５において１つのバイトｎを含む。ターミネーションパート４６には、ＣＲＣチェックサムが設けられている。
【００５１】
図３には、加入者局１０，２０，３０のうち１つの加入者局から送信されるフレーム６０が示されており、このフレーム６０は、ＣＡＮ  ＦＤ基本フォーマットで１６個までのデータバイトを含む。フレーム６０は、ＳＯＦビット６１と、複数のフレームフィールドとを含み、たとえばアービトレーションフィールド６２（Ａｒｂｉｔｒａｔｉｏｎ  ｆｉｅｌｄ）、コントロールフィールド６３（Ｃｏｎｔｒｏｌ  ｆｉｅｌｄ）、データフィールド６４（Ｄａｔａ  ｆｉｅｌｄ）、チェックサムフィールド６５（ＣＲＣ  ｆｉｅｌｄ）を含む。アービトレーションフィールド６２は基本ＩＤフィールド内に、フレーム６０のアイデンティファイヤ（識別子）を含む。アービトレーションフィールド６２の終端には、ＲＲＳビットが配置されている。コントロールフィールド６３はＩＤＥビットで始まり、このＩＤＥビットに続いて、ＦＤＦビット、ｒｅｓビット、これに続いてＢＲＳビット、その後にＥＳＩビットが続き、このＥＳＩビットにはＤＬＣフィールドが続いている。コントロールフィールド６３のＤＬＣフィールドが値０であるときには、データフィールド６４は存在しない。チェックサムフィールド６５は、ＣＲＣ−ｓｅｑフィールドにＣＲＣチェックサムを含み、それに続くＣＲＣデリミタＣＲＣ−Ｄｅｌで終了する。ここで挙げたフィールドおよびビットは、ＩＳＯ−ＣＤ−１１８９８−１により知られており、したがってここではこれ以上詳しくは説明しない。
【００５２】
図３には、この実施例によるアービトレーションフェーズ６７の長さが記載されている。フレーム６０においてＢＲＳビットがレセシブである場合には、アービトレーションフェーズ６７にデータフェーズ６８が続く。フレーム６０には、ヘッダパート６１〜６３と、データパート６４と、ターミネーションパート６５とが含まれている。
【００５３】
図３〜図６ではドミナントビットが、フレーム６０の下縁に太線で表されている。さらに図３〜図６ではレセシブビットが、フレーム６０の上縁に太線で表されている。
【００５４】
図３に示されているように、送信側の対応する通信制御装置１１，２１，３１は、ＳＯＦビット、ＲＲＳビット、ＩＤＥビットおよびｒｅｓビットがドミナントであるのに対し、ＦＤＦビットおよびＣＲＣデリミタＣＲＣ−Ｄｅｌがレセシブとなるように、フレーム６０を生成する。
【００５５】
図４には、加入者局１０，２０，３０のうち１つの加入者局から送信されるフレーム６００が示されており、このフレーム６００は、ＣＡＮ  ＦＤ基本フォーマットで１６個よりも多くのデータバイトを含む。フレーム６００は、データフィールド６４よりも長いデータフィールド６４０と、チェックサムフィールド６５よりも長いチェックサムフィールド６５０を除き、図３のフレーム６０と同じように構成されている。フレーム６００には、ヘッダパート６１〜６３と、データパート６４０と、ターミネーションパート６５０とが含まれている。
【００５６】
図５には、加入者局１０，２０，３０のうち１つの加入者局から送信されるフレーム７０が示されており、このフレーム７０にはＣＡＮ  ＦＤ拡張フォーマット（ＣＡＮ  ＦＤ  ｅｘｔｅｎｄｅｄ  ｆｏｒｍａｔ）で１６個までのデータバイトを含む。図５によればフレーム７０は、ＳＯＦビット７１と、複数のフレームフィールドとを含み、たとえばアービトレーションフィールド７２（Ａｒｂｉｔｒａｔｉｏｎ  ｆｉｅｌｄ）、コントロールフィールド７３（Ｃｏｎｔｒｏｌ  ｆｉｅｌｄ）、データフィールド７４（Ｄａｔａ  ｆｉｅｌｄ）、およびチェックサムフィールド７５（ＣＲＣ  ｆｉｅｌｄ）を含む。アービトレーションフィールド７２は基本ＩＤフィールドおよびＩＤ拡張フィールド内に、フレーム７０のアイデンティファイヤ（識別子）を含む。基本ＩＤフィールドとＩＤ拡張フィールドとの間に、ＳＲＲビットとＩＤＥビットが設けられている。アービトレーションフィールド７２の終端には、ＲＲＳビットが配置されている。コントロールフィールド７３は、ＦＤＦビットで始まり、このビットにｒｅｓビットが続く。さらにこのビットには、ＢＲＳビットとＥＳＩビットが続く。コントロールフィールド７３は、ＤＬＣフィールドで終了する。コントロールフィールド７３のＤＬＣフィールドが値０であるときには、データフィールド７４は存在しない。その他の点については、フレーム７０は図３に示したフレーム６０と同じように構成されており、対応するアービトレーション７とデータフェーズ７８とを有する。フレーム７０は、ヘッダパート７１〜７３、データパート７４およびターミネーションパート７５を含む。
【００５７】
図５に示されているように、送信側の対応する通信制御装置１１，２１，３１は、ＳＯＦビット、ＲＲＳビットおよびｒｅｓビットがドミナントであるのに対し、ＳＲＲビット、ＩＤＥビットおよびＣＲＣデリミタＣＲＣ−Ｄｅｌがレセシブであるように、フレーム７０を生成する。
【００５８】
図６には、加入者局１０，２０，３０のうち１つの加入者局から送信されるフレーム７００が示されており、このフレーム７００にはＣＡＮ  ＦＤ拡張フォーマット（ＣＡＮ  ＦＤ  ｅｘｔｅｎｄｅｄ  ｆｏｒｍａｔ）で１６個よりも多くのデータバイトを含む。フレーム７００は、データフィールド７４０がデータフィールド７４よりも長く、チェックサムフィールド７５０がチェックサムフィールド７５よりも長い点を除き、図５のフレーム７０と同じように構成されている。フレーム７００は、ヘッダパート７１〜７３、データパート７４０およびターミネーションパート７５０を含む。
【００５９】
図３および図４に示した基本フォーマットのＣＡＮ  ＦＤフレーム６０，６００については、ＣＲＣチェックサムをＣＲＣ−１７と称する。また、図５および図６に示した拡張フォーマットのＣＡＮ  ＦＤフレーム７０，７００については、ＣＲＣチェックサムをＣＲＣ−２１と称する。
【００６０】
図７には具体例として、加入者局１０の送信信号ＴＸ−１０と、加入者局２０の受信信号ＲＸ−２０と、加入者局２０の側で見えるサンプリングビューＶ−２０の推移が、それぞれ時間軸ｔ上に示されている。図７の破線はそれぞれ、個々のビット間のビット境界５０を表している。なお、図面を見やすくする理由から、受信信号ＲＸ−２０とサンプリングビューＶ−２０に関しては、境界５０を表す破線のすべてに参照符号が付されているわけではない。
【００６１】
図７に示したケースによれば、バスライン３を介して最初にアイドルビット５１が送信され、その後、スタートオブフレームビット（ＳＯＦビット）で送信信号ＴＸ−１０がスタートする。これに続いて、スタートオブフレームビットと同じレベルのビット２〜ビット５が送信される。ビット５の後に、スタッフビット５２が挿入される。
【００６２】
この結果として、バスライン３を介した送信信号ＴＸ−１０の伝送により生じる図示されていない遅延を伴いながら、送信信号ＴＸ−１０に対応する受信信号ＲＴＸ−２０が発生する。この受信信号ＲＸ−２０は、（ハードウェアエラー、外乱、電磁放射等）様々な理由から、送信信号がドミナントレベルのＳＯＦビットを有するにもかかわらず、期間Ｔにわたりレセシブレベルとなる可能性がある。このことに加え、このようにして誤って書き換えられた受信信号ＲＸ−２０に、短いドミナントの妨害パルスＧＤが含まれる可能性もあり、図７に示されているように、これによってバス信号３５にさらに信号誤りが引き起こされる。かかる妨害パルスＧＤはたとえば、やはり外乱特に電磁放射などによって発生する可能性があり、場合によっては、たとえばそのような外乱がタイムカンタムｔｑの最短バス時間単位よりも短ければ、受信側の加入者局すなわちここでは加入者局２０によっても検出されない。この場合、受信信号ＲＸ−２０には信号誤りが生じたままである。
【００６３】
加入者局２０の側で見える信号Ｖ−２０は、誤って書き換えられた受信信号ＲＸ−２０に基づいたものである。ＳＯＦビットに対するビット境界５０の後に、参照符号５４の付されたｓｙｎｃ＿ｓｅｇフェーズが続く。ついで伝送フェーズｐｒｏｐ＿ｓｅｇが続き、図７ではこのフェーズに参照符号５５が付されている。さらにその次に、参照符号５６の付されたｐｈａｓｅ＿ｓｅｇ１と、参照符号５７の付されたｐｈａｓｅ＿ｓｅｇ２とが続く。ここで挙げたフェーズ５４〜５７の順序は、いずれのビットについても同じである。
【００６４】
加入者局２０は受信信号ＲＸ−２０を、サンプルポイントＳＰ１，ＳＰ２，ＳＰ３，ＳＰ４，ＳＰ５においてサンプリングする。これらのサンプルポイントＳＰ１〜ＳＰ５は、参照符号５６の付されたｐｈａｓｅ＿ｓｅｇ１と、参照符号５７の付されたｐｈａｓｅ＿ｓｅｇ２との間に位置している。
【００６５】
図７に示したケースでは、ノードとも称する各加入者局１０，２０，３０のＣＡＮクロックは、ｆＲＸ＿ノード＝＝ｆＴＸ＿ノードである。つまり、受信クロックは送信クロックと一致している。この場合、“ｐｈａｓｅ＿ｓｅｇ２＋ε”のスタートオブフレームビット（ＳＯＦ）の短縮／信号誤りで、ここで考察した問題が十分に引き起こされる。図示のケースでは５番目のサンプルポイントＳＰ５により、誤ってレセシブの値が生じている。既述のように、１Ｍｂｉｔ／ｓで、各サンプルポイントＳＰ１，ＳＰ２，ＳＰ３，ＳＰ４，ＳＰ５のために８０％のサンプルポイントＳＰ（ＳＰ＝Ｓａｍｐｌｅ  Ｐｏｉｎｔ）であれば、２０５ｎｓだけ切り捨てられれば、ここで考察した問題が十分に発生する。
【００６６】
図８に示したケースによれば、バスライン３を介して最初に２つのアイドルビット５１が相前後して送信され、その後、ドミナントのスタートオブフレームビット（ＳＯＦビット）で送信信号ＴＸ−１０がスタートする。これに続いて、スタートオブフレームビットと同じレベルのビット２〜ビット４が送信される。ビット４に続くビット５２はレセシブで送信され、したがって先行ビットとは異なるレベルを有する。
【００６７】
この結果として、図８に示されているように、送信信号ＴＸ−１０に対応する受信信号ＲＸ−２０が発生する。この受信信号ＲＸ−２０は、（ハードウェアエラー、外乱、電磁放射等）様々な理由から、送信信号がレセシブレベルのアイドルビットを有するにもかかわらず、（図８ではグレーでハッチングされている）期間Ｔにわたり、ドミナントレベルとなる可能性がある。このことに加え、このようにして誤って書き換えられた受信信号ＲＸ−２０に、短いレセシブの妨害パルスＧＲが含まれる可能性もあり、図８に示されているように、これによってバス信号３６にさらに信号誤りが引き起こされる。かかる妨害パルスＧＲもたとえば、外乱特に電磁放射などによって発生する可能性があり、場合によっては、たとえばそのような外乱がタイムカンタムｔｑの最短バス時間単位よりも短ければ、受信側の加入者局すなわちここでは加入者局２０によっても検出されない。この場合、受信信号ＲＸ−２０には信号誤りが生じたままである。
【００６８】
加入者局２０の側で見える信号Ｖ−２０は、誤って書き換えられた受信信号ＲＸ−２０に基づいたものである。２つのアイドルビット５１間のビット境界５０の後に、参照符号５４の付されたｓｙｎｃ＿ｓｅｇフェーズが続く。ついで伝送フェーズｐｒｏｐ＿ｓｅｇが続き、図８においてもこのフェーズに参照符号５５が付されている。さらにその次に、参照符号５６の付されたｐｈａｓｅ＿ｓｅｇ１と、参照符号５７の付されたｐｈａｓｅ＿ｓｅｇ２とが続く。ここで挙げたフェーズ５４〜５７の順序は、いずれのビットについても同じである。
【００６９】
この場合も加入者局２０は受信信号ＲＸ−２０を、サンプルポイントＳＰ１，ＳＰ２，ＳＰ３，ＳＰ４，ＳＰ５においてサンプリングする。これらのサンプルポイントＳＰ１〜ＳＰ５は、参照符号５６の付されたｐｈａｓｅ＿ｓｅｇ１と、参照符号５７の付されたｐｈａｓｅ＿ｓｅｇ２との間に位置している。
【００７０】
図８に示したケースでは、ノードとも称する各加入者局１０，２０，３０のＣＡＮクロックは、ｆＲＸ＿ノード＝＝ｆＴＸ＿ノードである。つまり、受信クロックは送信クロックと一致している。この場合、スタートオブフレームビット（ＳＯＦ）の前に位置する２番目のアイドルビット５１の“ｐｈａｓｅ＿ｓｅｇ２＋ε”の短縮／信号誤りで、ここで考察した問題が十分に引き起こされる。図示のケースでは５番目のサンプルポイントＳＰ５により、誤ってドミナントの値が生じている。既述のように、１Ｍｂｉｔ／ｓで、各サンプルポイントＳＰ１，ＳＰ２，ＳＰ３，ＳＰ４，ＳＰ５のために８０％のサンプルポイントＳＰ（Ｓａｍｐｌｅ  Ｐｏｉｎｔ＝ＳＰ）であれば、やはり２０５ｎｓだけ切り捨てられれば、ここで考察した問題が十分に発生する。
【００７１】
図９には、本発明による第１の実施例として、ＣＡＮ  ＦＤフレーム６０００が示されており、このフレーム６０００には、チェックサムフィールド６５の先頭に配置されたＳＣフィールド内に、３ビット幅のスタッフ計数値が含まれている。つまり図３に示した慣用のＣＡＮ  ＦＤフォーマットに対し、フレーム６０００の場合にはＣＲＣフィールド内に３つのスタッフ計数ビットが挿入されている。なお、スタッフビットは図示されていない。
【００７２】
したがってこの実施例によれば、ＣＲＣ−１７およびＣＲＣ−２１に関する既述の問題点を解決するために、ＣＡＮ  ＦＤフレームの送信側および受信側はそれらの安全保護装置１２，２２，３２を用いて、固定スタッフビット方式に切り替えられる領域よりも前に存在するスタッフビット５２を計数し、つまりＣＲＣフィールドもしくはチェックサムフィールド６５よりも前に存在するスタッフビット５２を計数する。図９に示されているように、送信されるフレーム６０００においてＳＣフィールド内で、カウンタステータスが共に伝送される。受信側は、受信したフィールドＳＣのカウンタステータスを、受信側自身が計数したスタッフビット５２の個数と比較する。この場合、固定スタッフビットは計数には含まれない。これらのカウンタステータスが異なっていたならば、本来のＣＲＣ計算によってエラーが指示されていなくても、この状態はＣＲＣエラーのように扱われる。
【００７３】
ハミング距離６を確保すればよいので、つまり５つの誤りを識別すればよいので、安全保護装置１２，２２，３２において３ビットカウンタを用いれば十分である。したがってＳＣフィールド内で伝送されるカウンタステータスによって、スタッフビットの個数ｍｏｄｕｌｏ  ８が表される。よって、この３ビットカウンタステータス（スタッフカウント）を識別せずに無効にしてしまうには、少なくとも８つの誤りが必要になる。安全保護装置２２の３ビットカウンタを、ＣＲＣ評価ユニット２２Ａ内に含めることができる。当然ながら、４ビットカウンタ等を使用してもよい。
【００７４】
図９によれば、フレーム６０００内でスタッフカウント値もしくは安全保護装置１２，２２，３２の３ビットカウンタのカウンタステータスを伝送するために、ＣＲＣチェックサムフィールド６５がその先頭で３ビットだけ伸長される。１７−ＣＲＣ多項式を有するフレーム６０，７０についても、２１ビットの多項式を有するフレーム６００，７００についても、このことは同様に当てはまる。
【００７５】
ＳＣフィールドにこのように追加された３つのビットによって、さらに別の１つの固定スタッフビットが生成されるので、ＣＡＮ  ＦＤフレーム６０００はこの方法によれば、スタッフビット５２の個数、ＤＬＣフィールド、またはアイデンティファイヤの長さに関係なく、４ビットだけ伸長する。
【００７６】
ＣＡＮ  ＦＤフレーム６０００におけるスタッフカウントまたはスタッフ計数値は、ＣＲＣ計算に共に含められ、したがってデータビットのように扱われる。
【００７７】
従来技術において説明したように、特別なビット誤りがＣＲＣ計算によっても発見されない場合、そのような誤りが生じたことにより、受信側はスタッフビット５２の計数において異なる結果に至り、その場合にこの誤りは、スタッフカウントの比較により識別され、つまり受信側により計数されたスタッフビット５２とＳＣフィールド内に記述されたスタッフビット５２の個数との比較によって識別され、このフレーム６０００は受信側により無効であるとして破棄される。
【００７８】
別の選択肢として、スタッフビット５２だけでなく、フレーム６０００内のすべてのビットを計数してもよく、さらに別の選択肢として、３ビット幅よりも大きいカウンタステータスを使用してもよい。この方法によれば、スタッフビット計数エラーはＣＲＣエラーのように処理され、つまり誤りのあるフレームもしくはエラーフレームは、ＡＣＫスロット後にはじめて送信される。さらに別の選択肢として、受信側はＳＣフィールドの最後のビットの受信後にすでに比較を実施して、エラーフレームを送信してもよい。
【００７９】
第２の実施例によれば、ＣＲＣ−１７およびＣＲＣ−２１に関する既述の問題点を解決するために、ＣＲＣジェネレータ１３Ａ，２３Ａ，３３Ａの初期化ベクトルとして、“０．．．０”ではなく初期化ベクトル“１．．．０”を用いることができる。この初期化を安全保護装置１２，２２，３２によって行うことができ、安全装置２２であれば特に、ＣＲＣ評価ユニット２２Ａと挿入ユニット２２Ｂによって行うことができる。このようにすることによって、アイデンティファイヤビットＩＤ２８〜ＩＤ２５の２つのクリティカルな値である“００００”と“０００１”の双方に関連する問題点は、もはや発生する可能性がない。
【００８０】
誤って書き換えられた“０００００”ビットシーケンスは、ＣＲＣレジスタ値が“０．．．０”と等しいときにこのシーケンスがスタートすると誤って検出される、という問題点は、ＳＯＦ６１（スタートオブフレーム）と送信されたＣＲＣチェックサムまたはＣＲＣ検査合計との間の任意のビットポジションにおいて発生する可能性があるが、この問題点に対し、“１．．．０”の初期化ベクトルを用いることにより、最初の１８個の送信ビットに関して、“０．．．０”のテンポラリＣＲＣレジスタ値が発生する可能性がなくなる。
【００８１】
第２の実施例の場合にはその他の点について、バスシステム１は第１の実施例で述べたものと同じ態様で構成されている。
【００８２】
第３の実施例の場合、バスシステム１は第１の実施例で述べたものと同じ態様で構成されている。ただし相違点として第３の実施例の場合には、図１０を参照しながら以下の２つの問題点について考察する。
【００８３】
第１のケースにおいて、テンポラリＣＲＣレジスタ値が“０．．．０”と等しい一方、スタッフィングされた“０”のシーケンスが送信され、それら複数の“０”ビットのうち最初のビットが同期合わせ中、バスにおけるノイズに起因して切り捨てられた状態にあると、“０００００Ｉ”のビットシーケンスは（“Ｉ”はここでは送信されたスタッフビットを表す）、図１０に示されているように、受信側によって“００００１”と誤ってサンプリングされてしまう可能性がある。このような短縮もしくは信号誤りは、やはり既述の原因（ハードウェアエラー、外乱、電磁放射等）を有する可能性がある。これに加え、ドミナントの妨害パルスＧＤが同期合わせに妨害作用を及ぼす可能性もある。バス伝播時間によって必ず存在する信号シフト５８は、ここで考慮しないものとする。つまり場合によっては、５つではなく４つの“０”ビットしかサンプリングされない。このエラーは、ＣＲＣ計算によっても検出されない。図１０には、図７および図８と同様に信号推移ＴＸ−１０，ＲＸ−２０，Ｖ−２０に加え、さらに信号Ｔ１０も示されており、これは加入者局１０のビューに対応する。図１０によれば、１つのレセシブビットまたはアイドルビット５１の後に、５つのドミナントビットから成るシーケンスすなわちビット１〜ビット５が送信される。その後、１つのスタッフビット５２が挿入される。
【００８４】
図１０に示したケースが発生する可能性があるのは、クロック許容誤差に起因してビットタイムＲＸ＿ノード＞ビットタイムＴＸ＿ノード（BitTimeRX_node＞BitTimeTX_node）が当てはまるときであり、ここで加入者局１０，２０，３０のうち１つの加入者局ためのノードは、送信側または受信側を成すものである。
【００８５】
位相誤差の補正ではなく、ノイズによっても位相誤差が補正されずまたはそれどころか誤った方向に補正される。
【００８６】
第２のケースにおいて、テンポラリＣＲＣレジスタ値が“０．．．０”と等しい一方、スタッフィングされていないシーケンス“００００１”が伝送され、これらの“０”ビットのうち最初のビットが同期合わせ中に、やはりバスにおけるノイズに起因して伸長されると、“００００１”のビットシーケンスは、受信側によって“０００００Ｉ”（“Ｉ”はここでは送信されるスタッフビットを表す）と誤ってサンプリングされる可能性がある。つまり、４つではなく５つの“０”ビットがサンプリングされることになる。このシーケンス中の“１”は、スタッフの“１”と解釈されて除去される。このような挿入は、ＣＲＣ計算によっても検出されない。
【００８７】
かかるケースが発生する可能性があるのは、クロック許容誤差に起因してビットタイムＲＸ＿ノード＞ビットタイムＴＸ＿ノード（BitTimeRX_node＜BitTimeTX_node）が当てはまるときであり、かつ、サンプリングポイントのポジションが早めに位置しているときだけである。これについても図１０に示されている。
【００８８】
これとは逆のケースすなわち“１１１１１”ビットシーケンスの受信は、以下の理由から問題にはならない。到来してきた１つの“１”は、ＣＲＣにおいて（０．．．０）に変化させることができる。これに続く“１”によって、１７ビットよりも多いビットについて、（０．．．０）とは異なるＣＲＣとなる。この“１”のシーケンス中、ＣＲＣ値が変化しない場合にかぎり、問題が発生する可能性がある。ただし、これはこのケースでは該当しない。
【００８９】
既述の問題に対する解決策として、安全保護装置１２，２２，３２を以下のオプションに従って構成することができ、これらのオプションは択一的に使用してもよいし、任意に組み合わせて用いてもよい。
【００９０】
ａ）古典的なＣＡＮの場合のように、スタッフビットをＣＲＣ計算から除外する。
【００９１】
ｂ）フレーム全体において、またはＦＤＦビットポジションからスタートするように、固定スタッフビットを用いる。これは古典的なＣＡＮフレームと両立性がある。
【００９２】
ｃ）計算の際に、付加的な仮想ビットをＣＲＣチェックサムに挿入する。ただしこれによっても問題は解消しない。その理由は、特別なケースにおいてハミング距離が１まで劣化するからである。ＣＲＣレジスタがＦＤフレームにおいて“０．．．０”の値になったならば、ＣＲＣメカニズムを付加的に評価する際にＣＲＣロジックに“１”を挿入する。このことは、次に受信される／送信されるビットを評価する前に実施される。挿入された“１”を仮想スタッフビットとみなすことができる。この仮想スタッフビットは、ＣＲＣロジックだけにしか見えず、次に受信される／送信されるビットが評価される前に、ＣＲＣレジスタ内の“０．．．０”のクリティカルな値を変化させる。
【００９３】
ｄ）フレーム内で第２のＣＲＣシーケンスを送信する。
【００９４】
ｅ）フレーム内でスタッフビット５２の個数を送信する（オプションｂ）またはｄ）よりもオーバーヘッドが少ない）。このオプションに関する実施例は、第１の実施例としてすでに説明した。次に、さらに別の実施例について説明する。
【００９５】
これまでよりも形式的なアプローチとして、問題を取り扱うために以下のようなエラーモデルを導入する。
【００９６】
・エラータイプＡ：ビットフリップもしくはビット反転。かかるエラーを検出するために、ＣＲＣ計算は有効な方法であり、望ましいハミング距離（ＨＤレベル）を提供するものである。
【００９７】
・エラータイプＢ（既述の問題点）：スタッフビット５２と関連したビットシーケンスの短縮または伸長。その結果、既述のようにフレーム長のエラーが発生する。短縮または伸長は、フレーム６０，７０，６００，７００，６０００ごとに何度も発生する可能性がある。１つのフレーム６０，７０，６００，７００，６０００内で、短縮が生じる可能性または伸長が生じる可能性があり、これは送信側と受信側のクロックの関係によって決まる。このエラータイプを検出するために受信側は、スタッフビット５２の個数を含め、フレーム長を把握していなければならない。
【００９８】
ここで述べておきたいのは、ＣＲＣアルゴリズムが、送信側と受信側とで正確に同じ個数のビット（フレーム長）に適用された場合であれば、ＣＲＣ結果は信頼性がある、ということである。さもないと、つまり受信側が送信側よりも少ないまたは多いビットをＣＲＣアルゴリズムに適用したならば、これはダメージと見なされなければならない。
【００９９】
エラータイプＡ／Ｂをカバーする以下の措置のために、現在（２０１４年９月１１日）のＩＳＯ  ＣＤ  １１８９８−１が出発点を成す。ＣＡＮ  ＦＤのデータエントリのロバストネスは、古典的なＣＡＮと比べれば改善されているはずである。
【０１００】
固定スタッフビット（上述のオプションｂ）を参照）を使用した場合には、受信側が予期する既知の個数のビットが発生する。フレーム長は可変ではない。これは簡単な解決手段であるけれども、オーバーヘッドが大きくなり、それによって正味ビットレートが、現在のＩＳＯ  ＣＤ  １１８９８−１よりも約１０％減少する。
【０１０１】
第４の実施例によれば、考察した既述の問題点に対するさらに別の解決手段のバリエーションにおいて、図９に示して第１の実施例を参照しながら説明したように、スタッフビット５２の個数に関する情報がフレーム６０００内に付加的に含まれる。この情報を長さ情報と呼ぶこともできる。
【０１０２】
古典的なＣＡＮスタッフ方式から、ルールに従って決められるスタッフビットを伴う固定スタッフビット方式に切り替えられた後、スタッフビットカウンタを送信することができる。さもないと、送信されるスタッフビットカウントシーケンスに挿入されるスタッフビットが、スタッフビットカウンタにおいて共に計数に含まれなくなってしまう。
【０１０３】
さらにこれに加えて、この第４の実施例によれば、長さ情報すなわちフレーム６０００内のスタッフビット５２の個数に関する情報の安全監視が行われる。
【０１０４】
つまり１つのフレームにおいてエラータイプＢが発生すると、ＣＲＣチェックサムがダメージを受ける。同じフレームにおいてエラータイプＡによって、安全保護装置１２，２２，３２のスタッフビットカウンタステータスが誤って書き換えられると、受信側は誤って書き換えられたフレームを検出できない。
【０１０５】
このために必要になるのは、送信された長さ情報の安全性を付加的に監視することである（スタッフビット計数値ｍｏｄｕｌｏ  ８）。
【０１０６】
したがって図１１によればフレーム６００１において、パリティビットが安全保護情報としてＳＣフィールドに添付され、したがってチェックサムフィールド６５の前にパリティビットも伝送される。このパリティビットは本来は、常に挿入される固定スタッフビットである。安全保護装置１２，２２，３２は、ＣＲＣチェックサムがダメージを受けているか否かに応じて、このパリティビットを変化させる。このようにすれば、エラータイプＡとＢとが同時に発生したとしても、ダメージを受けたフレーム６００１を確実に検出することができる。
【０１０７】
第５の実施例によれば、さらに別の解決手段のバリエーションにおいて、さらに別の情報が計算され、つまりスタッフビットカウンタの内容に関して別個のＣＲＣチェックサムが計算され、この別の情報は安全保護情報として、たとえば９ビットのＣＲＣに対し図１２に示されているようにビットＳＣＲＣ８〜ＳＣＲＣ０として、フレーム６００２内に含まれている。９ビットを有する１つの可能なＣＲＣチェックサムは、生成多項式ｘ８＋ｘ５＋ｘ４＋ｘ３＋１を有する既知のＤＡＲＣ−８  ＣＲＣである。５ビットのＣＲＣチェックサムを用いてもよく、これによればいくらか安全性（ハミング距離ＨＤ）が小さくなる。ビットＳＣＲＣ８〜ＳＣＲＣ０には、生成多項式により求められた、フレーム６００２内のスタッフビットの計数値に関するチェックサムの値が含まれている。このようにすることによっても、たとえばエラータイプＡとＢとが同時に発生したときに、ダメージを受けたフレーム６００２を確実に検出することができる。
【０１０８】
以下の表３には、既述の種々の解決手段の概観が示されている。ＣＲＣフィールドの全長は、ＣＲＣの長さと、スタッフビットカウンタの長さと、付加的な安全保護情報の長さと、挿入された固定スタッフビットの個数とから生じる。ここで“ＳＣ”はスタッフビットカウントまたはスタッフビットカウンタを表し、“ｆ．ｓ．”は固定スタッフビットを表す。
【０１０９】
【表２】
0006324618.tif 000003
【０１１０】
この場合、表３の解決手段番号１は、第１の実施例に対応する。表３の解決手段番号２は、第４の実施例に対応する。表３の解決手段番号３は、５ビットＣＲＣによる第５の実施例の１つのバリエーションに対応する。表３の解決手段番号４は、９ビットＣＲＣによる第５の実施例のさらに別のバリエーションに対応する。
【０１１１】
バスシステム１、加入者局１０，２０，３０および方法に関する既述のすべての実施形態は、個々にまたはあらゆる可能な組み合わせとして、適用することができる。特に、既述の実施例のすべての特徴を、任意に組み合わせたり省いたりすることができる。この点に加え、特に以下の変形を考えることができる。
【０１１２】
これまで実施例による既述のバスシステム１を、ＣＡＮ  ＦＤプロトコルをベースとするバスシステムに基づいて説明してきた。ただし実施例によるバスシステム１を、他の種類の通信ネットワークとしてもよい。ここで有利には、ただし必須ではないが前提となるのは、バスシステム１において少なくとも特定の期間にわたり、１つの共通のチャネルへの加入者局１０，２０，３０による排他的でコリジョンのないアクセスが保証されている、ということである。
【０１１３】
この実施例およびその変形実施例のバスシステム１における加入者局１０〜３０の個数と配置は、任意である。特に、加入者局１０または２０または３０だけが、バスシステム１内に設けられているようにしてもよい。さらに加入者局１０〜３０を、バスシステム１内で任意に組み合わせることができる。
【０１１４】
安全保護装置１２，２２，３２を、これらの装置について図１に示した構成ではなく、それぞれ属する通信装置１１，２１，３１内に設けてもよい。また、１つまたは複数のこのような加入者局を、加入者局１０，２０，３０の代わりに、またはこれらの加入者局１０，２０，３０に加えて、これらの加入者局１０，２０，３０と任意に組み合わせて、バスシステム１に設けてもよい。
【図１】
0006324618.tif 000004
【図２】
0006324618.tif 000005
【図３】
0006324618.tif 000006
【図４】
0006324618.tif 000007
【図５】
0006324618.tif 000008
【図６】
0006324618.tif 000009
【図７】
0006324618.tif 000010
【図８】
0006324618.tif 000011
【図９】
0006324618.tif 000012
【図１０】
0006324618.tif 000013
【図１１】
0006324618.tif 000014
【図１２】
0006324618.tif 000015