|
嵌入式系統軟件是一個競爭優勢。軟件可以使得已經舒適的乘坐更具吸引力，比競爭性交通工具更好。它還可減少駕駛室噪音，或降低燃油消耗。可輕松地配置嵌入式軟件，以符合用戶的喜好 – 只需按一下開關便可將舒適的公路汽車變為更具運動特色的交通工具。 當然也可在硬件中實現那些可以通過軟件獲得的功能，但是這樣做會相應地增加制造成本和產品價格。嵌入式軟件還可實現重復利用利用，并且可更加頻繁地更新，以滿足不斷增長的需求。 圖1，在環測試示意圖 所有這些以及其他更多原因造成了嵌入式軟件應用的復雜性。很難測試和驗證復雜嵌入式軟件的功能。驗證和確認費用、解決缺陷的成本以及沒有及時發現的缺陷問題會抹殺掉軟件功能具有的所有優勢。 嵌入式軟件開發行業意識到這一點，并基于圖形化模型進行軟件開發，以應對不斷增長的復雜性。圖形化的產品功能還具有仿真能力，可提高驗證和確認方法。本文簡要概述通過基于模型的設計的關鍵軟件測試方法。 1 通過模型開發和測試嵌入式軟件 建模是設計和開發中的一個重要步驟，它發生在收集高層需求之后以及進行任何實現之前。模型還允許在開發的同時，進行持續地進行測試和驗證。 圖2，建模是設計和開發中的一個重要步驟 在早期的設計階段，開發者可開發純粹的行為模型，以闡明并定義軟件的詳細要求。 雖然此類模型已經具備了基本解決方案的輪廓，但是它們依然獨立于目標平臺。這些目標獨立的行為模型將用于設計驗證和早期的需求確認。 用于捕獲關鍵需求、在仿真中展示正確行為以及展示對高層需求可追溯性的模型通常被稱為“可執行規范”。 對可執行規范的進一步開發和具體實現可產生代表最終實現的模型的定義。這就是用于產品代碼生成的模型。通常，這些模型會對代碼生成做優化；它將從數據類型、目標架構以及要求的代碼風格。所有這些變更需要一個驗證過程，確保產品代碼生成模型中引入的變更不會改變軟件的行為。確認生產代碼生成模型以及生成代碼的正確行為的測試為代碼驗證。 把驗證分布在設計驗證和代碼驗證階段允許我們更早地開始驗證工作，更多的關注在測試上和更短的時間去修復在測試中檢測到的錯誤。在本文的其余部分，我將介紹兩個設計驗證方法： ·模型在環測試 ·軟件在環測試 以及用于代碼驗證的兩個方法： ·處理器在環測試 ·硬件在環測試 2 設計驗證 設計驗證的主要目的是確認所有關鍵要求和設計概念是否已正確體現在設計模型中。 ·模型在環測試 與“靜態”的書面設計不同，可在仿真過程中評估可執行規范。通常，通過改變一組模型參數或輸入信號，或通過查看輸出結果或模型的響應，來完成這一操作。依據模型執行的仿真順序也稱為模型在環測試。 模型在環測試的測試數據可來自測試矢量數據庫，或來自實際系統的模型，在后一種情況下，我們討論閉環控制系統。 可執行規范通常不僅僅包含功能設計模型和軟件邏輯，還包括設備和環境模型、高層需求的鏈接以及其他文件。它通常還包括用于自動化仿真結果評估的驗證數據。 模型在環測試的結果可用于驗證軟件行為是否正確，并確認開發流程的初始需求。通過仿真收集的信息會成為代碼驗證的基準。 ·軟件在環 (SIL) 在許多情況下，在目標環境中部署軟件之前，確保所設計的系統的軟件組件能夠按預期運行，這一點非常重要。 圖3，軟件在環（軟件算法測試） 軟件算法的測試（在主機上的聯合仿真中評估生成的函數或手寫的代碼）稱為“軟件在環”。與模型在環測試類似，輸入測試矢量可來自于測試數據庫或來自設備模型，并且可與 MIL 測試共享。 當軟件組件包含需要在目標平臺上執行的生成代碼（例如，更新控制器邏輯以滿足新要求）和手寫代碼（例如，現有驅動程序和數據適配器）的組合時，此類驗證尤其有用。 通常利用軟件在環測試來驗證圖形化模型中現有算法的重新實現。可能很難或需要花費較多成本來維護一些舊的但是正確的代碼，這對于在建模環境中重新實現及驗證而言意義重大。在這種情 況下，仿真成為比較新模型實現和舊代碼中已有算法的輸出的環境。 3 代碼驗證 驗證設計質量及其對現有的需求的兼容性之后，我們可專注于代碼驗證。代碼驗證的關鍵目標是確保軟件行為匹配在仿真中捕獲的模型行為。 ·處理器在環 (PIL) 從概念上來說，處理器在環 (PIL) 測試類似于軟件在環測試。關鍵的差別在于 PIL 代碼在嵌入式處理器硬件或指令集仿真器上執行，以便該驗證可考慮在目標處理器上執行的算法的特定具體條件。在模型與部署的目標代碼之間傳遞的數據通過 CAN 或串行設備之間通過真正的輸入輸出來完成。 圖4，處理器在環 用于 MIL 和 PIL 的模型現在可用作處理器板的測試框架。通過處理器在環，我們仍然可在主機上運行模型，并使用它對軟件組件輸入生成實際數據。除此之外，我們還可使用調試器分析代碼（已編譯的代碼）逐步說明裝配級別說明，就像在完全嵌入式系統中那樣進行鏈接和部署。 通過 PIL，我們還可查看代碼函數的執行順序，并確認操作系統函數的調用或在目標上執行時所需的其他庫，以及在執行驗證方案過程中監控內存容量。 在一些項目中，PIL 可在符合相同規范當來自不同廠商的處理器板上比較算法行為。 正如 SIL 一樣，此驗證方法并不用于非實時分析。 ·硬件在環 (HIL) 目前提到的所有測試方法不能用于實時地驗證設計。仿真以及與目標板通信的負荷不允許算法的實時測試。 圖5，硬件在環 為了重新利用為前面描述的測試方法創建的數據，并繼續使用該結果作為實時測試的指導和基準，我們為模型生成代碼并在實時環境中部署它。此類配置可降低在實際且通常較昂貴的設備上的測試風險，但是它允許我們驗證算法的實時方面。 此類型的驗證要求尖端的信號調節和電力電子技術，以便正確地模擬輸入并接收目標硬件的輸出。HIL通常在系統集成和現場測試之前，作為最后一個實驗室測試步驟。 4 結論 嵌入式系統開發的技術為提升驗證和確認方法提供了一次絕好的機會。通過仿真建模以及代碼生成使快速原型和更加系統的測試和早期驗證成為可能。 上述的每個在環測試方法解決了特定類型的問題，并且具有某些優勢。本文中描述的不同方法在嚴格的開發過程中均出現過，每個方法有助于將巨大的驗證挑戰分為更小、更易管理的驗證和確認活動。 |
