作者 | 明
小編 | 不吃豬頭肉

隨著汽車電子技術的快速發展，汽車軟件的復雜性與日俱增，如何確保軟件開發的高效性與穩定性成為了一個關鍵問題。為了解決這個問題，許多汽車企業和供應商逐漸引入了AUTOSAR架構，并在此基礎上構建了持續集成（CI）流程。今天，我們就來探討一下基于AUTOSAR架構的CI流程實踐，并通過對流程的詳細講解，展示其在實際開發中的重要性和優勢。

什么是AUTOSAR架構？
首先，AUTOSAR（Automotive Open System Architecture）是一個開放的、標準化的汽車電子軟件架構。它旨在通過提供一個標準的接口和抽象層，減少復雜的汽車軟件開發流程，并提升軟件的可復用性、模塊化和可維護性。AUTOSAR架構中的核心模塊可以分為應用軟件層（ASW）、基礎軟件層（BSW）和運行時環境（RTE）、微控制器四個層面，它們各自承擔不同的功能。

為什么要在AUTOSAR架構中引入CI？
隨著汽車軟件規模的日益龐大，軟件開發的復雜度也不斷增加，傳統的開發方式往往難以應對復雜系統的集成挑戰。尤其是在高度模塊化的AUTOSAR架構下，軟件的各個層次和模塊相互依賴，任何代碼變更都有可能影響整體系統的穩定性。為此，開發團隊需要一種高效的機制來快速檢測問題，確保每次代碼修改后的系統都能正常工作。這時，持續集成（CI）流程的重要性便凸顯出來，它能夠自動化地進行代碼集成、測試和反饋，確保軟件的質量與穩定性。接下來，我們將介紹在AUTOSAR框架中CI實現的詳細流程。

CI流程簡介

持續集成（CI）是一種軟件開發實踐，它強調開發者頻繁將代碼集成到共享的代碼庫中，并通過自動化測試和構建系統，確保每次集成都能夠得到及時的反饋。那么在本次介紹中的CI在基于AUTOSAR架構的軟件開發中，CI流程不僅僅是一個簡單的自動化工具鏈，而是保證軟件穩定性和一致性的關鍵所在。
雖然硬件在環（HIL）測試在開發流程中也扮演著重要角色，但它屬于硬件驗證的范疇，并不包含在CI流程之內。因此，本文中的CI流程將專注于軟件層面的集成和測試，不涉及HIL測試部分。
在本次介紹的CI流程實踐中，AUTOSAR框架的測試主要集中在三個部分：

ASW（應用層）

這一層主要基于MATLAB模型進行開發，因此在測試過程中，重點是對模型的驗證。在模塊開發的早期階段，測試的重點是確保模型本身的正確性和穩定性。當模型測試通過后，該模型模塊會被集成到整個開發工程中進行編譯，以此驗證其與最新代碼層是否兼容，并確保功能正常。這一過程可以保證每個模塊在合入到整體系統前已經過充分驗證。

BSW（基礎軟件層）

這里的BSW層指的是通過框架生成軟件自動生成出的代碼，通過AUTOSAR架構生成的代碼來實現軟件功能的更新和維護。每當BSW層的代碼更新時，CI流程會自動觸發項目的整體編譯，從而驗證所有基礎功能在最新更新下的一致性和穩定性。這一機制確保了基礎軟件層的變更不會破壞系統的整體功能。

CDD（復雜設備驅動層）

該層主要負責復雜設備的驅動程序開發。CDD層通常涉及手寫代碼，用來滿足客戶的特定需求。每當CDD層的代碼更新后，CI系統會自動執行代碼分析和驗證，確保新編寫的驅動程序與系統的其他部分協調工作，并符合功能要求。通過這三大模塊的分層測試和自動化驗證，CI流程確保了AUTOSAR架構下的軟件在開發和更新過程中始終保持高效和穩定。
下圖展示了一個典型的基于AUTOSAR架構的CI流程，通過Jenkins調度服務器和Gitlab版本管理工具實現模塊的自動化集成和測試。

基于AUTOSAR架構的CI流程實踐
從流程圖中可以看出，整個CI流程主要圍繞ASW模塊變更、BSW模塊變更和CDD模塊變更展開，并且根據不同模塊的變更類型，分別定義了相應的測試和編譯步驟。接下來，我們逐一對各個模塊的CI流程進行講解。
1. ASW模塊變更流程
ASW（應用軟件）模塊的變更通常是由模型開發人員和模型測試人員手動觸發的。當ASW模塊發生變更時，CI流程將執行一系列的靜態和動態模型測試、代碼生成以及編譯，確保變更后的代碼不會引入新的問題。

