JP5902799B2 - 直列バスシステム内でデータ伝送の信頼性を調整するための方法及び装置 - Google Patents

Description

本発明は、直列バスシステム内の少なくとも２つの加入者間のデータ伝送の信頼性を調整するための方法及び装置に関する。

例えば、ファミリ規格ＩＳＯ１１８９８−１〜５には、以下で規格ＣＡＮと呼ばれる、「コントローラ・エリア・ネットワーク」（ＣＡＮ：Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）及び「タイム・トリガ型ＣＡＮ」（ＴＴＣＡＮ：Ｔｉｍｅ Ｔｒｉｇｇｅｒｅｄ ＣＡＮ）と呼ばれるＣＡＮの拡張版が記載されている。ＣＡＮで利用される媒体アクセス制御方法は、ビットごとのアービトレーションに基づいている。ビットごとのアービトレーションの場合は、複数の加入者局がバスシステムのチャネルを介してデータを同時に伝送することが可能であり、これにより、データ伝送が妨げられることはない。さらに、加入者局は、チャネルを介したビットの送信の際に、当該チャネルの論理的状態（０又は１）を定めることが出来る。送信されるビットの値が、チャネルの定められた論理的状態と一致しない場合には、加入者局はチャネルへのアクセスを終了する。ＣＡＮの場合、ビットごとのアービトレーションは通常、チャネルを介して伝送されるメッセージ内の識別子を用いて行われる。加入者局が識別子を完全にチャネルに送信した後で、当該加入者局は、自身がチャネルに対する排他的アクセス権を有することが分かる。従って、識別子の伝送の終わりは、加入者局がチャネルを排他的に利用できる許可区間の始まりに相当する。ＣＡＮのプロトコル仕様によれば、他の加入者局は、送信加入者局がメッセージの検査フィールド（ＣＲＣフィールド）を伝送してしまうまでチャネルにアクセスしてはならず、即ち、チャネルにデータを送信してはならない。従って、ＣＲＣフィールドの伝送の終了時点は、許可区間の終了に相当する。

ビットごとのアービトレーションによって、チャネルを介した、アービトレーションに勝ったメッセージの破壊されない伝送が達成される。ＣＡＮプロトコルは、特に、実時間条件下で短いメッセージを伝送するのに適しているが、その際に、識別子の適切な割り当てによって、特に重要なメッセージが、ほぼ常にアービトレーションに勝ち、送信が成功することが保証される。

近代的な車両が益々ネットワーク化され、例えば走行時の安全性又は走行時の快適性を改善するために追加的なシステムが組み込まれるにつれて、伝送されるデータ量、及び、伝送時に許容される遅延時間に対する要請が大きくなる。例としては、例えばＥＳＰ（横滑り防止プログラム）のような走行ダイナミクス制御システム、例えばＡＣＣ（自動間隔制御）のような運転者支援システム、又は、例えば交通標識検出のような運転者情報システムが挙げられる（例えば、Ｖｉｅｗｅｇ＋Ｔａｕｂｎｅｒによる「ボッシュ自動車ハンドブック」、２０１１年、第２７版を参照されたい）。

独国特許出願公開第１０３１１３９５号明細書には、非対称な直列通信を、代替的に非対称な物理的なＣＡＮプロトコルを介して、又は、対称的な物理的ＣＡＮプロトコルを介して行うことが可能なシステムが記載されており、これによって、非対称な通信のためのより高いデータ伝送レート又はデータ伝送の信頼性が実現されうる。

独国特許出願公開第１０２００７０５１６５７号明細書は、伝送するデータ量を増大させるために、ＴＴＣＡＮプロトコルの排他的なタイムスロットにおいて、ＣＡＮに準拠しない非対称で高速のデータ伝送を利用することを提案している。

Ｇ．ＣｅｎａとＡ．Ｖａｌｅｎｚａｎｏは、「Ｏｖｅｒｃｌｏｃｋｉｎｇ ｏｆ ｃｏｎｔｒｏｌｌｅｒ ａｒｅａ ｎｅｔｗｏｒｋｓ」（Ｅｌｅｃｔｒｉｃｓ Ｌｅｔｔｅｒｓ、Ｖｏｌ．３５、Ｎｏ．２２（１９９９）、Ｓ．１９２４）で、効率良く獲得されるデータレートに対する、メッセージの部分範囲内のバス周波数のオーバークロックの作用について論じている。データ伝送の信頼性の調整には触れていない。

先行技術は、あらゆる点で満足できる結果を提供しないことが分かる。

以下では、本発明及びその利点が、図面と実施例によって記載される。本発明の主題は、提示され記載される実施例に限定されない。

本発明は、少なくとも２つの関与するデータ処理ユニットを備えたバスシステム内での、ＣＡＮ規格ＩＳＯ１１８９８−１に準拠した論理構造を有するメッセージの伝送から出発し、その際に、論理構造は、スタートオブフレームビット（Ｓｔａｒｔ−ｏｆ−Ｆｒａｍｅ−Ｂｉｔ）、アービトレーションフィールド（Ａｒｂｉｔｒａｔｉｏｎ Ｆｉｅｌｄ）、コントロールフィールド（Ｃｏｎｔｒｏｌ Ｆｉｅｌｄ）、データフィールド（Ｄａｔａ Ｆｉｅｌｄ）、ＣＲＣフィールド、アクノリッジフィールド（Ａｃｋｎｏｗｌｅｄｇｅ Ｆｉｅｌｄ）、及び、エンドオブフレームシーケンス（Ｅｎｄ−ｏｆ−Ｆｒａｍｅ Ｓｅｑｕｅｎｚ）を含み、コントロールフィールドは、データフィールドの長さについての情報を含むデータ長コード（Ｄａｔａ Ｌｅｎｇｔｈ Ｃｏｄｅ）を含む。

本発明は、伝送されるメッセージのＣＲＣフィールドが、少なくとも２つの異なるビット数を有することが可能であり、及び、データ長コードの少なくとも１つの有効な値について、ＣＡＮ規格ＩＳＯ１１８９８−１から外れるビット数を有し、及び、規格とは異なるビット数を有するＣＲＣフィールドの内容を設定するために、ＣＲＣ規格ＩＳＯ１１８９８−１から外れた少なくとも１つの生成多項式が利用されることで、伝送される特定のメッセージについて、チェックサムの計算のための変更された多項式を利用し、ＣＡＮ規格から外れた大きさを有するＣＲＣフィールドを伝送するという可能性を提供する。これには、より大きなデータ量が伝送される際にもエラー検出の信頼性が保持されるという利点がある。

特に有利な実施形態において、メッセージの開始に際して、複数のＣＲＣチェックサムの計算が平行して開始され、データ長コードの内容に従って、上記ＣＲＣ計算のうちのどの結果が利用され、又は、ＣＲＣフィールドで伝送されるのかが決定される。これにより、規格に準拠した方法に従って又は本発明に係る変更された方法に従ってメッセージが伝送されるのかについての情報を、メッセージと共に送信することが可能であり、その際に、受信者に前もって利用される方法が報知されることはない。正しいデータ伝送であるかを検査するためのチェックサムが、２つの方法のために存在し、必要に応じて評価されうる。

