(57)【特許請求の範囲】
【請求項１】
バスを介してメッセージを受信又は送信する少なくとも２つの関与するデータ処理ユニットを備えたバスシステム内での直列データ伝送のための方法であって、
前記送信されるメッセージは、ＣＡＮ規格ＩＳＯ１１８９８−１に準拠した論理構造を有し、
前記論理構造は、スタートオブフレームビット、アービトレーションフィールド、コントロールフィールド、データフィールド、ＣＲＣフィールド、アクノリッジフィールド、エンドオブフレームシーケンスを含み、
前記コントロールフィールドは、前記データフィールドの長さについての情報を含むデータ長コードを含む、前記方法において、
伝送されるメッセージの前記データフィールドは、ＣＡＮ規格ＩＳＯ１１８９８−１から外れて８バイトを超えることが可能であり、
前記データフィールドの大きさを確認するために、前記データ長コードの値が、少なくとも部分的にＣＡＮ規格ＩＳＯ１１８９８−１から外れて解釈され、
前記データフィールドとアプリケーションソフトウェア（６４０）との間のデータ転送のために、少なくとも１つの一時メモリ（６２０）が設けられ、前記転送されるデータ量は少なくとも、前記データフィールドの大きさが、利用される前記一時メモリ（６２０）の大きさと異なる場合には、データフィールドと利用される一時メモリ（６２０）の大きさの違いに対応して調整されることを特徴とする、方法。
【請求項２】
前記データフィールドの大きさが、前記利用される一時メモリの大きさを上回る場合には、前記バスを介して受信されたメッセージの前記データフィールドから、前記一時メモリの大きさに対応するデータ量が、予め設定され又は予め設定可能な選択方法に従って選択されて、前記一時メモリへと転送されることを特徴とする、請求項１に記載の方法。
【請求項３】
前記データフィールドの大きさが、前記利用される一時メモリの大きさを上回る場合には、前記バスを介して送信されるメッセージの前記データフィールドには、前記一時メモリの内容が、前記メッセージの前記データフィールドの少なくとも１つの予め設定され又は予め設定可能な範囲内に記録され、前記データフィールドの残りの前記範囲は、予め設定され又は予め設定可能な方法に従って充填されることを特徴とする、請求項１又は２に記載の方法。
【請求項４】
前記バスを介して受信されたメッセージの前記データフィールドの大きさが８バイトよりも大きい際には、前記少なくとも１つの一時メモリを介して、前記データフィールドの予め設定され又は予め設定可能な８バイトが、前記アプリケーションソフトウェアへと渡されることを特徴とする、請求項１〜３のいずれか１項に記載の方法。
【請求項５】
前記バスを介して送信されるメッセージの前記データフィールドの大きさが８バイトよりも大きい際には、前記データフィールドの前記残りの範囲のビットが、予め設定され又は予め設定可能な値で充填されることを特徴とする、請求項３又は４に記載の方法。
【請求項６】
前記バスを介して送信されるメッセージの前記データフィールドの前記充填される範囲内の前記ビットは、ＣＡＮ規格ＩＳＯ１１８９８−１の規定に従って当該範囲にスタッフビットを挿入する必要がないように、充填されることを特徴とする、請求項３〜５のいずれか１項に記載の方法。
【請求項７】
前記データ長コードのビットの、各可能な値の組み合わせが、前記データフィールドの許容される大きさの１つに割り当てられることを特徴とする、請求項１〜６のいずれか１項に記載の方法。
【請求項８】
ＣＡＮ規格１１８９８−１から少なくとも部分的に外れて解釈されるデータ長コードに従って、前記受信のプロセスが前記データフィールドの大きさに対して調整されることを特徴とする、請求項１〜７のいずれか１項に記載の方法。
【請求項９】
前記メッセージの前記ＣＲＣフィールドは、少なくとも２つの異なるビット数を有することが可能であり、前記ＣＲＣフィールド内の有効な前記ビット数の少なくとも１つは、ＣＡＮ規格ＩＳＯ１１８９８−１から外れたビット数であり、前記外れたビット数を有するこのようなＣＲＣフィールドの内容を設定するために、ＣＡＮ規格ＩＳＯ１１８９８−１から外れた生成多項式が利用されることを特徴とする、請求項１〜８のいずれか１項に記載の方法。
【請求項１０】
メッセージ内の時間的ビット長は、少なくとも２つの異なる値を取ることが可能であり、前記メッセージ内の少なくとも１つの第１の予め設定可能な範囲について、前記時間的ビット長は、約１マイクロ秒の予め設定された最小値よりも大きく又は当該最小値と等しく、前記メッセージ内の少なくとも１つの第２の設定可能な範囲内では、前記時間的ビット長は、前記第１の予め設定可能な範囲と比べて低減された値を有することを特徴とする、請求項１〜９のいずれか１項に記載の方法。
【請求項１１】
メッセージ内の前記時間的ビット長の前記少なくとも２つの異なる値は、最小時間単位又は駆動中の発振器クロックに対して相対的なバス時間単位を調整するための、少なくとも２つの異なる倍率を利用することによって実現されることを特徴とする、請求項１０に記載の方法。
【請求項１２】
前記メッセージ内の前記時間的ビット長が少なくとも２つの異なる値を取り得る前記メッセージは、前記コントロールフィールド内の標識によって検出可能であることを特徴とする、請求項１０又は１１に記載の方法。
【請求項１３】
少なくとも１つの追加的な状態ビットが設けられ、前記少なくとも１つの追加的な状態ビットによって、前記アプリケーションソフトウェアのために、ＣＡＮ規格ＩＳＯ１１８９８−１から外れたデータ処理方法に関する情報が提供されることを特徴とする、請求項１〜１２のいずれか１項に記載の方法。
【請求項１４】
前記少なくとも１つの追加的な状態ビットは、送信成功を知らせるための状態ビット、及び／又は、受信成功を知らせるための状態ビット、及び／又は、直近に発生したエラーの形態を知らせるための１つ以上の状態ビットを含むことを特徴とする、請求項１３に記載の方法。
【請求項１５】
ＣＡＮ規格ＩＳＯ１１８９８−１から外れるデータ伝送方法でのエラーの発生頻度に従って、ＣＡＮ規格ＩＳＯ１１８９８−１に準拠した伝送方法へと戻して切り替えられ、戻し切り替えの成功を知らせるための少なくとも１つの状態ビットが設けられることを特徴とする、請求項１３又は１４に記載の方法。
【請求項１６】
前記少なくとも１つの一時メモリ内、及び／又は、少なくとも１つの割り当てられたメッセージメモリ内に、各前記メッセージのために利用された又は利用されるデータ伝送方法を標識付けする少なくとも１つの追加的なメッセージビットが設けられることを特徴とする、請求項１〜１５のいずれか１項に記載の方法。
【請求項１７】
バスを介してメッセージを受信又は送信する少なくとも２つの関与するデータ処理ユニットを備えたバスシステム内での直列データ伝送のための装置であって、
前記送信されるメッセージは、ＣＡＮ規格ＩＳＯ１１８９８−１に準拠した論理構造を有し、
前記論理構造は、スタートオブフレームビット、アービトレーションフィールド、コントロールフィールド、データフィールド、ＣＲＣフィールド、アクノリッジフィールド、エンドオブフレームシーケンスを含み、
前記コントロールフィールドは、前記データフィールドの長さについての情報を含むデータ長コードを含む、前記装置において、
伝送されるメッセージの前記データフィールドは、ＣＡＮ規格ＩＳＯ１１８９８−１から外れて８バイトを超えることが可能であり、
前記データフィールドの大きさを確認するために、前記データ長コードの値は、少なくとも部分的にＣＡＮ規格ＩＳＯ１１８９８−１から外れて解釈され、
前記データフィールドとアプリケーションソフトウェアとの間のデータ転送のために、少なくとも１つの一時メモリが設けられ、前記転送されるデータ量は少なくとも、前記データフィールドの大きさが、利用される前記一時メモリの大きさと異なる場合には、データフィールドと利用される一時メモリの大きさの違いに対応して調整されることを特徴とする、装置。
【請求項１８】
前記装置は、適切な手段によって、請求項２〜１５に記載のデータ伝送方法のうちの少なくとも１つの実施するよう構成されることを特徴とする、請求項１７に記載の装置。
【請求項１９】
前記適切な手段は、前記データフィールドと前記一時メモリとの間を転送されるデータ量を、データフィールドと一時メモリの大きさの違いに対応して調整するための少なくとも１つのプロトコル制御部を含むことを特徴とする、請求項１８に記載の装置。
【請求項２０】
前記適切な手段は、少なくとも１つの追加的な又は拡張された状態レジスタを備え、前記状態レジスタの内容は、各前記利用されるデータ伝送方法の形態及び／又は成功及び／又は結果を標識付けすることを特徴とする、請求項１８又は１９のいずれか１項に記載の装置。
【請求項２１】
前記適切な手段は、少なくとも１つの追加的な又は拡張されたメッセージメモリ及び／又は一時メモリを備え、前記少なくとも１つの追加的な又は拡張されたメッセージメモリ及び／又は一時メモリ内では、追加的なメッセージビットが、各前記メッセージのために利用された又は利用されるデータ伝送方法を標識付けすることを特徴とする、請求項１８〜２０のいずれか１項に記載の装置。
【請求項２２】
車両又は産業施設の通常駆動において、適切なデータバスを介して接続された、前記車両又は前記産業施設の少なくとも２つの制御装置の間でデータを伝送するために利用される、請求項１〜１６のいずれか１項に記載の方法。
【請求項２３】
車両又は産業施設の製造又は保守の間に、プログラミングを目的として適切なデータバスと接続されたプログラミングユニットと、前記データバスと接続された前記車両又は前記産業施設の少なくとも１つの制御装置との間でデータを伝送するために利用される、請求項１〜１６のいずれか１項に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、直列バスシステム内の少なくとも２つの加入者の間での、メモリの大きさに対して調整される直列データ伝送のための方法及び装置に関する。
【背景技術】
【０００２】
例えば、ファミリ規格ＩＳＯ１１８９８−１〜５には、以下で規格ＣＡＮと呼ばれる、「コントローラ・エリア・ネットワーク」（ＣＡＮ：Ｃｏｎｔｒｏｌｌｅｒ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）及び「タイム・トリガ型ＣＡＮ」（ＴＴＣＡＮ：Ｔｉｍｅ  Ｔｒｉｇｇｅｒｅｄ  ＣＡＮ）と呼ばれるＣＡＮの拡張版が記載されている。ＣＡＮで利用される媒体アクセス制御方法は、ビットごとのアービトレーションに基づいている。ビットごとのアービトレーションの場合は、複数の加入者局がバスシステムのチャネルを介してデータを同時に伝送することが可能であり、これにより、データ伝送が妨げられることはない。さらに、加入者局は、チャネルを介したビットの送信の際に、当該チャネルの論理的状態（０又は１）を定めることが出来る。送信されるビットの値が、チャネルの定められた論理的状態と一致しない場合には、加入者局はチャネルへのアクセスを終了する。ＣＡＮの場合、ビットごとのアービトレーションは通常、チャネルを介して伝送されるメッセージ内の識別子を用いて行われる。加入者局が識別子を完全にチャネルに送信した後で、当該加入者局は、自身がチャネルに対する排他的アクセス権を有することが分かる。従って、識別子の伝送の終わりは、加入者局がチャネルを排他的に利用できる許可区間の始まりに相当する。ＣＡＮのプロトコル仕様によれば、他の加入者局は、送信加入者局がメッセージの検査フィールド（ＣＲＣフィールド）を伝送してしまうまでチャネルにアクセスしてはならず、即ち、チャネルにデータを送信してはならない。従って、ＣＲＣフィールドの伝送の終了時点は、許可区間の終了に相当する。
【０００３】
ビットごとのアービトレーションによって、チャネルを介した、アービトレーションを獲得したメッセージの破壊されない伝送が達成される。ＣＡＮプロトコルは、特に、実時間条件下で短いメッセージを伝送するのに適しているが、その際に、識別子の適切な割り当てによって、特に重要なメッセージが、ほぼ常にアービトレーションに勝ち、送信が成功することが保証される。
【０００４】
近代的な車両が益々ネットワーク化され、例えば走行時の安全性又は走行時の快適性を改善するために追加的なシステムが組み込まれるにつれて、伝送されるデータ量、及び、伝送時に許容される遅延時間に対する要請が大きくなる。例としては、例えばＥＳＰ（電子安全性プログラム）のような走行ダイナミクス制御システム、例えばＡＣＣ（自動間隔制御）のような運転者支援システム、又は、例えば交通標識検出のような運転者情報システムが挙げられる（例えば、Ｖｉｅｗｅｇ＋Ｔａｕｂｎｅｒによる「ボッシュ自動車ハンドブック」、２０１１年、第２７版を参照されたい）。
【０００５】
独国特許出願公開第１０３１１３９５号明細書には、非対称な直列通信を、代替的に非対称な物理的なＣＡＮプロトコルを介して、又は、対称的な物理的ＣＡＮプロトコルを介して行うことが可能なシステムが記載されており、これによって、非対称な通信のためのより高いデータ伝送レート又はデータ伝送の信頼性が実現されうる。
【０００６】
独国特許出願公開第１０２００７０５１６５７号明細書は、伝送するデータ量を増大させるために、ＴＴＣＡＮプロトコルの排他的なタイムスロットにおいて、ＣＡＮに準拠しない非対称で高速のデータ伝送を利用することを提案している。
【０００７】
Ｇ．ＣｅｎａとＡ．Ｖａｌｅｎｚａｎｏは、「Ｏｖｅｒｃｌｏｃｋｉｎｇ  ｏｆ  ｃｏｎｔｒｏｌｌｅｒ  ａｒｅａ  ｎｅｔｗｏｒｋｓ」（Ｅｌｅｃｔｒｉｃｓ  Ｌｅｔｔｅｒｓ、Ｖｏｌ．３５、Ｎｏ．２２（１９９９）、Ｓ．１９２４）で、効率良く獲得されるデータレートに対する、メッセージの部分範囲内のバス周波数のオーバークロックの作用について論じている。
【０００８】
先行技術は、あらゆる点で満足できる結果を提供しないことが分かる。
【発明の概要】
【課題を解決するための手段】
【０００９】
以下では、本発明及びその利点が、図面と実施例によって記載される。本発明の主題は、提示され記載される実施例に限定されない。
【００１０】
本発明は、少なくとも２つの関与するデータ処理ユニットを備えたバスシステム内での、ＣＡＮ規格ＩＳＯ１１８９８−１に準拠した論理構造を有するメッセージの伝送から出発し、その際に、論理構造は、スタートオブフレームビット（Ｓｔａｒｔ−ｏｆ−Ｆｒａｍｅ−Ｂｉｔ）、アービトレーションフィールド（Ａｒｂｉｔｒａｔｉｏｎ  Ｆｉｅｌｄ）、コントロールフィールド（Ｃｏｎｔｒｏｌ  Ｆｉｅｌｄ）、データフィールド（Ｄａｔａ  Ｆｉｅｌｄ）、ＣＲＣフィールド、アクノリッジフィールド（Ａｃｋｎｏｗｌｅｄｇｅ  Ｆｉｅｌｄ）、及び、エンドオブフレームシーケンス（Ｅｎｄ−ｏｆ−Ｆｒａｍｅ  Ｓｅｑｕｅｎｚ）を含み、コントロールフィールドは、データフィールドの長さについての情報を含むデータ長コード（Ｄａｔａ  Ｌｅｎｇｔｈ  Ｃｏｄｅ）を含む。
【００１１】
本発明は、メッセージのデータフィールドが、ＣＡＮ規格ＩＳＯ１１８９８−１から外れて８バイトを超えることが可能であり、その際に、データフィールドの大きさを確認するために、データ長コードの４ビットの値が少なくとも部分的に、ＣＡＮ規格ＩＳＯ１１８９８−１から外れて解釈され、データフィールドとアプリケーションソフトウェアとの間のデータ転送のために、少なくとも１つの一時メモリが利用のために設けられ、転送されるデータ量は少なくとも、データフィールドの大きさが、利用される一時メモリの大きさと異なる場合には、データフィールドと利用される一時メモリの大きさの違いに対応して調整されることにより卓越した方法を提供する。これにより、アプリケーションソフトウェアを変更せずに引き続き利用することが可能であり、データフィールドの大きさがＣＡＮ規格に対して大きくなる可能性があるとしても、不必要に通信コントローラの大きさを上げる必要がないという利点が実現される。
【００１２】
有利に、データフィールドの大きさが、利用される一時メモリの大きさ、典型的に８バイトを上回る場合には、バスを介して受信されるメッセージのデータフィールドから、利用される一時メモリの大きさに対応した特に８バイトを含むデータ量が、予め設定され又は予め設定可能な選択方法に従って選択されて、一時メモリへと転送される。データフィールドの大きさが利用される一時メモリの大きさを上回る場合には、バスを介して送信されるメッセージのデータフィールドには、一時メモリの内容が、メッセージのデータフィールドの少なくとも１つの予め設定され又は予め設定可能な範囲内に記録され、データフィールドの残りの範囲は、予め設定され又は予め設定可能な方法に従って充填される。メッセージの長さが不必要に大きくならないように、バスを介して送信されるメッセージのデータフィールドの上記充填される範囲内の上記ビットは、ＣＡＮ規格ＩＳＯ１１８９８−１の規定に従って当該範囲にスタッフビットを挿入する必要がないように、充填される。
【００１３】
データ長コードの内容とデータフィールドの長さとの間の一意の対応付けを作成することによって、有利に、データフィールドの提示可能な大きさに関して高いフレキシビリティが達成される。
【００１４】
さらに、データフィールドが本発明に基づき拡大される場合には、チェックサムの計算のための変更された多項式を利用し、ＣＲＣフィールド内で伝送することが可能である。このことには、より大きなデータ量が伝送される際にもエラー検出の信頼性が保持されるという利点がある。特に有利な実施形態において、メッセージの開始に際して、チェックサムの複数の計算が平行して開始され、データ長コードの内容に従って、上記計算のうちの１つのどの結果が利用され又はＣＲＣフィールド内で伝送されるかが決定される。これにより、規格に準拠した方法に従って又は本発明に係る変更された方法に従ってメッセージが伝送されるのかについての情報を、メッセージと共に送信することが可能であり、その際に、受信者に前もって利用される方法が報知されることはない。正しいデータ伝送であるかを検査するためのチェックサムが、２つの方法のために存在し、必要に応じて評価されうる。
【００１５】
本発明が、例えば少なくともデータフィールド及びＣＲＣフィールドのビットについての、ビット長の切り替えと組み合される場合には、より大きなデータ量を加速させて伝送し、バスシステムの中程度のデータ伝送レートを上げるという更なる別の利点が達成される。この場合、有利な発展形態において、ビット長が短いメッセージの標識付けは、コントロールフィールド内の標識ビットによって行われる。これにより、ビット長の切り替えは、ＣＲＣ演算の切り替え又はデータフィールドの大きさの切り替えに依存せずに行うことが可能であり、バスシステムの状態に対してフレキシブルに応答することが可能である。
【００１６】
利用される各伝送方法が分かるために、１つ以上の追加的な状態ビットを設けることは有利であり、この状態ビットによって、アプリケーションソフトウェアのために、ＣＡＮ規格ＩＳＯ１１８９８−１から外れるデータ処理方法に関する情報が提供される。例えば、送信成功を知らせるための状態ビット、及び／又は、受信成功を知らせるための状態ビット、及び／又は、直近に発生したエラーの形態を知らせるための状態ビットを構想することが可能である。ＣＡＮ規格ＩＳＯ１１８９８−１から外れるデータ伝送方法でのエラーの発生頻度に従って、有利に、ＣＡＮ規格ＩＳＯ１１８９８−１に準拠した伝送方法へと戻して切り替え、このことを、更なる別の状態ビットによってシグナリングすることが可能である。
【００１７】
メッセージメモリ内及び／又は一時メモリ内に、有利に、各メッセージのために利用された又は利用されるデータ伝送方法を標識付ける１つ以上の追加的なメッセージビットが設けられうる。ここには例えば、メッセージ内に設けられた標識を記録することが可能である。
【００１８】
本方法は有利に、車両の通常駆動において、適切なデータバスを介して接続された、車両の少なくとも２つの制御装置の間でデータを伝送するために利用することが可能である。しかしながら、有利に車両の製造又は保守の間にも同様に、プログラミングを目的として適切なデータバスと接続されたプログラミングユニットと、データバスと接続された車両の少なくとも１つの制御装置と、の間でデータを伝送するために利用することが可能である。同様に有利に、例えば制御を目的としてより大きなデータ量を伝送する必要がある場合には、本発明を産業分野でも利用することが可能である。特に、全ての加入者がバスへのアクセス権を獲得しうるように、伝送区間の長さに基づき、アービトレーションの間低減されたデータレートを利用しなければならない場合には、本方法によって、特に、データフィールドの長さの切り替え及びビット長の短縮との組み合わせによって、より高いデータ伝送レートを実現することが可能である。
【００１９】
更なる別の利点は、本発明に基づいて機能しうるために、規格ＣＡＮコントローラは最小限に変更されればよいということである。規格ＣＡＮコントローラとしても機能しうる本発明に係る通信コントローラは、従来の規格ＣＡＮコントローラよりも僅かに大きい。付属するアプリケーションプログラムを変更する必要はなく、既にデータ伝送の速度の点で利点が実現される。
【００２０】
有利に、ＣＡＮのコンフォーマンステスト（ＣＡＮ−Ｃｏｎｆｏｒｍａｎｃｅ−Ｔｅｓｔ）（ＩＳＯ１６８４５）の多大な部分が引き継がれる。有利な発展形態において、本発明に係る伝送方法を、ＴＴＣＡＮ（ＩＳＯ１１８９８−４）を補完したものと組み合わせることが可能である。
【図面の簡単な説明】
【００２１】
以下では、本発明が図面によってより詳細に解説される。
【図１ａ】従来技術によるＣＡＮ規格ＩＳＯ１１８９８−１に準拠したＣＡＮフォーマットによるメッセージの構造の２つの選択肢（標準型／拡張型）を示す。
【図１ｂ】本発明の一実施例に係る、本発明に基づき変更されたメッセージのフォーマットの類似する２つの選択肢を示す。
【図２】データ長コードの内容を、どのように本発明に基づきＣＡＮ規格ＩＳＯ１１８９８−１から外れて解釈しうるかという様々な可能性を示す。
【図３】本発明の一実施例に係るバスシステムの加入者局での本発明に係る受信プロセスを概略的に示す。
【図４】本発明の他の実施例に係るバスシステムの加入者局での本発明に係る受信プロセスを概略的に示す。
【図５】本発明の一実施例について、追加的にメッセージ内の固定範囲において様々なビット長が利用される本発明に基づき変更されたメッセージのフォーマットを示す。
【図６】データフィールドとアプリケーションソフトウェアとの間で転送されるデータ量の、本発明に係る調整についての一例を示す。
【図７】データフィールドの大きさ及びビット長の切り替えのために異なるビットが利用され、更にコントロールフィールド内に追加的なビットが収容される、本発明の他の実施例に係る本発明に基づき変更されたメッセージのフォーマットについての２つの選択肢（標準型／拡張型）を示す。
【図８】バスシステムの加入者局で実行される、本発明の同実施例に対して調整された受信プロセスを示す。
【発明を実施するための形態】
【００２２】
図１ａには、メッセージの構造、即ち、メッセージがＣＡＮバス上でデータ伝送のためにどのように利用されるのか示されている。２つの異なるフォーマット、即ち「標準型」（Ｓｔａｎｄａｒｄ）及び「拡張型」（Ｅｘｔｅｎｄｅｄ）が示されている。本発明に係る方法は、適切な実施形態において２つのフォーマットで利用することが可能である。
【００２３】
メッセージは、メッセージの開始をシグナリングする「スタートオブフレーム（ＳＯＦ：Ｓｔａｒｔ  ｏｆ  Ｆｒａｍｅ）」ビットで始まる。この後に、まず第１にメッセージの識別のために役立つ区間が続き、この区間によって、バスシステムの加入者は、自身がメッセージを受信するか否かを決定する。この区間は「アービトレーションフィールド」（Ａｒｂｉｔｒａｔｉｏｎ  Ｆｉｅｌｄ）と呼ばれ、識別子を含んでいる。この後に、特にデータ長コード（Ｄａｔａ  Ｌｅｎｇｔｈ  Ｃｏｄｅ）を含む「コントロールフィールド」（Ｃｏｎｔｒｏｌ  Ｆｉｅｌｄ）が続く。データ長コードは、メッセージのデータフィールドの大きさについての情報を含んでいる。これに続いて、バスシステムの加入者間で交換されるデータを含む本来の「データフィールド」（Ｄａｔａ  Ｆｉｅｌｄ）が続く。その後に、１５ビット長を含むチェックサム（Ｃｈｅｃｋｓｕｍｍｅ）及びデリミタ（Ｄｅｌｉｍｉｔｅｒ）を有する「ＣＲＣフィールド」と、これに続いて、送信者宛てのメッセージの受信の成功をシグナリングする役目を果たす２つの「アクノリッジ（ＡＣＫ：Ａｃｋｎｏｗｌｅｄｇｅ）ビット」と、が続く。メッセージは、「エンドオブフレーム」（ＥＯＦ：Ｅｎｄ  ｏｆ  Ｆｒａｍｅ）シーケンスで終わる。
【００２４】
規格に準拠したＣＡＮデータ伝送方法では、データフィールドは最大で８バイト、即ち６４ビットのデータを含んでもよい。データ長コードは規格に従って４ビットを含み、即ち、１６個の様々な値を取ることが可能である。今日のバスシステム内ではこの値の範囲から、１バイトから８バイトまでの様々な大きさのデータフィールドのために、８個の様々な値が利用される。０バイトのデータフィールドは、ＣＡＮ規格では推奨されておらず、８バイトを上回る大きさは許容されていない。データフィールドの大きさに対するデータ長コードの値の割り当てが、図２のＣＡＮ規格の欄に示されている。
【００２５】
図１ｂには、２つの規格フォーマットからそれぞれ得られた本発明に基づき伝送される変更されたメッセージが、類似した図で対比されている。
【００２６】
本発明に係る変更された伝送方法では、データフィールドは８バイトを超えることが可能であり、即ち示される仕様ではＫバイトまで含んでもよい。規格ＣＡＮとは異なって、より大きなデータフィールドに標識を付けるために、データ長コードが取りうる更なる別の値が利用される。例えば、０〜１５バイトまでの値を示すために、データ長コードの４ビットを利用することが可能である。しかしながら、他の割り当てを行うことも可能であり、例えば、今日のＣＡＮメッセージでは通常利用されないデータ長コードの値ＤＬＣ＝０ｂ００００を、データフィールドの更なる別の可能な大きさ、例えば１６バイトの大きさのために利用することが可能である。
【００２７】
この２つの可能性が、図２の表ではＤＬＣ１及びＤＬＣ２として示されている。この場合、データフィールドの最大値Ｋは値１５又は１６を有する。更なる別の可能性は、０ｂ１０００よりも大きい０ｂ１１１１までのデータ長コードの値について、データフィールドの対応する大きさが、より大きな増分の分だけ大きくなることである。この場合の一例が、表ではＤＬＣ３として示されている。データフィールドの最大値Ｋは、この変形例では値６４バイトに達する。当然のことながら、更なる別の選択が可能であり、例えば４バイトごとの増分が可能である。
【００２８】
本発明に係る通信コントローラが、自身がどのようにデータ長コードの内容を解釈したのか確認出来ることを保証するために、バスシステムの通信が規格ＣＡＮ又は本発明に係る方法に従って進行しているのかを、通信コントローラが自律的に検出出来ることは有利である。このための可能性は、アービトレーションフィールド又はコントロールフィールド内の予約ビットを標識付けのために利用することであり、この標識付けに基づいて、通信コントローラは、自身がそれに従って伝送方法を選択する第１の切り替え条件を導出することが可能である。例えば、図１ｂにおいてｒ０で示される、コントロールフィールドの第２ビットは、標識付けのために利用することが可能である。
【００２９】
上記設定は、識別子のフォーマットに従って選択することも可能である。従って、標準型のアドレス指定については、本発明に係るメッセージに標識付けするための可能性は、コントロールフィールド内の、規格ＣＡＮでは常にドミナントな（ｄｏｍｉｎａｎｔ）ｒ０ビットの位置への、レセッシブな（ｒｅｚｅｓｓｉｖｅ）ＥＤＬ（Ｅｘｔｅｎｄｅｄ  Ｄａｔａ  Ｌｅｎｇｔｈ、拡張データ長）ビットの挿入である。拡張型のアドレス指定については、レセッシブなＥＤＬビットは、コントロールフィールド内の、規格ＣＡＮでは常にドミナントなｒ１ビットの位置に入りうる。
【００３０】
他の可能性は、規格ＣＡＮでは常にレセッシブで送信しなければならないがメッセージを受信するバス加入者によってはドミナントで受け取られるＳＲＲビットを利用することである。第１の切り替え条件の確認のためにビットの組み合わせを評価することも可能である。
【００３１】
更なる別の可能性は、本発明に基づき変更される伝送方法のために、拡張フォーマットの利用を規定することであろう。拡張フォーマットによるメッセージは、バス加入者によって、ＩＤＥビットの値で検出され（図１ａ参照）、同時に、このＩＤＥビットは、第１の切り替え条件を表しうるであろう。従って、拡張型メッセージのために常に、変更された伝送方法が利用される。代替的に、拡張型メッセージで、予約ビットｒ１を、第１の切り替え条件に標識を付けるため又は当該条件を導出するために利用することも可能であろう。しかしながら、予約ビットは、以下で詳細に述べるように、データフィールドの２つ以上の異なる大きさの切り替えのため、又はデータ長コードの値とデータフィールドの大きさとの対応付けのための第２の切り替え条件を導出するためにも利用することが可能である。
【００３２】
しかしながら代替的に、本方法を、このために適した通信コントローラであって、規格ＣＡＮ通信のために設計されてもいない上記通信コントローラ内で利用することも可能である。この場合には、例えばメッセージの適切な標識付けに依存した、上述の第１の切り替え条件の設定を省略することも可能である。この場合には、通信コントローラはむしろ、記載された方法の一方にのみ従って動作し、これに対応して、このような本発明に係る通信コントローラが使用されるバスシステム内でのみ使用される。規格に準拠したメッセージに対して本発明に係るメッセージを標識付けするためにさもなければ利用されたメッセージ内の上記ビットも、この場合には同様に省略することが可能であり、又は、通信の加入者によってデータ伝送方法に関して無視される。
【００３３】
本発明で構想されるように、メッセージのデータフィールドが拡大される場合には、十分なフェイルセーフティ（Ｆｅｈｌｅｒｓｉｃｈｅｒｈｅｉｔ）を獲得するために、巡回冗長検査（ＣＲＣ：Ｃｙｃｌｉｃ  Ｒｅｄｕｎｄａｎｃｙ  Ｃｈｅｃｋ）に対して利用される方法を調整することも有効でありうる。特に、例えばより高次の他のＣＲＣ多項式を利用し、これに対応して、本発明に基づき変更されたメッセージ内に、規格とは異なる大きさのＣＲＣフィールドを設けることが有利でありうる。このことが図１ｂで、示される例では本発明に係るメッセージのＣＲＣフィールドがＬビットの長さを有するということにより提示され、但し、ＬはＣＡＮ規格から外れて同じではなく、特に１５ビットよりも大きくてもよい。
【００３４】
ＣＲＣチェックサムを計算するための変更された方法の利用は、第３の切り替え条件を表す標識によって、バス加入者に対してシグナリングすることが可能である。しかしながら、上記標識及び第３の切り替え条件は、第１の標識及び／又は切り替え条件と一致していてもよい。この場合にも、上述のように、例えば、図１ｂの予約ビットｒ０が標識付けのために役に立ち、又は、ＳＲＲビットが利用されうる。拡張型メッセージでの本発明の適用と組み合わせた、又はｒ１ビットの適用と組み合わせたＩＤＥビットの利用も考察される。
【００３５】
規格ＣＡＮコントローラ内では、送信されるＣＡＮメッセージのＣＲＣ符号が、メッセージの直列に送信されたビットがその入力口に直列に供給されるフィードバックシフトレジスタによって生成される。シフトレジスタの幅は、ＣＲＣ多項式の次数に対応する。ＣＲＣ符号化（ＣＲＣ−Ｃｏｄｉｅｒｕｎｇ）は、シフト演算（Ｓｈｉｆｔ  Ｏｐｅｒａｔｉｏｎ）の間の、レジスタ内容とＣＲＣ多項式との結合（Ｖｅｒｋｎｕｅｐｆｕｎｇ）によって行われる。ＣＡＮメッセージが受信される場合には、これに対応して、メッセージの直列に受信されたビットが、ＣＲＣシフトレジスタ内へとシフトされる。ＣＲＣ検査（ＣＲＣ−Ｔｅｓｔ）は、ＣＲＣフィールドの終りで、シフトレジスタの全ビットが０である場合には成功である。送信の場合のＣＲＣ符号の生成及び受信の場合のＣＲＣ検査は、双方ともハードウェア内で行われ、その際に、ソフトウェアの介入は必要ではない。即ち、ＣＲＣ符号化の変更は、アプリケーションソフトウェアに対して影響を与えない。
【００３６】
可能な実施形態において、通信コントローラは、規格ＣＡＮに対して互換性を有するように設計され、即ち、規格ＣＡＮバスシステム内で規格に準拠して動作するように設計されるが、通信コントローラは、本発明に基づき変更されたバスシステム内では、一方では、メッセージ内のより大きなデータフィールドを許容し、他方では、ＣＲＣ符号の、調整された計算及び検査も実行する。
【００３７】
メッセージの受信の開始時には、規格に準拠したＣＡＮメッセージ又は本発明に基づき変更されたメッセージが受信されるのかが未だに確定していないため、本発明に係る通信コントローラには、平行して動作する２つのＣＲＣシフトレジスタが実装される。ＣＲＣデリミタの受信後に、受信者のところでＣＲＣ符号が評価される場合には、本発明に係る標識付けに基づいて、又は、例えば標識若しくはデータ長コードの内容から導出される第３の切り替え条件に基づいて、どの伝送方法が利用されたのかが確定され、その後で、上記利用された伝送方法に対応付けられたシフトレジスタが評価される。第３の切り替え条件は、先に既に示したように、データフィールドの大きさ及びデータ長コードの解釈に関する第１の切り替え条件と一致していてもよい。
【００３８】
メッセージ送信の開始時には、送信者のために、どの伝送方法に従って送信されるのかが既に確定している。しかしながら、バスアクセスを巡るアービトレーションが失われ、開始されたメッセージが送信されず、その代わりに他のメッセージが受信されることが起こりうるため、この場合にも、２つのＣＲＣシフトレジスタが平行して駆動される。
【００３９】
平行して動作する２つのＣＲＣレジスタの上記実装によって更なる改善も可能となり、即ち、規格ＣＡＮプロトコルのＣＲＣ多項式（ｘ１５＋ｘ１４＋ｘ１０＋ｘ８＋ｘ７＋ｘ４＋ｘ３＋ｘ１）が、１２７ビットより小さいメッセージ長ために設計される。本発明に基づき伝送されるメッセージが、より長いデータフィールドも利用する場合には、伝送信頼性を保つために、特により長い他のＣＲＣ多項式を利用することが有効である。本発明に基づき伝達されるメッセージはこれに対応して、変更された、特により長いＣＲＣフィールドを獲得する。駆動中に、通信コントローラは、各適切な多項式を利用するために、２つのＣＲＣシフトレジスタ、即ち、規格ＣＡＮに準拠したシフトレジスタと本発明に係るシフトレジスタとの間で、動的に切り替える。
【００４０】
当然のことながら、データフィールドの長さ又は所望の伝送信頼性に従って、２つより多いシフトレジスタ、及びこれに対応して、２つより多いＣＲＣ多項式を段階的に使用することが可能である。この場合には、規格ＣＡＮに対する互換性が保たれる限りにおいて、対応する標識及びこれと関連する切り替え条件を調整する必要がある。例えば図２のＤＬＣ１に係る、より長いデータフィールドへの切り替え、及び、対応する第２のＣＲＣ多項式を特徴とする第１の切り替え条件を、図１ｂの予約ビットｒ０又はＳＲＲビットによって例えば起動することが可能であろう。拡張フォーマットによるメッセージについては追加的に、例えば図１ｂの予約ビットｒ１又はＩＤＥビットによって、データフィールドの大きさの更なる別のセット、例えば図２のＤＬＣ３への切り替え、及び、第３のＣＲＣ多項式を特徴とする第２の切り替え条件を起動することが可能であろう。
【００４１】
第１の切り替え条件が、例えば予約ビットｒ０又はＳＲＲビットによって、可能なより長いデータフィールド及びデータ長コードの内容の対応する解釈を切り替えること、並びに、第３の切り替え条件の決定及びこれと関連するＣＲＣ検査のために評価されるＣＲＣ多項式の選択が、データ長コードの内容に従って行われることも通常では可能である。第３の切り替え条件は、これに対応して、２つよりも多い値を取ることも可能である。例えば、ＤＬＣ３に係るデータフィールドの大きさを選択し、即ち、０〜６４バイトの間の値を取ることが可能であろうし、その場合には、適切なシフトレジスタを介して、３つのＣＲＣ多項式、例えば、８バイトまでのデータフィールドのための規格ＣＲＣ多項式、２４バイトまでのデータフィールドのための第２のＣＲＣ多項式、及び、６４バイトまでのデータフィールドのための第３のＣＲＣ多項式を平行して計算することが可能であろう。
【００４２】
図３は、本発明に係る受信プロセスの一部、即ち、受信プロセスがどのようにバスシステムの加入者局で進行するのかを簡素化した図で示している。ここでは、第１の切り替え条件に従って通信コントローラの挙動が調整されることにより、規格ＣＡＮに対する互換性が実現される場合が示される。図３では、ソフトウェア内でのプログラムシーケンスを記載するために一般的な図が選択されたが、本方法は、ハードウェア内での実装のために完全に適している。示されるシーケンスは、上述のとおりの切り替え条件、例えば、切り替え条件ＵＢ１が省略される実施形態のためにも適用することが可能である。しかしながら、受信プロセスは、さもなければ対応する切り替え条件に従って進行する経路のうちの１つのみが実際に進行する限りにおいて、簡略化される。ここでは、このような簡素化されたフローチャートを他に示さない。
【００４３】
加入者局は最初に、バス上に通信トラフィックが無い限り、バスをサンプリングする状態にある。即ち、問い合わせ３０２は、バス上のドミナントビットを待つ。このドミナントビットは、新しいメッセージの開始を表す。
【００４４】
新しいメッセージの開始が確認され次第、ブロック３０４において、平行して計算される少なくとも２つのチェックサムの計算が開始される。第１のチェックサムは、規格ＣＡＮのＣＲＣ演算に対応し、第２のチェックサムは、新しい方法に従って計算される。
【００４５】
引き続いて、ステップ３０６から、メッセージのＳＯＦビットの後に続く、アービトレーションフィールドで始まる更なる別のビットが受信される。複数のバス加入者がメッセージを送信したい場合には、ここで、規格ＣＡＮで一般的な方法に従ってバス加入者の間で、どの加入者がバスへのアクセス権を獲得するかについて調停が行われる。示されるブロック３０６は、第１の標識が受信されてしまうまで又は第１の切り替え条件が確定するまでの、全ビットの受信を表す。記載される例では、第１の切り替え条件は、アービトレーションフィールドから、例えば、ＳＲＲビット若しくはＩＤＥビットから、又は、コントロールフィールドから、例えばコントロールフィールドの予約ビットから定められる（図１参照）。引き続いて、ブロック３０８において、メッセージの特定ビット以降、定められた第１の切り替え条件に従って様々に処理されるまで、メッセージの更なるビットが受信されうる。様々な処理形態によるこの分割は、以下で例示するように、対応する問い合わせ又は分岐３１０によって保証される。
【００４６】
分岐３１０で、例えばコントロールフィールドの最初の２ビットの受信後に、第１の切り替え条件に従って通信が規格ＣＡＮに準拠して行われる（図３の「１」で示された経路）という情報が存在する場合には、ステップ３１２において、コントロールフィールドの更なる別のビットが読み込まれる。この更なる別のビットから、規格ＣＡＮに従ってデータ長コードが評価され、引き続いてステップ３１６で、対応するデータ量、即ち、データフィールドに対応した最大８バイトが受信される。その後ステップ３２０において、１５ビットを含むＣＲＣフィールドが受信される。分岐３２４で、送信者により伝達されたＣＲＣチェックサムと、受信者自身により定められたＣＲＣチェックサムとが一致するという情報が存在する場合には、ブロック３２８で、ドミナントなアクノリッジビット（Ａｃｋｎｏｗｌｅｄｇｅ−Ｂｉｔ）が送信される。この場合には、通信が規格ＣＡＮに従って行われるため、規格に準拠したＣＲＣチェックサムが比較されるということに注意されたい。一致が確認されない場合には、（ブロック３３０で）アクノリッジビットがレセッシブで送信される。この後に、ＡＣＫデリミタ（ＡＣＫ  Ｄｅｌｉｍｉｔｅｒ）、及び、ＥＯＦビットが続く（図１ｂを参照、図３には図示されない）。
【００４７】
これに対して、分岐３１０で、例えばコントロールフィールドの最初の２ビットの受信後に、第１の切り替え条件に従って本発明に基づき変更された通信方法が利用されるという情報が存在する場合には（図３の「２」で示された経路）、ブロック３１４において、コントロールフィールドの更なる別のビットが読み込まれる。この結果から、データ長コードが、図２の表で幾つかの例について記載した新しい解釈に従って定められる。ブロック３１８で、対応するデータ量、即ち、図２の表の例ＤＬＣ１については１５バイトまで、例ＤＬＣ２については１６バイトまで、例ＤＬＣ３については６４バイトまでのデータが受信される。ブロック３２２で、本発明に基づき異なる、特により長いＣＲＣフィールドが受信される。分岐３２４で、送信者に伝達されたＣＲＣチェックサムと受信者自身により定められたＣＲＣチェックサムとが一致するという情報が存在する場合には、この場合上記比較は本発明に基づき異なるＣＲＣチェックサムに基づいているのだが、ブロック３２８で、ドミナントなアクノリッジビットが送信される。送信者に伝達されたＣＲＣチェックサムと受信者自身により定められたＣＲＣチェックサムとが一致しない場合には、（ブロック３３０で）アクノリッジビットがレセッシブで送信される。引き続いて、ステップ３３２又は３３４において、ＡＣＫデリミタ及びＥＯＦビットが続く。これで、メッセージのための受信プロセスが終了する。
【００４８】
図３では、利用されるＣＲＣを決定する第３の切り替え条件が、データフィールドの大きさ及びデータ長コードの解釈に関する第１の切り替え条件と一致する場合が示された。即ち、ＣＲＣチェックサムの受信３２０又は３２２の前に、どのＣＲＣが第３の切り替え条件に従って受信されて分岐３２４のために評価されるのかについて、問合せが再度行われなかった。図３のフロー図を簡単に変更することにより、図４に示すように、この追加的な問合せをシーケンスに組み込むことが可能である。
【００４９】
このように変更された図４の受信プロセスでは、ブロック３１６若しくは３１８での、データ長コードの情報に従って予期されるデータフィールドのデータバイト数の受信後に、問い合わせ又は分岐４１０において、第３の切り替え条件がどの値を有するのかが定められる。この情報は、先に記載したように、例えば、対応する第３の標識又はデータ長コードの内容から定めることが可能である。示される例では、第３の切り替え条件のために３つの異なる値、即ちＡ、Ｂ、及びＣが存在する。その後、切り替え条件の値に従って、ブロック４２０、４２２、及び４２４において、ＣＲＣフィールドの様々なビット数が読み込まれ、例えば、値Ａについては１５ビット、値Ｂについては１７ビット、値Ｃについては１９ビットが読み込まれる。引き続いて、図３と同様に分岐３２４で、送信者により伝達されたＣＲＣチェックサムと、受信者自身により定められたＣＲＣチェックサムとが一致するかが検査され、これに従って更に処理される。
【００５０】
図５は、本発明に係る伝送方法の更なる別の実施例について、２つの可能なバリエーション、即ち、標準フォーマットによるメッセージ及び拡張フォーマットによるメッセージの構造を再度示している。図５には、２つのバリエーションについて、ここではファストＣＡＮアービトレーション（Ｆａｓｔ−ＣＡＮ−Ａｒｂｉｔｒａｔｉｏｎ）、ファストＣＡＮデータ（Ｆａｓｔ−ＣＡＮ−Ｄａｔａ）と呼ばれる２つの状態の間で切り替えられる範囲が示されている。本例では、この２つの状態の切り替えによって、アービトレーションの終了後に、メッセージの一部について、特にデータフィールド及びＣＲＣフィールドについてビット長が短縮され、個々のビットがより速くバスを介して伝送される。これにより、規格に準拠した方法に対して、メッセージの伝送時間を短縮することが可能である。これに伴う時間的ビット長の切り替えは、例えば、最小時間単位又は駆動中の発振器クロックに対して相対的にバス時間単位を調整するための、少なくとも２つの異なる倍数の利用によって実現することが可能である。ビット長の切り替え、及び、倍率の、対応する変更も同様に図５に例示されている。
【００５１】
状態ファストＣＡＮアービトレーションと状態ファストＣＡＮデータとの間の移行は、メッセージの標識であって、短縮されたビット長が利用されることをデータ伝送の加入者に対してシグナリングする上記標識に対応する更なる別の切り替え条件に従って行われうる。ここで示される実施例では、選択されたこの標識の位置は、データ長コードの前に伝送される「予約ビット」ｒ０である。即ち、この位置は、第１の切り替え条件に対応する第１の標識であって、より長いデータフィールド及びデータ長コードの変更された解釈の利用が可能であることを表す上記第１の標識の可能な位置、及び、変更されたＣＲＣ演算に対応する第３の標識の可能な位置にも相当する。
【００５２】
ビット長が短縮された本発明に係るメッセージに標識を付けるための他の可能性が、図７に示されている。ここでは、データフィールドがより長くなりうるメッセージ（第１の標識に対応）、及び、変更されたＣＲＣ演算（第３の標識に対応）が、レセッシブなＥＤＬビット（拡張データ長）であって、規格ＣＡＮメッセージによりドミナントで伝送されるビットの場所に入り及び当該ビットを置換し、又は当該ビットを１ポジション分だけ後ろにずらす上記ＥＤＬビットによって標識付けされる。標準型のアドレス指定については、ＥＤＬビットは、コントロールフィールド内の２番目の位置に入り、当該２番目の位置に存在する常にドミナントなｒ０ビットを１ポジション分ずらす。拡張型のアドレス指定については、示される例では、ＥＤＬビットは、コントロールフィールドの１番目の位置に入り、及び、当該１番目の位置に存在する、規格ＣＡＮでは常にドミナントで伝送される予約ビットｒ１を置換する。
【００５３】
短縮されたビット長の利用を報知する更なる別の又は第４の標識は、ＥＤＬビットにより標識付けされた本発明に係るメッセージのコントロールフィールドへの、追加的なレセッシブなＢＲＳビット（Ｂｉｔ  Ｒａｔｅ  Ｓｗｉｔｃｈ、ビットレート切り替え）の挿入によって示される。ここで示される実施例では、ＢＲＳビットの位置は、コントロールフィールド内の４番目の位置（標準型のアドレス指定）又は３番目の位置（拡張型のアドレス指定）である。
【００５４】
メッセージは、「ＣＡＮ  ＦＤファスト」（ＣＡＮ  ＦＤ  Ｆａｓｔ）という名称を有する。メッセージの２つの可能なアドレス指定のバリエーション、即ち、標準フォーマット及び拡張フォーマットについて、図７には、ファストＣＡＮアービトレーション、ファストＣＡＮデータと呼ばれる２つの状態の間で切り替えられる範囲が示されている。この２つの状態の切り替えによって、既に記載したように、メッセージの対応する部分についてビット長が短縮され、個々のビットがバスを介してより速く伝送される。これにより、規格に準拠した方法に対してメッセージの伝送時間を短縮することが可能である。状態ファストＣＡＮアービトレーションとファストＣＡＮデータとの間の移行は、第１又は第３の標識ＥＤＬを有するメッセージ内では、短縮されたビット長が利用されることをデータ伝送の加入者にシグナリングする更なる別の標識ＢＲＳに従って行われる。
【００５５】
示されるケースでは第１の標識ＥＤＬの後に第２の標識ＢＲＳが続いているが、本発明に係る伝送方法において、そのビット長が明らかに短く、そのデータフィールドの大きさが８バイトを上回る値に拡張可能であり、そのＣＲＣがより大きなデータフィールドに対して調整されるメッセージが伝送される。このようにして、バスシステムを介する伝送容量の著しい増大と同時に、伝送信頼性の改善が達成される。
【００５６】
示される例では、より速い伝送は、対応する標識の送信直後に始まって、戻し切り替えのために設定されたビットに到達した直後に終わり、又は、エラーフレーム（Ｅｒｒｏｒ−Ｆｒａｍｅ）を開始する理由が検出された場合に終わる。
【００５７】
図８は、図３に対して変更された受信プロセスを示しており、この受信プロセスでは追加的に、第２の標識ＢＲＳに従って、状態ファストＣＡＮアービトレーションと状態ファストＣＡＮデータとの間で切り替えられる。分岐３１０で、例えばレセッシブなビットＥＤＬとしてのコントロールフィールドの第２ビットの受信後に、本発明に係る変更された通信方法が利用されるという情報が存在する場合には、ブロック４０８において、コントロールフィールドの直近のビットが読み込まれる。第２の標識として役立つビット、例えば、本発明に基づき拡張されたコントロールフィールドの、構想された値を有する第４のビットＢＲＳが、例えばレセッシブで受信される場合には、例えばＢＲＳビットのサンプルポイント（Ｓａｍｐｌｅ  Ｐｏｉｎｔ）で、状態ファストＣＡＮデータに入り、即ち、短縮されたビット長に切り替えられる（経路「Ｃ」）。当該ＢＲＳビットが反対の値、即ちこの場合ではドミナントな値を有する場合には、ビット長の短縮は行われない（経路「Ｂ」）。ブロック４１２又は４１４で、データ長コードを含むコントロールフィールドの残りのビットの受信、及び、データ長コードからの大きさ情報に係るデータフィールドの受信が行われる。ブロック４１２では、通常のビット長で受信され、ブロック４１４では短縮されたビット長で受信される。ブロック４１６又は４１８では、本発明に基づき異なる、特により長いＣＲＣフィールドが読み込まれる。ブロック４１８において、ＣＲＣフィールドの最後のビット、即ちＣＲＣデリミタで、通常のビットレートによる状態ファストＣＡＮアービトレーションへと再び切り替えられる。引き続いて、図３と同様に分岐３２４で、送信者により伝達されたＣＲＣチェックサムと、受信者自身により定められたＣＲＣチェックサムとが一致するかが検査され、これに従って、図３で既に示したように、更なる処理が行われる。
【００５８】
より速い伝送は、例えば、対応する標識の直後に始まって、戻し切り替えのために定められたビットに到達した直後に終わり、又は、エラーフレームを開始する理由が検出された場合に終わる。
【００５９】
本方法は、車両の通常運転における、適切なデータバスを介して接続された、車両の少なくとも２つの制御装置の間のデータ伝送のために適している。しかしながら、車両の製造又は保守の間の、プログラミング目的で適切なデータバスと接続されたプログラミングユニットと、データバスと接続された車両の少なくとも１つの制御装置と、の間のデータ伝送のためにも同様に有利に利用されうる。さらに、工業オートメーションにおいて、バスによって互いに接続された分散された制御ユニットであって、産業的な製造工程の流れを制御する上記制御ユニットの間で、例えば制御情報を伝送するために本発明を使用することも可能である。この分野では、非常に長いバス線も登場する可能性があり、アービトレーション段階の間バスシステムを、比較的長いビット長で、例えば、１６、３２、又は６４マイクロ秒で駆動することも特に有利である可能性があり、従って、バス信号が、アービトレーション過程の間、バスシステム全体で必要なだけ伝播されうる。続いて、上述のように、メッセージの一部について、中規模の伝送レートが小さくなり過ぎないようにするために、より短いビット長に切り替えることが可能である。
【００６０】
以上本方法は、規格ＣＡＮコントローラが、本発明に基づき動作しうるために最小限に変更されればよいという点で卓越した伝送方法である。規格ＣＡＮコントローラとしても動作しうる本発明に係る通信コントローラは、従来の規格ＣＡＮコントローラより僅かに大きい。対応するアプリケーションプログラムを変更する必要はなく、既に、データ伝送速度の点で利点が実現される。データフィールドの拡張された大きさ、並びに、対応するＤＬＣ及びＣＲＣを利用することにより、データ伝送速度を更に上げることが可能であり、アプリケーションソフトウェアにおける調整は最小である。ＣＡＮコンフォーマンステスト（ＣＡＮ−Ｃｏｎｆｏｒｍａｎｃｅ−Ｔｅｓｔ）（ＩＳＯ１６８４５）の広範な部分を引き継ぐことが可能である。さらに、本発明に係る伝送方法と、ＴＴＣＡＮ（ＩＳＯ１１８９８−４）を補完したものと、を組み合わせることも可能である。
【００６１】
少なくとも特定の適用目的のために又は導入段階において、本発明に係るデータ伝送方法及び当該データ伝送方法を実施する装置のために、利用されるアプリケーションソフトウェアに関して完全に又は十分に互換性を有して動作するバリエーションを構想することは有効である。このアプリケーションソフトウェアは、例えば、車両のための横滑り防止装置の調整ソフトウェア、又は、車両の内燃機関のための制御ソフトウェアであってもよい。即ち、アプリケーションソフトウェアは特に、セキュリティクリティカルなシステムのために、膨大な保護プログラムを必要とし、従って、アプリケーションソフトウェアを変更しないで、本発明に基づき変更されたデータ伝送装置の導入を実施出来ることは有利である。
【００６２】
メッセージのデータフィールドとアプリケーションソフトウェアとの間のデータの転送は、通信コントローラ内で、この利用のために設けられた一時メモリであって、規格ＣＡＮでは例えば８バイトの予め定められた大きさを有する上記一時メモリと、付属するメッセージメモリと、を介して行われる。一時メモリ及びメッセージメモリは、本発明との関連で、より大きなメモリユニット内の、対応する利用のために割り当てられた範囲を意味してもよい。
【００６３】
これに対応して、規格ＣＡＮによりデータ伝送を実行するシステム内で、アプリケーションソフトウェアによって、最大８バイトの大きさのデータパケットが、大抵数多くのメッセージメモリ及び一時メモリを介して、ＣＡＮメッセージのデータフィールドと交換される。アプリケーションソフトウェアが変更されていない場合には、本発明に係る通信コントローラの大きさ又はチップ面積を必要以上に大きくしないために、メッセージメモリ及び一時メモリを、例えば８バイトの所定の大きさのままにしておくことも可能である。本発明に係るメッセージのデータフィールドの大きさ（例えば１６バイト）が、利用される一時メモリの大きさ（例えば８バイト）と異なる場合には、通信コントローラのプロトコル制御部を、データフィールドと一時メモリの大きさの違いに対応して調整する必要がある。
【００６４】
従って、図６で１６バイトの大きさのデータフィールドを有する標準フォーマットのメッセージの例で示される、本発明に係るデータ伝送方法の更なる別の実施例では、バスを介するビットの直列伝送に関して、本発明の完全な機能が実行されること、及び、データフィールド内の関連する８バイトのユーザデータのみが伝送されるということが構想されている。即ち、対応する切り替え条件が存在する際には、バスを介して、例えば１６バイトの大きさのデータフィールドと、付属する標識と、を有するメッセージが伝送され、及び、対応して調整されたＣＲＣ多項式により、伝送が正確であるかについてメッセージが検査され、その一方で、例えば、本発明に係る通信コントローラ内の一時メモリ６２０、及び、例えば、メッセージメモリ６３０を介して、アプリケーションソフトウェア６４０に対して８バイトのユーザデータが渡される。送信の場合には、アプリケーションソフトウェア６４０によって、８バイトのユーザデータが、例えば、更なる別の又は同一のメッセージメモリ６３０を介して一時メモリ６２０に書き込まれ、この８バイトのユーザデータは、予め設定され又は予め設定可能な方法に従って、送信されるメッセージの例えば１６バイトの大きさのデータフィールドに記録される。当然のことながら、８バイトとは異なる一時メモリの大きさ、例えば、６又は４バイトの方法に制限することも可能である。このことは特に、アプリケーションソフトウェアにも同様にこの制限を適用する場合には有効である。１６バイトというデータフィールドの大きさの選択は単に例示的なものとして解され、例えば、２４、３２、又は６４バイトという値も含んでもよい。数多くの他の可能性が、例えば図２で分かる。メッセージからアプリケーションプログラムへと渡されるデータ量、又は、アプリケーションソフトウェアからメッセージのデータフィールド内へと記録のために提供されるデータ量と、一時メモリ６２０の大きさと、の間に関係性が発生する。
【００６５】
本実施例において、通信コントローラのプロトコル制御部は、図６に二重の矢印６００で示されるように、伝送されるデータの直列化の際に、例えば、一時メモリ６２０からの８バイトのユーザデータを、データフィールドの最初の８個の直列バイト内に位置づけ、データフィールドの他のビットを、図６に矢印６１０で示されるように、予め設定され若しくは予め設定可能な充填データ、又は、例えば所定のビットパターンを有する任意の充填データで満たすことが可能である。ここでは、ＣＡＮ規格ＩＳＯ１１８９８−１の規定に従った追加的なスタッフビット（Ｓｔｕｆｆ−Ｂｉｔ）の挿入を引き起こさないビット列を利用することが有効である。そうでなければ、データフィールドが不必要に拡大されるからである。即ち、例えば、データフィールドの利用されない各バイトのために、ビット列０ｂ００１１００１１又は０ｂ１１００１１００を挿入することが可能である。
【００６６】
一時メモリ６２０の例えば８バイトのユーザデータを、データフィールドの最初の８バイトにではなく、データフィールド内の他の位置又は複数の他の範囲に記録するということも可能である。ユーザデータ・バイトの位置は、バス加入者にとって一様に予め設定され又は予め設定可能である必要がある。
【００６７】
本発明に係るバス加入者は、本発明に係る方法に従ってメッセージを読出し、例えばＣＲＣ検査を行い、アクノリッジ（Ａｃｋｎｏｌｅｄｇｅ）によって正確な受信を確認する。受信するバス加入者の通信コントローラ内のプロトコル制御部は、メッセージの直列に受信されたビットを移動させ、その際に、例えば１６バイトのデータフィールドから８バイトのユーザデータを抽出し、この８バイトのユーザデータは一時メモリ６２０に書き込まれる。このことが、図６に同様に二重の矢印６００で示される。残りの充填データは破棄される。即ち、アプリケーションソフトウェア６４０には、一時メモリ６２０、及び例えばメッセージメモリ６３０を介して、８バイトのユーザデータのみが渡される。アプリケーションソフトウェア６４０自体は、規格に準拠した伝送方法の利用と比べて違いは無い。
【００６８】
本発明に係るデータ伝送方法の様々な実施形態、即ち特に、メッセージの一部の範囲内でビット長が短縮され、データフィールドの長さが変更され、データ長コードの内容の解釈が変更され、即ち場合により多段階で（ｍｅｈｒｓｔｕｆｉｇ）変更され、様々なチェックサムが利用され、又は、転送されるデータ量が、データフィールドと一時メモリの大きさの違いに対して調整される方法をフェールセーフに（ｆｅｈｌｅｒｓｉｃｈｅｒ）実現するために、更なる補完が有効である。
【００６９】
適切な状態レジスタによって、例えば規格ＣＡＮでは、データ伝送中に対応する頻度でエラーが発生した際に入るエラー状態（エラー警告（Ｅｒｒｏｒ−Ｗａｒｎｉｎｇ）、エラーパッシブ（Ｅｒｒｏｒ−Ｐａｓｓｉｖｅ）、バス・オフ（Ｂｕｓ−Ｏｆｆ））に達したことが、例えばマイクロコントローラ又はアプリケーションソフトウェアにより読出されうることが保証される。更に、送信プロセス及び受信プロセスの成功は、フラグ（Ｆｌａｇ）によってシグナリングされ（ＴｘＯＫ、ＲｘＯＫ）、各直近のバス事象について情報が準備される（ＬＥＣ：Ｌａｓｔ  Ｅｒｒｏｒ  Ｃｏｄｅ、最終エラーコード）。上記情報の幾つか又は全てを、本発明に係る通信コントローラ内の、そのために設けられたメモリ領域内に何重にも提供することが可能であり、従って、例えば、付属するマイクロコンピュータ、又は、当該マイクロコンピュータ上で実行されるアプリケーションソフトウェアによって、実際に実行されたデータ伝送方法に従って各情報を別々に収集して、格納することが可能である。これにより、ＣＡＮ規格に対して変更された伝送方法で、例えば、メッセージの範囲内でデータフィールドがより長く又はビット長がより短い場合に、特定の故障モード（Ｆｅｈｌｅｒｂｉｌｄ）が、規格ＣＡＮの伝送方法よりも頻繁に発生するかどうかを確認することが可能である。
【００７０】
追加的なエラー状態を導入し、状態ビットによってシグナリングすることが可能であり、この状態ビットは、変更された伝送モードにおいてエラーが頻繁な場合に、データ伝送を永続的に規格ＣＡＮ伝送方法へと戻して切り替える。情報ＴｘＯＫ、ＲｘＯＫ、及びＬＥＣは、様々なデータ伝送方法について別々に収集されうる。代替的に、ＬＥＣについて、どの伝送モードでエラーが発生したかについての情報を追加的に格納することが可能である。
【００７１】
更に、受信されたメッセージについて、どの方法で、可能な標識のうちのどの標識と共に、当該受信されたメッセージが受信されたのかを記録し、送信されるメッセージについて、どの方法に従って、どの標識と共に送信されるのかを個別に設定することが有効でありうる。このために、特定又は全ての受信メッセージメモリ及び／又は一時メモリを、可能な標識に対応する複数の追加的なビットで補うことが可能である。このために設けられた更なる別のビット内に、どの状態において又はどの切り替え条件の下で各メッセージが受信されたのかについての情報を別々に格納することも可能である。同様に、特定又は全ての送信メッセージメモリ及び／又は一時メモリに、追加的なビットを備えることが可能であり、この追加的なビットに、各メッセージが修正された方法で及び／又は対応する標識と共に送信されることが記録される。
【００７２】
最後に、メッセージのデータフィールドとアプリケーションソフトウェアとの間で転送されるデータ量が例えば８バイトに制限されたアプリケーションソフトウェアに対応したモードと、対応して大きく設定された使用される一時メモリを活用してデータフィールドの大きさ全体を利用するデータ伝送に対して最適化されたモードと、の間で、適切な再構成によって切り替え可能であるように、本発明に係る通信コントローラを設計することが有効でありうる。この場合には、対応してより小さい一時メモリ及び／又はメッセージメモリの利用による、大きさ又はチップ面積の対応する節約を達成することは出来ないが、既存のアプリケーションソフトウェアを引き続き使用するバス加入者内、及び、データ伝送に対して最適化された新しいソフトウェアがそのために作成されたバス加入者内で、通信コントローラを非常にフレキシブルに使用することが可能である。
【００７３】
この切り替え可能な通信コントローラは、現在利用している自身のモード、即ち、アプリケーションソフトウェアに対応したモード、又は、データ伝送に対して最適化されたモードを、このために設けられたメモリ領域内で、例えば、対応する状態ビットにより可視化すべきであろう。
【００７４】
本発明についてのこれまでの記載においてＩＳＯ規格が引用された箇所では、対応するＩＳＯ規格の、出願時点で有効な各バージョンが従来技術として根底にある。
【図１ａ】
0005702505.tif 000002
【図１ｂ】
0005702505.tif 000003
【図２】
0005702505.tif 000004
【図３】
0005702505.tif 000005
【図４】
0005702505.tif 000006
【図５】
0005702505.tif 000007
【図６】
0005702505.tif 000008
【図７】
0005702505.tif 000009
【図８】
0005702505.tif 000010