JP2015536067A - 可変的なデータレート対応のコントローラエリアネットワーク - Google Patents

Abstract

バスシステムにより接続された送信ノードと少なくとも１つの受信ノードとの間のデータフレームの交換による直列通信のための方法であって、ＣＡＮ規格ＩＳＯ１１８９８−１で定義された調停手続きによって、データフレームごとに送信者及び受信者の役割がノードに割り当てられ、交換されるデータフレームは、ＣＡＮ規格ＩＳＯ１１８９８−１に準拠した論理構造を有し、データフレームは、ビットのシーケンスで構成され、データフレームの論理構造は、スタートオブフレームビット、アービトレーションフィールド、コントロールフィールド、データフィールド、ＣＲＣフィールド、アクノリッジフィールド、及びエンドオブフレームフィールドを含み、各ビットは、ビット時間を有し、各ビット時間は、タイムセグメント（ＳＹＮＣ＿ＳＥＧ、ＰＲＯＰ＿ＳＥＧ、ＰＨＡＳＥ＿ＳＥＧ１、ＰＨＡＳＥ＿ＳＥＧ２）に分けられる、上記方法において、コントロールフィールド内の特定ビットの所定の値に応じて、第１のノード群に属する第１のノードが、そのプロトコル復号ステートマシンを再起動し、自身がバスアクティビティに同期するまで待機し、第２のノード群に属する第２のノードが、ＣＡＮ ＦＤ仕様に準拠した通信プトロコルを用いて通信することを特徴とする、方法。【選択図】図２

Description

この発明は、可変的なデータレート対応のコントローラエリアネットワークに関する。

直列通信が受け入れられ、益々多くのアプリケーションに導入されるにつれて、直列通信のための帯域幅を増やす必要があるという要請が生まれた。

直列通信のための広く利用されているプロトコルは、ロバートボッシュ社のウェブサイト：ｈｔｔｐ:／／ｗｗｗ.ｓｅｍｉｃｏｎｄｕｃｔｏｒｓ.ｂｏｓｃｈ.ｄｅからダウンロードが可能なボッシュＣＡＮ仕様２．０と、国際規格ＩＳＯ１１８９８−１と、で規定されたＣＡＮプロトコルである。このＣＡＮプロトコルは、以下では「規格ＣＡＮ」と呼ばれる。

２つの要因が、ＣＡＮネットワーク内での有効なデータレートを制限しており、即ち、第１の要因は、ＣＡＮバスアービトレーション方法の機能のために必要な最小ビット時間であり、第２の要因は、ＣＡＮメッセージ内でのデータビット数とフレームビット数との間の関係である。

最近では、「ＣＡＮ ｗｉｔｈ Ｆｌｅｘｉｂｌｅ Ｄａｔａ−Ｒａｔｅ（可変的なデータレート対応のＣＡＮ）」又はＣＡＮ ＦＤと呼ばれる新しいプロトコルが開発された。この新しいプロトコルは、ＣＡＮバスのアービトレーション方法を今まで通り利用し、アービトレーション過程の終了後により短いビット時間へと切り替えることによってビットレートを上げ、受信機が自身のアクノリッジビットを送信する前に、ＣＲＣデリミタ（ＣＲＣ Ｄｅｌｉｍｉｔｅｒ）でより長いビット時間に戻る。より長いデータフィールドが可能になることによって、有効なデータレートが上げられる。ＣＡＮは、１６個の異なるコードとなるデータ長コード（Ｄａｔａ Ｌｅｎｇｔｈ Ｃｏｄｅ）として４ビットを利用するが、最初の９個の値のみが利用され、コード［０−８］は、［０−８］バイトのデータフィールドの長さを表す。ＣＡＮでは、コード［９−１５］が、８データバイトを示すよう定められている。ＣＡＮ ＦＤでは、当該コードは、より長いデータフィールドを示すために利用される。

ＣＡＮ ＦＤプロトコルは、「ＣＡＮ ｗｉｔｈ Ｆｌｅｘｉｂｌｅ Ｄａｔａ−Ｒａｔｅ仕様書」というタイトルのプロトコル仕様書に記載されており、以下では、ＣＡＮ ＦＤ仕様と呼ばれる。バージョン１．０は、２０１２年４月にリリースされ、ロバートボッシュ社のウェブサイト：ｈｔｔｐ:／／ｗｗｗ.ｓｅｍｉｃｏｎｄｕｃｔｏｒｓ.ｂｏｓｃｈ.ｄｅで一般にダウンロードが可能となった。

