進階火箭引擎測試架構可提升系統獨立性與維護作業
綜覽
此技術文件針對火箭引擎測試設施的設計與實作提供完整指南。其中包含火箭引擎測試流程、火箭測試架構的關鍵要素，以及測試設計的重要考量，例如系統潛時、時序與備援。此篇技術文件詳細說明實作步驟，包含系統識別、技術選擇，與系統效能檢驗。本文件亦說明 gRPC 與 iDDS 相關新興技術，此技術可提升測試系統的通訊與資料管理效能
內容
如何測試火箭引擎？
發射嘗試次數在 2021 年比以往任何一年都來得多。1全球公司與政府總共嘗試 146 次，成功進入軌道 135 次。1967 年太空競賽（蘇聯與美國為進入與深入太空而展開激烈競爭）創下的 139 次發射紀錄在 2021 年被打破。2020 年代的太空競賽不僅此兩國而已。發射國現在包括有美國、英國、歐洲、俄羅斯、中國、印度、土耳其、伊朗、以色列等國；僅 2022 年前 6 個月就成功進行了 72 次飛行。競賽不再是政府專案；許多私人太空公司也彼此競爭，為市場投入大筆資金。
新的火箭技術促成太空發射熱潮。SpaceX 公司在 2021 年發射 31 次獵鷹九號飛行任務，且任務全部順利完成。新的火箭設計方式讓他們能夠使用先前用過的火箭核心，來發射所有這些飛行任務，只有兩個新的獵鷹九號第一節被引進來支援這些發射活動。為提升太空發射作業的穩定性、再利用性與經濟性，發射次數與發射範圍也隨公司與國家的持續投資而不斷增加。
支援這些發射的基礎架構也同時增加中。目前共有 35 個有效的太空場與發射設施可支援亞軌道、軌道與軌道外任務。發射地點涵蓋全球，包括五大洲超過 13 個國家，2目前還有其他國家也在建設新設施。其他地點則是用來測試從那些設施發射的火箭。參與太空產業令人感到興奮。
美國聯邦航空局 (FAA) 對任何從美國境內外，由美國公民或實體進行的火箭發射任務進行監管。3其他國家也有類似的法規與監管機構。如公司未經適當的工程步驟，即無法發射升空。其中一項關鍵步驟是測試火箭載具，且可證明其成功的可能性極高。
測試火箭前要先測試各個火箭元件。工程團隊會分別測試組成結構、燃料與電子元件的材料與元件。接著將這些元件作為子系統進行組裝與測試，並在完成最後組裝後，進入完整的階段層級驗收測試。
NI 產品可用於載具各層面。靜態與疲勞結構測試平台適用於測試飛行壓力承受性的燃油箱強度。測試航空電子電路時，NI PXI 架構模組化儀器與自動化測試軟體可作為一個強大的平台。NI 的 LRU HIL 測試架構適用於測試航空電子控制器，可建立多種測試案例。
此篇技術文件著重於火箭引擎測試，但其中許多要素亦將套用至最後完整的載具測試。
火箭引擎測試是測試所有火箭引擎類型的重要部分。這項測試必須符合 FAA 法規。但測試所提供的價值不僅是遵守法規而已。美國太空總署 (NASA) 報告顯示，火箭引擎的測試時間量與這些引擎的穩定性有正相關關係。4各引擎製造商都必須決定，如何在額外測試的投資及成本，與測試的預期效益之間取得平衡。
什麼是火箭引擎測試台？
火箭引擎測試台是專為維持和測試火箭引擎所設計的結構，可提供必要的支援與控制系統，包含壓緊推力結構、推進劑、冷卻系統、廢氣轉移的地面支援設備，以及測試期間安全性與操作管理的自動化。若要測試火箭引擎，必須將引擎安裝至測試台，並啟動一段有限的時間。火箭引擎測試台必須具備必要的壓緊推力結構、推進劑、冷卻系統、轉移與廢氣的地面支援設備，以及冷卻系統，以進行自動化測試作業，並維護操作與測試期間的安全性。工程師必須決定要以垂直或是水平方式來安裝火箭。這兩種安裝方式各有優勢。垂直安裝引擎的受力與飛行期間的受力相近，因此較容易將量測結果與垂直安裝引擎相關聯。但垂直安裝引擎在測試期間會對火箭排廢氣布線造成問題，因此通常以火焰轉移器來進行。
圖 1.火箭引擎測試台要素
廢氣會對測試設施帶來不同難題。除熱能外，廢氣還會產生噪音與污漬。在廢氣中加入大量水流可作為排放引擎熱能的緩衝，並阻絕周圍環境的噪音與污染物。
火箭引擎測試有許多變數。海平面標準測試可能會在測試台上執行，不需要額外設備，但其他測試可能需要特殊的測試環境。舉例來說，若要在太空中的衛星上測試火箭推進器姿態控制，則測試台需要一個真空室，來複製引擎的預期操作條件。其他測試可能需要熱能真空室，或額外機械裝置，以測試引擎萬向節。
測試站也會因引擎開發階段而有所不同。早期的開發引擎測試可能包含許多額外的感測器，因為工程師會嘗試擷取更多引擎效能的動態。測試台在飛行任務之前執行資格或驗收測試時，可能會測試較小的一組訊號，以驗證是否正常運作。
設計火箭測試的工程團隊在設計新的測試台時，必須考慮到所有這些潛在需求。火箭技術日新月異，工程師也必須規劃未來可能需要的測試作業。測試設計的功能必須夠強大，才能符合已知需求，同時也要夠靈活，才能滿足日新月異的需求。
NI 工程師已與火箭測試系統的設計工程師密切合作 30 多 年。在此期間，隨新技術與軟體技術的問世，架構也趨於成熟。噴射引擎測試、風洞與其他大型測試設施等相關應用的最佳實務，已對火箭引擎測試系統設計形成影響。某些關鍵原則已成為火箭引擎測試架構設計成功與否的核心。
火箭測試設施可支援單一測試台或多個測試台。每個測試台都需要不同的子系統或墊片支援。這些子系統或測試台可能專屬於一個測試台，也可能由測試設施內的多個測試台或站點共用。設施範圍的地面控制系統監控器可整合所有的墊片和測試台，以協調運作管理設施資源。
圖 2.火箭測試設施子系統
支援墊片控制系統必須提供穩定的控制與量測功能，才能追踪並提升效能。
如要讓火箭測試基地成功實施，就必須仔細協調這些系統。過去幾年來，主要的太空設施均開發出控制機制，可提供靈活的設計場型，以因應系統間的通訊作業與測試間系統的差異。在管理測試與發射設施的太空公司中，許多場型元件都是共用的，以減少測試內容與發射方式之間的差異。
火箭測試架構
此架構使用所有測試台與墊片通用的系統設計場型。此場型可提供各系統所需的本地控制功能，並在系統間共用資訊，以確保測試作業同步化。
圖 3.一般控制系統設計場型
在此場型中，控制系統讀取通訊程序的輸入（本文件有後續說明）。
單位轉換程序會將這些原始單位轉換為適合子系統的科學單位。單位轉換程序亦可將多個通道整合為單一計算通道，例如，將所有推力負載單元相加，以提供單一推力值。單位轉換程序也會套用可重設的校準作業，因為儀器可能會在測試之間或操作期間改變。
警示程序會評估單位轉換程序的資料點輸出，以識別警示。警示可分為多個類別，例如立即中止測試，或通知操作人員有關潛在問題的警示。警示程序可能會管理測試序列的成功關機，也可能會傳送指令到其他系統，以管理這些動作。測試操作人員可使用此架構，來設計緊急停止或正常關機。
若沒有警示可阻止測試程序，則邏輯程序會分析讀取、單位轉換程序與警示程序的數值，以決定後續行動。舉例來說，邏輯程序可能會判斷流體歧管的溫度是否已達到可開啟閥門，好讓流體流過管線的時機（即在 Lox 歧管中冷卻），因此會發出指令至另一個遠端子系統，或傳送指令至序列程序，以於本地端開啟閥門。
接著序列程序會根據測試操作人員開發的條件（限制、邊界與紅線），來執行由有階次與時序事件所確認的動作，並由飛行需求（模擬飛行控制）或發射/設施需求（模擬發射或名義測試作業）來定義。可立即執行簡單的動作；因為複雜的動作可能會衍生出平行程序，以處理序列執行。序列程序會使用讀取、邏輯與警示程序的數值作為輸入，並根據需要更新平行序列程序的輸出。
圖 3 將這些功能描述為一系列步驟，但就應用而言，此場型可讓獨立的平行模組執行各自的執行緒，並同步化主要的作業調度執行緒。這樣一來，主執行緒就能以穩定的速度執行，不必停下來等待動作完成。控制系統迴圈的運作頻率通常介於 1 Hz ~ 400 Hz 之間，取決於受控制系統。
此通用設計場型可套用至任何控制系統，但在簡單系統中，某些元素可能是可選的，或由不同的系統來處理。舉例來說，簡單的馬達控制器可能沒有警示程序。相反地，警示條件可能會由另一個系統根據控制馬達的系統輸出來處理。 簡單的系統可能沒有序列程序，而是由基本控制系統的邏輯程序，或直接由其他控制系統的序列程序來控制，例如 iDDS 或 gRPC。
圖 4.通訊服務
控制系統會透過通訊服務讀取，並寫入遠端指令與遙測資料（例如指示開啟閥門，或對另一個控制支撐墊的遠端控制系統啟動序列）。這些服務屬於守護進程或微服務，可於背景中執行，而非直接在主應用程式中執行。使用服務來通訊，而非依賴讀取輸入功能本身，可讓主應用程式監控微服務的指標，如此一來，執行主應用程式時就不會受到任何問題的影響。這樣即可將通訊作業從主控制迴圈中抽離出來，以便使用新裝置時可更輕鬆地更新設備與設定。
圖 4 列出數個通訊服務範例，但仍有其他眾多不同的通訊選項。設施設計團隊可能會為設施建立客製化通訊協定，也可以選擇標準協定，以支援整個設施所使用的設備。
購買新設備時最重要的考量是，能否支援設施現有的通訊服務。只要控制現場通訊協定的數量，即可簡化軟體的開發與維護作業。當使用新的通訊協定時，使用服務即可改善程序。
圖 5.通訊服務設計場型
每項通訊服務都必須符合裝置與協定的需求。
典型的通訊服務包含某些常見元素。服務的核心是狀態機器 (State machine)，可追踪硬體的目前狀態，以決定下一個所需狀態。舉例來說，在傳送指令前，可能需要初始化裝置，亦即讓狀態機器追踪裝置初始化的狀態、要求初始化作業，並要求傳送指令。服務所提供的指標可由其他網路應用程式來監控，例如某個步驟何時超時，或失去與裝置的通訊作業。並可於其他系統中進行相關動作。
圖 6.操作台
硬體介面使用製造商的 API 與硬體來進行通訊。
通訊介面會針對協定封裝資料，資料內可能包含特定格式、元資料、加密或壓縮。某些協定需要交握 (handshaking) 或設定管理 (Configuration management)，再傳送至狀態機器 (State machine) 進行管理。
為讓操作人員存取功能，每個控制系統可能會配備一個或多個操作台。為避免控制系統混亂，通常只會啟用 1 組控制台。這可能是專用的控制台，或具有控制仲裁的控制台，讓操作人員可以請求控制。
其中一項必須考量的設計功能是控制台的可重設功能。測試之間甚或測試期間的測試需求都會不斷變化，測試工程師往往需要存取這些控制台中的額外資料。由於通訊服務可提供多數的所需資料，因此可建立操作台，讓使用者不需變更實際的軟體程式碼，即可訂閱新的資料點。這樣一來，需要資料的工程師即擁有靈活性，可避免系統其他部分的軟體需要變更。舉例來說，控制台可訂閱通訊服務中的所有資料通道，並讓控制台使用者選擇所要檢視的訊號。NI 採用此設計場型，來建立使用 NI G Web Development Software 的 Static Data Viewer。
同樣地，設計人員也應該考慮，是否要透過可設定的方式，將指令訊號提供給操作員控制台。這樣可讓測試工程師變更控制功能時，不需更新軟體，以便在快節奏的火箭測試環境中提高生產力。必須將此功能設計至通訊服務，以便在讀取輸入步驟時，將資料傳送至控制系統。
控制台可能是特定控制系統的專用裝置或螢幕，也可能與其他控制台整合為操作員工作站。操作員工作站可在單一位置提供整個測試台的檢視與控制功能。
如此可整合為一個完整的架構。
圖 7.火箭測試設施架構
此架構具有下列優點：
- 各個系統均可獨立運作，避免因等待其他系統回應而造成延遲。
- 作為獨立系統，每個系統都可以使用最合適的技術，而不影響其他系統的技術決策。
- 跨系統的通用設計場型可簡化軟硬體團隊的開發與維護作業。
- 此架構可隨設施規模來擴充，支援任何數量的測試台與支援系統。
- 此架構可支援任何製造商的元件，並可隨時更新。
最後組裝完畢的火箭測試設施可能如圖 8 所示：
圖 8.火箭測試設施
測試架構設計的考量要點
本文所述架構為火箭測試系統的設計場型。實作此架構時必須做出許多工程決策。此篇文件的目的在導引團隊了解架構的各個層面，以確保設計流程開始時，即可考量到最重要的層面。
在決定如何實作此架構時，下列主題是最關鍵考量要點的其中一部分，應儘早進行準備。
系統潛時
在每個子系統和整體測試設施中，為維持測試區域的控制性與安全性，最大容許延遲時間為何？
系統整體潛時是多項設計決策的結果。較快的迴圈可提高一個系統元件與另一個系統元件之間的通訊速度。但工程師也必須考量系統之間的跳數。如果資料必須在數個系統之間傳遞才能達到最終目標，則累積的延遲就會比直接在控制系統間傳遞資料的時間還要長。做出設計決策時應考慮如何將資料提供給其他系統——是直接提供，還是在系統之間複製多次。
時序
分散在設施中的系統將具有不同的時脈。量測作業可容許的時間歪曲 (Time skew) 量為何？
多數系統都會透過本地裝置的系統時脈來標記量測作業。跨系統分析資料時，跨系統建立資料關聯很有用。常見的解決方案即是使用 IEEE-1588 或類似協定，在所有系統間提供絕對時間。時間可能由設施監控系統提供，或者系統可依賴 GPS 訊號做為時基。
相關考量為處理電腦與地面系統之間的資料關聯方式。在火箭測試中，此一步驟相當簡單，但在發射時，則變得較複雜，因為地面系統與火箭之間的任何連結，都會在發射時喪失。由於測試系統會複製發射條件，因此設計測試台時應考慮這一點。
分配共用資源
哪些子系統會在測試台之間共用？哪些子系統會專屬於特定測試台？
共用資源時必須考慮如何平衡兩項成本——複製資源的成本與共用資源的成本。設定低溫儲槽系統的成本非常高。但若將低溫液體分別用於 2 組獨立測試台，會耗費大量成本，複雜性也變高。若 2 項活動均需相同資源，則共用資源也會限制同時執行的能力。
管理競態條件
如何保護共用資源不受不同控制系統間競合指令的影響？
任何可由多個指令系統控制的控制系統，都有可能因為通訊系統缺乏紀律，而執行非預期動作。舉例來說，閥門可能會根據測試台的需求開始作業。但如果第二個測試台覆寫設定點，那就會導致兩個測試台發生災難性故障。
設計團隊必須仔細檢視系統中的潛在競態條件，以確保系統中的指令訊號均具備適當的鎖定程序。
若在儲存系統檢索資料前即覆寫資料，則競態條件 (Race condition) 亦將影響量測資料，導致檢索資料可能並非預期資料。
備援功能
哪些系統必須具備備援控制功能？應提供何種程度的備援功能？
系統內有多處均可使用備援功能，例如備援感測器、接線、擷取裝置、處理器、演算法，或電源供應器。某些太空公司對整體系統要求 3 倍備援，以達最高安全性。其他系統則可找出最高風險的故障點，並針對這些故障點集中備援。
針對系統中的每個點，設計團隊均有多種可選擇的備援模型。就備用備援而言，相同的次要裝置會為主裝置備份。在冷備份 (Cold Standby) 系統中，次要裝置會處於閒置狀態，只在監控器 (Watchdog) 偵測到主裝置發生故障時才會開始運作。在熱備份 (Hot Standby) 系統中，次要裝置會通電，並主動監控系統，但在監控器切換控制之前不會使用其輸出。這樣一來，雖然可以縮短故障的停機時間，但由於次要裝置仍在運作中，因此無法為其保持穩定性。
模組化備援 (Modular Redundancy) 與熱備份 (Hot Standby) 方式類似，但此 2 組系統可平行運作，並產生系統輸出。投票系統有時稱為拍賣者 (Auctioneer) 或投票者 (Voter)，可決定應使用那些輸出。若其中一個控制器發生故障，則可提供無擾 (Bumpless) 傳輸。此模型可從 2 組控制器擴充為多組控制器。NI 的「Redundant System Basic Concepts（備援系統基本概念）」技術文件會說明這些範例與其他範例。
環境規定
量測設備會受何種環境的影響？我們需要哪些額外的基礎架構來保護量測與控制設備？
在推進測試期間，機架上或附近的設備會受極端環境條件的影響。其中可能包含瞬間衝擊、持續振動與高溫。
設備在測試期間也會受到極端環境的影響。高溫或低溫、濕度與鹽霧都是測試設施可用性的特定威脅。
工程師必須了解測試台的環境條件。他們必須參考這些資訊來選擇或設計系統潛在需求外的設備。這讓他們可能需要購買堅固耐用的設備、加入保形覆膜等保護措施，或保護機箱內或環境控制附屬建築中的設備。
網路拓撲
何項網路技術可為網路資料傳輸提供最佳效能（包含元件故障時的備援功能）？
設計網路拓撲時有多項選擇。IT 基礎架構團隊與測試工程團隊必須深入溝通，才能打造出成功的設施拓撲。測試團隊必須說明資料頻寬、潛時與技術需求。IT 團隊必須了解加密、配置與備援功能，才能規劃網路配置。
在設計網路的決策中，設計團隊必須決定備援模型，其中可能包括在整個設施中運行備援網路連接線、使用快速生成樹協定 (RSTP)，並使用多個分配切換器。
I/O 範圍
我們需要量測或控制哪些訊號？
工程團隊所面臨的首要任務之一是，收集需要在測試台中量測或控制的訊號清單。記錄訊號時必須列出訊號類型、位置、解析度、資料傳輸率、激發需求、安全需求、電壓與電流準位。
工程師可透過此資訊，將訊號收集至量測組間，並選擇正確的硬體來存取所有訊號。
資料頻寬
網路拓撲能否處理測試期間的預期資料量？
網路設計（包含運算裝置、切換硬體與子網路架構）將限制可跨網路傳輸的資料量。設計團隊必須仔細檢視網路元件，以找出系統中的瓶頸。
理論計算可提供系統設計指南，但網路應用永遠無法達到完整的理論資料傳輸率。資料負載與潛時會影響網路的總傳輸量。設計網路時，最好將資料傳輸率控制在遠低於理論限制的水平上。
安全性
需要準備好哪些安全系統？
火箭設施有許多危險的條件。不論是在設計、執行或系統運作中出錯，都可能導致災難性事故。設計團隊必須了解聯邦與當地法律所規定的安全協定。設計團隊也必須考慮如何以法律未涵蓋的方式，來保護人員、設備以及與測試站相關區域。
因受為推動火箭引擎而使用的氣體影響，火箭設施的某些區域屬於危險區域。其中某些氣體無法完全控制，因此任何電子火花都有可能導致某一區域發生火災或爆炸。為避免這種情況，危險區域內的所有設備都必須具備本質安全，也就是說不能產生火花。只要把電子設備移出危險區域，就可以解決這個問題。電子控制的閥門可放置在區域外，因此區域內唯一的設備是遠離閥門的管道。
如果裝置必須位於危險區域內，則設備必須經過設備製造商的本質安全認證。美國稱其為：Class 1 Div 1 認證。歐洲稱其為：氣體類型用 ATEX 認證。
若裝置位於危險區域外，但訊號傳輸至該區域，則裝置必須具備固有屏障，以防止裝置產生的火花進入危險區域。即便是初階裝置（如熱電偶量測儀器）亦需要內建阻障 (Intrinsic barrier)，以防止裝置（如外接電源供應器）的電力進入區域。裝置與危險區域間的訊號路徑可附加固有屏障，以防止電壓與電流突波。請注意，固有阻隔會因訊號類型而有所不同，所以專為熱電偶設計的阻隔不適用於閥門控制器。
認證
設施、支援系統與測試台必須通過哪些認證？
根據人口、設施用途、當地法律以及火箭設備用途，不同地區需要不同的認證。舉例來說，在美國執行火箭測試時，空軍基地可能需要 AFSPCMAN 91-7108 認證，才能進行任何火箭活動。
除執行測試需要認證外，認證也會影響測試目標。如果測試目的是為認證火箭引擎使用狀況，則測試台設計就必須符合該認證規定。舉例來說，MIL-STD-8109 可為受測裝置確保，符合預期的產品使用條件。MIL-STD-20210 可為 300 磅以下的元件確保，符合應用中嚴苛的電子與環境需求。如受測技術的目標客戶是美國國防部，則可能需要這些認證。
實作步驟
設計火箭測試設施、測試台與支援系統為大型專案。此篇技術文件的目的是提供一般的設計場型與設計流程。此篇技術文件不詳述設計流程每項步驟，但設計流程將依循這些基本步驟。如果您的設計團隊不具備流程所需的能力，請參閱下列服務章節，來了解如何讓 NI 與 NI 合作夥伴參與設計流程。
確認系統
輸出設施內系統與子系統設計用程式方塊圖
首先要佈署設施系統。根據設施目前與未來的需求，來規劃測試台與支援系統的位置。規劃系統之間的傳輸作業以及系統之間的連線。決定要共用的支援系統，以及測試台專用的支援系統。
建立系統需求
輸出設施內系統與子系統設計詳細需求
針對每個識別系統記錄其需求。列出預期的輸入與輸出，包含更新率與通訊協定。記錄系統的預期功能，包含所需效能。決定由公司的哪個職能團隊負責設計各個系統。
了解設施整體需求
輸出系統與基礎架構的詳細需求將配合設施
根據系統需求來確認設施系統所需效能，以支援這些系統。記錄必要的更新率，以符合所有系統與元件的潛時需求。與 IT 團隊合作確認網路基礎架構需求，以符合系統需求。計算系統中最壞情況的資料傳輸率。
選擇技術
輸出涵蓋系統與設施需求的技術清單
根據系統與設施需求，確認需要取得或開發的特定技術，以符合已記錄的需求。與供應商溝通，確認可用的現成技術。與工程團隊合作，確認客製化工程方式，以補強系統不足處。在可能的情況下測試系統效能，以確保系統符合需求。
設計通訊服務
輸出為系統與設施設備使用的各項通訊服務，記錄其需求與實作方式
充分了解系統可用的技術後，即可記錄各項通訊服務的需求。確認各項服務的輸入、輸出與處理作業。確認完整實作服務所需的專業知識。
設計系統控制器
輸出設施內各系統控制器的設計文件
將系統需求套用至針對系統與設施所選的技術。根據特定效能標準，來記錄所需的輸入、輸出與功能。了解實作系統控制器所需的專業知識。
實作系統控制器與通訊服務
輸出為各系統控制器與系統間執行的程式碼
開發可在系統控制器與通訊服務內執行的程式碼。記錄需求文件中的任何變更，並確認變更不會影響其他系統。將適當的工程原理套用至開發作業，包含單元測試，以確認每個元件是否符合記錄的需求。
連接系統控制器
輸出控制系統間的數值更新
連接系統控制器與通訊服務。確認系統可正常運作，且在預期的效能範圍內。只要元件、子系統與系統連線，即可持續執行單元測試。
檢驗系統效能
輸出檢驗每個系統元件、系統與互連系統的效能
安裝完整系統後，即可為系統與整體系統執行完整的檢驗測試作業。檢視需求，以確認是否符合所有需求。向開發人員回報任何非預期行為，並反覆執行，直到達到所需的效能為止。
建立操作站與檢視器
輸出用來控制和檢視系統的操作畫面與工作站
操作控制台將與系統一同開發。將改善後的功能套用至控制台，並建立最終操作控制台。
火箭引擎測試的新興技術
目前已有多項技術可用於此火箭測試架構。
gRPC
gRPC 是一種屬於開放原始碼的高效能架構，可執行於任何環境中。由 Google 開發，並以遠端程序呼叫 (RPC) 為基礎的 gRPC，在過去 5 年內迅速普及，成為系統各部分間傳輸資料的一種方式。使用 gRPC 後，用戶端應用程式就可以直接呼叫不同機器上伺服器應用程式的方法，就像是本地端物件一樣。如此可簡化如同火箭測試架構這樣的分散式架構。NI 軟硬體工具可搭配 gRPC 來使用。取得 gRPC 支援資源與相容性的相關資訊。
iDDS
iDDS 為 Rolls Royce 與 MDS Aero 針對噴射渦輪引擎測試所開發的資料抽象化協定。iDDS 在為儀器節點收集資料時提供通訊服務，這些資料可供網路訂閱者使用。iDDS 是以資料分配服務 (DDS) 骨幹與 Object Management Group (OMG) 標準為基礎。iDDS 定義 DDS 網路上儀控資料的封裝方式，包含通道元資料、時間戳記、設定與狀態監控等量測資料。由於裝置間的通訊均已在iDDS 模型中標準化，因此特定製造商的功能會被抽象化 (Abstraction)，只要有新的技術出現，就可以輕鬆替換設備，就算是來自新製造商的設備也沒問題。
為進階火箭引擎測試量身打造的 NI 解決方案
NI 針對火箭引擎測試提供客製化軟硬體解決方案，以將日新月異的安全需求，新的感測器，與市場需要的技術整合在一起。我們的軟體可提供客製化測試解決方案、即時資料呈現、記錄，與自動化測試序列等工具。這些軟體解決方案可透過強大且可調整的平台，來促進資料分析、設備管理與整體測試效率。
NI PXI、NI CompactDAQ 與 NI CompactRIO 等硬體平台均經過特殊設計，可承受極端條件，並支援多種訊號，以確保火箭引擎測試期間能達成精確量測與控制作業。這些堅固耐用的模組化系統，提供分散式量測與本地端處理功能，可提升測試的精確度與靈活性。了解更多我們的火箭引擎推進測試解決方案，並探討如何在更短時間內測試更多引擎。