帯域幅管理
CANネットワークに関する重要な問題は、メッセージの優先順位付けと帯域幅管理です。複数のノードが同時にネットワークにアクセスしようとするとすぐに、メッセージの優先順位付けが行われます。 CANはCSMS/CA調停（Carrier Sense Multiple Access/Collision Avoidance）を使用します。これは複数のノードが同時にネットワークにアクセスしようとするとき、 最も低い数値のアイデンティファイヤ（最高優先度と同じ）を持つメッセージを送信しようとするノードに、送信アクセス権が与えられることを意味します。 他のノードは退き、次の送信ウィンドウ（フレームの開始）の開始時に再試行を行います。このコンセプトの利点は、調停のために帯域幅を犠牲にしないことです。 システム設計者は、ノード（およびメッセージ）の数が増えるにつれて帯域幅管理を実行する必要がありますが、より高い優先度のメッセージは、他のメッセージをブロックし、過度の待ち時間を引き起こす時があります。 帯域幅管理は、ネットワーク上のバス負荷が一定制限内にあることを、時間の経過とともに均等にバランスさせ、ある程度の成長可能性が存在することを確認するために使用されます。 これは、ネットワーク内の各ノードの伝送速度を制御して、許容可能な限界を超えて単一のメッセージが遅延しないようにすることによって達成されます。
ここで提示された帯域幅管理の概念は、1つの許容可能な方法について説明します。この方法は、マイナー／メジャー・フレーム時間コンセプトに基づいています。 すべてのノードが同じマイナー／メジャー・フレーム時間周期を共有し、マイナー・フレーム時間がメジャー・フレーム時間の偶数となります（例：すなわち、1/2、1/4、1/8など）。
メジャー・フレーム時間はすべての周期メッセージが少なくとも1回送信される周期として定義され、マイナー・フレーム時間は、最も頻繁に送信されるメッセージが1度送信されるのに必要な時間として定義されます。
ここで定義されている方法は、バス上のメッセージの負荷のバランスを取る有効な手段を提供しています。 バス負荷がスケジューリングによってバランスが取れていない場合、より大きなメッセージ待ち時間が発生する可能性があります。
ISO 11898-1では、データリンク層（DLL）と物理的な信号が指定されています。CAN DLLを実装するモジュール間でデジタル情報の交換を設定するための特性を提供します。 論理リンク制御（LLC）および、メディア・アクセス制御（MAC）サブ層を含みます。
バス負荷の計算
特定の時間周期の間のバス負荷の割合を決定するには、次の式が使用されます：
- MessageLength：
- スタッフ・ビットを含む定義されたTransmissionInterval内で送信される各メッセージのビット長。
- NumberOfMessages ：
- 識別されたTransmissionIntervalにおける、選択された長さのメッセージの最大発生回数（すなわち、TransmissionIntervalに何回このメッセージが現れるか。）
- TransmissionInterval ：
- 選択された時間間隔の持続時間（マイナー・フレーム時間周期、msec）
- DataRate ：
- バス・スピード bits/second
帯域幅使用式は、周期的なデータ使用料のみを扱います。非周期データは、データの最小および最大発生率を使用して等価周期レートに変換することによって含めなければなりません。
CANバス帯域幅の使用率を適切に分析するには、バス上のノードによって送信されたすべてのデータ（データの受信者があるかどうかにかかわらず）を分析に含める必要があります。 選択した感覚に応じて平均バス負荷の計算のバリエーションも可能であるため、TransmissionIntervalを賢明に選択することも重要です。
表5-1 バス負荷計算の値にスタッフビットを含む識別された最大メッセージ長を持つメッセージデータフレームサイズのリストを示します。次の式は、表5-1の値を示しています。
MessageLength[bits] ＝ Overhead[bits] + Payload[bits] + MaxNrOfStuff[bits] + IFS[bits]
| メッセージ・ペイロード[Byte] | MessageLength 最大フレームサイズ[bit] |
| 0 | 79 |
| 1 | 88 |
| 2 | 99 |
| 3 | 109 |
| 4 | 119 |
| 5 | 128 |
| 6 | 139 |
| 7 | 149 |
| 8 | 158 |
以下の値の例は、TransmissionIntervalとしてマイナー・フレーム時間を使用する概念を示しています。
図5-1のように、「C」と識別されたメッセージが、マイナー・フレーム時間#1では発生しますが、マイナー・フレーム時間#2では発生しません。 したがって、マイナー・フレーム時間#1をTransmissionIntervalとして帯域幅の負荷の割合を決定することで、より現実的な観点を提供します。
図5-1 メジャーおよびマイナー・フレーム時間内のメッセージ
図5-1の場合
- A ： 4 byte フレーム= 119 bit
- B ： 8 byte フレーム= 158 bit
- C ： 3 byte フレーム= 109 bit
- D ： 8 byte フレーム= 158 bit (Bと同じ)
125 kbit/s（125,000 bit/s）のDataRate（バス速度）で上記の式を使用すると次のようになります。
したがって、ワーストケースの帯域幅利用率は42.72％です。
注意：バスの負荷がメジャー時間フレームで計算された場合、その値ははるかに低い値となります。
帯域幅管理の例
ここで説明する帯域幅管理の例は、バス上のすべてのノードがこの共通のメッセージ・スケジュールを使用する場合にのみ適用できます。
以下のバス・スケジューリング方法は、ネットワーク内のメッセージ数に基づいてバス負荷を計算し、それらの送信時間を調整してピーク負荷シナリオを最小限に抑える手段を提供します。 記載の例は、生成され得る大きな非周期データ・ブロック、例えばデータ・アップロード／ダウンロードサービスの使用を含まないことに注意してください。 このデータは、許容できないバス負荷のばらつきを避けるために、メッセージ・フローを適切に調整する必要があります。 良好な実践は、大規模なデータブロック送信をそれぞれのアプリケーションのために選択されたマイナー・フレームにリンクし、それを以下に説明するバス負荷計算に含めることです。 ブロック・データ転送の時間が大幅に増える可能性があることに注意してください。
29ビットのアイデンティファイヤCANデータ・フレーム（スタッフ・ビットを含む）の最大長は、158ビットです。 しかし、普遍的なガイドラインを確立するために、次の例では、平均19ビットのスタッフ・ビットを仮定し、合計フレーム長は150ビットになります。
| 29ビット アイデンティファイヤ CANデータ・フレーム・フィールド名 |
ビット長 |
| Start of Frame (SOF) | 1 |
| Identifier Field A | 11 |
| Substitute Remote Request (SRR) | 1 |
| Identifier Extension (IDE) | 1 |
| Identifier Field B | 18 |
| Remote Transmission Request (RTR) | 1 |
| Reserved | 2 |
| Data Length Code (DLC) | 4 |
| Data Field (0-8 Bytes) | 64 |
| Cyclic Redundancy Check (CRC) | 15 |
| CRC Delimiter | 1 |
| Acknowledge Slot (ACK) | 1 |
| Acknowledge Delimiter | 1 |
| End of Frame (EOF) | 7 |
| Assumed number of Stuff Bits (above average) | 19 |
| Minimum inter-frame space | 3 |
| 合計 | 150 |
注意：スタッフ・ビットの最小数は0で、ARINC 825互換メッセージの最大値は29です。この例では、最大値のおよそ2/3で19が選択されこの例の計算を簡単にしています。
特定のシステムのCANバス・スケジュールがどのように展開されているかを実証するために、データレートは1Mbpsと仮定すると、CANフレームあたりの最大伝送時間は150μsecになります。 さらに、バス上の任意のメッセージの最大転送速度は、毎秒66.6メッセージと仮定され、その結果15msecのタイムフレームが得られます。 これは、15msecごとに100フレームが送信される、または、約6666フレーム／秒の場合、100％のバス負荷を消費します。
理論的にはすべてのメッセージは1秒間に66回送信される可能性がありますが、関連する信号の変化率がこれを指示しない限り、そして、この速度でデータを利用することができるネットワークに設置された機器がない限り意味がないでしょう。 マイナー・フレーム時間は、バス上の最高速度メッセージの時間間隔として定義され、メジャー・フレーム時間は、少なくとも1回は（定期的な）すべてのメッセージを送信する間隔です。 バス・スケジューリングの概念は、「マイナー・フレーム時間」（この例では15msec）を使用し、措定のシステム内のすべてのメッセージをこの間隔で送信する必要がないという事実を利用します。 マイナー・フレーム送信時間の倍数および、関連する「送信スロット」を指定することにより、実質的により多数のメッセージを単一のネットワークを介して送信することが可能になります。 この方法は、ネットワーク内のすべてのノードが非同期で実行されている場合でも有効です。つまり、ノードはすべて同じマイナー・フレーム時間を使用する必要がありますが、 同じ時点でマイナー・フレーム時間を開始する必要はありません。
| 送信周期 | 送信スロットあたりの メッセージ数 |
送信スロット数 (100%バス負荷に等しい) |
送信スロット識別 |
| 15ms（66.7メッセージ/秒） | 1 | 50 | A0～A99 |
| 30ms（33.3メッセージ/秒）/td> | 2 | 100 | B0[0]～B99[1] |
| 60ms（16.7メッセージ/秒） | 4 | 200 | C0[0]～C99[3] |
| 120ms（8.3メッセージ/秒） | 8 | 400 | D0[0]～D99[7] |
| 240ms（4.2メッセージ/秒） | 16 | 800 | E0[0]～E99[15] |
| 480ms（2.1メッセージ/秒） | 32 | 1600 | F0[0]～F99[31] |
| 1000ms（1.0メッセージ/秒） | 66 | 6666 | G0[0]～G99[65] |
バス・スケジューリングの概念に基づく伝送スケジュールの例を以下に示す：
図5-2 メジャーおよびマイナー・フレームフレームを使用した帯域幅管理の例
上記の例のバス負荷計算では、次の結果が得られます：
| 送信周期 | メッセージ数 | 要求される 送信スロット |
送信スロットあたりの 最大メッセージ数 |
| 15 msec | 8 | 8 | 1 |
| 30 msec | 3 | 2 (1.5) | 2 |
| 60 msec | 7 | 2 (1.75) | 4 |
| 120 msec | 6 | 1 (0.75) | 8 |
| 合計 | 24 | 13 (12.0) |
この例では、100個の使用可能な送信スロットのうち13個を使用しているため、対応する平均バス負荷は13％です（一時的なバス負荷が高くなる可能性はあります）
最大バス負荷
妥当な数のイベントドリブン・メッセージとデータ破損の場合のエラー・フレームには、追加のバス容量が必要な場合があり、約50%の安全マージンが推奨されます。 したがって、この規格に従って設計されたシステムは、通常の動作中に平均バス負荷50％を連続的に超えてはなりません。非常に小さな送信ポイント・ジッタを必要とする実装では、 この値を30%に制限することも適当です。この場合、より多くの帯域幅が必要な場合はより高いボーレートまたは2番目のARINC 825ネットワークの使用を考慮する必要があります。
全ての飛行安全上重要なシステムの本質的な特徴は、正式な承認要件を満たすために、その動作を正確に定義し、分析し、試験する必要があることです。 この特性は、しばしばタイミング決定論として誤解されるが、実際には予測可能である。タイミングに必要な精度は、各アプリケーションに固有であり、システム分析によって定量化する必要があります。 しかし、達成すべき究極の目標は、安全上重要なシステムが予見可能な状況下で予測可能に動作することが証明機関に実証される可能性があることです。CANを使用すると、この予測可能性が達成される可能性があります。
ARINC 825規格では、マルチドロップCANネットワークの利用可能な帯域幅を管理して、1対多およびピアツーピア通信の予測可能な動作を保証するコンセプトを説明しています。 この管理概念は、ネットワーク内の任意のノードが「マイナー・フレーム時間」内で送信できるCANメッセージの数の制限に基づいています。マイナー・フレーム時間は、初期システム設計時に定義されます。 1つのマイナー・フレーム時間内で送信されるメッセージの最大数は、ノードごとに異なる場合があり、システム設計によって許可されている場合、成長可能性を含みます。
ネットワーク・トラフィックを生成するときには、ネットワーク内のすべてのノードがその送信スケジュールに常に従うことが帯域幅管理の概念にとって重要です。 他方では、ネットワーク内のノードが、メッセージ送信順序または、送信時間に関して他のノードと同期することが必須でもなく、禁止でもありません。 帯域幅が、ネットワークまたは、それに接続されたノードの障害に起因するエラー・フレームによって消費された場合、エラー・フレームは予期しない動作につながる可能性があります。 しかし、ARINC 825規格では、帯域幅の使用を最大帯域幅の50％に制限し、予測不能性を緩和しています。 この管理コンセプトはマージンを必要とし、ネットワーク帯域幅の使用を最適化しませんが、証明可能な（予測可能な）システムを構築するための安全で簡単なアプローチを提供します。 帯域幅管理の概念を適用すると、ARINC 825規格準拠のネットワークが予測可能に動作することが実証される可能性があります。
図5-5に示すのは、ARINC 825規格に準拠したネットワークの送信スケジュールで、2つのノードがメッセージを非同期的に送信することにより、 マイナー・フレーム時間で交互におよび、ランダムな時間（最悪の場合のシナリオ）で実行されます。この例では、最大帯域幅の50%を使用しています。
図5-5 送信スケジュール例
ARINC 825規格の帯域幅管理コンセプトを使用すると、この送信スケジュールのメッセージは1つのマイナー・フレーム時間の持続時間の3倍と最長メッセージの持続時間を超えるレイテンシを持ちません。 ARINC 825規格の帯域幅管理は、ネットワーク上のノードがメッセージ伝送を測定する必要があるため、メッセージ優先順位の影響を低減します。 ローカル・オシレータの許容誤差および、ノード間の時刻同期の欠陥は、マイナー・フレーム時間がお互いから離れるようになります。 これはすべてのノードのマイナー・フレーム時間の期間が密接に一致する限りメッセージのレイテンシに悪影響を及ぼしません。
予測可能性を保証するために、すべての非周期メッセージを帯域幅管理に含める必要があります。
ARINC 825規格の帯域幅管理コンセプトの実装をサポートするために、ノード・ソフトウェアはバックグラウンドでCANメッセージの送受信を処理できる必要があります。 この実装は、ノード・アプリケーション・ソフトウェアをCANインターフェイスのタイミング要件から切り離します。 さらにネットワーク内のすべてのノードは、優先順位の逆転によるジッタを最小限に抑えるために、メッセージの優先順位を降順に（優先順位が最も高いメッセージが最初に）送信する必要があります。
いくらかの帯域幅を犠牲にしながら、ARINC 825規格の帯域幅管理のコンセプトは、5.6で説明されているような簡単な数学に基づく効果的なアプローチを提供します。 帯域幅管理のコンセプトは、成長の可能性が計画されている場合は、システムのライフタイム中にネットワーク・トラフィックを増加させるための十分な柔軟性も確保します。 一例として、システム設計により、既存のノードに影響を与えることなく、ノードをネットワークに統合することが可能になります。
さらにARINC 825規格の帯域幅管理のコンセプトによって実施される予測可能な振る舞いにより、異なる臨界レベルを有するシステムが同じネットワーク上に共存することが可能になります。