システムの独立性と保守性を強化する高度なロケットエンジンテストアーキテクチャ

2021年に実施された軌道飛行の試行回数は過去最多となりました。¹世界中の企業や政府が試行した飛行の回数は146回に上り、そのうち軌道飛行に成功したのは135回でした。宇宙へ、そしてその彼方へ到達することをめぐってソビエト連邦と米国が激しく競い合った1967年の宇宙開発競争の絶頂期に樹立された139回という記録が2021年に更新されました。2020年代の宇宙開発競争には、2か国だけでなく、多くの国々が参加しています。現在、打ち上げを行っているのは、米国、英国、ヨーロッパ、ロシア、中国、インド、トルコ、イラン、イスラエルなどです。2022年の最初の6か月だけでも、72回の軌道飛行が成功しました。この競争はもはや政府のプロジェクトではありません。多くの民間宇宙企業が競争し、投資家は多額の資金を市場に投入しています。

宇宙打ち上げの急増を後押ししているのは新しいロケット技術です。SpaceXは、2021年に31機のFalcon 9の打ち上げミッションを実施し、そのすべてを成功させました。同社はロケット設計に新しいアプローチを用いることで、以前に使用したロケットコアを再利用して、そのすべての打ち上げミッションを実施することを可能にしました。それらの打ち上げをサポートするために新たに導入されたFalcon 9の1段ステージは2台のみでした。企業や各国が、宇宙への打ち上げの信頼性と再利用性の向上と低コスト化を目指して投資を続けるにつれ、打ち上げ回数は増加し、打ち上げで到達可能な領域も拡大していくでしょう。

これらの打ち上げをサポートするインフラストラクチャも増加しています。現在、準軌道飛行、軌道飛行、惑星間飛行のミッションをサポートするために、35の宇宙港とロケット打ち上げ施設が稼働しています。その所在地のリストは、すべての大陸と13か国以上²と世界中に及び、現在新しい施設を建設している国もあります。さらに、それらの施設から打ち上げるロケットをテストするために他の現場が使用されます。現在は、宇宙産業にすでに携わっている企業にとっても、これから参入しようとしている企業にとっても、好機であると言えるでしょう。

連邦航空局 (FAA) は、米国内でのロケット打ち上げ、または米国市民もしくは事業体による米国外でのロケット打ち上げを規制しています。³他の国々でも同様の規制や規制機関があり、企業はエンジニアリングにおいて適切な工程を経ることなく宇宙への打ち上げを行うことはできません。その重要な工程の1つは、ロケット機をテストし、打ち上げに成功する可能性が高いことを実証することです。

ロケットのテストは、ロケットのさまざまなコンポーネントをテストすることから始まります。エンジニアリングチームは、構造、燃料、電気機器を構成する材料とコンポーネントを個別にテストします。続いて、それらのコンポーネントをサブシステムとして組み立て、テストし、最終的に完全に組み立て、ステージレベルでの総合的な受け入れ試験を実施します。

NI製品は、ロケット機のあらゆる側面で使用されています。静的テストと疲労構造テストのプラットフォームは、飛行中の応力に耐える燃料タンクの強度をテストするのに最適です。NIのPXIベースのモジュール式計測器と自動テストソフトウェアは、アビオニクス回路をテストするための強力なプラットフォームとして機能します。NIのLRU HILテストアーキテクチャは、アビオニクスコントローラをテストするためのさまざまなテストケースを生成するのに最適です。 

このホワイトペーパーはロケットエンジンのテストに焦点を当てていますが、その多くの要素は、完全に組み立てられたロケット機の最終的なテストにも応用できます。

ロケットエンジンテストは、あらゆるタイプのロケットエンジンに不可欠です。このテストはFAAの規制要件を満たすために必要です。ただし、テストを実施することで規制要件を満たす以上の価値が得られます。NASAのレポートでは、ロケットエンジンのテストに費やされた時間とそのロケットエンジンの信頼性に正の相関関係があることが示されています。⁴各エンジンの製造元は、追加テストに投資し、コストをかける上で、そのテストに期待できる利点を考慮し、費やすものと得られるもののバランスをどのように取るかを決定する必要があります。

ロケットエンジン用試験装置は、ロケットエンジンを固定してテストするために設計された構造であり、ホールドダウン推力構造、推進剤のための地上支援装置、冷却システム、排気の分流、テスト中の安全管理と運転管理の自動化など、必要なサポートと制御システムを提供します。ロケットエンジンをテストするには、エンジンを試験装置に取り付けて一定時間発射します。ロケットエンジン用試験装置には、必要なホールドダウン推力構造、推進剤のための地上支援装置、冷却システム、排気の分流に加え、テストを自動化し、運転とテストの全体にわたって安全性を維持するための制御システムが必要です。エンジニアは、ロケットを垂直に取り付けるか、水平に取り付けるかを決定しなければなりません。どちらの方向にもメリットがあります。垂直に取り付けたエンジンは、飛行中に発生する力に匹敵する力を再現しやすいため、計測値を相関させやすくなります。しかし、垂直に取り付けたエンジンでは、テスト中にロケットからの排気を逃がす必要があり、これは通常、火炎偏向器を使用して行われます。

