發動機ECU HIL測試介紹

什么是HIL仿真？

在閉環控制系統中，被控制系統的當前狀態通過傳感器測量饋回控制器。對于汽車來說，電子控制單元（ECU）使用這些測量值來確定適當的執行器值，以獲得所需的工作條件。 例如，發動機ECU接收有關節氣門位置、發動機轉速和排氣氧含量的信息，以確定燃油噴射器位置、點火正時和進氣口對應的執行器命令，以保持最大的發動機性能和 減少有害尾氣排放。最終還是需要對整個系統進行物理測試; 但是通過HIL仿真，工程師 可以在沒有車輛甚至發動機的情況下徹底測試ECU，獲取重要的信息。

圖1. 硬件在環測試系統包含了模擬ECU工作環境所需的幾個關鍵功能

通過HIL仿真提高效率

HIL仿真可重現與ECU交互的物理系統，并執行激勵信號生成和測試結果數據記錄等測試執行功能。發動機ECU的激勵生成可能需要創建一系列期望的發動機速度（以模擬踩下油門踏板）和車輛載荷（以模擬各種道路狀況）。同時需要觀察整個系統以確保所有組件正確運行，并記錄測試結果，以便與理想的系統響應進行比較。

雖然HIL仿真并不能完全取代物理測試，但它確實可通過以下優勢來降低測試成本以及提高產品質量：

- 在開發過程中更早地進行測試—更及時地發現設計錯誤，減少修正成本以及對上市時間的影響

- 降低測試成本—無需使用物理系統，減少測試連接件的購置、維修和維護費用

- 增加測試覆蓋率—在無法進行物理測試的極端條件下測試ECU，避免安全和設備損壞問題

- 提高測試靈活性—擴展測試功能，無需考慮外部因素（例如：即使在炎熱的夏天，也可以模擬冬季道路狀況，以便測試車輛）

- 提高測試可重復性—隔離ECU的缺陷，即使這些缺陷僅在某些情況下才發生

圖2. 典型的HIL測試系統包含許多常見的硬件組件

HIL測試軟件基礎

組織采用HIL仿真的基本動機是提高其開發和測試過程的工作效率。用于HIL仿真的硬件和軟件工具需要能夠幫助工程師專注于測試ECU，而不是忙于配置、支持和維護測試系統。 HIL測試軟件應該兼顧易用性和靈活性，以適應不斷變化的要求。 HIL系統的價值取決于所能節省的時間和提高的產品質量。

在具有極其嚴格的上市時間要求的行業中，快速開始進行首次測量非常重要。您必須能夠快速輕松地將仿真模型連接到物理I/O設備，而且在ECU參數發生變化時更新配置。除了系統配置之外，系統還應可創建和執行測試配置文件來驅動ECU。駕駛虛擬汽車的前提是能夠提供代表ECU可能遇到的環境變量的信號模式。例如，如果要執行EPA行駛工況測試，就需要生成運行測試所需的速度設定值和路況條件。有多種選項可用于生成測試配置文件，包括傳統的編程和腳本語言、圖形化顯示和復雜的數據回放。最佳方法通常因ECU要求而異，而且HIL測試系統必須能夠滿足這些不同的要求。

仿真基礎

對象模型和模型來源

在HIL測試，通常使用仿真模型來“欺騙”被測嵌入式設備（DUT），讓DUT覺得自己正在控制一個真正的機械系統。機械系統的物理學機制可使用數學工具來重現，這些工具生成的信號通過電線傳輸并連接到DUT。過去，物理仿真是一個極具挑戰性的過程，需要深入了解與機械過程相關的數學原理，如流體動力學、應力特性和材料特性。

圖3. 使用各種建模環境來確保高效且有效的HIL測試

今天，有許多商用現成（COTS）工具可用為物理和電氣系統建模，而且不需要了解系統構建的基礎數學原理。其中有許多物理仿真工具專門為汽車動力總成HIL測試領域而設計。常見的汽車建模工具及其主要用途包括：

Gamma Technology 公司開發的 GT-SUITE 軟件—GT-SUITE 是一款仿真軟件工具，為汽車工程應用提供了多種功能和庫，包括快速概念設計、詳細的系統或子系統/組件分析、設計優化以及根本原因調查等。 GT-SUITE架構提供了獨一無二的系統集成模型構建功能，可以跨子系統、物理域和模型等級進行集成。

