近年來，「軟件定義汽車」興起，但各方觀點眾說紛紜，直到最近才有了標準化組織的官方理解，即來自中國汽車工業協會下屬的軟件定義汽車工作組（以下簡稱SDV工作組）發布的《軟件定義汽車產業生態創新白皮書（V1.0）》（以下簡稱白皮書）。

白皮書引用了 APTIV（安波福）和 BOSCH（博世）對于「軟件定義汽車」的理解：

APTIV（安波福）

「軟件定義汽車」是一個術語，描述的是一種主要通過軟件實現特性和功能的汽車。這是汽車從主要基于硬件的產品向以軟件為中心的車輪上電子設備不斷轉變的結果。

BOSCH（博世）

許多汽車駕駛員希望他們的汽車能完全融入他們的數字生活。此外，新的互聯化、自動化和個性化功能在未來將越來越多地通過軟件實現。過去，客戶對汽車的體驗主要由硬件決定，而現在軟件正承擔著更重要的角色。軟件極大地影響了客戶體驗，在某些情況下甚至影響了硬件規格的這種趨勢，被稱為「軟件定義汽車」(SWdV)。

頭豹研究院《汽車軟件行業概覽：軟件定義汽車》

目前行業普遍認為比較合理的描述是：“軟件定義汽車就是軟件深度參與到汽車的定義、架構、開發、驗證、銷售、服務等全生命周期的過程中，并不斷改變和優化各環節，實現駕乘體驗持續優化、汽車價值持續增值”。

這只是一個階段性的概念理解，距離形成標準定義仍有一段路要走，但確實標志著，行業已經發展到了新的里程碑。受各種因素影響，汽車市場前景仍不明朗，但軟件在汽車行業的重要度不斷提升的趨勢，已然不可逆轉，相應的機會也越來越多。

在這樣的背景下，越來越多的企業與個人源源不斷地涌入，而市場競爭的大浪淘沙下，并非所有人都能生存下來。

入局「軟件定義汽車」，你真的準備好了嗎

過去深耕傳統汽車的整車廠，

能適應快速迭代的敏捷開發嗎？

軟件外包團隊，

能應付數據激增、算法和架構高度復雜的系統嗎？

互聯網公司、ICT科技公司，

入局汽車能符合汽車行業的各項合規要求嗎？

我們正處在汽車行業歷史的關鍵節點

1）主流汽車軟件架構路線圖

上述 SDV 工作組引用的兩家企業，對「軟件定義汽車」這一轉變，有各自的行業洞察：

APTIV（安波福）的前身是從通用汽車公司分離出的德爾福，總部曾從美國遷到倫敦，后至愛爾蘭，在一定程度上代表了「英美法系」的技術見解。

在《安波福智能汽車架構白皮書》中，可以看到如下「汽車軟件架構路線圖」：

《安波福智能汽車架構白皮書》：

https://www.aptiv.com/zh/%E8%A1%8C%E4%B8%9A%E8%A7%86%E9%87%8E/%E6%96%87%E7%AB%A0/%E6%99%BA%E8%83%BD%E6%B1%BD%E8%BD%A6%E6%9E%B6%E6%9E%84-sva-tm

圖 / 逐步全面實現 SVA

來源：《安波福智能汽車架構白皮書》

翻譯如下：

簡言之，根據安波福發布的這份白皮書，當下的汽車軟件架構正處于域（Domain）和區域（Zone）架構的階段，2025 年將真正進入「軟件定義(Software Defined)」元年。

BOSCH（博世）總部位于德國，長期居于 Tier1 榜首的公司，在一定程度上代表了歐洲「大陸法系」的行業洞察。

圖源：

https://semiengineering.com/the-wild-west-of-automotive/

翻譯如下：

該時間表是博世于 2015 年提出，而當下的架構演化進程完全符合預測，正處在所有域控單元向「融合于一個集中式計算單元」發展的進程中。

結合國情理解「軟件定義汽車」這一轉變給行業帶來的影響，我們可以參考頭豹研究院《汽車軟件行業概覽：軟件定義汽車》報告：這是覆蓋「汽車的定義、架構、開發、驗證、銷售、服務等全生命周期」的顛覆性變革。

2）歷史 vs 當下

事實上，隨著「軟件定義汽車」的演進，汽車軟件產業鏈金字塔型結構，即「主機廠 - Tier1 - Tier2 - Tier3」，也已發生改變。

在過去傳統汽車供應鏈中，Tier1 為汽車軟硬件集成負全責，如電裝之于豐田、德爾福之于通用、偉世通之于福特。