図1.ロケットエンジン用試験装置の各要素

テスト施設は、排気によって引き起こされるいくつかの課題に直面しています。排気熱に加えて、騒々しい排気音や空気汚染の問題があります。排気に大量の水を噴射すると、噴射水がエンジンからの熱を吸収して放出する役割を果たすとともに、周辺地域に及ぼす騒音や汚染物質を和らげるシールドの役割を果たします。

ロケットエンジンテストにはさまざまな方法があります。標準的な海面でのテストは、多くの装置を追加することなく、1台の試験装置で実施できますが、その他のテストでは特殊なテスト環境が必要になる場合があります。たとえば、宇宙空間における衛星の姿勢制御用ロケットスラスタをテストするには、エンジンの意図した動作条件を再現するために、試験装置に真空チャンバが必要です。その他のテストでは、エンジンのジンバルをテストするために熱真空チャンバや追加の機械デバイスが必要になる場合があります。

また、テストステーションはエンジンの開発段階によって異なります。初期の開発エンジンテストでは、エンジニアがエンジン性能のダイナミクスをより詳細に把握するために、多くのセンサを追加する場合があります。一方、飛行任務前の認定試験または受け入れ試験を行う試験装置では、適切な動作を検証するために、初期の開発段階よりも絞り込んだ信号セットをテストする場合があります。

ロケットテストの設計を担当するエンジニアリングチームは、新しい試験装置を設計する際に、こうした潜在的なニーズをすべて考慮しなければなりません。ロケット技術が急速に進化している現在、エンジニアは将来必要になるテストを見越して計画を進める必要もあります。テスト設計には、既知のニーズを満たすのに十分なパフォーマンスだけでなく、時間の経過とともに変化するニーズに対応するための柔軟性も必要です。

NIのエンジニアは、30年以上にわたってロケットテストシステムを設計しているエンジニアと緊密に協力してきました。この期間を通して、さまざまな新しいテクノロジーやソフトウェア技術を導入したことにより、アーキテクチャは成熟してきました。ジェットエンジンのテスト、風洞、その他の大規模なテスト施設など、関連する用途で得られたベストプラクティスは、ロケットエンジンのテストに使用されるシステムの設計に活かされています。そして、ロケットエンジンをテストするためのアーキテクチャの設計を成功させる上で極めて重要ないくつかの原則が確立されました。

ロケットのテスト施設は、単一の試験装置に対応している場合と、複数の試験装置に対応している場合があります。各試験装置は、さまざまなサブシステムやパッドでサポートする必要があります。これらのサブシステムやパッドは、特定の装置専用のものもあれば、テスト施設内の複数の装置や試験場所で共有されるものもあります。施設全体の地上制御システムの監督者は、すべてのパッドと試験装置を統合し、施設リソースの運営管理を調整します。

図2.ロケットテスト施設のサブシステム

サポートパッド制御システムは、制御において高い信頼性を発揮することに加え、パフォーマンスを追跡して改善するための計測機能を備えている必要があります。

ロケットテスト施設の実装を成功させるには、これらのシステム間の慎重な調整が必要です。長年にわたって、主要な宇宙施設では、これらのシステム間の通信や各テストで使用されるシステムの多様性に対応する、柔軟性を備えたデザインパターンを提供する制御スキームが開発されています。テスト施設と打ち上げ施設の両方を管理する宇宙関連企業では、テスト内容と実際の打ち上げの差異を軽減するために、デザインパターンを構成する多くのコンポーネントを共有しています。

このアーキテクチャでは、すべての試験装置とパッドに共通するシステムデザインパターンを使用しています。このパターンにより、各システムで必要となるローカル制御を行うと同時に、システム間で情報を共有することでテストオペレーションを確実に同期することができます。

図3.一般制御システムのデザインパターン

このパターンにおいて、制御システムは、このホワイトペーパーの後半で説明する通信プロセスで得られる入力値を読み取ります。

スケールプロセスにより、これらの未処理の単位をサブシステムに適した科学的な単位に変換します。スケールプロセスでは、複数のチャンネルを組み合わせて1つの計算チャンネルにすることもできます。たとえば、すべてのスラストロードセルを合計して単一のスラスト値を生成できます。テストの合間やテストオペレーション中に計測器が変更される可能性があるため、スケールプロセスでは再構成可能なキャリブレーションも採用されます。