変更されていない規格ＣＡＮコントローラが使用されている限り、規格ＣＡＮノードとＣＡＮ ＦＤノードとが混ざったネットワークは、規格ＣＡＮ形式でのみ通信することが可能である。即ち、ネットワーク内の全てのノードが、ＣＡＮ ＦＤ通信のためのＣＡＮ ＦＤプロトコルコントローラを有する必要があるが、全てのＣＡＮ ＦＤプロトコルコントローラは、規格ＣＡＮ通信にも関与することが可能である。ＣＡＮ ＦＤ通信が、８データバイトまでの長さを有するデータフィールドに制限されるならば、コントローラの初期設定とは別にアプリケーションプログラムを変更する必要はない。

本発明は、規格ＣＡＮ実装（Ｎｏｒｍ ＣＡＮ ｉｍｐｌｅｍｅｎｔａｔｉｏｎｓ）の変更について記載し、この変更によって、（ＣＡＮ ＦＤフレームを送信及び受信できない）変更されたＣＡＮ実装は、ＣＡＮ ＦＤフレームを許容するようになる。ＣＡＮ ＦＤに対する許容とは、上記変更された実装が、ＣＡＮ ＦＤフレームを無視し、ＣＡＮ ＦＤフレームを妨害しないということを意味している。このことには、同じバス線を利用する（本発明に従って変更された）ＣＡＮノードとＣＡＮ ＦＤノードとの共存が可能になるという利点がある。ＣＡＮ ＦＤノードは、変更されたＣＡＮノードによって受信されないが許容されるＣＡＮ ＦＤフレームを用いて通信する。変更されたＣＡＮノードは、当該変更されたＣＡＮノードとＣＡＮ ＦＤノードとの両方によって受信される規格ＣＡＮフレームを用いて通信する。

規格ＣＡＮフレームの例である。 ＣＡＮ ＦＤフレームの例である。 メッセージ内のビットレートが切り替えられる位置を示している データ長コードによるデータバイト数の符号化の一例である。 ＡＣＫフィールドを示す。 公称ビット時間を示す。

序論：
コントローラエリアネットワーク（ＣＡＮ：Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）は、非常に高い安全レベルで、分散型の実時間制御を効率良くサポートする直列通信プロトコルである。ＣＡＮの適用範囲は、高速ネットワークから低コストの多重配線にまで至る。自動車エレクトロニクスでは、エンジン制御ユニット、センサ、滑り止めシステム等が、ビットレートが１Ｍｂｉｔ／ｓまでのＣＡＮを用いて接続される。同時に、そうでなければ必要となるワイヤーハーネスと置き換えるために、例えば、照明器具群、パワーウィンドウ等の車体エレクトロニクスを組み込むことの費用対効果が高い。

ＣＡＮ ＦＤ（ＣＡＮ ｗｉｔｈ Ｆｌｅｘｉｂｌｅ Ｄａｔａ−Ｒａｔｅ）は、高速データレートを必要とするアプリケーションにおいて、ＣＡＮを補完する。ＣＡＮ ＦＤプロトコルコントローラは、規格ＣＡＮ通信にも関与することが可能であり、特定の駆動モードでのみ、例えば、ラインの末端でのソフトウェアダウンロード又はメンテナンスにおいて、ＣＡＮ ＦＤを使用することを可能にする。ＣＡＮ ＦＤは、２組のビットタイミング設定レジスタと、アービトレーションフェーズのための１ビット時間と、データフィールドのための１ビット時間と、を必要とする。アービトレーションフェーズのためのビット時間は、規格ＣＡＮネットワーク内と同じ制限があり、データフィールドのためのビット時間は、選択されたトランシーバの性能、及び、ＣＡＮ ＦＤネットワークの特性に鑑みて選択される。
規格ＣＡＮトランシーバは、ＣＡＮ ＦＤのために使用することが可能であり、専用トランシーバは任意選択である。ＣＡＮ ＦＤプロトコルコントローラは、ビットレートがより高いフェーズにおいて専用ＣＡＮ ＦＤトランシーバを他の駆動モードに切り替えるために、追加的なイタフェース信号を提供してもよい。
専用ＣＡＮ ＦＤトランシーバは、ビットレートがより高いフェーズにおいて他の符号化システムを利用してもよく、ＣＡＮのＮＲＺ（Ｎｏｎ−Ｒｅｔｕｒｎ ｔｏ Ｚｅｒｏ、非ゼロ復帰）方式の符号化には限定されない。

