冗長性管理
冗長性は、可用性または完全性、またはその両方（例えば三重または、四重冗長システムなど）に使用できます。 冗長性を必要とするシステムをサポートするために、ARINC 825はオプションで冗長性情報のソースを示すCANアイデンティファイヤの最下位2ビットを予約しています。 2つのビットは、最大4つの冗長性を提供します。図6-1に示すCANアイデンティファイヤは、オプションの冗長チャンネル・アイデンティファイヤ（RCI）フィールドを識別します。 システムに4つ以上の冗長チャンネルが必要な場合は、必要に応じてRCIフィールドを拡張する必要があります
図6-1 CANアイデンティファイヤのRCIビット
冗長接続を持つシステム上のデータを管理するための追加要件があります。 各ユニットは、データが送信されているバスのRCI値を設定するか、ビットを使用して同じバス上の冗長ノードまたは類似ノードを区別する必要があります。 受信ユニットは、複数チャンネル（RCI）上の有効なデータをチェックしなければならず、そのデータは鮮度を検証する必要があります。 以下の3つの図に示すように、RCIフィールドには、いくつかの用途があります。図6-2は、5つの異なるユニットを持つ部分的なシステムを示し、それぞれが4つの冗長バスすべてとインターフェイスしています。
図6-2 RCI適用例 Case A
図6-3は、4つの冗長等価ノードを持つシステムの一部を示しています。
図6-3 RCI適用例 Case B
図6-4は、すべてのノードが同一であるが、異なるネットワークに接続されている部分的なシステムを示しています。
図6-4 RCI適用例 Case C
CANと相互接続された複数のサブシステムのいくつかの例を図6-5に示します。ここでは、「ネットワーク」は複数のバスを指しています。 CANネットワーク1には、二重冗長CANを介して接続された複数のユニットがあります。CANネットワーク2は、二重冗長を使用する独立したサブシステムですが、 CANネットワーク3は、三重冗長接続サブシステムの例です。ここで使用されているのと同じトポロジーを使用して、 非冗長ネットワーク（すなわち、CANネットワークの各バス上に異なるデータを有するシステム）を表すことができるが、ここでは冗長性を表すために使用しています。 複数のバスそれぞれに異なるデータを持つシステムを、すべてのバス上に複製された必須または、クリティカル・データで定義することが可能です。 複数のバスを混在させて使用できるシステムでは、障害によって1つまたは、複数のバスが失われた場合、いくつかの重要でない機能を失うことがあります。
図6-5 冗長化CANシステム
二重冗長
図6-5のCANネットワーク1などの二重冗長接続システムの場合、LRU x～zとゲートウェイa および、bが相互接続されています。
これらの各ユニットは、2つのネットワーク上に冗長な情報があることを認識する必要があります。 各ユニットは、データが送信されるバスに割り当てられたRCIフィールドを設定するように設計する必要があります。
図6-6に二重冗長CANを備えたLRUの簡略図を示します。バス接続にはAとBのラベルが付いています。 システム・インテグレータは、各バスのRCI値を割り当てます。二重冗長接続システムでは、RCI値01と10を使用する必要があります（RCI割り当てはシステム全体で一貫している必要があります）。
受信ユニットは、データが古いかリフレッシュされたかを判断するためのメカニズムを必要とすることがあります。 データが新鮮であるかどうかを判断することは、外部条件に応じてすべてのバスから冗長情報が同時に受信されない可能性があるため、冗長接続システムでは複雑になる可能性があります。 冗長情報を管理するためにLRUによって採用されるメカニズムは、LRU要件および受信しているデータのタイプの関数です。
図6-6 二重冗長CANインターフェイス
二重冗長接続から情報を受信するユニットおよび、特定のCANアイデンティファイヤを持つメッセージが存在しないか、リフレッシュされていない場合は、2番目のソースをチェックする必要があります いずれの値も受信されていない場合、送信ユニットが故障したか、レシーバがデータの最大レイテンシより前にデータをチェックしているかのどちらかです。
非ゲートウェイ・サブシステム
図6-5に示すCANネットワーク2などのサブシステムは、上記の要件と同じ要件を満たしています。 システムは他のサブシステムと相互接続されていないため、RCI値の割り当てはサブシステム開発者に委任することができます。
三重冗長サブシステム
図6-5に示す、CANネットワーク3は、三重冗長接続サブシステムです。三重冗長システムの要件は、2重冗長システムの要件と同様です。 メッセージを送信するユニットのそれぞれは、送信に使用されるバス用のシステム・インテグレータによって割り当てられたRCIフィールドを設定する必要があります。 受信ユニットは、受信したシステム要件およびデータ・タイプに応じて、受信データを管理する必要があります。 冗長データを管理するノードの開発者は、受信したときに同じ冗長データが時間的に歪む可能性があることを意識する必要があります。
冗長データの管理
冗長接続システムの潜在的な問題の一つは、データが更新されたことを確認することです。 システム要件に応じて、単一の接続を持つシステムは、データを読取済みとしてマークするだけで済みます。 ユニットがデータに対して循環処理を実行すると仮定すると、次の反復では、処理が進行する前にデータがリフレッシュされたことを確認するためにチェックが行われます。 冗長接続されたシステムのように、複数のデータバスが存在する場合、1つの接続からだけのデータが必要になります。データが読み込まれたら、使用済みとしてマークする必要があります。 他のCANデータ・チャンネル上の冗長データは破棄することができます。システム健康管理の理由から、冗長チャンネルが適切に動作していることを確認するために冗長チャンネルのデータを監視する必要があります。 潜在的なシステム障害を回避するには、冗長データ・チャンネルの監視が必要です。データが1つのチャンネルからのみ使用され、そのチャンネルが失われた場合、 システムは第2（または第3）のデータ・チャンネルに切り換り、バックアップ・チャンネルが動作していることを知ることが重要です。
前述したように、使用されたデータを使用済みとしてマークすることはかなり容易であるが、第2、第3、または他のチャンネルの冗長データはまだ受信されていない可能性があります。 ユニット開発者は、CANを介して冗長メッセージを受信するときに、かなりの時間スキューが発生する可能性があることに注意する必要があります。 時間スキューは、いくつかの通常発生するイベントによって引き起こされる可能性があり、予期されるはずです。 断続的な電気的干渉によって1つ以上のメッセージが破損または、シングルイベント・アップセットによって個々のメッセージが破損する可能性があります。 バスのエラー原因にかかわらず、リトライをトリガし、冗長接続システムの別々のバスを強制的に同期させないようにします。 バスの負荷が高いほど、それらの間の時間スキューが大きくなります。サブシステムの性質に基づいて、冗長データを管理するための複数のメカニズムがあります。
上述したように、同じデータを運ぶ2つのバスが同期しなくなる可能性のある複数のタイプのバス・エラーがあります。 簡単にするために、図6-7では、二重冗長システムのバスNB上のメッセージ遅延を引き起こすための信号干渉を示しています。 この例ではバスNBは、メッセージM1の送信を遅延させる何らかの外部干渉を拾います。 結果は、受信コントローラがSkew_Time1および、Skew_Time2として示されたバスNB上の完了メッセージを受信するときの遅延である。
図6-7 受信タイム・スキュー
メッセージの順序は、バス上のノイズまたは他のバスエラーのために、冗長バス間で異なる場合があります。 図6-8は、二重冗長システム内の2つのバス上のメッセージ順序が逆になっている状況を示しています。 この例では、ユニットは時刻t1にメッセージMaを送信する準備が整います。 このときバスNBに何らかの干渉が発生するので、メッセージはバスNAのみに送信されます。 遅延の間、より高い優先度のメッセージ（Mb）を有する別のユニットは、時刻t2において送信する準備が整います。 バスNAは、ビジーであるので、第2ユニットはバスNBを調停し、メッセージMbの送信を開始します。 メッセージMbが完了すると、メッセージMaは、別のより高い優先度のメッセージが保留中で無い場合に送信されます。
図6-8 メッセージ順序の変更
図6-9を参照すると、ネットワークNからネットワークMへのゲートウェイを介したメッセージの送信は同様です。 しかし、この場合ネットワークN上の冗長情報は、フィルタリングされるか、またはネットワークM上のユニットにパススルーされます。
図6-9 二重冗長ネットワークからゲートウェイ