スケールプロセスで提供されたデータポイント出力をアラームプロセスで評価し、アラームを識別します。アラームは、テストを即時に中断する際の警告や、潜在的な問題をオペレータに通知する際の警告など、複数のカテゴリに分類できます。アラームプロセスでは、テストシーケンスの正常なシャットダウンを直接管理する場合もあれば、それらの動作を管理するコマンドを他のシステムに送信する場合もあります。テストオペレータは、このアーキテクチャを使用して、緊急停止または安全なシャットダウンを設計できます。

テストの進行を妨げるアラームがない場合、論理プロセスにおいて、読み取り、スケール、アラームの各プロセスで得られた値を解析し、次の動作を決定します。たとえば、論理プロセスでは、流体マニホールドの温度が、バルブを開いて流体をパイプラインに流す (LOXマニホールド内で冷却する) タイミングに達したと判断すると、バルブを開くコマンドを別のリモートサブシステムに発行したり、バルブをローカルで開くコマンドをシーケンスプロセスに渡したりします。

シーケンスプロセスでは、限界、境界、レッドラインといった一定の条件に基づいて順序付けられたタイミングイベントに従って決定された動作を実行します。これらの条件はテストオペレータによって設定され、飛行要件 (模擬飛行制御) や打ち上げおよび施設の要件 (模擬的な打ち上げや公称値を使用したテストオペレーション) に基づいて定義されます。単純な動作は即時に実行されます。複雑な動作は、並列処理を起動することで逐次実行される場合があります。シーケンスプロセスでは、読み取り、論理、アラームの各プロセスで得られた値を入力として使用し、必要に応じて並列シーケンスプロセスの出力を更新します。

図3は、これらの機能を一連の段階として示していますが、実際に応用する際には、このパターンに基づいて個別の並列モジュールを構築し、各モジュールで固有のスレッドを実行しながら、メインのオペレーションの統括スレッドと同期することが可能です。これにより、メインスレッドは特定の動作の完了を待機するために停止することなく、一定の速度で実行されます。制御システムのループは、通常、制御されるシステムに応じて1 Hz～400 Hzの間で動作します。

この一般的なデザインパターンは、どの制御システムにも適用できますが、単純なシステムでは、一部の要素はオプションとして扱われたり、別のシステムで処理されたりする場合があります。たとえば、単純なモータコントローラにはアラームプロセスが存在しない場合がありますが、その代わりに、モータを制御するシステムの出力に基づいて、別のシステムによってアラーム状態が管理される場合があります。 単純なシステムにはシーケンスプロセスが存在しない場合がありますが、その代わりに、非常に基本的な制御システムでは論理プロセスによって直接制御されることがあります。または、iDDSまたはgRPCなどを通じて別の制御システムのシーケンスプロセスによって直接制御されることもあります。

図4.通信サービス

制御システムは、通信サービスを介してリモートコマンドの送信やテレメトリの読み取りおよび書き込みを行います (たとえば、サポートパッドを制御する別のリモート制御システムに対して、バルブを開くコマンドを送信したり、そのリモート制御システム上でシーケンスを開始したりします)。これらのサービスは、メインアプリケーション内で直接実行されるのではなく、バックグラウンドで実行されるデーモンやマイクロサービスです。読み取り入力機能自体に依存するのではなく、通信にサービスを使用することで、メインアプリケーションによってマイクロサービスのメトリックを監視できるようになります。したがって、問題が発生してもメインアプリケーションの実行に影響が及ぶことはありません。これにより、メインの制御ループから通信が抽象化されるため、時間の経過とともに、新しい通信インタフェースを持つ新しいデバイスが利用可能になったときに、機器や構成の更新を容易に行うことができます。

図4に通信サービスの例をいくつか示しますが、通信には他にもさまざまなオプションがあります。施設の設計チームは、施設用のカスタム通信プロトコルを確立するか、施設全体で使用される機器をサポートする標準プロトコルを選択します。

新しい機器を購入する際に重要な要素は、施設の既存の通信サービスをサポートすることです。施設内の通信プロトコルの数を制御することで、ソフトウェアの開発と保守が簡素化されます。サービスを使用することで、新しい通信プロトコルが利用可能になったときの処理能力が向上します。

図5.通信サービスのデザインパターン

各通信サービスは、デバイスとプロトコルのニーズを満たすように設計する必要があります。