ＣＡＮ ＦＤの基本コンセプト：
ＣＡＮ ＦＤフレームは、ＣＡＮフレームと同じ構成要素から成り、相違点は、ＣＡＮ ＦＤフレームでは、データフィールド（Ｄａｔａ Ｆｉｅｌｄ）及びＣＲＣフィールド（ＣＲＣ Ｆｉｅｌｄ）がより長くてもよいということである。メッセージの妥当性確認（ｖａｌｉｄａｔｉｏｎ）には、ＣＡＮのように、少なくとも１つの受信機からのドミナントな（ｄｏｍｉｎａｎｔ）アクノリッジビット（Ａｃｋｎｏｗｌｅｄｇｅ ｂｉｔ）が必要である。エラーフレーム（Ｅｒｒｏｒ Ｆｒａｍｅ）、エラーカウンタ（Ｅｒｒｏｒ Ｃｏｕｎｔｅｒ）、エラーパッシブレベル（Ｅｒｒｏｒ Ｐａｓｓｉｖｅ ｌｅｖｅｌ）、及びバスオフレベル（Ｂｕｓ−ｏｆｆ ｌｅｖｅｌ）によるＣＡＮ ＦＤの障害隔離はＣＡＮと同じであり、同じ５つのエラータイプ、即ち、ビットエラー（Ｂｉｔ Ｅｒｒｏｒ）、スタッフエラー（Ｓｔｕｆｆ Ｅｒｒｏｒ）、ＣＲＣエラー（ＣＲＣ Ｅｒｒｏｒ）、フォームエラー（Ｆｏｒｍ Ｅｒｒｏｒ）、及び、アクノリッジメントエラー（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ Ｅｒｒｏｒ）に基づいている。

フレームフォーマット：
規格ＣＡＮフレーム及びＣＡＮ ＦＤフレームの例は図１に図示されている。

ＣＡＮ ＦＤは、ＣＡＮプロトコルの２つの識別子の長さ、即ち、１１ビット長の「標準フォーマット」と、２９ビット長の「拡張フォーマット」と、をサポートする。ＣＡＮ ＦＤフレームはＣＡＮフレームと同じ構造を有し、ＣＡＮフレームとＣＡＮ ＦＤフレームとの相違点は、通常では「ｒ０」又は「ｒ１」と呼ばれる予約ビットであり、コントロールフィールド内のデータ長コードの前に位置付けられている。ＣＡＮ ＦＤフレームでは、このビットは、レセッシブ（ｒｅｃｅｓｓｉｖｅ）で送信され、ＥＤＬと呼ばれる。ＥＤＬの後には、規格ＣＡＮフレームと比べて追加的なコントロールフィールドのビットが続き、例えば、ＢＲＳが続く。

図２は、メッセージ内のビットレートが切り替えられる位置を示している。

プロトコルを区別する予約ビットまでの、ＣＡＮ ＦＤフレームの最初の部分は、ＣＡＮフレームと同じビットレートで送信される。レセッシブなＥＤＬビットが受信された場合には、ＲＢＳビットの値に従って、ビットレートが切り替えられる。ビットレートは、ＢＲＳビットで始まりＣＲＣデリミタに達するまで切り替えられ、又は、ＣＡＮ ＦＤコントローラがエラー状況を検知しＣＡＮエラーフレームが開始されることになるまで切り替えられる。ＣＡＮ ＦＤエラーフレームは、ＡＣＫフィールド、エンドオブフレーム、及びオーバーロードフレームと同様に、ＣＡＮエラーフレームと同じビットレートで送信される。ビットレートは予約ビットＢＲＳのところで、当該予約ビットＢＲＳがレセッシブで送信された場合に、より短いビット時間へと切り替えられる。このことが図２に、「ＣＡＮ ＦＤアービトレーション（Ａｒｂｉｔｒａｔｉｏｎ）」（低いビットレートが利用される）という名の２つの部分で囲まれた１つの部分「ＣＡＮ ＦＤデータ（Ｄａｔａ）」（高いビットレートが使用される）にＣＡＮ ＦＤメッセージを分ける矢印で示されている。

データフィールド内でのバイト数は、データ長コード（Ｄａｔａ Ｌｅｎｇｔｈ Ｃｏｄｅ）により示される。このデータ長コードは４ビット幅であり、コントロールフィールド内で送信される。

データ長コードの符号化は、ＣＡＮ ＦＤでは異なっている。最初の９個のコードは同じであるが、ＣＡＮで８バイトのデータフィールドを規定する後続のコードは、ＣＡＮ ＦＤでは、より長いデータフィールドを規定する。全てのリモートフレーム（Ｒｅｍｏｔｅ Ｆｒａｍｅ）は、対応するデータフレームのデータ長コードに関係なく、ゼロのデータ長コードを利用する。

データ長コードによるデータバイト数の符号化の一例が、図３に記載されている。

ＣＲＣフィールド（ＣＲＣ Ｆｉｅｌｄ）は、ＣＲＣシーケンスを含み、ＣＲＣシーケンスの後にＣＲＣデリミタ（ＣＲＣ ＤＥＬＩＭＩＴＥＲ）が続く。