有利な実施形態は、伝送されるメッセージのデータフィールドを拡大するという可能性を提供することにより、規格に準拠したＣＡＮメッセージに対して、より大きなデータ量を１つのメッセージでバスを介して伝送しうるという効果を達成する。従って、有利に、メッセージ内での制御情報に対するデータ量の割合が増し、従って、バスシステムを介した中程度のデータ伝送レートも上がる。

データ長コードの内容とデータフィールドの長さとの間の一意の対応付けを作成することによって、有利に、データフィールドの提示可能な大きさに関して高いフレキシビリティが達成される。

さらに、規格ＣＡＮで通常利用されるデータ長コードの値０ｂ０００１〜０ｂ１０００について、規格ＣＡＮに対応するデータフィールドの大きさ、即ち、１バイト〜８バイトが割り当てられ、データ長コードの残りの値は、最大可能な大きさに至るまでのデータフィールドの更なる別の許容される大きさのために利用されることは有利である。このことにより、本発明に係る方法に切り替える際のアプリケーションソフトウェアの調整費用が、コストを削減する形で下げられる。

さらに、メッセージ内のＣＲＣフィールドの前に現れる、場合により存在するスタッフビットが、チェックサムの計算に考慮されることは有利である。これにより、データ伝送の信頼性、又は、データ伝送エラーの検出確率がさらに改善される。

本発明を、例えば、少なくともデータフィールド及びＣＲＣフィールドのビットについて、ビット長の切り替えと更に組み合せる場合には、データフィールドを８バイトに制限した際よりも、より大きなデータ量を加速させて伝送するという更なる別の利点が達成される。これにより、バスシステムの中程度のデータ伝送レートが更に上げられる。この場合に、有利な発展形態において、ビット長が短縮されたメッセージの標識は、コントロールフィールド内の標識ビットにより与えられる。これにより、ビット長の切り替えは、ＣＲＣ演算の切り替え又はデータフィールドの大きさの切り替えに依存せずに行うことが可能であり、バスシステムの状態に対してフレキシブルに応答することが可能である。

本方法は有利に、車両の通常駆動において、適切なデータバスを介して接続された、車両の少なくとも２つの制御装置の間でデータを伝送するために利用することが可能である。しかしながら、有利に車両の製造又は保守の間にも同様に、プログラミングを目的として適切なデータバスと接続されたプログラミングユニットと、データバスと接続された車両の少なくとも１つの制御装置と、の間でデータを伝送するために利用することが可能である。同様に有利に、例えば制御を目的としてより大きなデータ量を伝送する必要がある場合には、本発明を産業分野でも利用することが可能である。特に、全ての加入者がバスへのアクセス権を獲得しうるように、伝送区間の長さに基づき、アービトレーションの間低減されたデータレートを利用しなければならない場合には、本方法によって、特に、データフィールドの長さの切り替え及びビット長の短縮との組み合わせによって、より高いデータ伝送レートを実現することが可能である。

更なる別の利点は、本発明に基づいて機能しうるために、規格ＣＡＮコントローラは最小限に変更されればよいということである。規格ＣＡＮコントローラとしても機能しうる本発明に係る通信コントローラは、従来の規格ＣＡＮコントローラよりも僅かに大きい。付属するアプリケーションプログラムを変更する必要はなく、既にデータ伝送の速度の点で利点が実現される。

有利に、ＣＡＮのコンフォーマンステスト（ＣＡＮ−Ｃｏｎｆｏｒｍａｎｃｅ−Ｔｅｓｔ）（ＩＳＯ１６８４５）の多大な部分が引き継がれる。有利な発展形態において、本発明に係る伝送方法を、ＴＴＣＡＮ（ＩＳＯ１１８９８−４）を補完したものと組み合わせることが可能である。

以下では、本発明が図面によってより詳細に解説される。
従来技術によるＣＡＮ規格ＩＳＯ１１８９８−１に準拠したＣＡＮフォーマットによるメッセージの構造の２つの選択肢を示す。 本発明に基づき変更されたメッセージのフォーマットの２つの類似した選択肢を示す。 本発明に基づいてどのようにＣＡＮ規格ＩＳＯ１１８９８−１から外れてデータ長コードの内容を解釈しうるかという様々な可能性を示す。 バスシステムの加入者局での本発明に係る受信プロセスの一実施例を概略的に示す。 バスシステムの加入者局での本発明に係る受信プロセスの他の実施例を概略的に示す。 追加的にメッセージ内の設定された範囲内で異なるビット長が利用される、本発明に基づき変更されたメッセージのフォーマットの２つの例を示す。 データフィールドの大きさ及びビット長の切り替えのために異なるビットが利用され、更にコントロールフィールド内に追加的なビットが収容される、本発明の他の実施例に係る本発明に基づき変更されたメッセージのフォーマットについての２つの選択肢（標準型／拡張型）を示す。 バスシステムの加入者局で実行される、本発明の同実施例に対して調整された受信プロセスを示す。

図１ａには、メッセージの構造、即ち、メッセージがＣＡＮバス上でデータ伝送のためにどのように利用されるのか示されている。２つの異なるフォーマット、即ち「標準型」（Ｓｔａｎｄａｒｄ）及び「拡張型」（Ｅｘｔｅｎｄｅｄ）が示されている。本発明に係る方法は、２つのフォーマットで同じように適用することが可能である。

メッセージは、メッセージの開始をシグナリングする「スタートオブフレーム（ＳＯＦ：Ｓｔａｒｔ ｏｆ Ｆｒａｍｅ）」ビットで始まる。この後に、まず第１にメッセージの識別のために役立つ区間が続き、この区間によって、バスシステムの加入者は、自身がメッセージを受信するか否かを決定する。この区間は「アービトレーションフィールド」（Ａｒｂｉｔｒａｔｉｏｎ Ｆｉｅｌｄ）と呼ばれ、識別子を含んでいる。この後に、特にデータ長コード（Ｄａｔａ Ｌｅｎｇｔｈ Ｃｏｄｅ）を含む「コントロールフィールド」（Ｃｏｎｔｒｏｌ Ｆｉｅｌｄ）が続く。データ長コードは、メッセージのデータフィールドの大きさについての情報を含んでいる。これに続いて、バスシステムの加入者間で交換されるデータを含む本来の「データフィールド」（Ｄａｔａ Ｆｉｅｌｄ）が続く。その後に、１５ビット長を含むチェックサム（Ｃｈｅｃｋｓｕｍｍｅ）及びデリミタ（Ｄｅｌｉｍｉｔｅｒ）を有する「ＣＲＣフィールド」と、これに続いて、送信者宛てのメッセージの受信の成功をシグナリングする役目を果たす２つの「アクノリッジ（ＡＣＫ：Ａｃｋｎｏｗｌｅｄｇｅ）ビット」と、が続く。メッセージは、「エンドオブフレーム」（ＥＯＦ：Ｅｎｄ ｏｆ Ｆｒａｍｅ）シーケンスで終わる。