AVL 公司開發的 BOOST 和 CRUISE 軟件—BOOST 是一款完全集成的虛擬發動機仿真工具，提供了先進的模型來準確預測發動機性能、噪聲和廢氣處理裝置的效率。在發動機開發過程中借助該軟件，您可以提供給定汽車概念所需的扭矩和功率以及優化排放、油耗和乘客舒適度（噪聲和瞬態工況）。

CRUISE 是一款系統級仿真工具，適用于從概念規劃到產品發布等一整個開發過程中的日常車輛系統和傳動系統分析任務。其應用范圍涵蓋了傳統車輛動力系統、高度先進的混合動力系統和純電動汽車。 CRUISE提供了參數優化和組件匹配功能，可幫助您實現實用且可行的解決方案。

ITI 公司開發的 SimulationX—Simulation X標準軟件用于評估所有技術系統組件之間的相互作用，提供了豐富的模型庫，適用于一維機械、三維多體系統、動力傳動、液壓、氣動、熱力學、電氣學、電氣驅動、磁學和控制學等領域。SimulationX是用于物理效應建模、仿真和分析的通用CAT工具。。

Mechanical Simulation 公司開發的 CarSim 軟件—CarSim 用于模擬乘用車、賽車、輕卡和多功能車的動態行為。它可生成動態仿真測試，并輸出超過800個計算變量來進行繪圖和分析或導出到Excel等其他軟件。

通過確定性確保準確的仿真

HIL測試的有效性取決于仿真能否準確反映ECU周邊環境。仿真模型必須通過數學計算對ECU命令進行準確的響應，并且這些響應所發生的時間范圍必須與所仿真的機械系統一致。因此，大多數HIL應用都需要使用實時系統執行確定性操作。您還可以使用實時系統來執行實時測試序列，以了解ECU功能和穩健性相關的信息。如果實時系統可以確定地代表機械系統，并具有足夠高的保真度，則可以對ECU參數進行校準，以優化和調整整個閉環系統的性能。實時系統的性能很大程度取決于可以從測功機轉移到實驗室的測試量，因為這直接影響測試成本和上市時間。

不同類型動力系統的關鍵考慮因素

在動力總成控制模塊（PCM）上執行HIL測試對系統提出了新的要求。由于其高度專業化特性，PCM除了依賴通用微控制器外，還依賴于專用協處理器。例如，內燃發動機PCM必須處理特定的高速發動機信號，例如轉動位置、爆震、氣缸壓力和精確執行器控制［2］。 PCM測試需處理這些獨特的I/O和協處理器。因此，PCM測試系統，如待測組件，使用相應復雜的測試系統來測專用協處理器來提供足夠的I/O復雜性。此外，盡管公司會不斷發布新的PCM硬件和軟件，但測試系統通常需要具有多年使用壽命。高度靈活性便成為測試系統的一個最基本要求

如今，FPGA是滿足這些需求的理想器件，其高性能和靈活性非常適合滿足當今先進PCM快速變化的測試需求［3］。 FPGA具有顯著優勢，例如并行處理、設計可擴展性、超快的引腳到引腳的響應時間、設計可移植性和終身可升級性。所有這些優勢都有助于構建強大的自適應測試系統。但是，FPGA編程通常只有非常專業的工程師才懂，但這類工程師非常稀缺。高級別抽象的FPGA編程軟件的出現以及易于訪問的現成FPGA庫極大地提高了部署基于FPGA的測試系統的可行性。

內燃動力系統

從本質上說，內燃機ECU的作用是讓發動機轉動。為此，ECU通過精心設計的編碼器輪提供的傳感器反饋來監測發動機的位置，如圖4所示的曲軸輪，并激活噴油器和火花塞來產生電能。

圖4. 現在的曲軸輪采用復雜的pattern，如圖中所示的pattern非常獨特且不斷變化。

內燃機ECU HIL測試儀的用途除了測量踏板等用戶輸入之外，還用于測量和生成這些燃燒信號。 表1顯示了典型的發動機ECU信號。

表1. 在開發測試儀時應考慮這些常見的發動機ECU信號。

