衛星通信バスインタフェースの選択

テストエンジニアは、“Pick the right tool for the job (仕事に合った道具を使え)” という格言は大筋において正しいと考えます。 間違ったツールを使えば時間が無駄になり、品質が損なわれますが、正しいツールを使えば正しい結果をわずかな時間で得ることができるからです。

主要なツールは刺激信号を測定するための計測器です。電子地上支援装置 (EGSE) または特定用途チェックアウト用STE (SCOS: Specialty Checkout Specialty Test Equipment) を構築するときに使用して統合化、チェックアウト、大量生産テストを支援します。これらの計測器には、デジタルマルチメータ (DMM)、オシロスコープ、波形発生器などのよく知られた製品の他、ベクトル信号トランシーバやオールインワンオシロスコープなど、新しいカテゴリや進化の途上にあるカテゴリに属するさまざまな製品があります。しかし、仕事に適したツールを選択するのは、それほど簡単ではありません。発生する多くのトレードオフを具体的に考慮して評価する段階では、なおさらです。このことは、一般向け計測器と特殊用途向け計測器の両方にあてはまります。一方で衛星通信バスインタフェースは、多くの場合、同じ程度の厳密さで考慮されることはありません。

EGSEに組み込んで検証テストまたは統合テストに使用する計測器を数多く比較検討することがあります。このとき、テストエンジニアは自らのテストプランと照らし合わせて、市場に出回っている計測器を評価することに慣れています。このようにして測定範囲全域をカバーし、テストプランの要件を満たす適切な計測器を選んで設置することは必須です。

特定の検査対象デバイス (DUT) のために作成されたテストプランでは、DUTをある状況下に置く、あるいはDUTにコマンドを送信して予測される応答を受信するなど、追加のステップが必要になることがよくあります。とくに、飛行およびシステムを制御するコントローラをテストするときは、こうしたステップが必要になります。さらに、品質保証 (QA) チェックを実行する、直接アビオニクスバス上で設計検証ステップの一部を実行する、あるいは後の解析や再現に役立てるために応答を記録するなどのステップを含めることもあります。このような機能をEGSE内部に確実に組み込むためにテストエンジニアは、DUTが通信に利用するプロトコルに重点を置いて、COTS (商用) 市場で入手可能な自分達の要件を満たす計測器を探すことがよくあります。

テスト装置プラットフォームとDUTの組み合わせに基づいて、特定のアビオニクスバスインタフェースを備える計測器が必要になりますが、そこには幅広い選択肢があります。MIL-STD-1553、ARINC-429、SpaceWireなどの最もよく使われるプロトコルを検討しているのであれば、そうしたニーズを満たす計測器を市販する企業は複数存在します。他方、高速/バックボーンバスとして、Fibre Channel (具体的にはSpaceFibre)、Serial RapidIO (SRIO)、AFDX、High-Speed Data Bus (HSDB)、IEEE-1394b、または特定アプリケーション向けバスのARINC-708、ARINC-717、ARINC-818などを検討する場合は、採り得るオプションはさらに複雑で、検討すべき課題が多くなります。 

SpaceWireをはじめとする多くのバスインタフェースが広く普及した結果、インタフェース計測器は市販の商品となっています。そのため、テスト装置ベンダー各社が物理仕様、データリンク、およびネットワーク層を特定機能デバイスに統合するためのコスト効率は向上しています。たとえばSTAR-Dundee社は、SpaceWireバス信号のインタフェースとスイッチングに使用する複数のPXIモジュールを提供しています。GPIBのようにハードウェアレベルで広く採用されているプロトコルに対応する計測器は、特定の標準規格に準拠するため、ベンダーによるアーキテクチャの違いはあまりなく、その多くは類似しています。 

