使用基于模型的設計進(jìn)行早期驗證和確認

此過(guò)程使所有驗證和測試都位于 V 型圖右側，即完成設計和實(shí)現之后。對于基于 C 代碼的傳統嵌入式控制開(kāi)發(fā)流程，集成測試通常在其他形式且級別逐漸提高的測試（例如硬件在環(huán)測試以及全系統測試）之前。雖然此開(kāi)發(fā)順序有助于組織復雜的系統設計，但還是有一些缺點(diǎn)：該順序直到開(kāi)發(fā)末期才考慮驗證和測試，而此時(shí)修復所找到的任何錯誤都要付出最高代價(jià)且最耗時(shí)；用戶(hù)必須實(shí)現所有組件后才能測試系統；并且該順序未能考慮開(kāi)發(fā)過(guò)程中的迭代。

通過(guò)基于模型的設計，可以將驗證作為并行活動(dòng)，貫穿整個(gè)開(kāi)發(fā)流程（圖 3）。

圖3：通過(guò)基于模型的設計，可以將驗證作為并行活動(dòng)，貫穿整個(gè)開(kāi)發(fā)流程。

在開(kāi)發(fā)流程的每一步進(jìn)行測試和驗證，意味著(zhù)可在引入錯誤之處發(fā)現這些錯誤。與傳統的 V 型圖流程相比，可以更快地重復、修復和驗證設計。那么該如何著(zhù)手實(shí)現早期驗證，從而減少在開(kāi)發(fā)末期花費在測試和調試設計上的時(shí)間呢？下文概述了一些最佳做法。

模型驗證和確認

基于模型的設計實(shí)現驗證和確認的主要方式是通過(guò)在仿真的過(guò)程中進(jìn)行測試。雖然許多組織都進(jìn)行某種形式的建模，但是大多是以專(zhuān)門(mén)的方式應用仿真，因此無(wú)法在最大程度上實(shí)現潛在的驗證好處。單靠仿真無(wú)法發(fā)現所有錯誤；但這是一個(gè)巨大的進(jìn)步，您幾乎在開(kāi)始設計模型時(shí)就可以進(jìn)行仿真。建模環(huán)境中的迭代快速且方便。

對各個(gè)組件進(jìn)行建模非常有用，可能是完成復雜設計所必需的；然而，不要因為這種優(yōu)勢，就不再對將在其中運行組件的系統或環(huán)境進(jìn)行建模。通過(guò)在單一環(huán)境中對整個(gè)系統進(jìn)行建模，您可以快速了解組件功能與其他組件的交互方式，以及集成組件在已部署的系統或環(huán)境中的行為方式?？赡軙?huì )發(fā)現對組件或其他方面的遺漏需求。通過(guò)使系統模型還原為迭代一個(gè)組件時(shí)的狀態(tài)，可以評估設計迭代對系統功能的影響。

與設計和開(kāi)發(fā)同時(shí)進(jìn)行測試有助于檢測出潛在問(wèn)題，并可顯著(zhù)減少修復這些問(wèn)題的成本和時(shí)間。通過(guò)在開(kāi)發(fā)模型期間考慮測試，可使設計更適合于進(jìn)行測試，從而確?？蓪υO計進(jìn)行完整測試。此原則的應用范圍遠不止嵌入式系統領(lǐng)域，但是嵌入式系統開(kāi)發(fā)人員卻常常忽視了此原則。原因是用戶(hù)以為可以在軟件中完成任何事情，也可能是文檔化的開(kāi)發(fā)流程忽視了此原則。然而，與新型靈活的軟件開(kāi)發(fā)流程一樣，在設計模型之前或與設計模型并行開(kāi)發(fā)測試是最佳做法。

幾乎每種測試方案都涉及到某些變數：輸入、對象參數、環(huán)境因素或其他要素。時(shí)間和開(kāi)支通常限制了測試方案的靈活度；然而，通過(guò)在仿真環(huán)境中進(jìn)行測試，您可以更加快速且并行（如果處理能力夠用）地仿真測試案例。在仿真中探查整個(gè)參數空間還可以縮小要實(shí)時(shí)運行的關(guān)鍵測試的范圍。

每個(gè)組織都有針對設計和實(shí)現的標準或最佳做法。這其中有許多標準并未形成文檔，但是卻被關(guān)鍵人員銘記在心。使標準書(shū)面化并將標準檢查加入模型開(kāi)發(fā)流程是很簡(jiǎn)單的做法，但卻可以產(chǎn)生巨大的影響，因為這樣做可盡早減少“愚蠢”錯誤的數量，確保模型在團隊成員之間共享時(shí)更具可讀性，并且更加容易在將來(lái)進(jìn)行維護。對標準進(jìn)行建?？梢苑浅：?jiǎn)單（如驗證所有輸入和輸出是否已連接），也可以非常復雜（如是否滿(mǎn)足行業(yè)標準）。關(guān)鍵在于開(kāi)發(fā)一致的檢查，然后在整個(gè)組織中推動(dòng)對這些檢查的遵從性。

確定測試組件何時(shí)能夠滿(mǎn)足需要通常不僅是一門(mén)科學(xué)，更是一門(mén)藝術(shù)，因為您通常要根據設計或測試工程師的判斷來(lái)確定。對于軟件組件，許多團隊使用代碼覆蓋率作為更客觀(guān)的標準來(lái)衡量測試的完整性。您同樣可以將模型覆蓋率用于模型測試。覆蓋率用于衡量您在測試過(guò)程中測試了模型中（或源代碼中）的多少邏輯。修改的條件/決策覆蓋率是一種針對覆蓋率的嚴格衡量標準，得到廣泛接受。