圖5顯示了一個典型發動機ECU測試儀的框圖（不包含負載和開關）。 測試儀包含了在CPU上運行的實時OS，用于執行低中速（1 kHz-10 kHz）建模。 CPU與模擬、數字和總線通信等獨立I/O結合，可讓低中速信號隨著模型的執行進行同步更新。不管對于哪類ECU測試系統，這些都是核心組件，但為了滿足內燃機ECU測試的特定要求，還需要增加一個用于實例化角度處理單元（angle processing unit，APU）的FPGA協處理器。

圖5. 典型的發動機ECU測試儀框圖包含了在FPGA上進行實例化的APU協處理器。

APU用于執行高速、高保真的發動機轉動仿真。轉動仿真是一個接受速度輸入值的過程，隨著時間的推移，0到360度連續發布轉動位置的仿真值。由于ECU編程為相對于其轉動位置控制發動機，因此驗證ECU時，需要在測試儀中模擬轉動位置并進行與轉動位置相關的測量。

圖6. 模擬可變磁阻傳感器輸出的旋轉信號。

將轉動仿真任務從CPU上剝離出來有許多好處。首先，使用專用硬件，APU可以高速運行，不受高級實時操作系統任務（如線程調度程序）的干擾。為了在10，000 rpm下實現0.1度 的分辨率下，轉動仿真必須至少以600，000 Hz的頻率運行，這在通用CPU上是不可能實現的。

其次，APU和CPU可以異步運行。這可允許CPU以固定的時間步進間隔運行物理對象模型，有助于提高許多對象建模和實時OS工具鏈的工作效率，同時獲得來自APU協處理器的基于角度的信息。

最后，通過將APU放置在靠近I/O引腳的位置，可以在轉動仿真和相關數據之間建立低延遲連接，以關聯到仿真的位置值。事件發生的時間及其與位置相關的時間之間的延遲會直接導致測量誤差。為了避免這一誤差，可以將APU放在與I/O相同的FPGA芯片。

前面討論的ECU信號、FPGA上的APU協處理器以及發動機物理模型相結合，就構成了一個閉環發動機ECU HIL測試儀。圖7顯示了該系統基于實際執行器負載的數據流。

圖7. 發動機ECU HIL閉環數據流

對于內燃動力系統，設計ECU HIL系統時，另一個重要考慮因素是燃油噴射器驅動的測量。實現這一目標的最佳方法之一是將真實執行器納入測試系統，就像將它們置于真實車輛中一樣。 ECU經過電流測量信號調理卡連接到噴油器，并為測試系統的FPGA提供電流測量值。這可允許FPGA測量流經噴油器的電流，以確定何時開啟和關閉電磁閥（圖8）。

圖8. 柴油燃料噴射器的電流和電壓曲線表明必須測量電流才能精確地捕獲正確的時機

對于汽油噴射器，一個更簡單的替代方案是直接測量ECU的數字輸出，以檢測噴射器何時 被命令打開和關閉。但是，測量通過實際噴射器的電流可得到更準確的結果，因為 打開電磁閥需要一定量的激活電流。此外，如果實際負載沒有連接到噴射器輸出，大多數ECU會出現診斷故障。

混合動力和純電動動力系統

在許多全電動或混合動力系統中，ECU必須管理多個獨立電源產生的電力。例如，混合動力傳動系統包含一個或多個電動機以及一個內燃發動機。無論使用的是何種混合動力傳動系統類型，都意味著ECU必須以安全且可重復的方式控制兩個耦合對象，這兩個對象的動態速度可能截然不同，需要大量測試才能確保控制系統的穩定性。

例如，在路面結冰的駕駛條件下，車輪會突然失去牽引力。在加速時，這可能會導致電機速度急劇增加，需要安全地應對。但是，從物理角度考慮，這種安全行為不可能在測功機上再現，即使是在測試跑道上，也是非常耗時和高難度的。由于針對這種特定安全條件開發的復雜控制算法必須進行驗證，測試需要考慮到極端的駕駛條件，以滿足量產車輛的質量要求。

圖9. 混合動力系統的HIL測試需要考慮更多的因素

混合動力和全電動傳動系統都增加了ECU測試的復雜性。不管是哪種情況，驅動電動機都需要ECU產生高速PWM信號來驅動電力電子硬件。如果要HIL測試系統對來自被測ECU的高速數字信號做出正確的響應，仿真必須以數量級達1μs的超快速循環速率運行。另一個需要考慮的方面是，電動機表現出復雜的非線性行為，例如磁性飽和和齒槽轉矩，這些行為都很難直接建模。線性模型可用于測試ECU的基本功能，但復雜的行為也需要建模，才能進行更嚴格的測試、調整和優化。

