データ・リンク層
ARINC 825は、ISO 11898-1に従い、ISO CAN2.0B、CAN拡張フレーム（29ビットID）にのみ基づいています。 デッドロックの可能性がない場合、標準フレーム（11ビット識別子）に基づくCANプロトコルをARINC 825と共に使用できます。
ISO 11898-1では、データ・リンク層（DLL）と物理的な信号が指定されています。CAN DLLを実装するモジュール間でデジタル情報の交換を設定するための特性を提供します。 論理リンク制御（LLC）および、メディア・アクセス制御（MAC）サブ層を含みます。
フレーム・タイプ
CANは次のフレーム・タイプを定義します：
- データ・フレーム
- エラー・フレーム
- リモート・フレーム
- オーバーロード・フレーム
データ・フレーム
データ・フレームは、情報を転送する目的を持っています。CAN 2.0B拡張フォーマットのデータ・フレームを図3-1 CANデータ・フレーム構造に示します。 CANはデータ転送のためのオブジェクト指向のアプローチを使用するブロードキャスト・バスです。CANデータ・フレーム（図3-1）は、 0～8バイトのペイロード・サイズを持ち、CAN ID（アイデンティファイヤ）が前についています。このCAN IDは2つの目的を果たします。
第1に、IDによって送信されるデータ・フレームの優先順位を決定し、最も低い数値のIDが最も高い優先度になります。 優先度は、複数のモジュールが同時にバス上で送信しようとしている場合に、送信されるメッセージの順序に直接影響を与えます。 第2に、CAN IDはデータ・フレームを一意に識別し、データ・ペイロードを受信ノードで正しく処理できるようにします。 CANは「標準」および「拡張」アイデンティファイヤと呼ばれる、異なる長さ（11ビットおよび29ビット）の2つのバージョンのアイデンティファイヤをサポートしています。 どちらのタイプも同じバス上に共存でき、互いに干渉しません（ARINC 825はより大きなアドレス空間のために29ビットの識別子のみを使用します）。
図3-1 データ・フレーム構造
- Inter-Frame Space
- 最小3レセッシブ・ビット
- Start Of Frame（SOF）
- データ・フレームおよびリモート・フレームの先頭を表す。1ビットのドミナント・ビットで構成されます。 ノードは、バスがアイドル状態のときのみ送信を開始することができます。すべてのノードは、Start Of Frameによって引き起こされるリーディング・エッジに同期する必要があります。
- Arbitration Field
- 調停を行う時に使用されるフィールド、32ビットで構成される。ARINC 825では拡張アイデンティファイヤが使用される。
- CANアイデンティファイヤ ベースID
- 標準フォーマットにおけるIDは、拡張フォーマットでは「ベースID」と呼ばれます。11ビット長で、この部分は標準フォーマットと同一です。 拡張フォーマット・アイデンティファイヤ・フィールドは、11ビットのベース・アイデンティファイヤと18ビットのアイデンティファイヤ拡張フィールドを含みます。 結合された29ビットのアイデンティファイヤ・フィールド（ID）は、メッセージの優先順位を確立するために使用される独自のビットパターンを提供し、フレーム・コンテンツを記述するために使用されます。 各ノードは、IDに応じてフレームを処理するかどうかを決定します。優先度はIDフィールドに基づいて行われ、IDフィールドの値が小さいほど高い優先度のメッセージを示します。
- Substitute Remote Request （SSR）
- ベースIDに続くのは「SRR（Substitute Remote Request Bit）」で、1ビット長のレセッシブとなっています。 このビットは、29ビット拡張フレーム・メッセージとの衝突において、11ビットのベースフレーム・メッセージが確実に存在することを保証するために使用されます。 ARINC 825は29ビット拡張フォーマット・フレームタイプのみを使用するので、このビットは常にARINC 825メッセージに対してレセッシブとして送信されます。
- Identifier Extension Flag（IDE）
- SRRの後には「IDE（Identifier Extension Bit）」が送信されます。これも1ビット長のレセッシブです。 ARINC 825は29ビット拡張フォーマット・フレームタイプのみを使用するので、このビットは常にARINC 825メッセージに対してレセッシブとして送信されます。
- CANアイデンティファイヤ 拡張ID
- IDEに続いて送信されるのは「拡張ID」で、18ビット長です。ベースIDと拡張IDを併せて29ビット長 となり、これによりIDを表します。 拡張フォーマットの29ビット長IDの範囲は0x0～0x1FFFFFFFと なり、536,870,912種類（約540万種）を使用することが可能となります。
- Remote Transmission Request（RTR）
- データ・フレーム・・・RTRビット＝０（ドミナント）
- リモート・フレーム・・・RTTビット＝１（レセッシブ）
- ARINC 825はリモート・フレームの使用を嫌うので、このビットは常にARINC 825メッセージに対してドミナントとして送信されます。
- Control Field
- データ・フレームに含まれるデータのサイズを表すフィールドです。
- r1 （1ドミナント・ビット）
- r0 （1ドミナント・ビット）
- Data Length Code（DLC）
- 4ビットのフィールドで、データのサイズを表します。DLCフィールドは、データ・フレームで送信されるデータバイト数を定義します。 ISO CAN 2.0Bは、最大8データバイトを提供します。DLCがゼロのとき、データ・フィールドはありません。各バイトは8ビットを含み、最上位ビット（MSB）が最初に転送されます。 CAN 2.0フォーマットに使用される4ビットフィールドのコーディングを表4-1 に示します。
| データバイト数 | ータ長コード | ||||
| DLC3 | DLC2 | DLC1 | DLC0 | ||
| CAN 2.0B | 0 | 0 | 0 | 0 | 0 |
| 1 | 0 | 0 | 0 | 1 | |
| 2 | 0 | 0 | 1 | 0 | |
| 3 | 0 | 0 | 1 | 1 | |
| 4 | 0 | 1 | 0 | 0 | |
| 5 | 0 | 1 | 0 | 1 | |
| 6 | 0 | 1 | 1 | 0 | |
| 7 | 0 | 1 | 1 | 1 | |
| 8 | 1 | 0 | 0 | 0 | |
- Data Field
- データ・フィールドは、転送されるデータバイト数を含みます。転送されるデータバイト数は、表3-1 データ長コードで定義されたDLCフィールドで定義されます。 各バイトは8ビットを含み、MSBが最初に転送されます。
- CRC Field
- フレームが正しいかチェックをする際に使用します。16 ビットで構成されます。15 ビットのCRC シーケンス、1 ビットのCRC デリミタから構成されます。CRC シーケンスの生成多項式は以下の通りです。
- X15 + X14 + X10 + X8 + X7 + X4 + X3 + 1
- なお対象はStart of Frame、Arbitration field、Control field、Data field（存在する場合）です。 生成されたCRC シーケンスは最上位ビットから出力が行われます。CRC デリミタは1 ビットのレセッシブ・ビットです。 CRC デリミタがレセッシブ以外のレベルだった場合、フォーム・エラーが発生します。
- Acknowledge field
- ACKフィールドは、ACKスロットおよびACKデリミタ・ビットを含み、これらは送信ノードによってレセッシブとして送信されます。 CANコントローラが、受信フレームがCAN整合フレームであると判断した場合、ネットワーク上のすべてのノードがドミナントなACKビットを送信します。 フレームが承認されると、少なくとも1つのノードがフレームを受信したことを意味します。ACKメカニズムは、データの整合性を示すものではなく、フレームの一貫性のみを示します。
図3-2 ACKメカニズム
- End of Frame
- データ・フレームの終了を表すフィールドです。 7 ビットのレセッシブ・ビットで構成されます。End of Frame にレセッシブ以外のビットが含まれる場合、フォーム・エラーが発生します。
エラー・フレーム
エラー・フレームは、2つの異なるフィールドで構成されています。最初のフィールドは、異なるノードから提供されたエラー・フラグの重ね合わせによって与えられます。 2番目のフィールドはエラー・デリミタです。
エラー・フラグには2つの形式があります：アクティブ・エラーフラグ、およびパッシブ・エラーフラグです。アクティブ・エラーフラグは、6つの連続する「ドミナント」ビットで構成されます。 パッシブ・エラーフラグは、6つの連続する「レセッシブ」ビットで構成されます。パッシブ・エラーフラグの一部またはすべてのビットは、他のノードからの「ドミナント」ビットによって上書きされる可能性があります。
リモート・フレーム
CAN 2.0Bフォーマット・フレームでは、リモート・フレームはCANノードからデータを要求するタスクを持ち、データ・フレームは要求されたデータをデータ・フレームによって送信します。 リモート・フレームの使用はARINC 825では推奨されていません。 リモート・フレームを使用しない理由は、ISO 11898-1のデータ長コード（DLC）のあいまいな定義に起因する異なるコントローラタイプ間での互換性の問題があるからです。 リモート・フレームは、他のARINC 825通信メカニズムが同じタスクを達成できない場合にのみ使用してください。
オーバーロード・フレーム
ビジー状態のため、現在CANコントローラがフレームを受信できないことを他のCANノードに伝えるために、オーバーロード・フレームを送信することができます。 オーバーロード・フレームは、次のデータグラムの開始を遅らせます。
ノードは、ネットワークの負荷を増加させ、ネットワークの信頼性と可用性を低下させるため、オーバーロード・フレームを開始すべきではありません。
調停
CANはマルチ・マスタバスであるため、同時に複数のノードがバスにアクセスしてメッセージの転送を行うことで発生するバスの競合を解決する必要があります。 この目的のためにCANは、衝突回避型キャリアセンス（CSMA／CA）と呼ばれる非破壊的調停方式を使用します。この利点は、調停プロセスによって帯域幅が失われないことです。 ネットワーク上のすべてのノードは、バス・トラフィックを継続的に監視しそれに応じて動作します。ノードが調停を失った場合、ノードは保留中のデータ・フレームを送信するまで次の調停フェーズに自動的に参加します。
CANでは、自分の出力したレベルと、バス上の実際のレベルを常に監視しています。
ドミナントを出力するノードがいると、バスはドミナント・レベルになります。
以下の真理値表は、3ノード・システムが与えられた場合の調停プロセスの各ビットのバス状態を示しています。
| ノード1 | ノード2 | ノード3 | CANバス | コントローラ監視状態 | コメント |
| 0 | 0 | 0 | 0 | バスはドミナント状態 | 調停は次の段階へ進む |
| 0 | 0 | 1 | 0 | ノード3は調停負け | ノード1および2は、次のビットへの調停を継続する。ノード3は調停負けでバックオフします。 |
| 0 | 1 | 0 | 0 | ノード2は調停負け | ノード1および3は、次のビットへの調停を継続する。ノード2は調停負けでバックオフします。 |
| 0 | 1 | 1 | 0 | ノード1が調停勝ち | ノード1が調停勝ちし、現在のバスを制御しています。 |
| 1 | 0 | 0 | 0 | ノード1は調停負け | ノード2および3は、次のビットへの調停を継続する。ノード1は調停負けでバックオフします。 |
| 1 | 0 | 1 | 0 | ノード1と3は調停負け | ノード2が調停勝ちし、現在のバスを制御しています。 |
| 1 | 1 | 0 | 0 | ノード1と2は調停負け | ノード3が調停勝ちし、現在のバスを制御しています。 |
| 1 | 1 | 1 | 1 | バスはレセッシブ状態 | 調停は現在次のビットに続く。 |
図3-3 調停の仕組み
ビット・スタッフ
CAN プロトコルでは、連続した同一ビットが続くことによる、同期ずれのエラーを防止するため、ビット・スタッフを行います。 ビット・スタッフとは、連続した5 ビットの同一レベルが出力された場合、次に1 ビット、反転したビットを付加します。このビットは受信する際には取り除かれて受信されます。 なお、この処理が行われるのは、後述するデータ・フレームとリモート・フレームの2 種類のフレームにおいてのみです。また対象となる範囲はStart Of Frame～CRC フィールドの間です。
エラー処理
CANは伝送中にエラーを認識するさまざまな方法を使用します。これらの方法は、エラー認識、エラー処理、エラー格納の3つの部分に分かれています。 ISO 11898で規定されるエラー認識とフォルト・トレランス性能は、達成すべき最小の基準です。
エラー管理によって検出される5つの異なる障害タイプがあります：
- ビット・エラー
- ビット・スタッフ・エラー
- CRCエラー
- フォーマット・エラー
- ACKエラー
ビット・エラー
トランシーバは自身の送信を監視し、メッセージの送信ビットと受信ビットとを比較することによってビット誤りを検出することができます。 ビット・エラーは、送信されたビットが最初に送信されたのと同じ論理値で受信されなかったことを意味します。例外は、アイデンティファイヤ・ビットとACKタイムスロットです。
ビット・スタッフ・エラー
ビットスタッフ・エラーは、メッセージ中に同じ論理値を持つ6つ以上連続ビットが検出された場合に発生します。唯一の例外は、 エラーとしてみなされない7つのレセッシブ・ビットを持つフレーム終了ビットシーケンスです。
CRC エラー
送信されたCRCチェックサムがレシーバによって計算された値と一致しない場合、CRCエラーが生成されます。CANで使用される15ビットCRCは理論上のハミング距離が6であり、 1つのメッセージで5つのシングルビット・エラーが検出される可能性があります。16番目の保護ビットは、誤ったビットストリーム同期のために発生するエラーの検出を提供します。 さらに、最大15の長さの直接シーケンスされたビット誤り（バースト誤りと呼ばれる）が検出される。
フォーマット・エラー
フォーマット・エラーは、あらかじめ定義されたビットの1つ以上が正しくないことが判明したことを意味します。 例として、レセッシブ・ビットではないCRCデリミタ、または、正しくないフレームビット・シーケンスの終わりのときです。 例外として、フレーム・シーケンスの終わりのドミナント・ラストビットは、フォーマット・エラーとして認識されません。
ACK エラー
ACKエラーは、トランシーバがACKスロット内のドミナント・ビットを受信していない場合に生成され、これは、フレームがどのCANノードによっても正しく認識されなかったことを示します。 トランシーバは、ACK応答を受信するまで同じメッセージを送信し続けます。
エラー・アクティブCANノードの検出により、エラーを最初に検出したノードから送信されたエラー・フレームが発生します。 他のすべてのCANノードはエラー・フレームを受信し、エラー・アクティブ状態になっていれば、それ自身のエラー・フレームで応答します。 結果としてすべてのノードはメッセージを破棄し、メッセージは少なくとも1回繰り返されます（再送信）。
エラー抑制とバス・オフ管理
1つのノードのローカル障害または、障害は、頻繁にアクティブなエラー・フレームを送信することによってバスをブロックすべきではありません。 したがって、各CANノードは、受信エラー・カウンタ（REC）および、送信エラー・カウンタ（TEC）と呼ばれ、受信および送信された破損メッセージ用の個々のエラー・カウンタを備えています。 エラー状況に応じてRECとTECは異なる方法で増加します。詳細については、ISO 11898の最新版を参照してください。以下の3つの動作モードはエラー・カウンタに依存し、以下の図3-4、図3-5で説明します：
- ① エラーアクティブ・モード （REC ≦ 127、および TEC ≦ 127）
- これはノードがメッセージを送受信する通常のモードです。エラーが発生した場合、ドミナント・ビットからなるアクティブ・エラーフラグが送信されます。
- ② エラーパッシブ・モード（REC ≧128、または TEC≧128、および TEC≦255）
- メッセージは引き続きこのモードで送受信されますが、レセッシブ・ビットのみを含むパッシブ・エラーフラグによって、エラーは他のノードに通知されます。
- ③ バスオフ・モード （TEC ＞ 255）
- バスオフ・モードは、ノードが論理的にバスから切断されたことを意味します。この状態では、フレームを送信も受信もせず、エラー・フレームも送信しません。 この機能は、障害のあるノードがネットワークを危険にさらすことを防止します。
図3-4 受信エラー・カウンタ（TEC）
図3-5 送信エラー・カウンタ（REC）
エラー状態
CANノードは、初期状態はバス・オフで、通信に参加するとエラー・アクティブとなります。 正常に動作している間はエラー・アクティブを維持します。エラーを起こしやすい状態になると、エラー・パッシブになります。これらの状態遷移は、エラー・カウンタの値を元に遷移します。 エラー・カウンタは、送信エラー・カウンタ（TEC）、受信エラー・カウンタ（REC）があり、図3-6のように遷移します。
図3-6 エラー状態遷移図
バス・オフの後ノードは、ノーマル・モード、すなわちエラー・アクティブに戻ることができます。 これは再取り付けプロセスに相当します。ISO 11898-1（「13章 スーパーバイザの説明」を参照）は、再接続プロセスに2つの要件が必要であることを説明しています:
- RECとTECの両方が0の値を持つ
- ノードは、11個の連続するレセッシブ・ビットの128個の発生を監視しなければなりません。 これらの11個のレセッシブ・ビットは、ACKデリミタ＋EOF＋IFSビットに対応し、バスが実質的に健全な状態で回復したことを意味する。
ARINC 825は、堅牢な動作のために、以下の手順を推奨しています：
- アプリケーション層は、CANコントローラのノーマル・モード要求を開始する必要があります。
- ノーマル・モード要求の前にタイムアウトを定義したシステムを実装する必要があります。
- 許可された再取り付けの数は、可能性と信頼性の要件に従ってシステムで定義される必要があります。