一般的な通信サービスには、いくつかの共通要素があります。サービスの中核となるのはステートマシンです。ステートマシンは、ハードウェアの現在の状態を追跡し、次の望ましい状態を決定します。たとえば、コマンドを送信する前にデバイスを初期化する必要がある場合があります。その際、ステートマシンは、デバイスの初期化ステータスを追跡し、初期化を要求した後、コマンドの送信を要求します。通信サービスは、ある段階でタイムアウトが発生した場合やデバイスとの通信が切断された場合などに、他のネットワークアプリケーションで監視できるメトリックを提供します。これらのメトリックにより、他のシステムでの動作が促される可能性があります。

図6.オペレータコンソール

ハードウェアインタフェースは、ベンダのAPIを使用してハードウェアと通信します。

通信インタフェースは、特定のフォーマット、メタデータ、暗号化、圧縮などが含まれるプロトコルのデータをパッケージ化します。プロトコルによっては、ハンドシェイクまたは構成管理が必要であり、この管理はステートマシンに渡されます。

オペレータがアクセスできるように、各制御システムには1つまたは複数のオペレータコンソールが用意されています。制御システムの混乱を避けるため、通常、アクティブな制御コンソールは1つのみです。これは、専用の制御コンソールか、制御アービトレーション機能を持つコンソールのどちらかであり、オペレータはそのコンソールで制御を要求できます。

考慮すべき設計機能は、コンソールにおける再構成可能性です。テストの合間、さらには1つのテスト中においても、テストのニーズが変化するため、多くの場合、テストエンジニアはこれらのコンソールで追加のデータにアクセスすることが必要になります。必要なデータのほとんどは通信サービスで使用できるため、実際のソフトウェアコードを変更することなく、コンソールを作成して新しいデータポイントをサブスクライブできます。これにより、データを必要とするエンジニアは、ソフトウェアシステムの他の部分が変更されないように保護された状態で、柔軟にデータを利用できるようになります。たとえば、コンソールで通信サービスのすべてのデータチャンネルをサブスクライブし、コンソールのユーザがどの信号を表示するかを選択できるようにするなどです。NIでは、NI G Web Development Softwareを使用してStatic Data Viewerを作成する際に、このデザインパターンを使用しました。

同様に、設計者はコマンド信号を構成可能な方法でオペレータコンソールに表示するかどうかを検討する必要があります。これにより、テストエンジニアはソフトウェアを更新せずに制御機能を変更することができ、急速に変化するロケットテスト環境での生産性が向上します。この機能は、読み取り入力の段階で、制御システムにデータを渡す通信サービスに組み込む必要があります。

コンソールは、特定の制御システム専用のデバイスや画面として使用されることもあれば、他のコンソールと組み合わせてオペレータステーションとして使用されることもあります。オペレータステーションでは、試験装置全体を1つの場所で表示し、制御することができます。

これらの要素を組み合わせることで、完全なアーキテクチャが構築されます。

図7.ロケットテスト施設のアーキテクチャ

このアーキテクチャには以下の利点があります。

• 各システムは、他のシステムから独立して実行されるため、他のシステムが応答するまでに遅延が発生することを回避できます。
• 各システムは独立したシステムであるため、互いのシステムのテクノロジーに関する決定に影響を与えることなく、それぞれに最適なテクノロジーを採用できます。
• これらのシステム全体に共通するデザインパターンを用いて、ハードウェアチームとソフトウェアチームの双方が開発と保守を簡素化できます。
• 施設の規模の成長に応じて、このアーキテクチャも拡張して、必要な数の試験装置とサポートシステムに対応できます。
• このアーキテクチャは、あらゆるベンダのコンポーネントをサポートしており、新しいテクノロジーが利用可能になったときに更新できます。

完全に組み立てられた最終的なロケットテスト施設は、図8のようになります。

図8.ロケットテスト施設

このホワイトペーパーで説明するアーキテクチャは、ロケットテストシステムを設計する際のデザインパターンです。このアーキテクチャを実装するには、多くのエンジニアリング上の決定を行う必要があります。ここでの目的は、アーキテクチャのさまざまな側面からチームを導き、設計プロセスの開始時に最も重要な側面を検討できるようにすることです。

アーキテクチャの実装方法を決定する上で、以下のトピックは、設計プロセスのできるだけ早い段階で検討すべき重要事項であることが明らかになっています。

システムのレイテンシ

各サブシステム内およびテスト施設全体で、テストエリアの制御と安全性を維持するために、どの程度の遅延まで許容できますか。

システム全体のレイテンシは、設計上のいくつかの決定に起因します。ループを高速に実行すると、あるシステム内のコンポーネントから別のシステム内の別のコンポーネントへの通信速度が向上します。しかし、エンジニアは同時にシステム間のホップ数 (中継機器の数) を考慮する必要があります。データが最終的なターゲットに到達するために複数のシステムを経由する必要がある場合、制御システム間でデータをより直接的に渡せる場合に比べて、累積遅延が大きくなります。設計上の決定を行う際には、データを他のシステムで直接利用できるようにする方法と、システム間で複数回コピーすることでデータを利用できるようにする方法の両方を検討してください。