規格に準拠したＣＡＮデータ伝送方法では、データフィールドは最大で８バイト、即ち６４ビットのデータを含んでもよい。データ長コードは規格に従って４ビットを含み、即ち、１６個の様々な値を取ることが可能である。今日のバスシステム内ではこの値の範囲から、１バイトから８バイトまでの様々な大きさのデータフィールドのために、８個の様々な値が利用される。０バイトのデータフィールドは、ＣＡＮ規格では推奨されておらず、８バイトを上回る大きさは許容されていない。データフィールドの大きさに対するデータ長コードの値の割り当てが、図２のＣＡＮ規格の欄に示されている。

図１ｂには、２つの規格フォーマットからそれぞれ得られた本発明に基づき伝送される変更されたメッセージが、類似した図で対比されている。

本発明に係る変更された伝送方法では、データフィールドは８バイトを超えてもよく、即ち示される仕様ではＫバイトまで含んでもよい。規格ＣＡＮとは異なって、より大きなデータフィールドに標識を付けるために、データ長コードが取りうる更なる別の値が利用される。例えば、０〜１５バイトまでの値を示すために、データ長コードの４ビットを利用することが可能である。しかしながら、他の割り当てを行うことも可能であり、例えば、今日のＣＡＮメッセージでは通常利用されないデータ長コードの値ＤＬＣ＝０ｂ００００を、データフィールドの更なる別の可能な大きさ、例えば１６バイトの大きさのために利用することが可能である。この２つの可能性が、図２の表ではＤＬＣ１及びＤＬＣ２として示されている。この場合、データフィールドの最大値Ｋは、値１５又は１６を有する。

更なる別の可能性は、０ｂ１０００よりも大きい０ｂ１１１１までのデータ長コードの値について、データフィールドの対応する大きさが、例えば２バイトずつ大きくなることである。この場合が、表ではＤＬＣ３として示されている。データフィールドの最大値Ｋは、この変形例では値２４バイトに達する。例えば４バイトのより大きな増分を選択することによって、対応してより大きなデータフィールドを実現することが可能であろう。

さらに、ＤＬＣ３の例では、更なる別の修正が行われる。即ち、本実施例では、値ＤＬＣ＝０ｂ００００は、リモートフレーム（Ｒｅｍｏｔｅ Ｆｒａｍｅ）により利用される。これに対して、規格ＣＡＮでは、リモートフレームへの応答として送信されるメッセージが有する値と同じＤＬＣの値を有するリモートフレームが送信されることが構想される。ここで記載される変更によって、同じ識別子を有するが異なるＤＬＣを有するリモートフレームが送信できない（衝突が解消出来なくなる可能性がある、ＩＳＯ１１８９８−１、１０．８．８章参照）ことが保証される。

図２の表の欄ＤＬＣ１、ＤＬＣ２、及びＤＬＣ３に示される方法の発展形態において、１バイトから８バイトまでのデータフィールドの大きさに対する、データ長コードの値０ｂ０００１〜０ｂ１０００の割り当ては、規格ＣＡＮでの割り当てに対応している。これにより、簡単なやり方で、規格ＣＡＮに対する互換性を実現すること、即ち、通信コントローラが規格ＣＡＮバスシステム内では規格に準拠して動作し、本発明に基づき変更されたバスシステム内ではメッセージ内のより大きなデータ量を許容するように、通信コントローラを設計することが可能である。しかしながら、データフィールドの許容される大きさに対する、データ長コードの可能な値の割り当てを完全に新しく行うことも可能である。その一例が、同様に図２にＤＬＣ４として示されている。この場合、実現されるデータフィールドの最大値Ｋは３０バイトである。

このような通信コントローラが、自身がどのようにデータ長コードの内容を解釈したのか確認出来ることを保証するために、バスシステムの通信が規格ＣＡＮ又は本発明に係る方法に従って進行しているのかを、通信コントローラが自律的に検出出来ることは有利である。このための可能性は、アービトレーションフィールド又はコントロールフィールド内の予約ビットを標識付けのために利用することであり、この第１の標識Ｋ１から、通信コントローラは、自身がそれに従って伝送方法を選択する第１の切り替え条件ＵＢ１を導出することが可能である。例えば、図１ｂにおいてｒ０で示される、コントロールフィールドの第２ビットは、標識付けのために利用することが可能である。他の可能性は、規格ＣＡＮでは常にレセッシブで送信しなければならないがメッセージを受信するバス加入者によってはドミナントで受け取られるＳＲＲビットを利用することである。第１の切り替え条件ＵＢ１の確認のためにビットの組み合わせを評価することも可能である。

更なる別の可能性は、本発明に基づき変更される伝送方法のために、拡張フォーマットの利用を規定することであろう。拡張フォーマットによるメッセージは、バス加入者によって、ＩＤＥビットの値で検出され（図１ａ参照）、同時に、このＩＤＥビットが、第１の切り替え条件ＵＢ１であってもよいであろう。従って、拡張型メッセージのために常に、変更された伝送方法が利用される。代替的に、拡張型メッセージで、予約ビットｒ１を、第１の標識Ｋ１として利用し、又は、第１の切り替え条件ＵＢ１を導出するために利用することも可能であろう。しかしながら、予約ビットは、以下で詳細に述べるように、２つ以上の異なる大きさの間でデータフィールドを切り替えるため、又は、データ長コードの値とデータフィールドの大きさとの対応付けを切り替えるため、の第２の切り替え条件ＵＢ２を導出するためにも利用することが可能である。

しかしながら代替的に、本方法を、このために適した通信コントローラであって、規格ＣＡＮ通信のためにも設計されていない上記通信コントローラ内で利用することも可能である。この場合には、例えばメッセージの適切な標識Ｋ１に依存した、上述の第１の切り替え条件ＵＢ１の設定を省略することも可能である。この場合には、通信コントローラはむしろ、記載された方法の一方にのみ従って動作し、これに対応して、このような本発明に係る通信コントローラが使用されるバスシステム内でのみ使用可能である。この場合に、規格に準拠したメッセ―ジに対して、さもなければ本発明に係るメッセージに標識を付けるために利用されたビットを省略することが可能であり、又は、データ伝送方法に関して、通信の加入者によって無視される。

