隨著智能汽車的逐步推進，汽車的復雜度在持續的提升，造成智能汽車的開發復雜度越來越難以管理。影響或滯緩智能汽車產業升級發展的主要原因有以下四點：
第一：用戶體驗帶來的復雜度提升。隨著智能化的發展與普及，用戶駕乘體驗逐漸從傳統的交通工具向第三空間擴展，汽車使用的場景、用戶功能等均在大幅度擴展，成百上千的場景、功能組合形成了現在越發復雜的智能汽車體系。
第二：技術進步帶來的復雜度提升。如越來越大的電池能量密度的追求和快充性能的追求帶來了嚴重的電池安全挑戰；人工智能、5G 通信、云計算等多種數據驅動汽車向智能化不斷進化的同時，也大幅度增加了軟硬件開發復雜度。
第三：競爭帶來的堆料、堆配置、各種選配等模式導致汽車配置多樣性、復雜度快速增長。
第四：監管&法規帶來的復雜度提升。智能化、網聯化賦予汽車智能、便捷體驗的同時，也帶來了黑客攻擊、數據濫用等嚴重的安全問題。
對于傳統汽車產業鏈上下游企業而言，復雜度提升的四大原因，到底意味著什么？這些原因對汽車產業的具體影響和挑戰是什么？這都將導致未來智能汽車在配置、硬件、外設、軟件的種類與數量將分別增加 10 倍以上。
尤其是軟件的大量引入將給汽車產業帶來五大挑戰：
第一：技術架構方面，當前架構下任何一個部件的增加、修改、更新都會對整車帶來影響，以傳統通信矩陣為例，當前修改和配置需要 N 周時間。未來電子電氣軟硬件數增加 10 倍以上，大量軟件的引入，那又意味著什么呢？
第二：安全和隱私保護方面，全量測試時間長、代價高，如果部分測試造成漏測會導致什么后果？尤其是安全漏洞被黑客劫持，那對整車廠的品牌和用戶粘性會帶來什么樣的后果？
第三：組織流程方面，整車廠如何建立與軟件定義汽車開發模式相匹配的組織架構？面對消費者上千種配置組合、上千種體驗場景、上萬種組合服務和應用，哪些更新推送給所有的用戶？哪些推送給限定的用戶？
第四：商業模式方面，面對軟件定義汽車對傳統汽車供應鏈與合作模式的顛覆，產業中各方利益如何分配？如何共同做大產業蛋糕？
第五：生態協同方面，傳統汽車供應鏈是 Tier2->Tier1->整車廠線性模式，但對于軟件定義汽車時代，一方面會出現新的玩家，比如互聯網公司、ICT 科技公司等，甚至出現個人開發者，另一方面整車廠按照傳統的采購和項目模式難以滿足消費者對汽車常用常新、千車千面的需求，故各企業將圍繞以消費者為中心進行產品創新、研發和供應，傳統線性模式將被打破，出現以網狀合作的形態。但如何合理分工從而優化整車研發效率和成本，成為行業發展的難題。
一、技術架構方面
1.1 軟件定義汽車技術亟待提升
面向汽車行業轉型發展，需要產業鏈中各利益相關方共同推動完成。當前，整車廠、Tier1、Tier2、ICT 科技公司等均從不同視角推出軟件定義汽車相關技術能力規劃和解決方案，技術著力點不一致，行業級技術協同方案尚未形成，如下圖所示，當前仍處于行業技術方案促動期。
圖 3-1 技術成熟度曲線
- 從整車廠視角來看
傳統“以整車硬件產品為主銷點”的技術能力逐漸轉變為“軟硬件融合，且以軟件產品為主銷點”的技術能力，需要在完成整車電子電氣架構升級的基礎上，依據研發主導程度和軟件能力兩個維度上進行技術能力規劃。
一般會形成四種模式：全棧技術布局；核心領域技術重點突破；與軟件企業戰略合作；同主流核心 Tier1 深度綁定。
因此，要形成長期清晰的軟件技術能力發展規劃、相應技術能力和軟件生態方案，都需要一定的探索論證周期。
- 從零部件供應商（Tier1/Tier2）視角來看
在“軟件定義汽車，整車架構升級”的背景下，既有的產品供應方式和技術能力存在嚴重挑戰，需要深刻調整，如何實現與盡可能多的整車廠技術方案對接，需要完成哪些關鍵技術能力儲備，需要一定的探索論證周期。
- 從 ICT 科技企業視角來看
軟件定義汽車如同是“四個輪子的智能手機”在手機端的相關成熟技術能力可直接借鑒，躍躍欲試，和其他相關方存在一定程度認知偏差和技術能力對接偏差，需要一定的探索論證周期。
軟件定義汽車剛剛在行業內達成共識，產業鏈中各利益相關方在軟件定義汽車技術能力方面仍處于探索儲備期，行業內缺少成功案例，沒有成熟經驗借鑒，大規模嘗試一旦選錯技術路徑將帶來巨大的風險。
因為產業鏈中各利益相關方基本處于同一起跑線，所以在軟件定義汽車探索中會發現很多新技術在消費電子領域成功應用過，但在車輛領域并沒有應用過。有的芯片產品規劃路線圖不滿足控制器和整車開發計劃；有的操作系統、協議棧、中間件還處于一種不成熟狀態；原有的電子電氣架構不滿足快速響應市場的需求；原有的開發流程和開發工具不滿足快速迭代的開發需求。
要解決這些問題，需要整個產業鏈，包括整車廠、零部件供應商、軟件開發商、芯片廠商、工具廠商、ICT 等企業共同努力。
1.2 定制和私有接口，造成開發低效和浪費
汽車行業自身存在的大量定制化與私有化接口，這種低效、浪費的的傳統開發模式卻還在持續。
-
軟件方面：軟件定制化將帶來大量的接口適配、驅動適配、反復標定、通信矩陣的反復調整等重復性勞動，端到端軟件開發效率低，人力資源浪費嚴重。在傳統汽車時代，這種傳統模式可以基本維持，但隨著整車智能化加快，軟件將呈現指數級的增長，軟件開發模式轉型將勢在必行。
- 硬件方面：硬件定制化導致的結果就是硬件的頻繁定制、線束定制、重復的 DV/PV、認證等，使端到端管理復雜度和成本居高不下，頻繁的產線調整導致產能浪費，型號的切換導致備件和庫存總量的線性增加等。隨著汽車智能化的發展，對硬件的要求越來越高，如果延續這種硬件定制模式，那硬件的定制工作量以及由此帶來的軟件的適配工作量是難以想象的，故這種硬件模式也亟待優化。
二、安全&隱私保護方面
2.1 安全威脅日益嚴峻
汽車生產供應鏈和制造流程復雜，需要各級的供應商配合參與，若其中有一個供應商環節出現安全隱患，就會影響到最終消費者的安全。如何構建貫穿全流程涉及研發、生產、供應鏈、銷服、消費者等多個環節的整車數字化安全防護體系是智能網聯汽車的巨大挑戰。
從汽車產業發展方向看，未來以車內網、車際網和車載移動互聯網為基礎，在 V2X 之間實現智能化交通管理、智能動態信息服務和車輛智能化控制的一體化網絡將是大趨勢。隨著智能汽車產業的發展，汽車行業將安全的范疇從功能安全延伸到網絡安全。智能網聯汽車網絡攻擊風險加劇，將對社會和生命造成安全威脅。
汽車行業安全事件頻發，整車廠越來越重視汽車網絡安全。汽車智能化程度越高，所遭受的安全攻擊面越多。在智能化背景下，全球整車廠無一幸免，例如奔馳、寶馬、奧迪、大眾、豐田、本田、現代等國際一線品牌，均遭受了不同程度的安全攻擊。數據安全對智能汽車甚至國家安全都有重要影響，未來不排除將進一步出臺更多政策規范。
2.2 網絡安全的技術挑戰
第一：智能網聯汽車的攻擊面廣
智能網聯汽車的產品形態決定了攻擊面眾多、物理暴露面巨大。僅無線接口安全就涉及到 WIFI 安全、藍牙安全、蜂窩通信安全、GNSS 安全、TPMS 安全、調頻安全等方面。在可接觸的范圍內，又有 NFC 安全、USB 安全、OBD 安全等需要考慮的暴露面。
車端 ECU 面臨的常見網絡安全風險包括：
- 車內網絡目前大多采用 CAN/CAN FD 協議進行通訊，而 CAN/CAN FD 的字節長度有限、仲裁機制、無源地址域和無認證域等問題有潛在的網絡安全隱患；
- ECU 硬件可能存在可讀絲印和暴露的調試口，容易遭受防逆向分析等安全隱患；
- ECU 固件刷寫機制未進行信息安全保護，可能導致 ECU 固件或其配置數據被篡改；
- ECU 中的敏感數據（如調校數據、虛擬鑰匙數據、地圖數據、配置數據等）的存儲、訪問過程中，若未采取加密存儲和訪問控制等防護措施，則可能導致數據被篡改或泄露，被篡改的數據可能導致系統功能偏離預期，甚至帶來其他信息安全方面的隱患。
第二：智能網聯車的漏洞更多
漏洞和缺陷多，分布在不同器件上，防不勝防。造成漏洞分布廣，數量多，隱藏性強的原因是由于隨著智能網聯車技術架構的迭代發展，軟件定義汽車概念的興起，汽車正在軟件層面被重構。
智能汽車的發展，是由智能汽車承載的應用功能發展來作為驅動力的，而且離不開電子電氣架構的發展。在未來智能汽車控制器將會承載越來越多的功能，而且不同的電子電氣架構下呈現的信息安全狀態也有所不同，同時車載控制器復雜度越來越高，逐漸趨同于 ICT 行業的高性能計算機，也可能會帶來新的信息安全威脅和攻擊手段。
以智能駕駛技術為核心驅動力的智能網聯汽車依賴大量的智能傳感器、算法、云端平臺的支撐。這些基礎設施和功能單元包含了海量的代碼以支撐運作，其中稍有一個環節出現問題，就會影響到整個鏈條的安全可靠運行。所以軟件大規模的進入車輛生產制造行業，帶來了機遇，同時也帶來了極大的安全挑戰。
2.3 法規監管要求
國內近幾年開始重視智能汽車網絡安全、數據安全、OTA 升級安全問題，在以政府引導、產業推動、標準委員會執行的模式下積極開展相關汽車安全標準制定工作。在汽車網絡安全標準研制方面已取得一定進展，如下圖所示，全國汽車標準化技術委員會（SAC/TC114）2021 年 10 月 11 日已發布《GB T 40855-2021 電動汽車遠 程服務與管理系統信息安全技術要求及試驗方法》、《GB T 40856-2021 車載信息交互系統信息安全技術要求及試驗方法》、《GB T 40857-2021 汽車網關信息安全技術要求及試驗方法》和《GB T 40861-2021 汽車信息安全通用技術要求》四項國標，并于2022 年 5 月 1 日開始實施，同時啟動國際汽車網絡 安全、升級管理的標準法規R155、R156 的國標轉化工作。
圖 3-2 汽車網絡安全標準研制成果
在數據安全方面，備受消費者和國家層面的關注。一方面，關于數據安全的法規相繼出臺，從《網絡安全法》到《數據安全法》到《個人信息保護法》，進一步規范汽車數據安全管理和網絡安全自查制度。另一方面，數據安全能力進一步聚焦，具體體現在：-
數據采集和處理過程可追溯，可審計；
-
進一步加強中國法律法規的監管要求和個人信息的處理要求；
-
進一步加強對基于密碼學的通信安全的研究和監管。
圖 3-3 汽車數據安全相關的法律法規
為支撐 2021 年 10 月 1 日發布的《汽車數據安全管理若干規定（試行）》落地實施，全國信息安全標準化技術委員會于 10 月 8 日發布技術文件 TC260-001《汽車采集數據處理安全指南》，技術文件細化了部分《規定》條款中關于汽車數據傳輸、存儲和出境等方面的要求，同時為遵循《規定》中的部分原則給出了指引。其中汽車采集數據是通過汽車傳感設備、控制單元采集的數據，以及對其進行加工后產生的數據；不包括通過其他網絡傳輸到汽車進行處理的數據，例如手機等車外設備采集的數據、汽車數據處理者通過銷售合同等線下方式收集的個人信息等。技術文件明確了汽車采集數據分為車外數據、座艙數據、運行數據和位置軌跡數據，并對不同類型的數據分別提出要求。
-
技術文件對車外數據，圍繞車外個人信息的匿名化處理、數據的最長存儲時間、數據出境等方面提出要求；
-
對座艙數據，圍繞數據向車外傳輸和數據出境等方面提出要求；
- 對位置軌跡數據，圍繞數據的最長存儲時間和數據出境等方面提出了要求。
同時，技術文件明確提出汽車制造商應對其生產的整車數據安全負責，除約束和監督零部件供應商處理汽車采集數據的行為外，還應將汽車采集數據向外傳輸的完整情況對用戶披露。
構建整車級的安全能力和機制，確保智能汽車真正讓消費者放心、安心成為發展的關鍵。而傳統功能車時代，汽車處于孤立單元，整車廠具有很強的功能安全保障機制，但基本未涉及網絡安全和隱私保護，也沒有相關應對經驗。智能汽車時代亟需構筑功能安全、網絡安全、隱私保護全方位防御護城河。
三、組織流程方面
3.1 組織架構變革
組織架構決定了產品架構，想要什么樣的系統就要搭建什么樣的團隊。目前整車廠組織架構示意圖如下所示。整車研發團隊主體是研發總部，同時在國內外設置分支機構。研發總部的機構劃分有兩個維度，一個維度是車型，根據車型劃分為乘用車、商用車、客車、新能源車等車型開發部門；另一個維度是車輛功能模塊，根據車輛功能劃分為電子電氣、發動機、變速箱、車身等總成開發部門，其中軟件開發只是隸屬于電子電氣部門之下的一個專業模塊。在軟件開發專業模塊下，發動機電控系統、變速箱電控系統、車身電控系統等控制單元是由不同專業團隊獨立開發的。
圖 3-4 整車廠組織架構示意圖
隨著軟件定義汽車時代到來，汽車電子電氣架構向“域集中”、“中央集中”方向發展，電控單元之間的界線逐步模糊化。硬件被合并，軟件運行在同一控制單元當中。原來整車廠中很多部門的邊界被打破，在向中央集中式組織架構邁進過程中，部門的邊界已經變得非常模糊。傳統的整車功能軟件是整體性、系統級的，在軟件定義汽車趨勢下，軟件架構和形態上越來越強調分層解耦、標準化、模塊化和開放性。模塊具備標準清晰的接口，模塊之間可組合擴展，且可由不同的供應商提供。層出不窮的場景會催生出新的應用，這勢必要求軟件架構具備足夠的開放性和魯棒性，面向不同的場景要能夠有高復用度、高延展性。中央計算平臺/域控制器通常采用面向服務的軟件架構進行部署，下圖為面向服務的軟件架構示意圖。
圖 3-5 面向服務的軟件架構示意圖
為此，產業鏈中各利益相關方都需要從戰略出發調整公司組織架構，建立一個自上而下驅動、基于共同戰略目標、能協調跨部門合作、平臺型的軟件組織，打破原來煙囪式的以功能模塊劃分的組織模式。在組織機構變革過程中，決策層戰略上的投入決心與定力起著至關重要的作用，如果決策層對軟件定義汽車發展趨勢缺乏判斷，那么在內部變革碰到阻力時，就會碰到很多困難，結果可能是半途而廢。
3.2 汽車軟件人才
傳統整車廠對軟件的把控能力需要進一步提高
在過去的整車開發模式中，整車廠主要負責產品的功能需求定義與驗收，供應商負責根據整車廠釋放的需求規范進行軟硬件開發與驗證，并交付給整車廠，在這個過程中整車廠很少參與零部件產品的實際開發過程，從而導致整車廠現有研發團隊相對缺乏軟件開發能力。
在中央/域集中電子電氣架構下，軟件架構的復雜度大大提升。不同功能域的軟件模型或代碼如何集成到單一的 SoC 或 MCU 上，并且進行合理的算力分配與優化，融合后的集成測試與驗證等都是汽車軟件開發人員面臨的技術挑戰。
隨著 SoC 等芯片技術的引入，許多 IT 技術領域的軟件技術將應用到汽車中，例如操作系統、SOA 中間件、AI 技術及復雜的以太網通訊協議等等，這些都對整車廠和供應商的軟件開發能力都提出了更高的要求。
傳統整車廠人才結構以機械和動力為主，目前各整車廠正積極引入軟件工程、人工智能、車聯網、自動駕駛、電子工程等復合型人才，以快速調整現有人才隊伍結構，增加軟件工程師的比例，確保企業在向軟件轉型、產品創新過程中保持競爭力。
汽車軟件人才緊缺的主要原因
汽車電子軟件開發屬于嵌入式軟件的一個分支，行業相對封閉，從業人員來源相對較窄，人員能力儲備不足，高度緊缺。
汽車工程師需要跨界，傳統的汽車電子電氣架構工程師和嵌入式軟件開發工程師主要領域是 CAN 總線通信、控制器配電和線束、車輛物理拓撲、動力、底盤、娛樂、AUTOSAR CP 等，而軟件定義汽車大趨勢下，更多的 ICT 能力需要融入，增加了以太網、TSN、SOME/IP、SOA、Linux/QNX、Hypervisor、AUTOSAR AP 等領域技能。而來自互聯網企業的軟件工程師，IT 軟件開發雖然能力強，但在汽車電子嵌入式硬件等領域，缺乏汽車工程和軟件技能。
綜上所述，行業中缺少既懂軟件又懂汽車的人才，尤其是系統架構工程師，汽車軟件工程師處于緊缺的狀態。因此，很難通過短時間集中一大批的軟件人才形成成熟的軟件開發團隊。
3.3 開發模式變革
傳統汽車的軟件開發采用 V 字形瀑布式開發模式，如下圖所示。由于各開發部分之間相對獨立，更多只是在部分內部展開局部性優化，缺乏系統級平臺級的開發全局觀，很難做到整體優化。同時各部分的開發時間都不一致，各部分之間的進度順序依賴很容易造成隊列效應，一旦出現某個部分開發發生延誤時，便會影響整體的開發進度。每個階段都過于依賴上個階段成果，導致開發成本較高且周期過長，而這些都是與“軟件定義汽車”要求整車廠必須縮短產品上市周期、產品基于消費者需求、支持不斷的迭代、對市場需求迅速響應等相矛盾。
圖 3-6 傳統 V 字瀑布式開發流程圖
在軟件定義汽車背景下，汽車軟件開發將由傳統的瀑布式開發向敏捷開發模式轉變。敏捷式開發模式既有利于達到密切的協調合作，最大限度地減少管理成本，同時因其靈活的工作模式，使開發團隊可與用戶實現高度互動，采用最低可行性產品的形式快速滿足用戶需求，并在使用中不斷創新迭代，實現持續開發、持續集成、持續交付，體現軟件定義汽車的優勢。主要體現如下：- 軟件開發流程
- 開發交付方式
隨著軟件定義汽車時代的到來，“軟硬分離，軟軟分離”逐漸成為了主旋律，嵌入式軟件從依附于硬件的一堆“代碼”真正脫胎換骨為獨立可售賣的產品；且這項產品可以在整個車輛的生命周期內持續產生價值。從嵌入式軟件開發和驗證的技術層面，這樣的趨勢使得軟件要能夠快速迭代，持續更新持續交付。
- 項目管理
面向開放架構/持續交付的軟件特性，在項目管理上，敏捷成為了關鍵詞，隨著軟件交付不再是統一固定的交付節點，軟件模塊在整個車輛生命周期都有新增的機會：模塊化軟件具備單獨交付的條件和場景，隨之而來的是軟件的設計/開發/測試/驗證的節點也隨之迭代起來，變化和持續交付是常態，這對整體的軟件項目管理提出了更高的要求。
綜上，汽車軟件開發模式由傳統的瀑布式開發向敏捷開發模式的變革，為軟件定義汽車落地面帶來巨大挑戰。
轉自汽車電子與軟件
