嵌入式軟件開發全生命周期管理

文/王飛飛 魏倩雯 王龍

嵌入式軟件在汽車行業得到了越來越廣泛的應用，汽車行業由過去的機械與電子的簡單組合發展為更為復雜的電控系統，由機械時代進入電控時代，在電控時代，嵌入式軟件開發質量直接影響到了產品質量，因此，嵌入式軟件開發得到了越來越廣泛的關注。

16949 標準是廣泛適用于汽車行業的國際標準體系，幾乎所有的整車廠及汽車行業供應鏈上的組織均遵循該標準，新版16949標準：IATF 16949：2016在繼承之前的ISO/TS 16949標準的基礎上專門新增了針對嵌入式軟件的全新要求，用以規范汽車產品中嵌入式軟件開發。新版16949標準在8.3.2.3條款中明確指出：組織應有一個質量保證過程，用于其帶有內部開發的嵌入式軟件的產品。應采用軟件開發評估方法來評估組織的軟件開發過程。組織應按照風險和對顧客潛在影響的優先級，為軟件開發能力自評估保留形成文件的信息。組織應將軟件開發納入其內部審核方案的范圍。

由此可見，嵌入式軟件開發已然成為國際通用的汽車行業標準中的一項重要內容，每一個涉及嵌入式軟件開發的汽車行業的組織都必須保證其組織內部的嵌入式軟件開發形成規范的開發流程，配備規范的質量保證工具，具備有效的手段實現對嵌入式軟件全生命周期規范管理，并引入滿足16949體系要求的軟件評估方法（CMMI或者 A SPICE），才可以保證最終交付的嵌入式軟件產品滿足16949體系的要求。

本文闡述了汽車電控系統嵌入式軟件V流程開發模式，明確了汽車電控系統嵌入式軟件從需求

定義到系統驗證的開發流程；并針對汽車電控系統嵌入式軟件開發V流程中各環節的開發及管理工具提供了解決方案，確保通過該解決方案可以實現汽車電控系統嵌入式軟件全生命周期的管理。

圖1：嵌入式軟件開發V流程

圖2：嵌入式軟件開發及管理工具

1 嵌入式軟件V流程

從接收到客戶需求，到最終交付滿足客戶需求并且符合適用的法律法規相關要求的產品，嵌入式軟件開發需要經過系統需求定義、系統架構設計、系統詳細設計、算法開發、軟件實現等一系列環節，而每一個環節均要經過采用相應手段的測試及驗證，來保證相關交付的準確性和可靠性。這是個逐層開展及驗證的過程，為保證嵌入式軟件開發質量，建議采用V流程開發模式，如圖1所示。

需求是設計的基礎，只有明確了需求，才可能開發出讓客戶滿意的產品。嵌入式軟件開發中需通過市場問卷調查、市場調研、客戶滿意度調查、客戶溝通會等方式去挖掘客戶需求，形成書面化的客戶需求。客戶需求文檔是客戶需求的直觀表達，客戶需求文檔需要得到客戶的確認。

客戶需求文檔是客戶需求的直接體現，無法直接用于指導開發，需要由專業系統開發人員將客戶需求轉化為專業術語描述的條目化需求，用以指導后續的設計及開發工作，即系統需求。在將客戶需求轉化為系統需求的過程中，需要挖掘分析客戶可能并不會直接提出的隱含需求，尤其是國家相關法律法規帶來的隱含需求，這些隱含需求同樣是系統設計開發的基礎，必須得到滿足。

由客戶需求到系統需求，需建立需求跟蹤矩陣，建立客戶需求與系統需求的雙向跟蹤追溯關系，確保客戶需求得到了全面的覆蓋。

系統需求完成之后，系統架構開發人員需要根據系統需求完成系統架構設計。架構是將需求分配至解決方案的基礎，通過架構設計明確各產品組件之間的接口。通常，可以把軟件系統中的組件當作一個具備獨立功能的物體，做好各個組件分配工作，能夠有效提升系統資源應用效率[2]。產品組件得以集成為最終的產品，一個產品包含多個層次的產品組件。嵌入式軟件系統架構設計需明確嵌入式軟件與硬件之間的接口，同時應明確嵌入式軟件內部各產品組件之間的接口，嵌入式軟件系統架構設計應按照產品組件的層級逐層開展。

基于系統架構設計，系統開發人員需完成各產品組件的詳細設計，用于指導軟件開發人員進行軟件實現。在詳細設計過程中，需明確各產品組件要實現的具體功能以及具體功能的實現方案。

系統詳細設計完成后，模型開發人員基于詳細設計文檔開展算法開發工作，所開發算法需要經過相關人員評審，確認滿足系統詳細設計文檔的要求。

汽車電控系統嵌入式軟件的軟件實現通常包括基礎軟件和應用軟件兩部分，基礎軟件部分需要完成相關驅動的代碼開發，基礎軟件部分通常通過C語言編寫代碼實現；而客戶絕大多數的控制需求以及診斷需求均是通過應用軟件部分實現的，應用軟件部分通常通過Mathworks公司的Matlab軟件中的simulink & stateflow實現。應用軟件部分，首先需要完成浮點模型的搭建，基于完成的浮點模型，完成單元功能測試；單元功能測試通過后，需完成浮點模型定標，將浮點模型轉化為定點模型，在此過程中需要注意精度損失問題。