テスト装置ベンダーは、自社製品と他社製品の差異をOSI参照モデル上位にあるデータ関連層で作り出そうとすることがあります。これらの層で、プロトコル支援に特有の機能や性能を実装するのです。例として、エラー検出、柔軟なスケジューリング、タイムスタンプ、データ記録、欠陥生成などがあります。監視またはデバッグ用途に、OSI各層のデータに個別にアクセスできるようにする製造元もあります。システムレベル検証およびシステムインテグレーションテストの要件に関連して、さらに細かな機能がありますが、それらの多くはアプリケーションを完成させる上でとくに重要でないものもあります。したがって、どれを選ぶかという最終的な判断は、通常、エンジニアの優先順位に委ねられます。

図1.ARINC-664p7/​AFDXのOSI各層を簡略化して描いた図

普段は簡単な選定作業も、テストシステムが高速/バックボーンインタフェースまたはアプリケーション特有のプロトコルインタフェースを必要とする場合、その判断が難しくなります。テストエンジニアは、これらのプロトコルをテストシステムに統合することの煩雑さをしばしば見過ごしてしまいます。こうした高機能プロトコル導入に起因する課題の1つが、パラレルからシリアルへのデータ伝送方法の移行です。 

シリアル標準規格がますます普及している理由は、パラレルバスで約1～2 GHzというクロックレートの物理的限界です。個々のクロックおよびデータラインで生じるスキューが、これより高速なレートでビットエラーを引き起こすからです。一方、高速シリアルバスは、1つ以上の差動信号にデータとクロックの両方の情報を格納し、データを符号化して転送するため、パラレルバスで生じるような速度制限を回避できます。その上、専用の高速シリアルハードウェアトランシーバをクロックリカバリ、プリエンファシス、等化などの先進的機能と併用することで、さらに機能を高度化することができます。 

高速シリアルプロトコルインタフェースは設計上、最新テクノロジを用いたFPGA上で実行するのに非常に適しています。たとえば、数ギガビットのトランシーバを最新のXilinx FPGA上で実行した場合、30 GB/秒を超える速度で運用することが可能です。これは、通信プロトコル用データプロセッサの候補として理想的です。この種の計測器では、そのハードウェア設計の複雑さに加えて、プロトコルIP自体が市販計測器のものより複雑度を増します。というのも、プロトコルにあらゆる機能を盛り込んでいる上、桁違いに速いデータレートを扱うために複雑度が増して、さらに厳格なデータ要件を満たす必要があるからです。 

高速/バックボーンインタフェースまたはアプリケーション特有のプロトコルインタフェースをEGSEに統合しようとするとき、エンジニアがよく検討対象とする2つのオプションがあります。

• オプション1は、商用オフザシェルフ (COTS) 市場を見渡して、目的のインタフェースを提供するベンダーを見つけることです。ここでも、そのハードウェア設計とIPの複雑さゆえ、多くの場合、エンジニアはベンダー2社と係わる必要があります。高速シリアルハードウェアを扱う会社と、プロトコルIPコアを扱う会社です。

• オプション2は、社内検証チームの設計を活用して検査対象デバイス (DUT) をテストすることです。この場合、IPコアをカスタムまたは市販のFPGA評価ボードに組み込んでEGSEに統合します。社内で独自に設計するというオプションは魅力的ですが、時間が経つにつれ、サポートの負担が重くなるという目に見えないリスクが少なからずあります。

図2.「自社開発」テストシステムのライフサイクル管理

図2に、テストシステムの設計から使用開始、終了までのライフサイクルを例示します。このシステムで保守コストが発生する際のイベントも時系列上に記載しています。EGSE全体の設計が完了したら、カスタムボード上のコンポーネントが寿命を終える時期 (EOL: End of Life) を考慮します。コンポーネントのEOLは予期される事態です。一般に半導体テクノロジは、市場の変化に応じて現在のサイクルが終了し、新しいサイクルへと移行します。とくに社内検証チームの設計を採用した場合、その設計要件にライフサイクルという懸案事項は、おそらく含まれていません。 