ＣＲＣシーケンス：フレームチェックシーケンスは、巡回冗長コード（ＢＣＨコード）に由来する。
ＣＲＣ演算を行うために、除算すべき多項式は、その係数が関連するビットストリームにより与えられる多項式として定められる。ＣＡＮ ＦＤは、異なるフレームの長さについて、異なるＣＲＣ多項式を利用する。８データバイトまでのフレームについては、ＣＡＮと同じ多項式が利用される。８データバイトまでのフレームについて、関連するビットストリームは、スタートオブフレーム（ＳＴＡＲＴ ＯＦ ＦＲＡＭＥ）と、アービトレーションフィールド（ＡＲＢＩＴＲＡＴＩＯＮ ＦＩＥＬＤ）と、コントロールフィールド（ＣＯＮＴＲＯＬ ＦＩＥＬＤ）と、（もし存在するのであれば）データフィールド（Ｄａｔａ Ｆｉｅｌｄ）と、１５番目の最下位の係数のために０と、で構成される、デスタッフ処理された（ｄｅｓｔｕｆｆｅｄ）ビットストリームである。この多項式は、ハミング距離（ＨＤ＝Ｈａｍｍｉｎｇ Ｄｉｓｔａｎｃｅ)＝６で、ビットカウントが１２７ビットより小さいフレームに最も適した生成多項式、即ち、
Ｘ１５＋Ｘ１４＋Ｘ１０＋Ｘ８＋Ｘ７＋Ｘ４＋Ｘ３＋１
により除算される（係数は、モジュロ２（ｍｏｄｕｌｏ−２）演算される）。
データフィールド内の、８バイトより大きいフレームについては、フレームの長さに対して調整された、異なる（及び、より長い）ＣＲＣ多項式が利用される。ＣＲＣフィールドは、これに応じて延長される。より長いフレームでは、ＣＲＣシーケンスの前に発生するスタッフビット（Ｓｔｕｆｆ Ｂｉｔ）も、ＣＲＣにより保護される。
各ＣＲＣシーケンスは、別のシフトレジスタブロック（ｓｈｉｆｔ ｒｅｇｉｓｔｅｒ ｂｌｏｃｋ）で計算される。フレームの開始時には、全てのノードにおいて、全てのＣＲＣシーケンスが、アービトレーションの後にＣＲＣシーケンスのうちの１つが予約ビット及びＤＬＣにより選択されるまで、同時に計算される。選択されたＣＲＣシーケンスのみが、ＣＲＣエラー（ＣＲＣ Ｅｒｒｏｒ）を起動することが可能である。

ＣＲＣデリミタ（ＣＲＣ ＤＥＬＩＭＩＴＥＲ）：ＣＲＣシーケンスの後には、１個又は２個の「レセッシブ」ビットで構成されるＣＲＣデリミタが続く。送信機は、ＣＲＣデリミタとして「レセッシブ」ビットを１個だけ送信するが、全てのノードは、アクノリッジスロット（Ａｃｋｎｏｗｌｅｄｇｅ Ｓｌｏｔ）を開始するレセッシブからドミナントへのエッジの前で、２個の「レセッシブ」ビットを受け取るものとする。
注：ＣＲＣデリミタが検出された場合には、ＣＡＮ ＦＤプロトコルコントロ―ラは、ビット時間がより長いビットレートへ戻して切り替える。
ＣＡＮネットワーク内でのノード間の位相のずれは、トランシーバ内での遅延時間、及び、ＣＡＮバス線上での遅延時間により定められる。位相のずれは、ＣＡＮ内、ＣＡＮ ＦＤ内において同じであるが、ビット時間がより短い位相においては、位相のずれが比例して長い。ネットワーク内の全ての受信機は、様々な時間に送信されたエッジを検出するため、送信機に対して異なる位相のずれを有する可能性がある。より長いビット時間へと戻してビットレートが切り替えられた場合に上記の位相のずれを補正するために、アクノリッジスロットを開始するレセッシブからドミナントなエッジの前及び後で、追加的な１ビット時間分の公差が許容される。

ＡＣＫフィールド（ＡＣＫ ＦＩＥＬＤ）は、２又は３ビット長であり、図４に示すように、ＡＣＫスロットと、ＡＣＫデリミタと、を含む。ＡＣＫフィールドでは、送信局が、２個の「レセッシブ」ビットを送信する。有効なメッセージを正しく受信した受信機は、このことを送信機に、ＡＣＫスロットの間に「ドミナント」ビットを送信することにより報告する（受信機は「ＡＣＫ」を送信する）。