靜態模型測試：使用靜態模型測試工具（MXAM）導入模型并進行測試，確保模型的完整性和正確性。

動態模型測試：通過動態模型測試工具（TPT）執行測試用例，并生成測試報告上傳到版本管理系統，最后通過郵件通知到對應的模型更改人員。

代碼生成：通過MATLAB進行模型生成代碼，將其上傳至版本管理系統。

編譯：完成模型生成代碼后，該模型模塊代碼會被集成到整個開發工程中進行編譯，以此驗證其與最新代碼層是否兼容，并確保功能正常。

在ASW模塊的CI流程中，Jenkins服務器會根據預定的觸發條件，如代碼提交或配置文件的變化，自動執行上述步驟，并將結果通知給相關開發人員。
2. BSW模塊變更流程
BSW（基礎軟件）模塊的觸發后的執行流程相對簡單，通常包括整體工程的編譯以及編譯后的結果自動上傳，其主要目的是確保基礎軟件的功能和性能在各個開發階段的一致性。

代碼上傳：從拉取最新的代碼，開發人員根據變更需求對代碼進行調整并重新上傳。

BSW模塊編譯：從版本管理系統中拉取開發上傳好的代碼，然后進行編譯，最后將編譯結果傳遞到版本管理系統中，并通知到對應的開發人員。

3. CDD模塊變更流程
CDD（手寫代碼）模塊的變更與測試也在整個CI流程中占據重要位置。其主要作用是通過靜態代碼測試和動態代碼測試來驗證組件的正確性以及組件的合規情況。

靜態代碼測試：通過Helix QAC工具對導入的代碼進行靜態分析，檢查代碼的命名規則和編碼規范是否符合標準要求。

動態代碼測試：使用VectorCAST工具對組件進行動態測試，并生成測試報告上傳到版本管理系統供開發人員查看。

編譯：完成模型生成代碼后，該模型模塊代碼會被集成到整個開發工程中進行編譯，以此驗證其與最新代碼層是否兼容，并確保功能正常。

在CDD模塊的CI流程中，Jenkins服務器會根據預定的觸發條件，如代碼提交或配置文件的變化，自動執行上述步驟，并將結果通知給相關開發人員。

基于AUTOSAR的CI流程優勢
通過上述流程的詳細解讀，我們可以看出基于AUTOSAR架構的CI流程具有以下幾個顯著的優勢：

自動化測試與集成：通過Jenkins服務器自動執行代碼的集成、測試和發布流程，減少了開發人員和測試人員的手動操作，提高了開發效率。

代碼質量保證：靜態代碼分析和動態測試用例的自動化執行，確保了代碼的規范性和正確性，極大地降低了潛在的代碼缺陷風險。

及時反饋機制：CI流程中的每個步驟都伴隨著詳細的報告生成與郵件通知，使得開發人員能夠及時獲取變更結果，快速進行問題定位和修復。

固定的文件結構：由于AUTOSAR架構中的文件結構是固定和標準化的，CI鏈路能夠很好地利用這一特點，實現高效的集成和自動化測試。這種標準化結構使得代碼的組織和管理更加一致，有助于CI流程的自動化處理，進一步提升了集成效率并減少了出錯的可能性。

實踐中的挑戰與建議
雖然基于AUTOSAR架構的CI流程在實際應用中展示了極大的優越性，但在實施過程中也可能會遇到一些挑戰：

工具鏈集成復雜：由于AUTOSAR涉及多個不同的工具，如MXAM、HeliX QAC、TPT、VectorCAST等，工具鏈的集成和維護需要耗費較多精力。建議企業在實施過程中設立專門的CI工具鏈維護團隊或讓供應商進行鏈路搭建，后續可以通過內部人員進行維護，確保工具鏈的高效運轉。

團隊協作要求高：CI流程的順利實施需要開發、測試、運維等多方團隊的緊密協作，因此在實踐中應加強團隊之間的溝通與協同，定期進行流程優化與改進。

結語
基于AUTOSAR架構的CI流程是汽車軟件開發中不可或缺的一環。它通過自動化的集成與測試，保證了軟件的高質量和穩定性。在未來，隨著汽車智能化和自動駕駛技術的發展，CI流程的重要性將愈發凸顯。因此，持續優化和完善CI流程，是每個從事汽車軟件開發的企業都需要高度重視的問題。
通過這次流程的實踐介紹，相信大家對基于AUTOSAR的CI流程有了更加清晰的認識。希望本文能夠為正在或即將實施CI流程的企業和團隊提供有益的參考與啟發。北匯信息已為國內汽車客戶提供相應的服務內容，歡迎垂詢！