本発明で構想されるように、メッセージのデータフィールドが拡大される場合には、十分なフェイルセーフティ（Ｆｅｈｌｅｒｓｉｃｈｅｒｈｅｉｔ）を獲得するために、巡回冗長検査（ＣＲＣ：Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ）に対して利用される方法を調整することも有効でありうる。特に、例えばより高次の他のＣＲＣ多項式を利用し、これに対応して、本発明に基づき変更されたメッセージ内に、規格とは異なる大きさのＣＲＣフィールドを設けることは有利でありうる。このことが図１ｂで、示される例では本発明に係るメッセージのＣＲＣフィールドがＬビットの長さを有するということにより提示され、但し、ＬはＣＡＮ規格から外れて同じではなく、特に１５ビットよりも大きくてもよい。

ＣＲＣチェックサムを計算するための変更された方法の利用は、第３の切り替え条件ＵＢ３を表す第３の標識Ｋ３によって、バス加入者に対してシグナリングすることが可能である。しかしながら、上記標識Ｋ３及び第３の切り替え条件ＵＢ３は、第１の標識Ｋ１及び／又は切り替え条件ＵＢ１と一致していてもよい。この場合にも、上述のように、例えば、図１ｂの予約ビットｒ０が標識付けのために役に立ち、又は、ＳＲＲビットが利用されうる。拡張型メッセージでの本発明の適用と組み合わせた、又はｒ１ビットの適用と組み合わせたＩＤＥビットの利用も考察される。

規格ＣＡＮコントローラ内では、送信されるＣＡＮメッセージのＣＲＣ符号が、メッセージの直列に送信されたビットがその入力口に直列に供給されるフィードバックシフトレジスタによって生成される。シフトレジスタの幅は、ＣＲＣ多項式の次数に対応する。ＣＲＣ符号化（ＣＲＣ−Ｃｏｄｉｅｒｕｎｇ）は、シフト演算（Ｓｈｉｆｔ Ｏｐｅｒａｔｉｏｎ）の間の、レジスタ内容とＣＲＣ多項式との結合（Ｖｅｒｋｎｕｅｐｆｕｎｇ）によって行われる。ＣＡＮメッセージが受信される場合には、これに対応して、メッセージの直列に受信されたビットが、ＣＲＣシフトレジスタ内へとシフトされる。ＣＲＣ検査（ＣＲＣ−Ｔｅｓｔ）は、ＣＲＣフィールドの終りで、シフトレジスタの全ビットが０である場合には成功である。送信の場合のＣＲＣ符号の生成及び受信の場合のＣＲＣ検査は、両方ともハードウェア内で行われ、その際に、ソフトウェアの介入は必要ではない。即ち、ＣＲＣ符号化の変更は、アプリケーションソフトウェアに対して影響を与えない。

規格ＣＡＮプロトコルでは、ＣＡＮメッセージ内のスタッフビット（Ｓｔｕｆｆ−Ｂｉｔ）（ＩＳＯ１１８９８−１、１０．５章参照）は、ＣＲＣ符号の計算又は検査に含まれない（ＩＳＯ１１８９８−１、１０．４．２．６章：“ｔｈｅ ｂｉｔ ｓｔｒｅａｍ ｇｉｖｅｎ ｂｙ ｔｈｅ ｄｅｓｔｕｆｆｅｄ ｂｉｔ ｓｅｑｕｅｎｃｅ”（デスタッフビットシーケンスにより与えられるビットストリーム）参照）。これにより、ＣＲＣは本来、メッセージ内にランダムに分散するビットエラーを５個まで検出すべきであるにも関わらず、稀な場合にしかメッセージ内の２個のビットエラーも検出しないという結果になる。このことは、ビットエラーによって、スタッフビットがデータビットに変換され、又は、データビットがスタッフビットに変換される場合に起こりうる（Ｕｎｒｕｈ、Ｍａｔｈｏｎｙ、Ｋａｉｓｅｒ著「Ｅｒｒｏｒ Ｄｅｔｅｃｔｉｏｎ Ａｎａｌｙｓｉｓ ｏｆ Ａｕｔｏｍｏｔｉｖｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌｓ」、ＳＡＥ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｇｒｅｓｓ、Ｎｒ.９００６９９、Ｄｅｔｒｏｉｔ、ＵＳＡ、１９９０年参照）。

これに対して、本発明に基づき変更された伝送方法では、メッセージ内のスタッフビットもＣＲＣ符号の計算又は検査の際に含まれるように、ＣＲＣ符号化を変更することが可能である。即ち、本実施形態では、アービトレーションフィールド、コントロールフィールド、及び、データフィールドに属するスタッフビットが、巡回冗長検査（Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ）により保護されるデータの一部として処理される。ＣＲＣフィールドのスタッフビットは、規格ＣＡＮのようにマスクされる。

可能な実施形態において、通信コントローラは、規格ＣＡＮに対して互換性を有するように設計され、即ち、規格ＣＡＮバスシステム内で規格に準拠して動作するように設計されるが、本発明に基づき変更されたバスシステム内では、一方では、メッセージ内のより大きなデータフィールドを許容し、他方では、ＣＲＣ符号の、調整された計算及び検査も実行する。

メッセージの受信の開始時には、規格に準拠したＣＡＮメッセージ又は本発明に基づき変更されたメッセージが受信されるのかが未だに確定していないため、本発明に係る通信コントローラには、平行して動作する２つのＣＲＣシフトレジスタが実装される。ＣＲＣデリミタの受信後に、受信者のところでＣＲＣ符号が評価される場合には、本発明に係る第３の標識Ｋ３に基づいて、又は、例えば標識若しくはデータ長コードの内容から導出される第３の切り替え条件ＵＢ３に基づいて、どの伝送方法が利用されたのかが確定され、その後で、上記利用された伝送方法に対応付けられたシフトレジスタが評価される。第３の切り替え条件ＵＢ３は、先に既に示したように、データフィールドの大きさ及びデータ長コードの解釈に関する第１の切り替え条件ＵＢ１と一致していてもよい。

メッセージ送信の開始時には、送信者のために、どの伝送方法に従って送信されるのかが既に確定している。しかしながら、バスアクセスを巡るアービトレーションが失われ、開始されたメッセージが送信されず、その代わりに他のメッセージが受信されることが起こりうるため、この場合にも、２つのＣＲＣシフトレジスタが平行して駆動される。

平行して動作する２つのＣＲＣレジスタの上記実装によって更なる改善も可能となり、即ち、規格ＣＡＮプロトコルのＣＲＣ多項式（ｘ１５＋ｘ１４＋ｘ１０＋ｘ８＋ｘ７＋ｘ４＋ｘ３＋ｘ１）が、１２７ビットより小さいメッセージ長のために設計される。本発明に基づき伝送されるメッセージが、より長いデータフィールドも利用する場合には、伝送信頼性を保つために、特により長い他のＣＲＣ多項式を利用することが有効である。本発明に基づき伝達されるメッセージはこれに対応して、変更された、特により長いＣＲＣフィールドを獲得する。駆動中に、通信コントローラは、各適切な多項式を利用するために、２つのＣＲＣシフトレジスタ、即ち、規格ＣＡＮに準拠したシフトレジスタと本発明に係るシフトレジスタとを動的に切り替える。

