像是飛機推進系統這類機電系統,是由軟體、控制器和機械元件組成。隨著複雜度持續增加,這些系統需要更精細的測試方法,以便在專案時程和預算限制中達到所需的測試範圍。此外,這些測試系統在數十年的生命週期內必須不斷維護,以履行維護-維修-停產 (MRO) 服務合約,同時也要定期進行改良以適應系統升級。
在漫長的系統生命週期內,妥善支援日益複雜的受測裝置 (DUT) 和測試系統是一項重大挑戰,而在資源有限的情況下這項挑戰又特別明顯。靈活的平台架構測試方法可協助您開發一致的測試架構,來應對這些挑戰。在單一測試架構上整合作業有許多優點,包含縮短測試開發時間,盡可能減少整個開發週期或跨專案不同測試團隊的重複作業量。
為了獲得最大利益,機電系統的一致測試架構應:
• 為整個設計週期的測試需求提供服務,從前期的原型製作到軟體、電氣和機械驗證,到系統層級的測試設備和系統整合實驗室 (「鐵鳥」),再到生產測試
• 支援模型架構的控制和模擬作業,以在開發週期內盡早進行測試,並且模擬各種難以複製的測試案例以及壓力測試。
• 整合各種 I/O 和第三方裝置,例如感測器、致動器、儀器和軟體,藉此盡可能提升重複使用率,並將整合作業降到最低。必須採用可配置/可擴充和分配式/同步的 I/O 架構,以滿足在設計流程中對測試案例的不同 I/O 需求,同時促進跨專案的重複使用。
• 提供企業級與 IT 較容易支援的資料管理和系統管理架構,改善決策制定流程、減少重複測試次數、報告生成時間與工作量,並提升資產利用率和正常運作時間。
機電系統可將能源轉換為機械功,反之亦然。此類系統包含控制電子裝置 (例如:電子控制單元) 或嵌入式控制器 (例如:可更換線路的單元),這些裝置運行專用的軟體,而這些軟體會使用來自感測器與其他系統的輸入,來控制機器、致動與實體元件。機電系統提供載具推進力,並在飛機、地面車輛與船舶上提供各種其他功能。
圖 1.載具類別範例與其中常見的機電系統類型
雖然這些載具系統的功能、操作機制與設計需求差異可能大為不同,這些機電載具系統的開發與測試作業卻遵循相同的一般工作流程。系統工程師會進行整體車輛/飛機/船隻的設計,並確認這些載具的系統、子系統與元件必須滿足的需求。不同的團隊會根據規格開發合適的控制電子裝置、軟體和機械元件,藉此滿足這些需求。這些團隊會採取各自的開發流程 (通常是針對特定組織需求的常見方法,例如敏捷方法 (Agile)),來完成機電載具系統特定部件的設計和驗證。接著,團隊會以迭代的方式分階段進行建置、整合與測試工作,以生產車輛/飛機/船隻等載具。
圖 2.機電系統常見的產品開發流程
從需求到設計與驗證的過程有多種表示方式,其中一種方式就是 V 字模型 (圖 3)。儘管 V 字模型及許多衍生版本與解釋還有許多疑點,但這個模型仍是一款實用的架構,可檢驗某個通用測試架構的優點,可滿足設計流程中的測試需求。
圖 3.表示開發流程與相關測試類型的 V 字模型方法
一般來說,V 型圖的左側代表透過漸進式的設計決策,將高層次的需求分解為低層次的規格。這些決策是使用日漸增加的模型架構設計方法來制定,這些設計方法包含各種電腦輔助工程 (CAE) 工具,具體內容則是依照開發中的系統類型而定。如需此主題的更多討論,請參閱有關數位轉型與數位分身 (Digital Twin) 的其他文獻。在 V 型圖的底部,系統已分解為最底層的基本元件,而設計可隨時轉換為實體執行代碼,且元件原型已準備好可供建置 (而且程式碼已部署至運行軟體的原型,這也是為何 V 型圖的底部有時會標示為「部署」的原因)。V 型圖右側展示的步驟是,將這些不同部件整合在一起、根據規格驗證其作業,並針對從基本元件到整台載具中每個整合步驟的需求進行效能驗證。
請注意:隨著系統、子系統與元件的詳情出爐,軟體、電子元件與機械元件的開發也會同步進行,如圖 2 所示。具備所需領域之專業知識的個別設計與測試團隊,通常會負責開發流程。
請注意:術語「驗證」與「檢驗」的使用,在某種程度上並未明確細分,有時會使用概括性的詞語「V&V」來說明。一般而言在驗證期間,您想知道的是「我建置的方式正確嗎?」,然後根據一系列的規格,驗證系統的運作能否在公差或量測範圍內如預期進行。但在檢驗期間,您會想知道「我建置的系統是正確的嗎?」 您要確保系統在完成之後,就能執行預期執行的工作,並根據一系列需求量測系統是否具備可接受的效能。
以下測試的簡短描述和定義,大致是按照您在產品設計流程中所遇到的測試順序所描寫,而此測試順序在實際應用中的迭代程度相當高。快速有效地按照 V 型圖來進行設計迭代的能力,是一種競爭優勢,也是同級最佳測試組織的關鍵能力。某個對 V 字模型的批評說法,是它的開發過程順序就跟瀑布式設計方法是一樣的。
MIL 測試需要使用軟體同時為控制器和設備建模。您可以在設計流程的早期進行此測試,以在軟體模擬環境中測試控制器的策略和系統行為。
若為 SIL 測試,您需要為待測模型建模,但該模型需連接至以所選之開發語言編寫與執行的實際控制程式碼,並在開發系統 (有時候是在虛擬機器中) 上進行該模型的編譯與執行。
PIL 測試與 SIL 測試類似,但是控制程式碼的編寫和編譯必須針對在已部署系統中使用的特定處理器架構和作業系統進行。例如,如果要在具備特定之設定的特定 FPGA 上執行程式碼,可以針對該特定情境編譯程式碼,以確保實際的處理架構可正常運作,且具有足夠的可用資源。這個測試步驟通常會獨立命名,因為開發部署之處理架構與硬體的過程可能非常棘手與耗時,尤其是若要最佳化電子控制單元 (ECU) 的設計,這通常會導致軟體功能與功能設限,因此需要取捨。
對於使用在即時控制器上執行的數學模型,和/或透過真實 I/O 連接到實際測試對象的 FPGA,我們會使用 RCP 來快速迭代可能的控制方案。
HIL 是使用模擬的實體元件與感測器,在實際嵌入式控制器上進行的軟體測試,因此 ECU 就能透過訊號調節、真實負載層級,執行其真實的電氣 I/O,並具有執行故障植入的能力
實體測試應用程式使用傳感器架構的量測 (例如溫度、壓力、壓力/應變、聲音、加速、位移等),來測試待測元件或系統的物理特性。應用程式範例包含噪音與振動 (NVH) 測試,其中涉及從麥克風與加速規進行聲音與振動的量測。另一個範例是耐久性測試/生命週期測試 (高度加速的生命測試,也就是 HALT,以及高度加速的壓力篩選,也就是 HASS),這項測試的重點是判斷 DUT 在各種不同預期作業條件下的表現。
MRO 又稱為維修站測試,用意是為載具系統提供所需的服務、維修與升級,好讓載具能連續正常運作數十年或數個世代。有時,系統測試設備會使用相同的設備或該設備的改良版。MRO 測試的一項挑戰在於面對測試機軟硬體停產、人員流動,與因為定期系統升級而導致需求不斷變更的狀況下,仍能在整個專案生命週期內有效維持測試能力。
由於這類測試的成本極高,因此用於現場測試的載具通常裝有大量儀器,好在測試期間盡可能提供大量運作相關資料。這類測試的主要考量是重量/尺寸、為測試設備供電的能力,以及資料儲存與檢索。儘管過程耗時且成本高昂,現場測試仍是產品開發過程的一大關鍵,因為模型不可能完美無缺,而系統的互動過程很複雜,也可能會出現在先前的測試流程中未涉及的非預期行為。現場測試可判斷載具是否能正式運作。
熟悉開發過程與相關的測試類型之後,您就能了解一致測試架構的潛在優勢。一致的測試平台可滿足整個設計週期內的測試需求,其中包括早期原型製作到軟體、電氣與機械驗證,再到系統層級的測試單元和系統整合實驗室,這使得測試開發的過程更快速、資源利用更有效率。而在整個設計 V 型圖和各專案之中,設備與人員都有的互通性和可替換性也就越高。在測試能力與迭代方面來說,工程師能更輕鬆快速地完成 V 字模型的各個階段,這點特別具有價值。
一致的測試架構可提供類似物件導向程式設計模型的優點。如果您經常需要使用類似方法開發相同類型的系統,就可以投資開發一套核心系統,確保此系統可以跨專案使用,而且可以根據每個專案獨特的規格來進行客制化。
而且這種平台架構的測試方法會更加強大,因為這種測試架構是以彈性且可擴充的平台為基礎,就系統功能與測試能力來說,即使面對不斷變化的需求與未來對系統的非預期需求,您也不至於感到手忙腳亂。換句話說,透過這種方法,您就不需要十分精確地設計出系統功能,進而靈活地因應未知的狀況,並預測未來的需求。這比專門建置具備固定功能的系統好很多,因為針對這類系統,您還必須明確設計出未來可能需要的靈活性與可擴展性。這些固定功能的系統會迫使您在時間與成本及功能之間進行權衡。
您必須在開發過程盡可能預先將更多測試分配於前期,以加快迭代速度並降低測試成本與提高測試安全性。這時您可以在實驗室中使用模型架構的控制與模擬,充分模擬各種刺激和真實世界條件。這樣一來,以往只能透過現場測試進行的分析,就能移至系統整合實驗室或系統層級的測試設備上。某些技術可以改善這類測試,例如透過模型控制的致動,在現場記錄真實世界刺激,然後回到系統上「重播」。
如果您的測試需要用到其他團隊的組件,您也可以透過模擬其他團隊的元件來進行測試,不需要配合其他團隊的時程。但是,若要確保足夠的測試結果精確度,您必須花時間驗證模擬元件時所用之模型與方法的準確度與效力。
支援模型架構的控制與模擬還有一個優點,就是能更完善地測試難以複製、危險與極端的測試案例。這點擴大了測試的範圍,能讓團隊對設計更有信心。
有時若要用於特定功能,可以選擇的感測器、致動器、儀器或軟體的類型或品牌通常都不多。使系統中所有不同部件順利搭配運作,通常就占據測試系統設計成本的一大半,在舊版測試機改造或重新設計的作業中處理老化系統元件時,情況尤其明顯。能夠運用具有各種 I/O 與第三方內建裝置功能的平台,可透過最大化重複使用機會與最小化整合作業的方式來改善效率。此外,採用可配置/可擴充和分配式/同步的 I/O 架構,可滿足在設計流程中對測試案例的不同 I/O 需求,同時促進跨專案的重複使用。
量測速率不斷提高,使得資料量大幅增長,而且資料的格式也變得更為多樣。而更多客戶必須在整個設計週期中存取各種類型的測試資料,來滿足更多報告需求。確保資料可用性,以及資料是否確實被使用,一直都是個重大挑戰。您必須能夠有效地尋找與載入資料、以互動方式呈現和分析該資料,並透過將報告自動化來節省時間。一致的測試架構必須提供企業級和 IT 較容易支援的資料管理和系統管理架構,將資料化為可用資產 (而不是負擔),藉此改善決策制定流程、減少重複測試次數、報告生成時間與工作量,並提升資產利用率和正常運作時間。
如今足跡遍布全球的開發和測試團隊越來越多,而他們在有效管理跨據點部署的測試機,以及將過程中產生的資料產生關聯時遇到了許多困難。有效管理分散式測試系統和資料,便可提升營運深入分析能力、縮短停機時間與提高產生資料的可信度,並大幅節省成本。
投資建構以軟體定義測試平台為基礎的一致測試架構,對於設計和測試進階機電載具系統的團隊而言,無疑是同級最佳的做法。與完全內部客制開發或完全一站式外包相比,這個做法可以加快測試開發速度、提升測試範圍與營運效率、使團隊更靈活且能力越強大,並且降低資本支出,提升長期測試系統正常運作時間和可維護性。