而當下，Tier1 不再是 OEM 軟硬件的唯一來源，取而代之，OEM 可能會從第三方軟件、OEM 本身軟件、軟件棧工程集成服務商、面向 OEM 的硬件提供商、硬件工程服務商、EMS 服務商等多個來源獲取對應的軟硬件組件進行集成。

在這樣一個新的產業鏈關系中，甲乙雙方的合作模式如何？

理想的開發狀態當然是甲方和乙方基于統一標準和工具鏈，如雙方 PM、程序員、測試均在同一套軟件平臺進行需求管理、開發與評審。

但目前，甚至很少企業能做到甲乙雙方 PM 針對 Jira 上的一個 story 跟蹤狀態；雙方需求人員基于同一個 Polarion 里的工作項進行評審；雙方程序員基于極狐GitLab 進行軟件研發等，更遑論在同一個平臺進行研發管理。

要實現理想狀態，不可能一蹴而就?，F階段，「軟件定義汽車」對汽車軟件鏈條中的不同角色都提出了新要求：

更快捷

對于項目的開發和管理人員而言，這或許意味著需要通過敏捷方法推動持續軟件開發，比如采用目前在互聯網大規模落地實踐、并已證明有效的DevOps 方法，使汽車制造商能夠在車輛出廠后持續將軟件高效地部署到車輛上。

更可控

對于定義業務功能的產品經理和搭建架構的架構師而言，車輛軟件和電氣電子架構轉向更模塊化的面向服務架構（SOA）模型，使軟件組件更易以構建塊格式重用。隨著軟件復雜度提升，對于代碼追溯和版本管理的可控性要求也進一步提升。

更安全

對于網絡安全專家和測試驗證團隊而言，為了避免、檢測和防御網絡攻擊，安全策略變得更加關鍵。相較于事后補救，更需要防患于未然，提前實施安全測試，軟件安全左移，在早期將安全要素融入到設計、開發、測試和部署的每個階段。

汽車行業軟件研發三大挑戰

面對「更快捷」、「更可控」、「更安全」的行業要求，汽車行業軟件研發鏈條上下游面臨著諸多挑戰，聚焦軟件研發方面包括：

1）缺乏研發運維一體化標準平臺

軟件研發過程中，需求管理、源代碼托管、CI/CD、安全掃描等，都有對應的工具平臺，若缺乏有效整合，研發團隊面對的將是許多復雜的工具，研發流程節點之間難以流轉；且工具之間數據結構不同，API 豐富程度不一，集成難度大，團隊需要花更多時間和精力在工具細節上，難以實現敏捷。

2）缺乏確保標準合規的手段和機制

盡管軟件架構方面有了 AUTOSAR（汽車開放系統架構）、代碼質量方面有了 MISRA（汽車工業軟件可靠性聯會）、開發流程方面有了 ASPICE（汽車產業軟件流程改進和能力測定標準）和規?；艚莸葮藴?，但具體落地中，仍然沒有形成有效的機制強制標準合規。例如：只有評審通過的代碼才能上傳、不合規問題及時檢出報告、支持版本控制、確保可追溯性等，這些機制的缺失，可能最終導致整個項目失控。

3）復雜度和性能要求進一步提升

涉及更多兼容、安全要素的行業標準正在制定或剛剛發布，但在落地層面仍然存在很多不確定性。例如 2021 年 8 月發布了 ISO21434，但實際上的產品架構設計、代碼實現、驗證檢測方面都還處于初級階段，缺少安全保障很可能釀成嚴重事故。

應運而生的DevOps

更復雜的系統、更嚴格的標準、更緊迫的交付時間、更劇烈的競爭……一切都在層層「做加法」。

DevOps 應運而生：旨在讓軟件研發鏈條上的所有人緊密協作，加速軟件交付。

近年來，DevOps 被各大行業所追捧和實踐，尤其在互聯網領域，已獲得巨大成功。

但對于車企而言，關于 DevOps 的落地實踐仍存在誤區：

1）過分關注工具鏈建設

工具是 DevOps 落地實踐的有效支撐。因為 DevOps 涉及多階段，每個階段都會用到很多開源或閉源工具。企業往往陷入各種工具鏈的建設，然而每個階段使用一種工具，最后將耗費大量的時間和精力在工具運維上（采購、安裝、補丁升級等），而無力投入到汽車軟件研發和團隊創新的核心工作上。

因此，切記一點：工具只是手段，不是目的。理想狀態下，好的研發平臺應當屏蔽所有工具底層細節，車企直接使用開箱即用的能力。

2）忽略規范化、標準化流程的構建與沉淀