汽車電控系統嵌入式軟件基礎軟件部分，完成手寫代碼的編制后，需要完成針對手寫代碼的單元測試，確認手寫代碼邏輯功能正確性，并出具離線測試報告，單元測試完成后，需完成基礎軟件預編譯，完成基礎軟件多模型之間的聯調；應用軟件部分定標完成后，需要將定標后的模型與浮點模型進行對比，確保定標在允許的誤差范圍內，并開展多模型檢查，確認應用軟件模型之間的接口、頭文件定義等沒有沖突。

汽車電控系統嵌入式軟件基礎軟件部分和應用軟件部分開發完成后，需要通過集成平臺完成基礎軟件和應用軟件的集成，完成集成后的嵌入式軟件應該具備了嵌入式軟件系統所要求的所有系統功能，集成完成后，需完成集成測試，確保嵌入式軟件系統具備進行系統測試的基本條件。

集成測試通過后，嵌入式軟件配套相應的汽車電控單元完成系統放行測試，系統放行測試通常在硬件在環系統上完成，通過設計測試用例，完成系統功能以及系統接口的系統級放行測試。

完成系統級放行測試后，需開展基于實際使用環境的驗證，將嵌入式軟件以及與之相配套的電控單元硬件，置于客戶實際使用環境中開展系統驗證，確保客戶需求得到全面滿足和驗證。

2 嵌入式軟件開發及管理工具

在嵌入式軟件開發的整個V流程中，每個環節都需要一定的開發及管理工具，來保證開發的規范性，提高開發效率。本文給出了汽車電控系統嵌入式軟件V流程各環節的開發及管理工具，為實現嵌入式軟件全生命周期的管理提供了整體解決方案。如圖2所示。

2.1 嵌入式軟件開發工具

系統需求定義階段的需求建立及需求管理工具可選用IBM的DOORS或者PTC的ALM，IBM DOORS是一個業界領先的需求管理工具，可以滿足系統需求定義階段，客戶需求、系統需求、需求跟蹤一系列要求，但IBM DOORS是相對獨立的需求管理工具，很難與IBM其他產品集成整合。PTC ALM中需求管理是整個軟件的一個組成部分，可以與配置管理、流程管理等其他組成部分有效配合，無縫銜接。

PREEvision是一款汽車電控系統嵌入式軟件系統架構設計的理想的開發工具，可實現基于模型的架構設計。與傳統的架構設計工具Excel、Visio等相比，PREEvision可以清晰高效的逐層建立系統架構，并使得各層架構形成一個整體。

系統詳細設計階段，可以通過IBM的DOORS來完成系統詳細設計；或者通過PTC的ALM完成系統詳細設計，兩者都是專業的需求管理工具。

在算法設計、軟件實現、離線測試階段，汽車電控系統嵌入式軟件基礎軟件部分和應用軟件部分所采用的開發工具有所不同，基礎軟件部分通常使用C語言進行開發，而應用軟件部分采用Matlab作為開發工具，離線測試階段，基礎軟件部分可采用Tessy進行單元和集成測試，可以自動搭建測試環境、執行測試、評估測試結果；而應用軟件部分，則可以直接利用Matlab生成測試用例，執行單元和集成測試。系統集成階段，可選用WindRiver作為開發工具，實現基礎軟件部分和應用軟件部分的集成；流程和配置管理可以通過IBM的ClearQuest和ClearCase組合或者PTC的ALM實現。

硬件在環測試階段，通過HIL平臺運行自動測試用例，實現對嵌入式軟件的全面放行，自動測試用例的開發及執行通過ECU-Test實現。ECU-TEST是TraceTronic公司開發的一款用于嵌入式系統測試驗證的軟件工具，ECU-TEST可實現所有測試環境的控制自動化操作，同時支持廣泛的測試平臺。

2.2 嵌入式軟件管理工具

嵌入式軟件V流程整個開發過程中的管理工具需要包括流程管理和配置管理兩部分內容，IBM的ClearQuest是一款行業里比較通用的流程管理工具，ClearQuest作為流程管理工具，可實現定制化開發，用戶可根據實際情況定制流程，實現對需求、設計、缺陷、變更等的流程管理；IBM的ClearCase是一款行業里比較通用的配置管理工具，可有效實現對配置項的存儲、版本管理、權限控制等操作，確保配置項的可追溯性。而PTC的ALM提供了流程管理與配置管理一體化解決方案，ALM成功將流程控制與配置管理融合，通過流程控制對配置項的寫權限的控制，確保每一次的改動都是受控狀態，進一步提升了對產品質量的把控。

PTC的ALM可實現與嵌入式開發過程中的開發工具有效集成，從而實現各工具之間有效銜接，大大節省開發人員開發時間，提高工作效率。本文提到的嵌入式軟件的開發工具PREEvision、Matlab、ECU-TEST等均可以實現與PTC的ALM集成，實現相關配置項的共享，可通過ALM去調用相關開發工具實現對相關文件的修改，也可以通過ALM去調用ECU-TEST自動執行ALM上存儲的測試用例并將ECU-TEST的執行結果自動回傳給ALM，因此在工具集成開發一體化方面，無疑ALM具備更大的優勢。

3 結束語

本文闡述了嵌入式軟件開發的V流程，并對嵌入式開發V流程中各環節的開發工具及管理工具給出了建議的解決方案。