ＡＣＫスロット（ＡＣＫ ＳＬＯＴ）：一致するＣＲＣシーケンスを受信した全ての局は、このことを、「ドミナント」ビットで、送信機の「レセッシブ」ビットを上書きすることにより、ＡＣＫスロット内で報告する。受信機間の位相のずれを補正するために、全てのノードは、有効なＡＣＫとしてＡＣＫビットが重畳された２ビット長の「ドミナントな」フェーズを受け入れる。

ＡＣＫデリミタ（ＡＣＫ ＤＥＬＩＭＩＴＥＲ）：ＡＣＫデリミタは、ＡＣＫフィールドの第２又は第３番目のビットであり、「レセッシブ」ビットである必要がある。結果的に、ＡＣＫスロットは、２個の「レセッシブ」ビット（ＣＲＣデリミタ、ＡＣＫデリミタ）で囲まれる。

エンドオブフレーム（ＥＮＤ ＯＦ ＦＲＡＭＥ）：各データフレーム及びリモートフレームは、７個の「レセッシブ」ビットから成るフラグシーケンスにより区切られる。

ビットタイミング（ＢＩＴ ＴＩＭＩＮＧ）要件：
ＣＡＮ ＦＤプロトコルは、２つのビットレート、即ち、ビット時間がより長い第１のビットレートと、ビット時間がより短い第２のビットレートと、を定める。第１のビットレートの定義は、ＣＡＮプロトコル仕様書の公称ビットレート（ＮＯＭＩＮＡＬ ＢＩＴ ＲＡＴＥ）及び公称ビット時間（ＮＯＭＩＮＡＬ ＢＩＴ ＴＩＭＥ）についての定義と同じである。第２のビットレートの定義は、別の設定レジスタセットを必要とする。２つのビット時間は、重畳しない異なるタイムセグメントで構成され、これらタイムセグメント、即ち、
・同期化セグメント（ＳＹＮＣ＿ＳＥＧ：ＳＹＮＣＨＲＯＮＩＺＡＴＩＯＮ ＳＥＧＭＥＮＴ）と、
・遅延時間セグメント（ＰＲＯＰ＿ＳＥＧ：ＰＲＯＰＡＧＡＴＩＯＮ ＴＩＭＥ ＳＥＧＭＥＮＴ）と、
・位相バッファセグメント１（ＰＨＡＳＥ＿ＳＥＧ１：ＰＨＡＳＥ ＢＵＦＦＥＲ ＳＥＧＭＥＮＴ１）と、
・位相バッファセグメント２（ＰＨＡＳＥ＿ＳＥＧ２：ＰＨＡＳＥ ＢＵＦＦＥＲ ＳＥＧＭＥＮＴ２）と、
は、図５に示されるビット時間を構成する。

ＣＡＮ ＦＤプロトコルの２つのビットレートのためのタイムセグメントは、２組の設定レジスタによって定められる。

ＳＹＮＣ ＳＥＧ：ビット時間のこの部分は、バス上の様々なノードを同期化させるために利用される。エッジがこのセグメント内に存在することが期待される。

ＰＲＯＰ ＳＥＧ：ビット時間のこの部分は、ネットワーク内での物理的な遅延時間を補正するために利用される。ＰＲＯＰ ＳＥＧは、バス線上での信号の遅延時間と、入力比較器の遅延と、出力ドライバ遅延と、の合計の２倍の長さである。

ＰＨＡＳＥ ＳＥＧ１、ＰＨＡＳＥ ＳＥＧ２：この位相バッファセグメントは、エッジの位相エラーを補正するために利用される。このセグメントは、再同期化によって延長され又は短縮されうる。

サンプルポイント（ＳＡＭＰＬＥ ＰＯＩＮＴ）：サンプルポイントは、バスレベルが読み込まれて、対応するビットの値として解釈される時点である。サンプルポイントの位置は、ＰＨＡＳＥ＿ＳＥＧ１の終りにある。

情報処理時間：情報処理時間は、後続のビットレベルの計算のために予約された、サンプルポイントで開始するタイムセグメントである。
このセグメントの長さは、タイムクォンタム（ＴＩＭＥ ＱＵＡＮＴＵＭ）の整数倍で定められ、このタイムクォンタムとは、発振子の周期に由来する固定の時間単位である。少なくとも１〜３２の範囲の整数値による、プログラム可能なプリスケーラ（ｐｒｅｓｃａｌｅｒ）が存在する。最小タイムクォンタムから始まって、タイムクォンタムは以下の長さを有する。即ち、
タイムクォンタム（ｎ）＝ｍ（ｎ）＊最小タイムクォンタム
但し、ｍはプリスケーラの値
プリスケーラの２つの値、即ち、ｍ（１）及びｍ（２）がＣＡＮ ＦＤプロトコルでは定められ、即ち、それぞれが各ビットレートのための値であり、異なる２つの長さのタイムクォンタムをもたらす。