規范化、標準化流程是研發效率提升的重要手段之一，能夠讓研發團隊遵循同樣的流程進行研發，減少無序和混亂；也能夠讓團隊新成員快速熟悉團隊工作、進入狀態，最終提高團隊端到端交付能力。

同時，規范化、標準化流程可以沉淀為最佳實踐，在團隊、組織間大規模推廣，有效提升生產力。

3）忽略「數據孤島」的治理

工具、流程的背后，其實是數據。數據為研發、測試、運維、決策者等角色，提供諸如變更代碼質量如何、安全如何等的直觀感受。

但軟件研發流程的每個階段都有很多數據產生，如果不能夠被有效整合，就容易形成 “數據孤島”，讓 “數據驅動決策” 成為口號。

另外更為重要的是，所有數據應該 “左移”，讓研發、測試、安全等第一責任人在第一時間掌握現狀，對于有問題的代碼進行及時修復，降低修復成本。

4）安全「掃而不修」，無法「安全閉環」

為確保汽車軟件安全交付，常規的思路是選擇安全工具進行掃描，但往往只掃描，不修復，因為缺少完整的機制來落地「安全掃描 → 漏洞管理 → 安全修復」的閉環。

汽車行業DevOps的最優解

因此，一個適合汽車行業使用場景、滿足汽車軟件需求，且能幫助車企快速完成「軟件定義汽車」轉變的 DevOps 平臺，應該滿足：

· 一體化：方便所有人員在同一個平臺上協作、所有信息公開透明，有效消滅「數據孤島」；

· 體系化：能夠屏蔽工具細節，直接為用戶提供開箱即用的 DevOps 能力，構建體系化、標準化的 DevOps 流程；

· 安全可控：確保軟件安全左移，及時修復，落地「安全閉環」。

極狐GitLab ，安全的企業級一體化 DevOps 平臺。

從 2011 年面世之初的源代碼托管工具，已經演變成為集項目管理、源代碼托管、CI/CD、DevSecOps、GitOps 等能力于一身的一體化平臺，實現高質量軟件創新落地。

1）極狐GitLab workflow 標準化敏捷研發流程，提升研發效率

極狐GitLab workflow 將需求管理、代碼變更與托管、CI/CD、安全掃描、代碼準入融合在一起，在一個流程上完成代碼變更到上線，兼顧效率和質量。

這種 workflow 讓研發流程規范化、標準化，減少了軟件研發的無序和混亂，節約了不同角色之間的溝通、協作成本，可極大提升研發效率。

2）版本控制，實現變更可追溯、可審計

極狐GitLab 版本控制功能，能夠實現對文件、代碼的版本控制，記錄每次變更的時間、范圍、變更人員等信息。在后續的故障回溯、安全審計中，可以快速查閱對應信息。

3）極狐GitLab CI/CD，為軟件研發提速

極狐GitLab CI/CD無需安裝第三方工具即可使用：

· 只需要通過創建 .gitlab-ci.yml 文件，并且使用內置的關鍵字完成 YAML 文件的編寫即可使能 CI/CD Pipeline；

· 內置的 include 語法能夠減少 CI/CD Pipeline 的冗余，便于 CI/CD Pipeline 的維護與快速構建；

· 多種流水線類型，注入父子流水線、多項目流水線、合并請求/結果流水線等，方便不同規模團隊、不同應用場景的使用。

4）安全可控，為車企軟件構建安全生命線

極狐GitLab 的安全表現在多個方面：

私有化部署，保護代碼安全

極狐GitLab 支持私有化部署，方便用戶在數分鐘之內快速構建起可用的極狐GitLab 實例，同時，所有數據都在用戶側，確保數據安全可控。

安全審計，防止核心資產外泄

極狐GitLab 內置安全審計功能，對于代碼的相關操作會都會有對應的審計事件。通過對審計事件的監控，可防止代碼核心資產的外泄。

DevSecOps，構建應用縱深防御體系

DevSecOps 是 Security 與 DevOps 的結合，意味著在軟件研發的每個階段，都嵌入對應的安全防護手段，構建縱深防御體系。

極狐GitLab DevSecOps 提供敏感信息掃描、依賴項掃描、SAST、DAST、容器鏡像掃描、License 合規以及模糊測試等安全防護手段，提供從靜態到動態的安全防護能力，同時所有的掃描報告會統一展示，并且嵌入到對應的 MR 下，實現真正的安全 “左移”。

軟件定義汽車的征途剛剛開始，產業鏈條正在日趨完善，相信支撐軟件定義汽車的研發團隊通過實踐 DevOps，將推動汽車產業加速駛入“軟件定義汽車”時代。