こうした状況では、コンポーネントを購入した後、スペア部品を管理しながら寿命を終えるまで使い続けるか、または新製品を見つけてそのハードウェア設計を再評価することが、実質的な選択肢として残されています。次に、WindowsなどのOSのバージョンアップグレードを考慮します。あるいは、Linuxに移行することも考えます。さらに、コード中の各種ドライバを書き換えることと、ソフトウェア設計を再評価することが必要です。仮に、ある程度時間が経過した時点で、テスタの要件が変更されるか、または新しい機能を追加する必要が出てきたときはどうすればよいでしょうか。この場合、ファームウェアまたはソフトウェアの再設計が必要になるか、DUTの要件次第では物理層の再設計さえ必要になります。最後に、FPGAのEOLについて考慮します。コンポーネントのアップグレードに簡単な道筋はありません。往々にしてすべてを設計し直す必要が出てきます。 

ここに例示されている事柄は、テストシステムで現実に起こり得ることばかりです。航空宇宙/防衛産業では、テストシステムに求められる耐用年数が数十年に及ぶことがよくあります。古くなったシステムの問題が表面化したときは、最初にEGSEとそこで実行するテストソフトウェアプログラムを設計した人達はすでに周囲にいないため、保守に関して助言や助力を得られないということがよくあります。結局のところ、設計当初のコストは、システムのライフサイクル全体でかかるコストに比べるとわずかなパーセンテージを占めるに過ぎません。

その代わり、エンジニアは可能な限り「オプション1: COTSベースのソリューション」を検討すべきです。具体的には、テストおよび計測アプリケーションで使用するための設計ソリューションです。衛星通信プロトコルとのインタフェースを必要とする複雑なソフトウェアIPを設計し、管理するだけの能力が社内にあったとしても、後からのしかかってくるカスタムハードウェアの保守と維持にかかる負担を考えると、COTSアプローチの方がテスト全体のコスト削減につながります。 

航空宇宙/防衛産業は、数十年にわたり、NIのモジュール式計測器やアプリケーションソフトウェアを使用して、製品のテストおよびサポートに関連する総コストとリスクを削減してきました。この間、NIはPXIプラットフォームの先駆者として、DCからミリ波にいたる600種類もの異なるPXIモジュールをリリースしてきました。NIはそのパートナーネットワーク、およびSTAR-Dundee社をはじめとするPXIプラットフォームの基盤部分を製造する70超のPXISAメンバーと協力して、従来型の計測器に加えて統合化、チェックアウト、および大量生産テストのソリューションを提供してきました。これにより、この分野で最も包括的なPXIベースのバスインタフェースを扱って、「仕事に合った道具を使え」の格言どおりに柔軟な選択肢を常にご用意しています。

製造およびデポテスト用のデジタルアビオニクスインタフェース

ジェネリックインタフェース:

• MIL-STD-1553 
• RS-232/422/485 
• ARINC-429 
• CANバス 

高速/バックボーンインタフェース:

• Fibre Channel (具体的にはSpaceFibre)
• Serial RapidIO 
• ARINC-664p7/AFDX 
• 1394b FireWire 
• イーサネット (40 GbEまで) 

アプリケーションに特化したインタフェース:

• ARINC-708 
• ARINC-717 
• ARINC-818 
• SpaceWire 
• DVI

COTSアプローチは実行可能なオプションではなく、カスタム設計が必要だと、テストエンジニアが考えるときがあります。よく引き合いに出される例が、カスタマイズされた特別なプロトコルで通信するDUTをテストする場合です。しかしながら、このようなケースでもカスタム設計を回避することをお薦めします。将来にわたってそのテスト用EGSEを保守することの負担とスケジューリングリスクを減らすためです。航空宇宙用に完全な電子テストシステムを構築する方法の詳細については、こちらのApplication Noteを参照してください。そこでは、COTS通信バスインタフェースハードウェアを自社のテストシステムに統合してカスタム設計で直面する課題を解決する方法についても検討します。