第１のビットレートのタイムセグメントの長さ：
・ＳＹＮＣ＿ＳＥＧ（１）は、長さが１タイムクォンタム（１）である。
・ＰＯＲＰ＿ＳＥＧ（１）は、長さ１、２、…、８タイムクォンタム（１）にプログラム可能である。
・ＰＨＡＳＥ＿ＳＥＧ１（１）は、長さ１、２、…、８タイムクォンタム（１）にプログラム可能である。
・ＰＨＡＳＥ＿ＳＥＧ２（１）は、ＰＨＡＳＥ＿ＳＥＧ（１）の最大値及び情報処理時間である。
・情報処理時間は、２タイムクォンタム（１）より短く、又は、２タイムクォンタム（１）と等しい。

第２ビットレートのタイムセグメントの長さ
・ＳＹＮＣ＿ＳＥＧ（２）は、長さが、１タイムクォンタム（２）である。
・ＰＯＲＰ＿ＳＥＧ（２）は、長さ０、１、２、…、８タイムクォンタム（２）にプログラム可能である。
・ＰＨＡＳＥ＿ＳＥＧ１（２）は、長さ１、２、…、８タイムクォンタム（２）にプログラム可能である。
・ＰＨＡＳＥ＿ＳＥＧ２（２）は、ＰＨＡＳＥ＿ＳＥＧ（２）の最大値及び情報処理時間である。
・情報処理時間は、２タイムクォンタムより短く、又は、２タイムクォンタムと等しい。

ビット時間におけるタイムクォンタムの合計数は、少なくとも８〜２５にプログラム可能である必要がある。
サンプルポイントの位置は、２つのビットタイミング設定において異なっていてもよく、ＰＲＯＰ＿ＳＥＧの長さは、第２のビットレートのための設定において短縮されてもよい。

ＣＡＮ ＦＤ実装：
ＣＡＮ ＦＤプロトコルによる実装は、既存のＣＡＮアプリケーションための簡単な移行経路を提供するために、ＣＡＮプロトコルによる実装と同じコントローラ・ホストインタフェースを提供するものである。必要となる最小の相違は、ＣＡＮ ＦＤ駆動のための新しい設定レジスタである。
ＣＡＮ ＦＤプロトコルは、８データバイトよりも大きいフレームを可能とする。全てのＣＡＮ ＦＤ実装が、より長いフレームをサポートすることは求められておらず、ＣＡＮ ＦＤ実装は、データフィールド長の一部（ｓｕｂｓｅｔ）に制限されてもよい。フレーム内で例えば８データバイトまでのみサポートするＣＡＮ ＦＤ実装は、受信されたより長いフレームをエラーとして扱わず、エラーの無いより長いフレームが肯定応答されアクセプタンスフィルタリング（ａｃｃｅｐｔａｎｃｅ ｆｉｌｔｅｒｉｎｇ）に関与する。ＣＡＮ ＦＤのデータ処理容量を超える、受信されたデータバイトは破棄される。より長いフレームを送信することが要求されているこのような限定されたＣＡＮ ＦＤ実装は、一定のバイトパターンを有するデータ処理容量を超えたフレーム内のデータバイトを充填するものである。このバイトパターンは、例えば０ｘ３３のスタッフビットの挿入を引き起こさないように選択される。

ＣＡＮ ＦＤに対するＣＡＮ実装の許容：
ＣＡＮ ＦＤは、ＣＡＮプロトコルと物理層を共有する。しかしながら、フレーム形式は異なっている。ＣＡＮ ＦＤフレームには２つの新しい制御ビットがあり、即ち、第１の制御ビットはＥＤＬと呼ばれ、異なるデータ長符号化が行われる新しいフレーム形式を可能にし、第２の制御ビットはＢＲＳと呼ばれ、調停が決定された後でより速いビットレートに任意に切り替える。定評のあるＣＡＮプロトコルとハミング距離が同じであるより長いＣＡＮ ＦＤフレームを保証するために、新しいＣＲＣ多項式が導入される。ＣＡＮ ＦＤのフレーム形式は、ＣＡＮフレーム形式によるメッセージとＣＡＮ ＦＤフレーム形式によるメッセージとが、同じネットワーク内で共存できるように定められている。

本発明は、ＣＡＮ実装がＣＡＮ ＦＤフレームを許容することを可能にする規格ＣＡＮプロトコルの変更を記載する。ＣＡＮ ＦＤフレームを許容するとは、ＣＡＮ ＦＤフレームが無視され、妨害されないということを意味している。