傳統的仿真系統無法達到1μs的循環速率，這限制了控制系統設計人員的測試能力，迫使他們嚴重依于賴昂貴的測功機或現場測試。在失去牽引力的情況下，如果要通過現場測試來確保在所有可能運行條件下的安全性，所需的費用非常高昂甚至不可能實現。然而，提高仿真速度和保真度有助于在仿真中進行更多可重復的測試，從而減少物理測試的時間和成本。

要達到1μs的模擬周期，需要測試徹底改變電動機和電力電子HIL測試系統的設計。一個關鍵方法是摒棄傳統的基于處理器的HIL系統，采用基于FPGA的仿真器。

由于通信總線將處理器和I/O分離開，傳統的基于處理器的HIL系統可提供的最大速度僅為50 kHz左右。在仿真的單個時間步長內，對輸入進行采樣后，采樣數據傳輸到處理器進行處理，處理結果傳輸回I/O節點，并更新輸出結果。對于PCI或PXI總線，通信的延遲通常可占整個仿真周期的四分之三。將計算任務轉移到FPGA上有助于提高計算速度。然而，提高速度的最快方法是在單個設備上并列配置處理節點和I/O節點，這樣可最小化通信延遲。

對高級電機驅動器進行實時仿真時，面臨的另一個挑戰是實現仿真保真度和速度的平衡。雖然進行功能級HIL測試時，簡單的常量參數或線性模型就足夠了，但通常需要提高模擬保真度來提高測試的可靠性以及優化先進電機驅動器。在不增加計算復雜度的情況下提高模擬保真度的一個有效方法是使用查找表替換模型參數，并在每次仿真迭代時更新這些參數。

使用有限元分析結果或通過實驗得出的表格，您可以模擬復雜的非線性行為，例如齒槽轉矩或磁飽和，并設計可正確響應復雜現象的控制器。無論是哪種情況，查找表都可以捕獲復雜的行為，而無需在仿真中直接對其進行建模。

最大化測試覆蓋率

創建測試用例

為ECU制定測試計劃和測試用例需要設計和測試團隊之間密切合作。對ECU要求進行文檔記述是此過程的一個關鍵步驟。通常，這些要求可以分為三個高級類別：安全性、功能性和性能。

安全性

在產品設計中，我們應用稱為故障模式和影響分析（FMEA）的過程來定性地識別可能的故障及其對系統的整體影響。FMEA是20世紀40年代末測試軍事系統的可靠性工程師開發的，并沿用至今。當識別出可能的故障時，就會詳細描述故障并分配相應的概率值、嚴重程度值以及計算出的總體風險值（概率和嚴重程度的乘積）。表2顯示了一個FMEA表的示例。

表2. 設計工程師創建故障模式和影響分析表作為有效的安全測試起點。 （表格由Quanser提供）

完成FMEA后，設計工程師會添加一些功能來減緩識別到的風險最大的故障。 例如，他們可以添加傳感器來檢測機械組件的故障，然后軟件會自動將車輛切換到跛行回家模式，以防止進一步損害。 測試這些補救措施是ECU驗證和確認的關鍵部分。如果要為每個故障設計相應的測試用例，需要設計團隊提供故障樹分析（FTA）。 圖10顯示一個FTA的例子。

圖10. 在創建對安全至關重要的測試用例時，故障樹分析是一個重要的參考文檔。

使用FTA作為流程圖，您可以為每個具有足夠高風險的FMEA項目設計測試用例（“足夠高”的閾值由產品管理人員設定）。考慮到一些故障的危險系數非常高，如果能在HIL仿真中對這些項目進行測試，那將是一項非常有價值的投資。

在驗證安全要求時，必須確保測試準確無誤，尤其是對于汽車和航空航天等必須符合功能安全標準的受管制行業。錯誤的驗證可能導致項目在投入生產和處于安全關鍵狀態時，產生極為不利的后果。另外，由于電子復雜性的不斷增加，相同的時間內需要進行的測試增多，這就引入了自動化驗證需求。但是，我們如何知道所使用的測試自動化工具是否如預期的那樣正常工作？自行開發測試自動化工具的成本可能非常高，特別是在設計時需要確保工具的功能安全性。除此之外，還需要對整個驗證過程進行詳細且全面的文檔記述。正確地創建該文檔可能非常耗時，因此所使用的任何工具必須能夠生成適當的工件，這使得許多人認為手動工具認證是唯一的方法。