大多數質(zhì)量標準的核心原則是進(jìn)行文檔化。把需求，流程。結果記錄下來(lái)。如果不進(jìn)行記錄，則不可能跟蹤做過(guò)的事情；不可能向別人（如客戶(hù)）證明您滿(mǎn)足了他們的需求；也不可能重復您的結果。雖然記錄通常很單調乏味，但是有許多工具可通過(guò)生成標準報告，來(lái)幫助自動(dòng)記錄活動(dòng)。在您以后發(fā)現問(wèn)題或希望重復使用設計時(shí)，良好的記錄可幫助您節省時(shí)間，這也是非常重要的。

代碼驗證

這些做法是在模型級別開(kāi)始早期驗證的良好起點(diǎn)。最后，需要實(shí)現并部署到產(chǎn)品化硬件上。此時(shí)，代碼驗證成為重點(diǎn)?；谀Ｐ偷脑O計可以提供哪些幫助呢？

自動(dòng)代碼生成是一種非常有用的方法。通過(guò)在模型級別驗證您的設計，然后直接從模型生成代碼，您只需要驗證模型和代碼是否等效。這是一種理想狀態(tài)的工作流程。在實(shí)際情況中，有時(shí)不可能從模型生成需要的所有代碼。您可能使用傳統流程開(kāi)發(fā)了一些中間件和設備驅動(dòng)程序代碼，或是可能將舊有代碼用于某些功能。對于這些情況，可通過(guò)一些其他的最佳做法來(lái)驗證代碼。

用戶(hù)幾乎可以在任何位置測試硬件；然而，硬件通常沒(méi)有與仿真中的測試有連接。許多因素都可能導致這種沒(méi)有聯(lián)系的情況：在硬件上運行測試的小組與對設計建模的小組不是同一批人，在實(shí)驗室中運行的軟件與設計中的軟件也不相同。然而，當您在模型上運行的測試與在實(shí)驗室中運行的測試相同時(shí)，您就可以確切地了解設計在實(shí)驗室中的執行情況。若要驗證代碼是否等效于設計模型，您可以將相同的測試工具用于模型測試，來(lái)測試已編譯并在嵌入式目標上運行的模型軟件實(shí)現。同時(shí)對組件設計模型和嵌入式目標上的代碼運行測試是一種協(xié)同仿真步驟，稱(chēng)為 PIL（處理器在環(huán)）測試?，F在，可以使用一些工具在軟件上執行測試（開(kāi)發(fā)人員在主機（如 PC）上創(chuàng )建的測試），同時(shí)也在嵌入式處理器上運行測試。將嵌入式代碼與原始模型的測試結果進(jìn)行比較，可幫助您確保組件的行為在編譯和下載后保持不變，并確保代碼可正確運行。

嵌入式代碼中的運行時(shí)錯誤特別難以發(fā)現，一旦發(fā)現后，又難以進(jìn)行調試。這類(lèi)例子包括溢出和下溢、被零除和其他算術(shù)錯誤、超出范圍的數組訪(fǎng)問(wèn)、非法取消引用的指針、對非初始化數據的只讀訪(fǎng)問(wèn)以及危險的類(lèi)型轉換等。直到最近，基本上只有三種選擇可用于檢測嵌入式軟件中的運行時(shí)錯誤：代碼檢查、靜態(tài)分析器和試錯法動(dòng)態(tài)測試。代碼檢查所需的人工工作量很大，通常不適用于大型的復雜應用程序。靜態(tài)分析器可發(fā)現的問(wèn)題相對較少，更重要的是，無(wú)法診斷大多數源代碼。動(dòng)態(tài)（或“白盒”）測試要求您編寫(xiě)并執行大量測試用例。如果測試失敗，可能難以調試問(wèn)題?；谛问津炞C的代碼驗證工具可以證明不存在運行時(shí)錯誤，并可為代碼的可靠性提供強有力的保證。當在開(kāi)發(fā)流程中使用代碼驗證工具進(jìn)行測試時(shí)，這些工具還可提供其他技術(shù)，用于發(fā)現在后期測試階段中難以發(fā)現并需要花費很高代價(jià)進(jìn)行更正的設計和實(shí)現錯誤。

系統建模和仿真工具（如 Simulink）可幫助優(yōu)化設計和驗證復雜算法的任務(wù)，而無(wú)需昂貴的硬件。摒棄手工編碼、難以維護的仿真后，控制設計人員可以快速開(kāi)發(fā)復雜算法和系統模型，并在將算法應用到硬件上之前測試這些算法。經(jīng)過(guò)多年經(jīng)驗的積累，現在已形成了可提供自動(dòng)代碼生成的方法，以支持原型系統中的實(shí)時(shí)測試并在以后用于可部署的嵌入式代碼?，F在，基于模型的設計已廣泛應用于各種領(lǐng)域，包括控制、圖像處理、音頻、通信和信號處理。

基于模型的設計的一個(gè)主要好處在于，我們有機會(huì )隨所有其他開(kāi)發(fā)步驟（尤其是在開(kāi)發(fā)流程早期）一起，并行地進(jìn)行嚴格驗證和確認?；谀Ｐ偷脑O計的采用者通過(guò)不懈的實(shí)踐已發(fā)現了一系列最佳做法，使用這些最佳做法可以在最大程度上獲得這種設計帶來(lái)的好處。這些做法（特別是隨模型一起開(kāi)發(fā)測試并在代碼和硬件上重復使用模型測試）可以顯著(zhù)降低開(kāi)發(fā)項目由于在流程后期發(fā)現錯誤而導致未能達到質(zhì)量或交付目標的風(fēng)險。