当然のことながら、データフィールドの長さ又は所望の伝送信頼性に従って、２つより多いシフトレジスタ、及びこれに対応して、２つより多いＣＲＣ多項式を段階的に使用することも可能である。この場合には、規格ＣＡＮに対する互換性が保たれる限りにおいて、対応する標識及びこれと関連する切り替え条件を調整する必要がある。例えば図２のＤＬＣ１に係る、より長いデータフィールドへの切り替え、及び、対応する第２のＣＲＣ多項式を特徴とする第１の切り替え条件ＵＢ１を、図１ｂの予約ビットｒ０又はＳＲＲビットによって例えば起動することが可能であろう。拡張フォーマットによるメッセージについては追加的に、例えば図１ｂの予約ビットｒ１又はＩＤＥビットによって（第２の標識Ｋ２）、データフィールドの大きさの更なる別のセット、例えば図２のＤＬＣ３への切り替え、及び、第３のＣＲＣ多項式を特徴とする第２の切り替え条件ＵＢ２を起動することが可能であろう。

第１の切り替え条件ＵＢ１が、例えば予約ビットｒ０又はＳＲＲビットによって、可能なより長いデータフィールド、及び、データ長コードの内容の対応する解釈へと切り替えること、並びに、第３の切り替え条件ＵＢ３の決定及びこれに関連するＣＲＣ検査のために評価されるＣＲＣ多項式の選択が、データ長コードの内容に従って行われることも通常では可能である。第３の切り替え条件ＵＢ３は、これに対応して、２つよりも多い値を取ることも可能である。例えば、ＤＬＣ３に係るデータフィールドの大きさを選択し、即ち、０（リモートフレームのため）、１、・・・、８、１０、１２、１４、１６、１８、２０、及び２４バイトの値を取ることが可能であろうし、その場合には、適切なシフトレジスタを介して、３つのＣＲＣ多項式を平行して計算し、例えば、８バイトまでのデータフィールドのための規格ＣＲＣ多項式、１６バイトまでのデータフィールドのための第２のＣＲＣ多項式、及び、２４バイトまでのデータフィールドのための第３のＣＲＣ多項式を平行して計算することが可能であろう。

図３は、本発明に係る受信プロセスの一部、即ち、受信プロセスがどのようにバスシステムの加入者局で進行するのかを簡素化した図で示している。ここでは、第１の切り替え条件ＵＢ１に従って通信コントローラの挙動が調整されることにより、規格ＣＡＮに対する互換性が実現される場合が示される。図３では、ソフトウェア内でのプログラムシーケンスを記載するために一般的な図が選択されたが、本方法は、ハードウェア内での実装のために完全に適している。示されるシーケンスは、上述のとおりの切り替え条件、例えば、切り替え条件ＵＢ１が省略される実施形態のためにも適用することが可能である。しかしながら、受信プロセスは、さもなければ対応する切り替え条件に従って進行する経路のうちの１つのみが実際に進行する限りにおいて、簡略化される。ここでは、このような簡素化されたフローチャートを他に示さない。

加入者局は最初に、バス上に通信トラフィックが無い限り、バスをサンプリングする状態にある。即ち、問い合わせ３０２は、バス上のドミナントビットを待つ。このドミナントビットは、新しいメッセージの開始を表す。

新しいメッセージの開始が確認され次第、ブロック３０４において、平行して計算される少なくとも２つのチェックサムの計算が開始される。第１のチェックサムは、規格ＣＡＮのＣＲＣ演算に対応し、第２のチェックサムは、新しい方法に従って計算される。第２のチェックサムの計算の際には、示される実施例ではスタッフビットが含められるが、規格ＣＡＮに従った計算ではスタッフビットは含まれない。しかしながら、規格ＣＡＮと同様に、スタッフビットを、第２のチェックサムの計算のために考慮しないということも可能である。

引き続いて、ステップ３０６から、メッセージのＳＯＦビットの後に続く、アービトレーションフィールドで始まる更なる別のビットが受信される。複数のバス加入者がメッセージを送信したい場合には、ここで、規格ＣＡＮで一般的な方法に従ってバス加入者の間で、どの加入者がバスへのアクセス権を獲得するかについて調停が行われる。示されるブロック３０６は、第１の標識Ｋ１が受信されてしまうまで又は第１の切り替え条件ＵＢ１が確定するまでの、全ビットの受信を表す。記載される例では、第１の切り替え条件ＵＢ１は、アービトレーションフィールドから、例えば、ＳＲＲビット若しくはＩＤＥビットから、又は、コントロールフィールドから、例えばコントロールフィールドの予約ビットから定められる（図１参照）。引き続いて、ブロック３０８において、メッセージの特定ビット以降、定められた第１の切り替え条件ＵＢ１に従って様々に処理されるまで、メッセージの更なるビットが受信されうる。様々な処理形態によるこの分割は、以下で例示するように、対応する問い合わせ又は分岐３１０によって保証される。

分岐３１０で、例えばコントロールフィールドの最初の２ビットの受信後に、第１の切り替え条件ＵＢ１に従って通信が規格ＣＡＮに準拠して行われる（図３の「１」で示された経路）という情報が存在する場合には、ステップ３１２において、コントロールフィールドの更なる別のビットが読み込まれる。この更なる別のビットから、規格ＣＡＮに従ってデータ長コードが評価され、引き続いてステップ３１６で、対応するデータ量、即ち、データフィールドに対応した最大８バイトが受信される。その後ステップ３２０において、１５ビットを含むＣＲＣフィールドが受信される。分岐３２４で、送信者により伝達されたＣＲＣチェックサムと、受信者自身により定められたＣＲＣチェックサムとが一致するという情報が存在する場合には、ブロック３２８で、ドミナントなアクノリッジビット（Ａｃｋｎｏｗｌｅｄｇｅ−Ｂｉｔ）が送信される。この場合には、通信が規格ＣＡＮに従って行われるため、規格に準拠したＣＲＣチェックサムが比較されるということに注意されたい。一致が確認されない場合には、（ブロック３３０で）アクノリッジビットがレセッシブで送信される。この後に、ＡＣＫデリミタ（ＡＣＫ Ｄｅｌｉｍｉｔｅｒ）、及び、ＥＯＦビットが続く（図１ｂを参照、図３には図示されない）。