ＣＡＮ ＦＤ仕様によれば、ＣＡＮ ＦＤ仕様に従って設計されたＣＡＮ ＦＤ実装と、ボッシュＣＡＮ仕様２．０に従って設計された規格ＣＡＮ実装とは、ＣＡＮ ＦＤフレーム形式が使用されない限りは、互いに通信することが可能である。このことによって、ＣＡＮシステムは、ＣＡＮ ＦＤシステムへと段階的に移行することが可能となる。導入段階では、例えば、ＣＡＮ ＦＤをサポートしない他のコントローラがスタンドバイ状態にある間のラインの末端でのプログラミング時のソフトウェアダウンロードのような、特定の動作モードでのみＣＡＮ ＦＤを利用することが可能である。

ＣＡＮ ＦＤ実装は、全てのＣＡＮフレームを復号することが可能であるが、ボッシュＣＡＮ仕様２．０又はＩＳＯ１１８９８−１に準拠した規格ＣＡＮ実装は、エラーフレームでＣＡＮ ＦＤフレームを破壊するであろう。

本発明は、ＣＡＮ実装がＣＡＮ ＦＤフレームを許容する（即ち、ＣＡＮ ＦＤフレームが無視され、破壊されないことを意味する）ようにする規格ＣＡＮプロトコルの変更について記載する。ＣＡＮプロトコルに既に備わる２つの特徴が、ＣＡＮ実装がＣＡＮ ＦＤを許容するようにするために組み合わされる。第１の特徴は、再起動の後で、又は、ＢＵＳ＿ＯＦＦ ＲＥＣＯＶＥＲＹ ＳＥＱＵＥＮＣＥの間にＣＡＮ実装がバスアクティビティに対して同期している場合に、１１個の連続するレセッシブビットの発生を確認するために利用されるカウンタである。第２の特徴は、ビット同期化のための基準としてのタイムクォンタムごとに一度、ＣＡＮバス入力値をサンプルするエッジの検出システムである。

ＣＡＮ ＦＤ ＥＤＬ管理：
本発明に従って変更されたＣＡＮ実装は、以下の仕組みを利用することによって、ＣＡＮ ＦＤを許容するようになる。即ち、標準フォーマットによる規格ＣＡＮフレーム内のビット位置ｒ０で、又は、拡張フォーマットによる規格ＣＡＮフレーム内のビット位置ｒ１で（例えば、ＣＡＮ ＦＤフレームのＥＤＬビットに対応する、図１ａ及び図１ｂ参照）リセッシブビットが検出された直後に、変更されたＣＡＮ実装は、自身のプロトコル復号ステートマシンを再起動する。ＣＡＮ実装は、自身のエラーカウンタを変更することなく、又は、エラーフレームを送信することなく再起動し、以下に記載するようにＣＡＮ ＦＤリカバリを行う。

ＣＡＮ ＦＤリカバリ：
ＣＡＮ ＦＤリカバリ（ＣＡＮ ＦＤ Ｒｅｃｏｖｅｒｙ）は、上述したように、プロトコル復号ステートマシンの再起動を開始する。その後、プロトコル復号ステートマシンは、連続する１１個のレセッシブビットのシーケンスを確認することによりバスアクティビティ（ｂｕｓ ａｃｔｉｖｉｔｙ）に同期するまで待機する。上記シーケンスの中に、レセッシブからドミナントへのエッジが存在してはならず、このようなエッジはビットカウントを再起動する。上記シーケンスが検出された場合には、ユニットはアイドル状態になり、受信機又は送信機に切り替わりながらスタートオブフレームへの準備態勢を整える。

このような仕組みの利点は、変更されたＣＡＮノードが、ＣＡＮ ＦＤメッセージが連続して送信されてしまうまで（又は、エラーの原因がＣＡＮ ＦＤノードによって検出された場合にエラーフレームにより中断されるまで）待機することが想定されることである。ＣＡＮ ＦＤメッセージの送信中には、連続する１１個のレセッシブビットのシーケンスの要件が満たされることは決してなく、従って、変更されたＣＡＮノードは、上述のようにＣＡＮ ＦＤリカバリを終了しないであろう。従って、ＣＡＮ ＦＤリカバリ方法によって、変更されたＣＡＮ実装は、全てのＣＡＮ ＦＤフレームを許容するようになる。

ＣＡＮ ＦＤフレームのデータフェーズでのビット時間（図２参照）が、ＣＡＮ ＦＤアービトレーションフェーズ内の１タイムクォンタムよりも短くないことは有利である。そうでなかったら、稀なケースであるが、ＣＡＮ ＦＤフレーム内で連続する１１個のレセッシブビットが、変更されたＣＡＮノードにより検知されるということが起こりうる。

ＣＡＮ ＦＤフレームの検出によって、エラーカウンタの増分は引き起こされず、ＣＡＮ実装は、ＣＡＮ ＦＤフレームが終了した直後にバスアクティビティを再開することが可能である。