タイミング

施設内には複数のシステムが分散しており、それぞれに異なるタイムクロックが使用されます。計測全体でどの程度の時間スキューを許容できますか。

ほとんどのシステムでは、ローカルデバイスのシステムクロックで計測値に時刻スタンプを付けます。システム間でデータを解析する場合、それらのシステム間でデータを相関させることができると便利です。一般的な解決策は、IEEE-1588または同様のプロトコルを使用して、すべてのシステムに共通する絶対時間を提供することです。絶対時間は施設監視システムによって提供される場合があります。あるいは、各システムでGPS信号に基づいて時間ベースが決定される場合もあります。

この件に関連して、処理用コンピュータと地上システムの間のデータをどのように相関させるかを考慮する必要があります。これは、ロケットテストでは非常に簡単なことですが、打ち上げの状況ではもっと複雑になります。発射時に、地上システムとロケットの間のリンクが失われるためです。テストシステムでは打ち上げ時の条件が再現されるため、試験装置の設計時にこの点を考慮すべきです。

共有リソースの分配

試験装置間で共有するサブシステムと、特定の試験装置専用とするサブシステムをどのように選定しますか。

共有リソースを検討する際、2つのコスト、つまりリソースの複製にかかるコストとリソースの共有にかかるコストのバランスを考慮する必要があります。極低温タンクシステムの設置には多大なコストがかかります。さらに、極低温流体を2つの別個の試験装置に流すとなると、かなりのコストと複雑さが伴います。一方で、リソースを共有した場合も、2つの作業でどちらもリソースを使用する必要がある場合に、それらの作業を並行して実行する上で制限がかかる可能性があります。

競合状態を管理する

複数の制御システムからの命令が競合している場合、共有リソースをどのように保護しますか。

いずれの制御システムにおいても、複数のコマンドシステムで制御される場合、意図しない動作が実行される恐れがあります。その理由は、通信システムの統制が欠如していることです。たとえば、バルブは試験装置からの要求に基づいて動作を開始しますが、2台目の試験装置で設定値が上書きされると、両方の試験装置で致命的な障害が発生します。

設計チームは、システム内のコマンド信号に対して適切なロックアウトの手順が確立されており、システムが競合状態になっていないことを注意深く確認する必要があります。

ストレージシステムでデータを取得する前にそれが上書きされると、競合状態は計測データにも影響し、取得されるデータは意図したデータとならない可能性があります。

冗長化

どのようなシステムに冗長化制御を配置する必要がありますか。どの程度の冗長化を行いますか。

冗長化は、センサ、配線、収集デバイス、プロセッサ、アルゴリズム、または電源など、システム内のさまざまな場所で行うことができます。一部の宇宙関連企業は、安全性を最大限に高めるためにシステム全体を3重に冗長化することを必要としています。その他の宇宙関連企業は、最もリスクの高い障害箇所を特定し、それらの障害箇所に集中して冗長化を行っています。

設計チームは、システム内の各箇所を冗長化するにあたり、複数の冗長化モデルから選択できます。スタンバイ冗長化では、同一のセカンダリユニットがプライマリユニットをバックアップします。コールドスタンバイシステムでは、セカンダリユニットはアイドル状態にあり、ウォッチドッグがプライマリユニットの障害を検出した場合にのみ稼働します。ホットスタンバイシステムでは、セカンダリユニットは、電源が投入された状態でシステムを監視しますが、その出力はウォッチドッグが制御をセカンダリに切り替えるまで使用されません。これにより、障害時のダウンタイムが短縮されますが、セカンダリユニットが常時稼働しているため、その信頼性はアイドル状態と比べて低下します。

モジュール式冗長化はホットスタンバイ方式に類似していますが、両方のシステムは並列で実行され、それぞれに出力を生成します。多数決システム、時にはオークショナーまたは多数決回路とも呼ばれるものが、どの出力を使用するかを決定します。これにより、コントローラの1つに障害が発生した場合でも、バンプレス転送により、シームレスな切り替えが可能になります。このモデルは、2つのコントローラだけでなく、複数のコントローラに拡張できます。これらの例やその他の例は、冗長システムの基本概念に関するNIホワイトペーパーの「Redundant Systems: Definition & System Redundancy Models」で取り上げています。

環境要件

計測装置はどのような環境にさらされることになりますか。計測・制御機器を保護するためにどのようなインフラストラクチャを追加する必要がありますか。

推進力テストの実行中、試験装置の上や試験装置の近くにある機器は過酷な環境条件にさらされます。具体的には、突然の衝撃、連続振動、高温などが挙げられます。