これに対して、分岐３１０で、例えばコントロールフィールドの最初の２ビットの受信後に、第１の切り替え条件ＵＢ１に従って本発明に基づき変更された通信方法が利用されるという情報が存在する場合には（図３の「２」で示された経路）、ブロック３１４において、コントロールフィールドの更なる別のビットが読み込まれる。この結果から、データ長コードが、図２の表で幾つかの例について記載した新しい解釈に従って定められる。ブロック３１８で、対応するデータ量、即ち、図２の表の例ＤＬＣ１については１５バイトまで、例ＤＬＣ２については１６バイトまで、例ＤＬＣ３については２４バイトまで、例ＤＬＣ４については３０バイトまでのデータが受信される。ブロック３２２で、本発明に基づき異なる、特により長いＣＲＣフィールドが受信される。分岐３２４で、送信者に伝達されたＣＲＣチェックサムと受信者自身により定められたＣＲＣチェックサムとが一致するという情報が存在する場合には、この場合上記比較は本発明に基づき異なるＣＲＣチェックサムに基づいているのだが、ブロック３２８で、ドミナントなアクノリッジビットが送信される。送信者に伝達されたＣＲＣチェックサムと受信者自身により定められたＣＲＣチェックサムとが一致しない場合には、（ブロック３３０で）アクノリッジビットがレセッシブで送信される。引き続いて、ステップ３３２又は３３４において、ＡＣＫデリミタ及びＥＯＦビットが続く。これで、メッセージのための受信プロセスが終了する。

図３では、利用されるＣＲＣを決定する第３の切り替え条件ＵＢ３が、データフィールドの大きさ及びデータ長コードの解釈に関する第１の切り替え条件ＵＢ１と一致する場合が示された。即ち、ＣＲＣチェックサムの受信３２０又は３２２の前に、どのＣＲＣが第３の切り替え条件ＵＢ３に従って受信されて分岐３２４のために評価されるのかについて、問合せが再度行われなかった。図３のフロー図を簡単に変更することにより、図４に示すように、この追加的な問合せをシーケンスに組み込むことが可能である。

このように変更された図４の受信プロセスでは、ブロック３１６若しくは３１８での、データ長コードの情報に従って予期されるデータフィールドのデータバイト数の受信後に、問い合わせ又は分岐４１０において、第３の切り替え条件ＵＢ３がどの値を有するのかが定められる。この情報は、先に記載したように、例えば、対応する第３の標識Ｋ３又はデータ長コードの内容から定めることが可能である。示される例では、第３の切り替え条件ＵＢ３のために３つの異なる値、即ちＡ、Ｂ、及びＣが存在する。その後、切り替え条件ＵＢ３の値に従って、ブロック４２０、４２２、及び４２４において、ＣＲＣフィールドの様々なビット数が読み込まれ、例えば、値Ａについては１５ビット、値Ｂについては１７ビット、値Ｃについては１９ビットが読み込まれる。引き続いて、図３と同様に分岐３２４で、送信者により伝達されたＣＲＣチェックサムと、受信者自身により定められたＣＲＣチェックサムとが一致するかが検査され、これに従って更に処理される。

図５は、本発明に係る伝送方法の更なる別の実施例について、２つの可能なバリエーション、即ち、標準フォーマットによるメッセージ及び拡張フォーマットによるメッセージの構造を再度示している。図５には、２つのバリエーションについて、ここではファストＣＡＮアービトレーション（Ｆａｓｔ−ＣＡＮ−Ａｒｂｉｔｒａｔｉｏｎ）、ファストＣＡＮデータ（Ｆａｓｔ−ＣＡＮ−Ｄａｔａ）と呼ばれる２つの状態の間で切り替えられる範囲が示されている。本例では、この２つの状態の切り替えによって、アービトレーションの終了後に、メッセージの一部について、特にデータフィールド及びＣＲＣフィールドについてビット長が短縮され、個々のビットがより速くバスを介して伝送される。これにより、規格に準拠した方法に対して、メッセージの伝送時間を短縮することが可能である。これに伴う時間的ビット長の切り替えは、例えば、最小時間単位又は駆動中の発振器クロックに対して相対的にバス時間単位を調整するための、少なくとも２つの異なる倍率の利用によって実現することが可能である。ビット長の切り替え、及び、倍率の、対応する変更も同様に図５に例示されている。

状態ファストＣＡＮアービトレーションと状態ファストＣＡＮデータとの間の移行は、メッセージの第４の標識Ｋ４であって、短縮されたビット長が利用されることをデータ伝送の加入者に対してシグナリングする上記第４の標識に対応する第４の切り替え条件ＵＢ４に従って行われうる。ここで示される実施例では、選択されたこの標識Ｋ４の位置は、データ長コードの前に伝送される「予約ビット」ｒ０である。即ち、この位置は、第１の切り替え条件ＵＢ１に対応する第１の標識Ｋ１であって、より長いデータフィールド及びデータ長コードの変更された解釈の利用が可能であることを表す上記第１の標識Ｋ１の可能な位置、及び、変更されたＣＲＣ演算に対応する第３の標識Ｋ３の可能な位置にも相当する。

ビット長が短縮された本発明に係るメッセージに標識を付けるための他の可能性が、図６に示されている。ここでは、データフィールドがより長くなりうるメッセージ（第１の標識Ｋ１に対応）、及び、変更されたＣＲＣ演算（第３の標識Ｋ３に対応）が、レセッシブなＥＤＬビット（拡張データ長）であって、規格ＣＡＮメッセージによりドミナントで伝送されるビットの場所に入り及び当該ビットを置換し、又は当該ビットを１ポジション分だけ後ろにずらす上記ＥＤＬビットによって標識付けされる。標準型のアドレス指定については、ＥＤＬビットは、コントロールフィールド内の２番目の位置に入り、当該２番目の位置に存在する常にドミナントなｒ０ビットを１ポジション分ずらす。拡張型のアドレス指定については、示される例では、ＥＤＬビットは、コントロールフィールドの１番目の位置に入り、及び、当該１番目の位置に存在する、規格ＣＡＮでは常にドミナントで伝送される予約ビットｒ１を置換する。ＥＤＬビットによる上記の標識付けは、先に記載した状況において省略することも可能であろう。

短縮されたビット長の利用を報知する（同様に任意の）更なる別の標識又は第４の標識Ｋ４は、ＥＤＬビットにより標識付けされた本発明に係るメッセージのコントロールフィールドへの、追加的なレセッシブなＢＲＳ（Ｂｉｔ Ｒａｔｅ Ｓｗｉｔｃｈ、ビットレート切り替え）ビットの挿入によって示される。ここで示される実施例では、ＢＲＳビットの位置は、コントロールフィールド内の４番目の位置（標準型のアドレス指定）又は３番目の位置（拡張型のアドレス指定）である。

メッセージは、「ＣＡＮ ＦＤファスト」（ＣＡＮ ＦＤ Ｆａｓｔ）という名称を有する。メッセージの２つの可能なアドレス指定のバリエーション、即ち、標準フォーマット及び拡張フォーマットについて、図６には、ファストＣＡＮアービトレーション、ファストＣＡＮデータと呼ばれる２つの状態の間で切り替えられる範囲が示されている。この２つの状態の切り替えによって、既に記載したように、メッセージの対応する部分についてビット長が短縮され、個々のビットがバスを介してより速く伝送される。これにより、規格に準拠した方法に対してメッセージの伝送時間を短縮することが可能である。状態ファストＣＡＮアービトレーションとファストＣＡＮデータとの間の移行は、第１又は第３の標識ＥＤＬを有するメッセージ内では、短縮されたビット長が利用されることをデータ伝送の加入者にシグナリングする第４の標識ＢＲＳに従って行われる。