Claims (9)

1. バスシステムにより接続された送信ノードと少なくとも１つの受信ノードとの間のデータフレームの交換による直列通信のための方法であって、
   ＣＡＮ規格ＩＳＯ１１８９８−１で定義された調停手続きによって、データフレームごとに送信者及び受信者の役割がノードに割り当てられ、
   交換される前記データフレームは、ＣＡＮ規格ＩＳＯ１１８９８−１に準拠した論理構造を有し、
   前記データフレームは、ビットのシーケンスで構成され、
   前記データフレームの前記論理構造は、スタートオブフレームビット、アービトレーションフィールド、コントロールフィールド、データフィールド、ＣＲＣフィールド、アクノリッジフィールド、及びエンドオブフレームフィールドを含み、
   各ビットは、ビット時間を有し、
   各ビット時間は、タイムセグメント（ＳＹＮＣ＿ＳＥＧ、ＰＲＯＰ＿ＳＥＧ、ＰＨＡＳＥ＿ＳＥＧ１、ＰＨＡＳＥ＿ＳＥＧ２）に分けられる、前記方法において、
   前記コントロールフィールド内の特定ビットの所定の値に応じて、第１のノード群に属する第１のノードが、自身のプロトコル復号ステートマシンを再起動し、自身がバスアクティビティに同期するまで待機し、
   第２のノード群に属する第２のノードが、ＣＡＮ ＦＤ仕様に準拠した通信プトロコルを用いて通信することを特徴とする、方法。
2. 前記第１のノードは、自身のエラーカウンタを変更することなく、自身のプロトコル復号ステートマシンを再起動することを特徴とする、請求項１に記載の方法。
3. 前記第１のノードは、エラーフレームを送信することなく、自身のプロトコル復号ステートマシンを再起動することを特徴とする、請求項１又は２に記載の方法。
4. 前記第１のノードは、連続する１１個のレセッシブビットのシーケンスを確認することにより、前記バスアクティビティに同期することを特徴とする、請求項１〜３のいずれか１項に記載の方法。
5. 前記第２のノードは、送信された前記フレームのＣＡＮ ＦＤデータフェーズでは、より短いビット時間を利用して通信し、
   前記ＣＡＮ ＦＤデータフェーズは、前記コントロールフィールドの送信中に開始し、前記アクノリッジフィールドの送信中に終了し、
   前記タイムセグメントの長さは、タイムクォンタムの整数倍で定義され、前記タイムクォンタムは、発振子の周期から得られる固定の時間単位であり、
   前記ＣＡＮ ＦＤデータフェーズ内の前記ビット時間は、ＣＡＮ ＦＤアービトレーションフェーズ内の１タイムクォンタムよりも短くないことを特徴とする、請求項１〜４のいずれか１項に記載の方法。
6. バスシステムにより接続された送信ノードと少なくとも１つの受信ノードとの間のデータフレームの交換による直列通信のための装置であって、
   ＣＡＮ規格ＩＳＯ１１８９８−１で定義された調停手続きによって、データフレームごとに送信者及び受信者の役割がノードに割り当てられ、
   交換される前記データフレームは、ＣＡＮ規格ＩＳＯ１１８９８−１に準拠した論理構造を有し、
   前記データフレームは、ビットのシーケンスで構成され、
   前記データフレームの前記論理構造は、スタートオブフレームビット、アービトレーションフィールド、コントロールフィールド、データフィールド、ＣＲＣフィールド、アクノリッジフィールド、及びエンドオブフレームフィールドを含み、
   各ビットは、ビット時間を有し、
   各ビット時間は、タイムセグメント（ＳＹＮＣ＿ＳＥＧ、ＰＲＯＰ＿ＳＥＧ、ＰＨＡＳＥ＿ＳＥＧ１、ＰＨＡＳＥ＿ＳＥＧ２）に分けられる、前記装置において、
   受信されたデータフレームの前記コントロールフィールド内の特定ビットの所定の値に応じて、前記装置は、自身のプロトコル復号ステートマシンを再起動し、自身がバスアクティビティに同期するまで待機することを特徴とする、装置。
7. 前記装置は、自身のエラーカウンタを変更することなく、自身のプロトコル復号ステートマシンを再起動することを特徴とする、請求項６に記載の装置。
8. 前記装置は、エラーフレームを送信することなく、自身のプロトコル復号ステートマシンを再起動することを特徴とする、請求項６又は７に記載の方法。
9. 前記装置は、連続する１１個のレセッシブビットのシーケンスを確認することにより、前記バスアクティビティに同期することを特徴とする、請求項６〜８のいずれか１項に記載の方法。
   

Images