テストの合間も、装置は過酷な環境にさらされます。高温または低温、湿度、塩害は、いずれもテストする機器の機能を妨げる要因となります。

エンジニアは、試験装置の環境条件に注意しなければなりません。こうした内容を踏まえ、システムの潜在的な要件を十分に満たす機器を選択するか、設計する必要があります。そのためには、堅牢な機器を購入したり、コンフォーマルコーティングなどの保護を追加したり、キャビネット内や環境が管理された建物に機器を設置して保護したりする必要があります。

ネットワークトポロジ

コンポーネントに障害が発生した場合の冗長化も含め、ネットワーク上のデータ転送のパフォーマンスを最適化するには、どのようなネットワークテクノロジーが必要ですか。

ネットワークトポロジの設計には、さまざまな方法があります。施設向けに成功するトポロジを確立するには、ITインフラストラクチャチームとテストエンジニアリングチームの間で詳細な話し合いが必要です。テストチームは、データの帯域幅、レイテンシ、テクノロジーのニーズを説明する必要があります。ITチームは、ネットワークのレイアウトを計画するために、暗号化、レイアウト、冗長化について理解する必要があります。

設計チームは、ネットワークの設計に関する決定事項の1つとして、冗長化モデルを選定する必要があります。冗長化モデルには、施設全体での冗長化ネットワークケーブルの配線、ラピッドスパニングツリープロトコル (RSTP) の使用、複数の分散スイッチの使用などがあります。

I/Oの網羅範囲

どのような信号を計測または制御する必要がありますか。

エンジニアリングチームが直面する最初の課題の1つは、試験装置で計測または制御する必要のある信号のリストを作成することです。信号に関するドキュメントを作成する際、信号タイプ、位置、分解能、データレート、励起の必要性、安全性の必要性、電圧および電流のレベルをリスト形式で示す必要があります。

この情報に基づき、エンジニアは信号を収集して、計測のために各バンクに分類し、その後、すべての信号にアクセスするための適切なハードウェアを選択できます。

データの帯域幅

テスト中に予想されるデータ量を処理できるネットワークトポロジを採用していますか。

ネットワークの設計 (コンピューティングデバイス、スイッチハードウェア、サブネットワークアーキテクチャなど) により、ネットワークを介して移動できるデータ量の制限が決まります。設計チームは、システムのボトルネックが生じていないかどうか、ネットワークのコンポーネントを注意深く確認する必要があります。

理論上の計算はシステム設計の指針となりますが、実際のネットワークアプリケーションで理論上のデータレートを完全に達成することは不可能です。データのオーバーヘッドとレイテンシは、ネットワークの総スループットに影響を及ぼします。ネットワークを設計する際は、データレートを理論上の制限値よりかなり低く抑えることを推奨します。

安全性

安全性を確保する上でどのようなシステムを導入する必要がありますか。

ロケット打ち上げ施設には多くの危険な条件が存在します。システムの設計、実装、または操作を誤ると、致命的な事故につながる可能性があります。設計チームは、国および地方の法律で要求される安全プロトコルを把握している必要があります。また、設計チームは、法律で規定されていない方法でも、テストステーションに関わる人員、機器、およびその区域を保護する方法を検討しなければなりません。

ロケット打ち上げ施設の一部の区域は、ロケットエンジンの駆動にガスが使用されるため、危険区域となります。これらのガスの中には、完全に封じ込めることができないものもあり、電気火花が火災や爆発を引き起こす可能性のある区域が形成されてしまいます。このような状況を防ぐには、危険区域に設置された機器は本質的に安全である必要があります。つまり、火花を発生させないことが絶対条件となります。これは、電気機器を危険区域の外側に移動することで達成できます。電気的に制御されるバルブを危険区域の外側に配置することで、危険区域内に存在する機器はバルブから延びるパイプのみとなります。

デバイスを危険区域内に設置する必要がある場合、機器はベンダによって本質的に安全であると認定されている必要があります。米国では、これはClass 1 Div 1 (クラス1ディビジョン1) の認定を取得していることを意味します。ヨーロッパでは、これはガスタイプに基づくATEX認証を取得していることを意味します。

デバイスが危険区域外に設置されている場合も、そのデバイスから危険区域内へ信号を送信する際は、デバイスで発生した火花が危険区域を通過しないように、デバイスに本質安全防爆バリアが装備されている必要があります。熱電対計測器などの下位レベルのデバイスについても、デバイスから生じる電力 (付属の電源など) が危険区域内を通過しないようにするための本質安全防爆バリアが必要です。デバイスと危険区域の間の信号経路に本質安全防爆バリアを取り付けることで、電圧スパイクと電流スパイクの両方から保護することができます。本質安全防爆バリアは信号タイプによって異なるため、熱電対用に設計されたバリアはバルブコントローラには適していません。