示されるケースでは第１の標識ＥＤＬの後に第４の標識ＢＲＳが続いているが、本発明に係る伝送方法において、そのビット長が明らかに短く、そのデータフィールドの大きさが８バイトを上回る値に拡張可能であり、そのＣＲＣがより大きなデータフィールドに対して調整されるメッセージが伝送される。このようにして、バスシステムを介する伝送容量の著しい増大と同時に、伝送信頼性の改善が達成される。

示される例では、より速い伝送は、対応する標識の送信直後に始まって、戻し切り替えのために設定されたビットに到達した直後に終わり、又は、エラーフレーム（Ｅｒｒｏｒ−Ｆｒａｍｅ）を開始する理由が検出された場合に終わる。

図７は、図３に対して変更された受信プロセスを示しており、この受信プロセスでは追加的に、第４の標識ＢＲＳに従って、状態ファストＣＡＮアービトレーションと状態ファストＣＡＮデータとの間で切り替えられる。分岐３１０で、例えばレセッシブなビットＥＤＬとしてのコントロールフィールドの第２ビットの受信後に、本発明に係る変更された通信方法が利用されるという情報が存在する場合には、ブロック４０８において、コントロールフィールドの直近のビットが読み込まれる。第２の標識として役立つビット、例えば、本発明に基づき拡張されたコントロールフィールドの、構想された値を有する第４のビットＢＲＳが、例えばレセッシブで受信される場合には、例えばＢＲＳビットのサンプルポイント（Ｓａｍｐｌｅ Ｐｏｉｎｔ）で、状態ファストＣＡＮデータに入り、即ち、短縮されたビット長に切り替えられる（経路「Ｃ」）。当該ＢＲＳビットが反対の値、即ちこの場合ではドミナントな値を有する場合には、ビット長の短縮は行われない（経路「Ｂ」）。ブロック４１２又は４１４で、データ長コードを含むコントロールフィールドの残りのビットの受信、及び、データ長コードからの大きさ情報に係るデータフィールドの受信が行われる。ブロック４１２では、通常のビット長で受信され、ブロック４１４では短縮されたビット長で受信される。ブロック４１６又は４１８では、本発明に基づき異なる、特により長いＣＲＣフィールドが読み込まれる。ブロック４１８において、ＣＲＣフィールドの最後のビット、即ちＣＲＣデリミタで、通常のビットレートによる状態ファストＣＡＮアービトレーションへと再び切り替えられる。引き続いて、図３と同様に分岐３２４で、送信者により伝達されたＣＲＣチェックサムと、受信者自身により定められたＣＲＣチェックサムとが一致するかが検査され、これに従って、図３で既に示したように、更なる処理が行われる。

実現されるデータレートに鑑みてデータフィールドの大きさが変更されるという、ＤＬＣ３により示される方法の実施例と組み合わせた、図５に示した実施例の利用により、以下の計算が解説される。即ち、２４バイトのデータフィールドの長さ、１１ビットのアドレスを有する標準フォーマットによるデータフレーム、及び、５００ｋＢｉｔ／ｓのボーレートから出発する。さらに、倍率が「予約ビット」ｒ０の後で４倍に上げられると仮定する。この場合に、ビット長は、「予約ビット」ｒ０の後で、２マイクロ秒から０．５マイクロ秒に短縮される。本例で可能なスタッフビットを無視した場合に、データフレームごとに、通常のビット長の２７ビット（ＳＯＦ、識別子、ＲＴＲ、ＩＤＥ、ｒ０、ＡＣＫフィールド、ＥＯＦ、インタミッション（Ｉｎｔｅｒｍｉｓｓｉｏｎ））と、ビット長が短縮された２１２ビット（ＤＬＣ、データ、ＣＲＣ、ＣＲＣデリミタ）と、が伝送され、その際に、ここでは未だに１５ビットのＣＲＣから出発したが、本発明に基づいて、より長いＣＲＣと置換することも可能であろう。

任意の限定条件において、１６０マイクロ秒で２９３ビットの効率のよい伝送性能が獲得され、このことは、バス負荷が同じであると仮定した際の、変更されていない規格ＣＡＮ伝送に対して３．７倍上げられたデータ伝送レートに相当する。追加的に、プロトコルオーバーヘッド（Ｐｒｏｔｏｋｏｌｌ−Ｏｖｅｒｈｅａｄ）に対するユーザデータ（データフィールド）の割合が有利に動かされる。

本方法は、車両の通常運転における、適切なデータバスを介して接続された、車両の少なくとも２つの制御装置の間のデータ伝送のために適している。しかしながら、車両の製造又は保守の間の、プログラミング目的で適切なデータバスと接続されたプログラミングユニットと、データバスと接続された車両の少なくとも１つの制御装置と、の間のデータ伝送のためにも同様に有利に利用されうる。さらに、工業オートメーションにおいて、バスによって互いに接続された分散された制御ユニットであって、産業的な製造工程の流れを制御する上記制御ユニットの間で、例えば制御情報を伝送するために本発明を使用することも可能である。この分野では、非常に長いバス線も登場する可能性があり、アービトレーション段階の間バスシステムを、比較的長いビット長で、例えば、１６、３２、又は６４マイクロ秒で駆動することも特に有利である可能性があり、従って、バス信号が、アービトレーション過程の間、バスシステム全体で必要なだけ伝播されうる。続いて、上述のように、メッセージの一部について、中規模の伝送レートが小さくなり過ぎないようにするために、より短いビット長に切り替えることが可能である。

以上、本方法は、規格ＣＡＮコントローラが、本発明に基づき動作しうるために最小限に変更されればよいという点で卓越した伝送方法である。規格ＣＡＮコントローラとしても動作しうる本発明に係る通信コントローラは、従来の規格ＣＡＮコントローラより僅かに大きい。対応するアプリケーションプログラムを変更する必要はなく、既に、データ伝送速度の点で利点が実現される。データフィールドの拡張された大きさ、並びに、対応するＤＬＣ及びＣＲＣを利用することにより、データ伝送速度を更に上げることが可能であり、アプリケーションソフトウェアにおける調整は最小である。ＣＡＮコンフォーマンステスト（ＣＡＮ−Ｃｏｎｆｏｒｍａｎｃｅ−Ｔｅｓｔ）（ＩＳＯ１６８４５）の広範な部分を引き継ぐことが可能である。さらに、本発明に係る伝送方法と、ＴＴＣＡＮ（ＩＳＯ１１８９８−４）を補完したものと、を組み合わせることも可能である。