使用在某些方面符合特定功能安全項目要求的COTS驗證工具可以滿足這一需求，且可讓您對測試工具充滿信心。 NI聯盟合作伙伴CertTech針對NI測試自動化軟件工具TestStand開發了一款資格鑒定包。 TestStand是一款隨時可運行的測試管理軟件，旨在幫助您更快地開發、執行和部署自動化測試系統。由于CertTech工程師對受監管行業和功能安全標準非常熟悉，他們很理解用戶迫切需要使用符合DO-178C和ISO 26262等標準的合格工具。TestStand鑒定包全面覆蓋了最常用功能的要求和測試種類，提供了驗證指定要求的全套測試以及一個易于擴展的框架，因此用戶可以根據需要擴展測試覆蓋范圍。此外，CertTech還使用工具生成了所需的文檔，作為合規性的必要工件。這個文檔是必不可少的，因為我們的總體目標是確保驗證過程的完全透明性，以便測試可以快速地重建。 借助鑒定包，CertTech將生成該文檔所需的時間縮短了95%。

一些較新的功能安全標準，如ISO 26262和DO-178C要求項目使用“合格工具”來完成一些不需要人工審核的驗證和確認任務，這使得使用像TestStand這樣的合格工具變得更為重要。這些標準需要您對未進行適當測試的工具的總體影響進行評估，然后判定一個TCL值，也就是ISO 26262等標準所稱的工具置信度（ Tool Confidence Level，TCL）。兩個主要因素決定了TCL：工具影響（TI）和工具錯誤檢測（TD）。 TI1和TI2是TI的兩個級別。當故障軟件工具不可能違反安全要求時，則選擇TI1。其他所有情況均選擇TI2。 TD分為TD1、TD2和TD3。 TD1表示工具檢測錯誤的置信度很高，TD2表示置信度中等，TD3表示置信度很低。測試工具的不同TCL等級意味著用戶所承擔的額外負擔也有所不同。

最大化測試覆蓋率

創建測試用例

為ECU制定測試計劃和測試用例需要設計和測試團隊之間密切合作。對ECU要求進行文檔記述是此過程的一個關鍵步驟。通常，這些要求可以分為三個高級類別：安全性、功能性和性能。

安全性

在產品設計中，我們應用稱為故障模式和影響分析（FMEA）的過程來定性地識別可能的故障及其對系統的整體影響。FMEA是20世紀40年代末測試軍事系統的可靠性工程師開發的，并沿用至今。當識別出可能的故障時，就會詳細描述故障并分配相應的概率值、嚴重程度值以及計算出的總體風險值（概率和嚴重程度的乘積）。表2顯示了一個FMEA表的示例。

表2. 設計工程師創建故障模式和影響分析表作為有效的安全測試起點。 （表格由Quanser提供）

完成FMEA后，設計工程師會添加一些功能來減緩識別到的風險最大的故障。 例如，他們可以添加傳感器來檢測機械組件的故障，然后軟件會自動將車輛切換到跛行回家模式，以防止進一步損害。 測試這些補救措施是ECU驗證和確認的關鍵部分。如果要為每個故障設計相應的測試用例，需要設計團隊提供故障樹分析（FTA）。 圖10顯示一個FTA的例子。

圖10. 在創建對安全至關重要的測試用例時，故障樹分析是一個重要的參考文檔。

使用FTA作為流程圖，您可以為每個具有足夠高風險的FMEA項目設計測試用例（“足夠高”的閾值由產品管理人員設定）。考慮到一些故障的危險系數非常高，如果能在HIL仿真中對這些項目進行測試，那將是一項非常有價值的投資。

在驗證安全要求時，必須確保測試準確無誤，尤其是對于汽車和航空航天等必須符合功能安全標準的受管制行業。錯誤的驗證可能導致項目在投入生產和處于安全關鍵狀態時，產生極為不利的后果。另外，由于電子復雜性的不斷增加，相同的時間內需要進行的測試增多，這就引入了自動化驗證需求。但是，我們如何知道所使用的測試自動化工具是否如預期的那樣正常工作？自行開發測試自動化工具的成本可能非常高，特別是在設計時需要確保工具的功能安全性。除此之外，還需要對整個驗證過程進行詳細且全面的文檔記述。正確地創建該文檔可能非常耗時，因此所使用的任何工具必須能夠生成適當的工件，這使得許多人認為手動工具認證是唯一的方法。