認定

施設、サポートシステム、試験装置について、どのような認定を取得する必要があるでしょうか。

地域の人口、施設の目的、地域の法律、ロケット打ち上げ装置の目的に応じて、地域ごとに異なる認定が必要です。たとえば、米国空軍基地のロケットテストでは、ロケット打ち上げ活動を実施する前に、AFSPCMAN 91-7108の認定を取得する必要がある場合があります。

テストの実施に必要な認定に加え、認定がテストの目的に影響することを考慮する必要があります。試験の目的が、ロケットエンジンの使用認定取得である場合、試験装置の設計はその認定の要件を満たすものでなければなりません。たとえば、MIL-STD-8109では、テスト対象のデバイスが製品の使用に関して想定される条件を満たしていることを確認します。MIL-STD-20210では、300 lbs未満のコンポーネントが厳しい使用環境下での電気要件と環境要件を満たしていることを確認します。これらの認定は、テスト対象のテクノロジーの潜在顧客が米国国防省である場合に必要となる場合があります。

試験装置とサポートシステムを備えたロケットテスト施設の設計は、大規模でありながら、詳細な設計が必要となるプロジェクトです。このホワイトペーパーの目的は、一般的なデザインパターンと設計プロセスを構築する手法を提供することです。ここでは、このプロセスの各段階に関する詳細は取り上げていませんが、少なくとも、設計プロセスはここで示されている基本的な手順に従います。お客様の設計チームがこの設計プロセスを単独で実装することが難しい場合は、NIおよびNIのパートナー企業のサポートを受けることができます。詳細については、ページ下部のサービスに関するセクションを参照してください。

システムの特定

作成内容:施設用に設計して組み込むシステムおよびサブシステムのブロック図

施設のシステムのレイアウトを作成することから始めます。施設の現在および将来のニーズに基づき、試験装置とサポートシステムの位置を計画します。システム間の転送および接続を計画します。共有するサポートシステムと、試験装置専用とするサポートシステムを選定します。

システム要件の作成

作成内容:施設用に設計して組み込む各システムおよび各サブシステムの詳細要件

特定した各システムの要件をドキュメント化します。アップデートレートや通信プロトコルなど、予想される入出力のリストを作成します。必要なパフォーマンスなど、システムに求められる機能をドキュメント化します。各システムの設計を社内のどの分野のチームが担当するかを決定します。

施設全体の要件の特定

作成内容:施設全体を連携するシステムとインフラストラクチャの詳細要件

特定した各システムの要件に基づき、それらのシステムをサポートするために、施設全体のシステムで必要となるパフォーマンスを特定します。すべてのシステムとコンポーネントのレイテンシ要件を満たすために必要なアップデートレートをドキュメント化します。ITチームと協力して、システムのニーズを満たすためのネットワークインフラストラクチャの要件の概要を作成します。システム内で起こり得る最悪のシナリオに基づいて、データレートを計算します。

テクノロジーの選定

作成内容:システム要件および施設要件に対応するテクノロジーのリスト

システムと施設の要件に基づき、ドキュメント化したニーズを満たすために取得または開発する必要のあるテクノロジーを特定します。ベンダと話し合い、すぐに使用可能な既成のテクノロジーを特定します。エンジニアリングチームと協力し、システムに関する未解決の課題に対処するためのカスタムの技術的アプローチを特定します。可能な場合、システムのパフォーマンスをテストして、要件を満たしていることを確認します。

通信サービスの設計

作成内容:システムおよび施設機器に使用する各通信サービスの要件および実装を示すドキュメント

システムで使用可能なテクノロジーを十分に理解した上で、各通信サービスのニーズをドキュメント化します。各サービスの入力、出力、処理を特定します。サービスを完全に実装するためにどのような専門知識が必要かを特定します。

システムコントローラの設計

作成内容:施設内の各システムコントローラの設計ドキュメント

システムおよび施設のために選定したテクノロジーにシステム要件を適用します。特定のパフォーマンス基準に基づいて、必要な入力、出力、機能をドキュメント化します。システムコントローラの実装にどのような専門知識が必要かを特定します。

システムコントローラと通信サービスの実装

作成内容:各システムコントローラおよびシステム間で実行するコード

各システムコントローラおよび各通信サービスで実行するコードを開発します。要件を記載したドキュメントに変更を加えた場合はそのすべてをドキュメント化し、いずれの変更も他のシステムに影響を与えないことを確認します。適切なエンジニアリングの指針を開発に適用します。たとえば、ドキュメントに記載された要件を各コンポーネントが満たすことを確認するためにユニットテストを実施するなどです。

システムコントローラの接続

