CANaerospaceは、コントローラーエリアネットワーク(CAN)をベースとした上位層プロトコルであり、1998年にStock Flight Systems社によって航空用途向けに開発されました。

CANaerospaceは、CANを介してデータを共有するためにライン交換可能ユニット(LRU)の概念を採用した航空機システムをサポートし、CAN物理層特性、ネットワーク層、通信メカニズム、データタイプ、航空軸システムを定義することでCAN LRU間の相互運用性を確保します。CANaerospaceはオープンソースプロジェクトであり、システムレベルでCAN LRU間のインターフェースを標準化するために開始されました。CANaerospaceは継続的に開発が進められており、 2001年にはNASAによってAdvanced General Aviation Transport Experiments Databus Standard [ 1 ]として公開されました。これは世界中の航空研究で広く使用されています。リアルタイムのコンピュータ相互接続のために複数のCANaerospaceネットワークを使用している主要な研究機は、2.5mの天体望遠鏡を搭載したボーイング747SPである成層圏赤外線天文台(SOFIA)です。 CANaerospaceは、フライトシミュレーションでも頻繁に使用されており、航空機のコックピット全体(例えば、ユーロファイタータイフーンのシミュレーター)をシミュレーションホストコンピュータに接続します。イタリアでは、CANaerospaceはUAVデータバス技術として使用されています。[ 2 ]さらに、CANaerospaceは、いくつかの一般航空アビオニクスシステムの通信ネットワークとして機能します。
CANaerospaceインターフェース定義は、ISO/OSIレイヤー1および2のCANプロトコル(CANコントローラ自体に実装されている)と航空機の分散システムの特定の要件との間のギャップを埋めるものです。これは、主要な航空電子機器ネットワークまたは補助的な航空電子機器ネットワークとして使用でき、以下の要件を満たすように設計されています。
CANaerospaceは、相互運用性と信頼性の高い通信を確保するため、 ISO 11898に基づき、電気的特性、バストランシーバの要件、および対応する許容誤差を含むデータレートを規定しています。ビットタイミング計算(ボーレート精度、サンプルポイント定義)と電磁干渉に対する堅牢性には特に重点が置かれています。また、CANコネクタ、配線に関する考慮事項、および電磁両立性を最大限に高めるための設計ガイドラインについても規定しています。
Bosch CAN 仕様自体は、メッセージを周期的にも非周期的にも送信することを許可していますが、データ表現、ノードアドレス指定、接続指向プロトコルなどの問題は対象としていません。CAN は完全に Anyone-to-Many (ATM) 通信に基づいており、CAN メッセージは常にネットワーク内のすべてのステーションで受信されます。CAN コンセプトの利点は、すべてのステーション間でデータの一貫性が確保されることですが、欠点は、Peer-to-Peer (PTP) 通信の基盤となるノードアドレス指定を許可していないことです。しかし、航空アプリケーションで CAN ネットワークを使用するには、航空機搭載システムの特定の要件を対象とした標準が必要であり、必要なレベルのシステム監視を可能にするために、ネットワーク内の個々のステーション間の通信が可能でなければなりません。そのため、CANaerospace は、ノードアドレス指定と統一された ATM/PTP 通信メカニズムをサポートするために、追加のISO/OSIレイヤ 3、4、および 6 機能を定義しています。PTP 通信により、ネットワーク内の個々のステーション間で、一時的または永続的にクライアント/サーバのやり取りを設定できます。これらの相互作用は複数同時に有効になる場合があり、各ノードは同時に1つの操作のクライアントであり、別の操作のサーバーとなることができます。このCANaerospaceのメカニズムは「ノードサービスコンセプト」と呼ばれ、例えば、ネットワーク内の複数のステーションにシステム機能を分散させたり、障害発生時に動的なシステム再構成を制御したりすることを可能にします。ノードサービスコンセプトは、TCP/IPやイーサネットのUDP/IPなど、コネクション指向型とコネクションレス型の両方の相互作用をサポートします。
CANでATMとPTPの両方の通信を可能にするには、異なる種類の通信を分離するための独立したネットワーク層を導入する必要があります。CANaerospaceでは、図1に示すようにCAN識別子グループを形成することでこれを実現しています。この構造により論理通信チャネル(LCC)が作成され、各LCCに特定の通信タイプ(ATM、PTP)が割り当てられます。ユーザー定義のLCCは設計者に必要な自由度を提供し、特定のアプリケーションのニーズに応じてCANaerospaceを実装することを可能にします。
図1:CANaerospaceの論理通信チャネル
副次的な効果として、図1に示すCAN識別子グループは、バスアービトレーションの場合のメッセージ送信の優先順位に影響を与えます。したがって、通信チャネルは相対的な重要度に応じて配置されます。
航空分野で使用されるリアルタイム制御システムの大部分は、「ビッグエンディアン」プロセッサアーキテクチャを採用しています。そのため、CANaerospaceでもこのデータ表現が規定されています。ビッグエンディアンデータ表現では、図2に示すように、CANaerospaceでは任意のデータの最上位ビットが左端に配置され、最初に送信されます。
図2:CANaerospaceにおける「ビッグエンディアン」データ表現
CANaerospaceは、図3に示すようにメッセージペイロードを構造化することで実現される、自己識別型のメッセージフォーマットを使用しています。この構造は、4バイトのメッセージヘッダーと4バイトのパラメータセクションを定義します。
図3:CANaerospaceの自己識別メッセージフォーマット
一見すると、CANメッセージペイロードの50%を運用データの送信以外の目的で使用することは、帯域幅の無駄遣いのように思えるかもしれません。しかし、CANaerospaceメッセージヘッダーは、メッセージペイロードバイトを別の用途に使用した場合にも必要となる貴重な情報を提供します。このヘッダーにより、受信局は受信メッセージを発信元、データタイプ、整合性、作成時刻に関して即座に分析できます。これを実現するために、特定のシステムのCAN識別子割り当てに関する知識以外に、追加の情報は必要ありません。メッセージヘッダーバイトの意味は次のとおりです。
CANaerospaceメッセージヘッダーに含まれる上記の情報は、飛行安全上重要なシステムで使用するパラメータの完全性を判断するための重要な情報であり、システムの冗長性をサポートします。さらに、異なるベンダーのLRU間の相互運用性を大幅に向上させ、CANaerospaceネットワークに接続されたLRUの状態を監視できるようにします。相互運用性をさらに高めるため、CANaerospaceは航空宇宙固有の軸システムを対応する符号規則と物理単位で定義します。これらの定義は、事前定義された識別子割り当てリストと合わせて、CANaerospaceネットワーク内のトラフィックを明確に記述します。CANaerospace標準識別子割り当てリストは、CAN識別子300~1799を予約し、このリストの抜粋(図4)に示すように、それらにパラメータを割り当てます。
図4:CANaerospace V 1.7の標準識別子割り当てリストからの抜粋
システム設計者は、独自に定義した識別子割り当てリストを使用できます。CANaerospaceの各LRUが応答しなければならない必須の「ノード識別サービス」により、ネットワーク上の接続されたLRUとその識別子割り当てリストコードをスキャンして、不整合を回避できます。CANaerospace標準識別子割り当てリスト、およびデータタイプとユニットのリストには、システム設計者がニーズに応じてリストを拡張するために使用できるユーザー定義セクションが用意されています。
飛行安全上重要なすべてのシステムに共通する重要な特性は、その動作が正式な認証要件を満たすために、正確に定義、分析、およびテストされる必要があることです。この特性はしばしばタイミングの決定論と誤解されますが、実際には予測可能性です。タイミングに必要な精度はアプリケーションごとに異なり、システム分析によって定量化する必要があります。しかし、最終的に達成すべき目標は、安全上重要なシステムが予見可能な状況下で予測可能な動作をすることを認証機関(FAA、EASAなど)に証明することです。CANaerospaceを使用することで、この予測可能性を実現できます。
CANaerospaceは、ATMおよびPTP通信の予測可能な動作を保証するために、マルチドロップCANネットワークの利用可能な帯域幅を管理する概念として、タイムトリガーバススケジューリングを提唱しています。タイムトリガーバススケジューリングは、ネットワーク内の各ノードがマイナータイムフレーム内に送信できるCANメッセージ数の制限に基づいています。マイナータイムフレームは、システムの初期設計時に定義されます。1つのマイナータイムフレーム内に送信できるメッセージの最大数はノードごとに異なり、システム設計で許可されている場合は増加の可能性を秘めています。タイムトリガーバススケジューリングの概念において重要なのは、ネットワークトラフィックを生成する際に、ネットワーク内のすべてのノードが常に送信スケジュールに従うことです。ただし、ネットワーク内のノードがメッセージの送信順序や送信時間に関して他のノードと同期することは、必須でも禁止でもありません。
CAN エラー フレームは、ネットワークまたはそれに接続されたノードの障害によって発生するエラー フレームによって帯域幅が消費されると、予測不可能な動作を引き起こす可能性があります。そのため、CANaerospace は、予測不可能性を軽減するために、帯域幅の使用を最大帯域幅の 50% に制限することを推奨しています。時間トリガーバス スケジューリングはマージンを必要とし、ネットワーク帯域幅の使用を最適化しませんが、認証可能な (予測可能な) システムを構築するための安全で簡単なアプローチを提供します。障害条件下でこれを保証するには、システム設計者は、これらの条件 (エラー フレームと優先順位の逆転の回避) 下での動作を定義する必要があります。[ 4 ]時間トリガーバス スケジューリングの概念を適用すると、CANaerospace ネットワークが予測可能な動作をすることが実証できます。図 5 は、2 つのノードがメッセージを非同期で、交互に、マイナー 時間フレーム内のランダムな時間に (最悪のシナリオ) 送信する CANaerospace ネットワークの送信スケジュールを示しています。この例では、最大帯域幅の 50% を使用しています。
図5:CANaerospace伝送方式の簡略化
時間トリガー型バススケジューリングを使用すると、この送信スケジュール内のどのメッセージも、マイナータイムフレームの50%に最長メッセージの送信時間を加えた時間を超える遅延が発生しません。時間トリガー型バススケジューリングでは、ネットワーク上のノードがメッセージ送信を計測する必要があるため、メッセージの優先度の影響が軽減されます。
局部発振器の許容誤差やノード間の時間同期の不備により、マイナータイムフレームが互いにずれることがあります。すべてのノードにおけるマイナータイムフレームの期間がほぼ一致している限り、メッセージの遅延には悪影響はありません。予測可能性を確保するためには、すべての非周期メッセージを帯域幅管理の計算に含める必要があります。
時間トリガー型バススケジューリングは、将来的な成長が見込まれる場合、システムの運用期間中にネットワークトラフィックが増加する状況にも十分対応できる柔軟性を確保します。例えば、システム設計によって、既存のノードに影響を与えることなく、新しいノードをネットワークに統合することが可能になります。さらに、時間トリガー型バススケジューリングによって実現される予測可能な動作により、重要度の異なるシステムが同じネットワーク上で共存できるようになります。