使用在某些方面符合特定功能安全項目要求的COTS驗證工具可以滿足這一需求，且可讓您對測試工具充滿信心。 NI聯盟合作伙伴CertTech針對NI測試自動化軟件工具TestStand開發了一款資格鑒定包。 TestStand是一款隨時可運行的測試管理軟件，旨在幫助您更快地開發、執行和部署自動化測試系統。由于CertTech工程師對受監管行業和功能安全標準非常熟悉，他們很理解用戶迫切需要使用符合DO-178C和ISO 26262等標準的合格工具。TestStand鑒定包全面覆蓋了最常用功能的要求和測試種類，提供了驗證指定要求的全套測試以及一個易于擴展的框架，因此用戶可以根據需要擴展測試覆蓋范圍。此外，CertTech還使用工具生成了所需的文檔，作為合規性的必要工件。這個文檔是必不可少的，因為我們的總體目標是確保驗證過程的完全透明性，以便測試可以快速地重建。 借助鑒定包，CertTech將生成該文檔所需的時間縮短了95%。

一些較新的功能安全標準，如ISO 26262和DO-178C要求項目使用“合格工具”來完成一些不需要人工審核的驗證和確認任務，這使得使用像TestStand這樣的合格工具變得更為重要。這些標準需要您對未進行適當測試的工具的總體影響進行評估，然后判定一個TCL值，也就是ISO 26262等標準所稱的工具置信度（ Tool Confidence Level，TCL）。兩個主要因素決定了TCL：工具影響（TI）和工具錯誤檢測（TD）。 TI1和TI2是TI的兩個級別。當故障軟件工具不可能違反安全要求時，則選擇TI1。其他所有情況均選擇TI2。 TD分為TD1、TD2和TD3。 TD1表示工具檢測錯誤的置信度很高，TD2表示置信度中等，TD3表示置信度很低。測試工具的不同TCL等級意味著用戶所承擔的額外負擔也有所不同。

表3. ISO 26262標準中的工具置信度意味著對工具進行鑒定時的工作量不同

TCL2工具對于用戶的價值最大，因為任何TCL1工具不是對安全沒有任何實質影響，就是已經具有高置信度，因而不需要額外的資格鑒定和文檔記述。而TCL3工具置信度較低，不管如何都需要一定程度的人工資格鑒定。

功能性

從高層次來說，ECU功能的測試非常簡單。我們可以簡單地逐個功能進行測試；但是嵌入式軟件的詳細信息可以幫助發現需要嚴格測試的可能故障點。因此，功能測試的設計同樣需要與ECU設計團隊密切合作。

此外，特定ECU的特性可以與狀態圖相結合來指導測試用例的設計。

性能

與安全和功能測試用例不同，設計基于性能的測試卻不需要與ECU設計團隊協作。這些測試的開發通常從用戶的角度來考慮。設計團隊能接受的對于用戶來說可能是無法接受的，因而這些反饋非常重要。幸好，有些用戶關心的性能問題，例如每加侖英里數（MPG），可以根據聯邦政府定義的測試程序直接變為測試用例。圖11顯示了聯邦政府針對市區駕駛規定的車速隨時間的變化圖（FTP-75）。

圖11. 聯邦政府針對車輛MPG性能規定標準化測試，例如FTP-75駕駛工況。

另一種基于性能的測試是內部性能，例如總線消息時序、ECU CPU利用率或ECU事件

響應時間。這些類型的測試可能需要測試儀具有額外的功能，包括ECU校準、調試數據鏈路（以讀取微處理器參數）和/或過程數據日志時間戳發布（以驗證可接受的總線消息行為）。有關使用NI DIAdem軟件進行此分析的示例，請查看 時間相關的NI VeriStand數據日志。

需求創建、可追溯性和實現

需求可追溯性的重要性

為了確保嵌入式軟件和一般軟件的質量，經證明在軟件開發過程的所有階段跟蹤需求工件是非常重要的。典型的軟件過程包括研究、定義、開發、測試和部署。通過跟蹤來建立各種關系以及分析軟件更改的影響是軟件開發過程的常見操作，尤其是對于故障成本非常高或故障可能導致生命危險的領域。