本発明についてのこれまでの記載においてＩＳＯ規格が引用された箇所では、対応するＩＳＯ規格の、出願時点で有効な各バージョンが従来技術として根底にある。

Claims (18)

1. バスを介してメッセージを送信または受信する少なくとも２つの関与するデータ処理ユニットを備えたバスシステム内での直列データ伝送のための方法であって、
   前記送信されるメッセージは、ＣＡＮ規格ＩＳＯ１１８９８−１に準拠した論理構造を有し、
   前記論理構造は、スタートオブフレームビット、アービトレーションフィールド、コントロールフィールド、データフィールド、ＣＲＣフィールド、アクノリッジフィールド、及びエンドオブフレームシーケンスを含み、
   前記コントロールフィールドは、前記データフィールドの長さについての情報を含むデータ長コードを含む、前記方法において、
   前記データ長コードのビットの値に従って、伝送されるメッセージの前記ＣＲＣフィールドは、少なくとも２つの異なるビット数を有し、
   前記メッセージの前記データフィールドは、ＣＡＮ規格ＩＳＯ１１８９８−１から外れて８バイトを超えることが可能であり、前記データフィールドの大きさを確認するために、前記データ長コードの値が、少なくとも部分的にＣＡＮ規格ＩＳＯ１１８９８−１から外れて解釈されることを特徴とする、方法。
2. 前記ＣＲＣフィールドのビットの値を設定するために、前記データ長コードのビットの値に従って、少なくとも２つの異なる生成多項式が利用されることを特徴とする、請求項１に記載の方法。
3. 前記データ長コードの少なくとも１つのビットの値について、前記ＣＲＣフィールド内の前記ビット数、及び、前記ＣＲＣフィールドのビットの値の設定のために利用される生成多項式は、ＣＡＮ規格ＩＳＯ１１８９８−１に対応することを特徴とする、請求項１又は２に記載の方法。
4. 前記ＣＲＣフィールド内の前記ビット数は、前記データ長コードのビットの値に従って導出され、前記ＣＲＣフィールド内の前記導出されたビット数に従って、前記受信のプロセスが調整されることを特徴とする、請求項１〜３のいずれか１項に記載の方法。
5. メッセージの開始に際して、少なくとも２つのＣＲＣチェックサムの計算が、異なる生成多項式を用いて平行して開始され、前記データ長コードのビットの値に従って、前記平行に開始されたＣＲＣチェックサムの計算のうちのどの結果が利用されるのかが決定されることを特徴とする、請求項１〜４のいずれか１項に記載の方法。
6. 前記平行して実行されるＣＲＣ演算のうちの少なくとも１つのＣＲＣ演算が実行される際に、前記ＣＲＣフィールドの前に存在する前記メッセージの区間内の、場合により存在するスタッフビットも考慮されることを特徴とする、請求項５に記載の方法。
7. 前記データ長コードのビットの、各可能な値の組み合わせが、前記データフィールドの許容される大きさの１つに割り当てられることを特徴とする、請求項１〜６のいずれかに記載の方法。
8. 前記データ長コードのビットの値は、前記関与するデータ処理ユニット内で、前記データフィールドの大きさを定めるために評価され、前記受信のプロセスが、前記データフィールドの大きさに対して調整されることを特徴とする、請求項１〜７のいずれか１項に記載の方法。
9. 前記データ長コードの値０ｂ０００１〜０ｂ１０００は、ＣＡＮ規格ＩＳＯ１１８９８−１に従った、１〜８バイトの前記データフィールドの大きさのために利用され、前記データ長コードの残りの値は、最大可能な大きさに至るまでの前記データフィールドの更なる別の許容される大きさのために利用されることを特徴とする、請求項１〜７のいずれか１項に記載の方法。
10. メッセージ内の時間的ビット長は、少なくとも２つの異なる値を取ることが可能であり、前記メッセージ内の少なくとも１つの設定可能な第１の範囲について、前記時間的ビット長は、約１マイクロ秒の予め設定された最小値よりも大きく又は当該最小値と等しく、前記メッセージ内の少なくとも１つの設定可能な第２の範囲内では、前記時間的ビット長は、前記第１の範囲と比べて低減された値を有することを特徴とする、請求項１〜９のいずれか１項に記載の方法。
11. メッセージ内の前記時間的ビット長の前記少なくとも２つの異なる値は、最小時間単位又は駆動中の発振器クロックに対して相対的なバス時間単位を調整するための、少なくとも２つの異なる係数を乗じることによって実現されることを特徴とする、請求項１０に記載の方法。
12. 前記メッセージ内の前記時間的ビット長が少なくとも２つの異なる値を取り得る前記メッセージは、前記コントロールフィールド内の標識によって検出可能であることを特徴とする、請求項１０又は１１に記載の方法。
13. 前記メッセージは、ＴＴＣＡＮ規格ＩＳＯ１１８９８−４に記載された方法に従って時間制御されて伝送されることを特徴とする、請求項１〜１２のいずれか１項に記載の方法。
14. バスを介してメッセージを送信または受信する少なくとも２つの関与するデータ処理ユニットを備えたバスシステム内での直列データ伝送のための装置であって、
    前記送信されるメッセージは、ＣＡＮ規格ＩＳＯ１１８９８−１に準拠した論理構造を有し、
    前記論理構造は、スタートオブフレームビット、アービトレーションフィールド、コントロールフィールド、データフィールド、ＣＲＣフィールド、アクノリッジフィールド、エンドオブフレームシーケンスを含み、
    前記コントロールフィールドは、前記データフィールドの長さについての情報を含むデータ長コードを含む、前記装置において、
    前記データ長コードのビットの値に従って、伝送される前記メッセージの前記ＣＲＣフィールドは、少なくとも２つの異なるビット数を有し、
    前記メッセージの前記データフィールドは、ＣＡＮ規格ＩＳＯ１１８９８−１から外れて８バイトを超えることが可能であり、前記データフィールドの大きさを確認するために、前記データ長コードの値が、少なくとも部分的にＣＡＮ規格ＩＳＯ１１８９８−１から外れて解釈されることを特徴とする、装置。
15. 前記装置は、手段によって、請求項２〜１３のいずれかに記載のデータ伝送方法を実施するよう構成されることを特徴とする、請求項１４に記載の装置。
16. 前記手段は、少なくとも２つの異なる生成多項式により前記ＣＲＣフィールドのビットの値を計算するために十分な数のシフトレジスタを備えることを特徴とする、請求項１５に記載の装置。
17. 車両の通常駆動において、データバスを介して接続された、前記車両の少なくとも２つの制御装置の間でデータを伝送するための、請求項１〜１３のいずれか１項に記載の方法。
18. 車両の製造又は保守の間に、プログラミングを目的としてデータバスと接続されたプログラミングユニットと、前記データバスと接続された前記車両の少なくとも１つの制御装置と、の間でデータを伝送するための、請求項１〜１３のいずれか１項に記載の方法。

Images