作成内容:制御システム間での値の更新

システムコントローラと通信サービスを接続します。システムが、予測されるパフォーマンスの範囲内で適切に動作することを確認します。コンポーネント、サブシステム、システムを順次接続し、その各段階でユニットテストを引き続き実施します。

システムパフォーマンスの妥当性確認

作成内容:各システムコンポーネント、システム、および相互接続されたシステムのパフォーマンスの妥当性確認

システム全体が揃った状態で、各システムと施設全体のシステムの妥当性確認テストを実行します。要件を見直し、すべての要件が満たされていることを確認します。予期しない動作が発生した場合は開発者に報告し、望ましいパフォーマンスが得られるまで妥当性確認テストを反復します。

オペレータステーションとビューアの作成

作成内容:システムの制御と表示を行うオペレータ画面およびステーション

オペレータコンソールは、システムと共に開発されます。コンソールの操作性を改善し、最終的なオペレータコンソールを作成します。

このロケットテストアーキテクチャで使用できるテクノロジーには、近年、いくつかの進歩が見られます。

gRPC

gRPCは、あらゆる環境で実行できるオープンソースの高性能フレームワークです。Googleが開発し、リモートプロシージャコール (RPC) をベースにしたgRPCは、システムの各部の間でデータを受け渡す方法として、この5年間で急速に普及しました。gRPCを使用すると、クライアントアプリケーションから、別のマシン上のサーバアプリケーションのメソッドをローカルオブジェクトのように直接呼び出すことができます。これにより、ロケットテストアーキテクチャのような分散型のアーキテクチャを容易に作成できるようになります。NIソフトウェアおよびハードウェアのツールはgRPCに対応しています。「NI gRPC Support Resources & Compatibility」の記事で、gRPCのサポートリソースと互換性に関する情報を提供しています。

iDDS

iDDSは、Rolls-RoyceとMDS Aeroがジェットタービンエンジンテスト用に開発したデータ抽象化プロトコルです。iDDSは、計測器ノードからデータを収集するための通信サービスを提供し、このデータはネットワーク上のサブスクライバに提供されます。iDDSは、データ配布サービス (DDS) バックボーンおよびオブジェクト管理グループ (OMG) 規格に基づいて構築されています。iDDSは、DDSネットワーク上の計測データのパッケージ化を定義します。この計測データには、チャンネルメタデータ、タイムスタンプ、構成、健全性の監視などの内容が含まれます。デバイス間の通信はiDDSモデル内で標準化されているため、ベンダ固有の機能が抽象化され、新しいテクノロジーが利用可能になったときに機器の交換が容易になります。これは、交換する機器が新しいベンダのものであっても同様です。

NIは、ロケットエンジンテスト、変化する安全性要件の統合、新しいセンサ、市場で要求されるテクノロジーに対応する、カスタマイズされたハードウェアおよびソフトウェアソリューションを提供しています。NIのソフトウェアでは、カスタムのテストソリューション、リアルタイムのデータ可視化、ロギング、自動テストシーケンスのためのツールをご利用いただけます。これらのソフトウェアソリューションでは、強力で適応性の高いプラットフォームを活用して、データ解析、施設管理、そして全体的なテスト効率を向上します。

NI PXI、NI CompactDAQ、NI CompactRIOなどのハードウェアプラットフォームは、過酷な条件に耐えるように設計されており、さまざまな信号をサポートしているため、ロケットエンジンテストにおいて、信頼性が高く、正確な計測と制御を行うことができます。これらの堅牢なモジュール式システムの分散型計測とローカル処理機能を使用して、テストの確度と柔軟性を高めることができます。ロケットエンジンの推進力をテストするNIソリューションでは、かつてないほど短いタイムラインでより多くのエンジンをテストできます。詳細については、「ロケットエンジンの推進力のテスト」を参照してください。

• ロケットエンジンの推進力のテスト向けソリューション
• ロケット推進試験用NASAデータ収集システムソフトウェア
• テストによって革新的なロケット開発の効率を実現する

脚注:

¹ https://arstechnica.com/science/2022/01/thanks-to-china-and-spacex-the-world-set-an-orbital-launch-record-in-2021
² https://www.go-astronomy.com/space-ports.php
³ https://www.ecfr.gov/current/title-14/chapter-III
⁴ https://ntrs.nasa.gov/api/citations/20050182932/downloads/20050182932.pdf

参考資料

• https://static.e-publishing.af.mil/production/1/ssc/publication/sscman91-710v3/sscman91-710v3.pdf
• https://www.atec.army.mil/publications/mil-std-810g/mil-std-810g.pdf
• https://nepp.nasa.gov/DocUploads/1F6AB74B-4517-4AD0-A34813268E75B8EB/MIL-STD-202.pdf