經證明，軟件項目如果缺乏足夠的需求可追溯性，就會出現較多嚴重影響系統安全性和可靠性的缺陷。即使是微小的變化，也可能產生很大的連鎖效應，導致最終產品無法完全滿足項目啟動時確定的所有要求。

由于監管機構出于對安全問題的考慮，以及企業不期望發生代價巨大的產品召回事件，因此兩者聯手，制定了大量關于需求管理的標準、最佳工程實踐和軟件工具。在未來的項目中，應對需求可追溯性進行硬性規定

測試自動化

在現代測試系統中，從最上層的功能到測量儀器均可自動化。這是一個復雜的過程，涉及來自不同供應商的多個工具和不同操作系統，其中一些任務可能需要在實時HIL系統上執行。因此需要盡早與工具提供商確認，以確保兼容性。測試自動化是經濟高效地確保需求可追溯性的關鍵因素。

除了執行測試腳本來驅動虛擬汽車之外，具有前瞻性思維的組織還會使用測試自動化框架來進一步實現測試執行和自動化。借助這些框架，就可以批量運行測試，對測試數據執行后期處理和分析，并生成報告，且運行時無需任何人工交互。只需配置測試系統，測試執行就可以獨立完成。測試自動化可自動將產品需求和測試用例鏈接到測試結果，幫助工程師更有效地進行溝通。這樣就無需人工對測試數據與需求進行比較，從而提高了工作效率。

ECU測試團隊的一個高級目標是開發一個提供足夠測試覆蓋率的測試用例庫。這個庫是確保ECU質量的關鍵因素。隨著測試用例庫不斷擴展，測試可以設置為連夜自動運行或者在軟件發生變化時自動觸發運行回歸測試。及時的回歸測試報告可以避免最新出現的嵌入式軟件錯誤持續數周并逐漸變得難以修復。

為您的ECU選擇合適的HIL系統

開放性、可擴展性、靈活性

選擇HIL系統時，首先應考慮是要購買組件并自行集成系統還是購買完整的交鑰匙系統。大多數交鑰匙系統供應商通常不銷售組件，而銷售組件的供應商通常通過合作伙伴提供交鑰匙系統。

如果選擇購買組件，則需要擁有掌握專業知識的工程人員來集成組件，這樣可以更靈活地控制系統的可擴展性和定制性。而選擇購買交鑰匙系統可以減輕工程負擔，但必須確保系統能夠滿足您當前和未來的需求。保證這一點的一個方法是購買“開放”且“可擴展”的平臺。由多個供應商支持的開放式平臺提供了最大的可能價值并可保護您的投資。

HIL測試系統靈活性的重要性

將HIL仿真集成到測試系統的方式有很多種。隨著降低測試成本的需求日益迫切，靈活的解決方案對于在開發過程中融入HIL仿真至關重要。高效的HIL仿真解決方案應能夠快速適應開發過程中遇到的各種變化，而且不需要大幅修改HIL仿真儀就能夠對測試過程或配置進行小改動。以目前的創新速度，單靠一個供應商是無法滿足所有最新技術的上市時間、質量和成本預期。基于COTS工具的開放式HIL仿真解決方案可確保您始終可以集成ECU測試所需的技術。

圖12. 靈活的HIL測試系統可以滿足未來需求和項目擴展的要求。

盡管HIL系統已廣泛應用到嵌入式測試領域，但它們仍然只是測試環節的一部分。在選擇HIL測試策略時，請務必考慮除了嵌入式軟件驗證之外應如何將HIL系統集成到測試工作流程中。相比僅關注測試周期的某個特定領域的公司，對測試具有整體觀的測試工具公司能夠提供更有價值的見解。

NI HIL平臺是一個COTS解決方案，可進行擴展和自定義來滿足不斷變化的需求。由于其模塊化架構和開放式軟件，NI工具既可以在小型臺式系統上使用，也可以進行擴展，用于具有緊密同步的分布式高通道數系統，例如鐵鳥飛機模擬器。 NI設計的產品可以滿足從工業控制到消費電子等各個行業的需求。這些要求苛刻的應用所需的性能、可靠性和靈活性同樣也適用于工程師進行HIL仿真，這使得NI成為嵌入式軟件測試的理想合作伙伴。

責任編輯：gt