導讀：隨著軟件定義汽車的持續走熱，各OEM車企開始建立自己的研發創新中心，關注在軟件，人工智能，等創新研發。近在眼前的案例是，上汽集團成立上汽創新開發總院。獨立研發中心的建立，從組織授權和資金上給予了充分的保障。但是，這樣做就萬事大吉了嗎？我想，答案肯定是“No”。
今天，我們重點談談目前汽車行業面臨的痛點問題，如何進一步解決，讓軟件真正發揮其巨大潛能。
圖源：互聯網
通過對不同的汽車軟件開發者的訪談，以及軟件開發管理過程中的經驗教訓，@愛索咨詢認為，除去組織架構的獨立性之外，汽車軟件的轉型，目前還存在幾大方面的痛點亟待解決：
1、文化思想層面的沖突
2、人員技能的轉型
3、內部流程制度的升級
4、成本管理的轉變
一、文化思想層面沖突
一百多年的汽車工業史，將汽車打造成了高度模塊化的集成。汽車結構與機械工程師，窮盡力量確保車內不同的零部件做到最大程度解耦，保持其獨立性。但是，“成也蕭何，敗亦蕭何”，高度模塊化為并行工程及外包奠定了厚實的基礎，但也導致了OEM主機廠更多關注在產品定義，造型設計，產品組裝集成和品牌宣傳上。而大量的工程、開發和制造工作，都交給了供應商來做。但是，當大量的零部件及軟件產品是來自內部開發團隊時，傳統的工作思維將面臨諸多新的挑戰：
1、“甲方爸爸思維”與生態管理思維的轉換
在多年的供應商管理過程中形成的“甲方思維”又將如何適應新的情況呢？隨著軟件在整車的比重和重要性的擴大，傳統的客戶供應商關系將會演變為生態合作伙伴（如車聯網的各種生態公司），軟件平臺供應商（如自動駕駛平臺提供商），等等。這些轉變，對傳統的供應鏈體系都將帶來很大的沖擊，需要思維上的轉變。發生在2021年的汽車芯片危機，現在還在延續的，而這，就是對傳統的供應商管理體系考驗的試金石。其次，隨著OEM主機廠內部研發的建立和自主研發的起步，傳統的，管理供應商的方法將很難套用到內部團隊管理上。“甲方爸爸”的管理思維會加劇內部的沖突。需要對外、對內兩種不同的管理方式和理念，而這需要時間來磨合并消化。
下圖展示了未來智能車的生態場景。面向未來的智能駕駛，更多的互聯網內容提供商（ISP）會成為汽車企業的重要生態合作伙伴，因為他們同時面對C端用戶（手機或PC端），又面對車廠（車端），所以，既不是傳統的供應商，又不是完全松散的“路人甲”。對于生態合作伙伴的管理，需要新的創新思維與方法。
2、 “零部件管理”的思維與系統和功能導向的場景的解決方案思維轉換
與硬件相比較，軟件是無形的，抽象的。在傳統的零部件開發中，軟件是嵌入到硬件實體里而不可見的，OEM主機廠更多關注的是零部件如何與整車適配在一起。而各個零部件的開發是獨立的，相互之間的接口協調更多的是通過基于控制信號的整車物理通信網絡實現。
與之相對應的是，系統與軟件的開發，則是從客戶需求的功能場景出發。下圖2展示了典型的V2X的應用場景，需要各個ECU零部件相互協調，通過SOA的架構，形成有機整體。所以，客戶場景與市場的需求，需要的是跨場景的解決方案，更多的生態伙伴的參與。從基礎網絡設施提供商，城市大腦方案商，基礎公共實施方案商到云端平臺服務商，生態內容提供商，都考驗著汽車企業的方案設計與整合能力。
圖2源：信息通信網
3、“硬件開發管理”與“軟件開發管理”的思維轉換
零部件的管理，是通過嚴苛的質量閥門的管理，供應商交付的零部件產品（軟件+硬件）將會被組裝到整車上，其生產過程，版本和發布是嚴格計劃管控的。但軟件產品卻可以做到“柔性生產”。每天甚至每小時“生產”，隨時隨地發布，更新替代。版本和功能的多樣性，硬件的依賴關系，等，都帶來與零部件開發管理不一樣的技能和思維挑戰（下圖）。
硬件產品開發過程中，很多依賴是無法調和的，例如，如果芯片沒有，開發工程師就無法完成電路板的焊接。但是，對于“柔性”的軟件，很多依賴卻可以找到不同的變通方法，未必是“Hard Dependency”。這需要管理層的敏捷性（Agility）以及經驗的積累，團隊的精誠合作。
4、“硬件產品管理”與“軟件產品管理”的思維轉換
硬件產品的“剛性”與軟件產品的“柔性”，決定了二者存在不同的產品策略。未來趨勢的判斷，隨著技術大鱷的參與，硬件會逐步標準化，通用化；而軟件的柔性卻會因主機廠的不同，客戶及市場的需求不同，展現了其多樣性，成為未來競爭的戰略要地。但正是這種柔性，也必將給OEM主機廠的各個職能系統，如生產制造系統，財務系統，采購系統，質量管理系統，技術中心，甚至人力資源部門帶來思維的沖擊與變革。這里簡單摘取兩點進行描述。
從產品的可靠性來看，硬件產品通常存在“浴盆曲線”（見下圖），但作為軟件產品，卻是不同的可靠性曲線。隨著軟件產品的獨立發布與演進，軟、硬件產品的質量管理將出現不同的方向和手段。
硬件產品的生命周期與軟件產品呈現不同的形態 – 硬件產品一旦裝配，將伴隨著車輛10~15年而不可更改。如有問題，只能是“召回”，無論是物理召回或返回4S店維修。但軟件產品卻是“發布”和“更新”。現代互聯網的ICT技術，支持了遠程OTA。在整輛車的生命周期內，將會出現多輪新功能的迭代（下圖）。
軟硬件的解耦，形成獨立的產品路線圖（Roadmap）；而獨立演進，導致產品生命周期的不同，演化為不同的思路：硬件產品的標準化，通用；軟件產品的多樣化。這必將產生新的問題，如軟硬件兼容性的問題，后向兼容等，這都是對傳統零部件產品管理的思維挑戰。而這點，也同樣沖擊著OEM主機廠的生產制造系統 – 是要求軟件功能面面俱到還是“最小可靠”軟件？OEM主機廠的財務系統，如何更好地定義及使用軟件資本？
5、“硬件成本”的管理思維與全生命周期成本的思維轉換
傳統上，OEM主機廠更關注的是零部件的成本（Per Unit Cost），軟件開發成本更多地是分攤到零部件上。
當面對軟件供應商提供的軟件產品，Unit Cost又將如何定價，又如何轉化為可盈利的軟件商業模式呢？同樣，如果是內部開發的軟件產品，開發成本如何攤銷？軟件資本如何合理配置？因為軟件是“柔性”的，當管理不善，軟件的開發成本將大大超過了零部件硬件成本的節省。
BMW公司的Christian Salzmann曾經提供過一組數據：對于每年需求量為500K的一款ECU，如果每年降低硬件成本20Euro每件，在7年的生產周期內，共計可以節省70MEuro。但是，如果軟件開發沒有做到更好的重用，卻會浪費額外的100MEuro。
另外，“開源節流”，傳統的硬件成本的管理模式關注的是“節流”。但是，作為前車之鑒的ICT行業，如摩托羅拉，諾基亞，蘋果公司，汽車界的“鯰魚”（見上圖6），特斯拉，他們的軟件銷售卻打開了一扇“開源”的窗戶，通過硬件的預留，雖然短期內硬件成本上升了，但是，通過軟件的OTA迭代升級，卻創造了更大的銷售收入。這種全生命周期的成本考核，是對傳統汽車人的新的思維和管理體制上的挑戰。
二、人才技能轉型
汽車軟件相對而言是復雜的，并且是分布式部署的。其應用領域，覆蓋了從車機娛樂軟件到安全實時控制軟件，跨度大且分散。根據其應用領域及對安全實時性要求來劃分，汽車軟件可以概括為這些領域（如下圖示例）：
車內多媒體及HMI相關的軟件開發。這部分通常對實時性要求不高，也是目前車聯網軟件的重點域；
車內智能駕艙相關的語音識別，手勢識別等AI軟件。這部分通常對實時性要求不高，更多的是基于事件的處理，部件之間的通信是通過服務請求與反饋的形式實現；
車輛底盤、動力控制，車內通信等相關的軟件及算法。這部分通常對實時性和安全要求高，需要非常高的可靠性。部件之間的通信是基于信號的控制來實現；
車內與自動駕駛相關軟件，如ADAS， AVP等。這部分通常對實時性要求高，需要安全設計的考慮；同時，對算力有更高的要求，需要高性能的處理器來滿足系統功能的要求；
云端軟件及移動通信基礎架構：這部分通常不依賴于具體的硬件，根據應用場景，對實時性要求各不相同。同時，通信網絡的開放，對信息安全的要求日益苛刻。
圖源：瑞薩網站
通過上述簡單的軟件劃分，我們可以分析：
和整個汽車軟件關系最大的，可能就是OEM主機廠的電子電氣架構部門。但是，觀察一下各大車企技術中心、研究院的負責人，基本都是傳統底盤、發動機等領域出身。他們對智能駕艙，自動駕駛和云端及移動通信，以及信息安全的知識短板需要補足（見下圖）。
圖源：QNX網站
目前，OEM主機廠基本是提供類似“Black Box”的零部件規格（SOR或RFQ），具體的實現和技術上的Know-how，基本上都掌握在供應商手里。
如圖9所示，是來自OEM主機廠的典型VDC （Vehicle Dynamic Control）子系統功能規格書，除了這種黑盒的接口定義，軟件與硬件的實現，基本掌握在供應商手中。所以，傳統汽車產業鏈當中，對軟件了解最多的，應該是Tier1供應商中的汽車電子軟件部門。而知識產權從供應商手里轉移到汽車OEM開發人員手里，幾乎是不可能的。尤其是，傳統上的汽車OEM企業，基本不會為軟件開發單獨支付NRE成本 （某種意義上講，就是“白嫖”）。所以，要獲得這部分知識產權，更是難上加難。
受限于整個行業的發展趨勢，汽車電子軟件的主流開發大部分還局限在微控制器（MCU）層面。最近五、六年，隨著車聯網和自動駕駛的發展，逐步轉向了基于ARM的SOC平臺，多核的芯片處理器。
目前汽車行業的從業人員，基本是利用基于AUTOSAR的自動代碼生成工具，如Etas， Mentor Graphic， EB Tresos等，通過圖形化的界面配置應用程序，自動產生代碼。但是，隨著自動駕駛，智能駕艙的新功能出現，汽車對算力的要求越來越高，分層的軟件架構，操作系統和高性能SOC平臺的采用成為常態。之前的開發工具鏈開始面臨挑戰，新的工具鏈還不成熟。這對于傳統汽車行業軟件從業人員，將是新的挑戰。多年使用類似于AUTOSAR CP的工具鏈，已經讓大部分汽車軟件開發人員淪為了簡單的配置工程師，逐步喪失了底層軟件0到1的開發能力； 對底層芯片的理解更是捉襟見肘。這種挑戰將觸及靈魂。缺少必要的，成熟工具鏈來支撐代碼的自動生成與測試，將會產生發自內心深處的焦慮感。
下圖是節選自互聯網的一張HPC的系統架構圖。復雜的系統結構，對傳統ECU的從業人員的挑戰是巨大的。代碼運行從傳統的單核到現在的多核，如何合理地，動態分配資源而不是之前的靜態資源分配，都對傳統汽車電子軟件開發人員帶來挑戰與技能的轉型。
圖源：互聯網
汽車電子軟件屬于嵌入式軟件開發范疇，是在專用計算機系統上進行軟件開發，一般要求開發人員具有一定的硬件基礎。主流的嵌入式平臺包含ARM、DSP、FPGA等，開發語言主要是匯編/C/C++。
相對應的是，IT與互聯網大部分的軟件開發人員，都屬于在通用計算機系統上的軟件開發，一般是在某種操作系統上，如Windows，Linux，Android，IOS等，進行應用軟件開發，主要包含電腦端，手機端，服務器端等設備，以X86與ARM架構為主。大部分開發人員都會使用某種高級語言，如C++，JAVA，JS，PYTHON，MySQL，等，進行特定任務的開發。
但是，對來自汽車產業外部的互聯網開發人員，雖然人數巨大（據估計，有100萬的從業人員），但如果從事汽車電子軟件的開發，卻需要了解整車架構及汽車本身的know-how（下圖）。這個限制了互聯網軟件開發人員的選擇。
ICT行業與智能硬件的公司，以及芯片公司，也培養了大量的通信精英（移動通信，Wifi，Ethernet 等）和底層BSP或Firmware固件開發團隊，他們屬于軟件團隊中最懂電子硬件的人。這部分人將是汽車電子軟件開發的最佳人選。但是，對整車架構和汽車本身的know-how的理解（圖11），也同樣限制了這部分嵌入式軟件開發人員能夠快速上手。
復雜的整車架構，需要多年的知識沉淀與積累 圖源：互聯網
AI智能的發展，互聯網公司培養了大量的算法人員(圖像/語音/數據）。開放的互聯網精神，也培養了一批技術深厚的信息安全團隊。而應用軟件的多樣化和成熟的C/S框架，如Restful，RCP等，也練就了一批優秀的前端和后端開發人員。因其更多的獨立于具體的硬件，或者傾向于云端和熟悉的PC及移動端打交道，切換成本會很少。這部分人才是實現車聯網的云端軟件，以及大數據分析的專業人才。當然，對于整車的架構，汽車產業法令、法規的了解以及B端市場的規律，仍然需要一定時間的磨合與歷練。
三、管理流程升級
百年的汽車工業開發，形成自己特色的，基于質量閥門的整車開發流程。通過這種流程，把OEM主機廠和其Tier1，Tier2供應商密切地聯系在一起，形成有機的開發整體。但是，隨著基于功能和場景的解決方案逐步發展，軟件占據主導地位，現有的OEM開發流程卻不能很好地適應軟件系統與軟件工程，流程面臨巨大的挑戰，需要全方位的系統建設。這種流程的系統化建設，需要流程的架構與設計，它涵蓋了組織制度，角色和職責等維度：
1、需求管理流程
傳統的開發模式是OEM主機廠負責系統和子系統的功能及接口定義。但是，很多子系統的劃分是根據物理的機械件（ECU）及接口進行了劃分，相應的負責工程師也跟隨相應的硬件耕耘多年，形成自己的專業know-how；但是，專業化的分工，形成“I”字型的知識架構。不同的零部件之間的技術壁壘逐步產生，甚至各自為政，“老死不相往來”。問題是，如下圖所示，基于場景的需求開發需要多個子系統的聯動；需要“T”字型的知識架構。如何分解需求；如何進行需求管理；分層管理；如何做到需求的重用；如何減少各功能之間的依賴，都對原有的流程產生新的挑戰。
汽車OTA功能的實現，如何管理汽車上市后的OTA功能與需求，如何連接運營，4S售后服務等功能需求，如何隨時提供云端服務功能，都需要對原有基于零部件開發的流程進行改造。
智能汽車功能需求
2、架構設計與接口定義流程
汽車工業的傳統模式，軟件的know-how 基本被有實力的供應商把控，具體的軟件實現，接口定義，對OEM是不可見的。所以，如何確保不同的ECU軟件有機結合，協調實現必要的場景，相應的工作機制需要建立。
而車、管、端三位一體的未來發展方向，三者的聯動的架構設計，同樣需要合理的流程機制來保障。伴隨著SOA架構的逐步實現和車內通信線路的以太網化，接口的定義將逐步從基于信號的定義或者簡單的消息結構的定義C/S模式轉向更復雜的SOA架構與接口定義（如下圖所示）。當沖突發生，需要相應的技術仲裁流程進行合理評估。
接口定義將由簡單的C/S模式向更復雜的接口定義演進
3、代碼與集成流程
汽車的造型設計形成不同的車型及零部件的Fit和Form。傳統的零部件開發模式，不同Fit的零部件的軟件代碼各不相同。如何有效地重用代碼；如何構建軟件架構平臺；如何將不同代碼集成在一起，成為新的挑戰。需要新的流程來確保軟件代碼的重用性及軟硬件的集成。
4、產品與項目管理流程
傳統的零部件產品與項目常常合二為一。一旦硬件最終認可，軟件將隨之凍結，直至生命周期的終結。但是，智能車的軟件產品卻可以隨時增加新的功能，形成新的版本，通過遠程OTA進行更新。可以想象，未來同一款硬件，將會預裝不同的軟件版本，在市場上銷售。如何管理客戶車輛的軟件版本，如何管理軟件的兼容性，等等，需要新的流程改造。而項目管理，如下圖所示，可能會以軟件開發管理為主，在硬件產品的生命周期內，通過項目的模式組織軟件的交付。
5、售后服務的流程
隨著軟件遠程診斷的開啟，以及AI及IOT技術的落地，基于數據的售后服務體系終將建立。傳統的4S服務的模式將逐步轉移到線上。如下圖所示的遠程服務體系的場景將成為常態，相應的流程體系的改造也勢在必行。多生態合作伙伴的介入，如何管理端到端的場景解決方案，提供更高的服務質量，都是OEM主機廠面臨的問題。
復雜的智能汽車場景
6、開發工具鏈的挑戰
各種自動駕駛，人工智能，軟件算法，云端軟件的開發訴求，將會促使新的開發工具鏈。或者傳統的工具鏈進行演化，如基于AUTOSAR CP開發的工具鏈將進一步進化為AUTOSAR AP等（見下圖）。而流程的優化和改造，同樣需要類似JIRA，禪道，Synopsys，RobertFramework之類的軟件開發測試驗證等工具鏈的引進。
AUTOSAR工具鏈 圖片源自CSDN
四、成本管控方式轉變
做過汽車Tier1供應商的小伙伴，我相信都經歷過那種血淋淋的汽車零部件的商務報價過程 – “沒有最低，只有更低”。最后的后果，不管你是否相信，會是產品質量的喪失。這從一個維度，充分反映了目前傳統OEM主機廠的思維定式：一輛汽車的功能決策，更取決于零部件的價格。在過去以機械結構為主的汽車中，這個做法可以理解。但是，隨著軟件驅動汽車的發展，如前面幾篇文章所述，全生命周期的成本的權重要遠大于目前單件成本的爭奪。對比來看，在新勢力造車的蔚小理中，交付讓消費者眼前一亮的功能卻被視為更為重要的決策依據。
在零部件采購中，這種“砍到骨頭”的低價策略，會帶來負面影響。工程師們，不管是來自供應商或者OEM主機廠，會不斷地降低處理器的算力，內存，通信帶寬等關鍵計算資源，從而降低硬件成本。如此一來，卻對軟件帶來根本的損害及不可預測的后果：
軟件工程師們將不得不優化軟件代碼，以適應有限的計算資源。但因為系統的復雜性，這樣的后果是，在未來的性能測試中發現各種莫名其妙的問題，導致很難查找根本原因，從而增加了工程成本，甚至延誤了產品的上市周期。另一方面，盡管沒有找到問題的根源，迫于項目的進度，工程師們也是“拆東墻補西墻”，采用臨時方案應對項目的交付，為量產后的產品質量種下隱患，增加了售后服務的成本。
軟件工程師不得不壓縮他們的代碼，確保其足夠的小，可以被調入有限的內存運行。代碼要足夠地精簡，確保內存的每一位（Bit）都能被充分利用。如此一來，任何新功能的增加將變得幾乎不可能。更有甚者，甚至缺陷的修復也將無從下手，而不得不進行硬件的召回。這些，在增加了工程師成本同時，進一步加劇了公司的售后服務成本，消減了公司的軟件銷售收入來源。
由于代碼的過度優化，會導致后期的代碼維護尤其困難。復雜的語句，讓后期維護人員不敢有絲毫的觸碰。對代碼的修改成為每個人心中的噩夢。
過度精簡代碼，將會很難做到代碼的重用及其可移植性。也無法做到功能的預埋。如此一來，唯一的途徑是通過OTA進行從上到下的固件和應用軟件的更新。從客戶成本的角度，浪費了客戶的時間，增加了流量成本。從業務的角度，增加了內部的運營成本及軟件工程成本。
全生命周期成本
這里，我們并不是強調傳統的Cost Per Unit的成本管控不重要。我們強調的是全生命周期的成本概念。如圖17所示。所以，在評估零部件的單件成本時，除了零部件相關成本之外，必須考慮其帶來的項目延遲風險，產品上市窗口，工程成本，調試成本，售后服務成本，代碼復用以及未來新的銷售收入增長的機會成本。
消費者需求的多樣性和定制化的訴求，驅使主機廠在配置上形成不同的配置版本，產生不同的汽車Variant。以“簡單的動力系統控制的應用功能來講，會有3488中不同功能配置”（注：來自Manfred Broy）。而目前的奢華車，基本配備120個左右的ECU，簡單的“有”或“沒有”的配置，會有2120種Variants，供消費者選擇。除了市場和用戶的驅使，在整車長達10~15年的生命周期內，各種小改款，中期改款，大改款，VAVE層出不窮，同樣結構的ECU，會有不同的FIT，FORM，也可能預裝了不同的軟件版本。如此眾多的Variant，需要巨大的驗證與確認工作，必將產生龐大的汽車工程成本。同樣，龐大的汽車Variant，也對售后服務的備件，服務技能和召回預算形成巨大的壓力 。
汽車行業的“賴特定律”（注：萊特定律由美國航空工程師西奧多·賴特在1936年提出，他將制造效率和制造經驗聯系起來，其核心是每生產一定單位的產品，其制造成本將下降恒定的百分比）指出，“單個型號的汽車產量每累計增加一倍，成本的價格就會下降15%”。這終將會驅動硬件的標準化，降低汽車的Variants，從而降低汽車工程成本；功能的差異化實現，則更多地通過軟件來競爭。
某品牌汽車OTA升級新聞
然而汽車軟件帶來的成本增加，將越來越顯現。如何管控軟件的劣質質量成本，將成為擺在每一位汽車從業人員面前的一道關卡。圖18是關于某品牌汽車的OTA升級的一則新聞（德國《汽車與體育》(Auto Motor und Sport) 報道），12小時的升級過程，7.5小時的軟件安裝過程。按4G網速計算，升級包高達30G，單車流量費將高達三位數。更令人大跌眼鏡的是，電池電量居然被耗光，這讓消費者情何以堪？
汽車工程成本的另一個維度，是汽車軟件的Variant。傳統的ECU零部件，在整車的生命周期內，會有不同的FITs，Form等。但是，不同外觀尺寸的ECU與ECU之間的軟件差異可能不超過10%。不幸的是，因為軟件的不重用性以及單位硬件成本的管控理念、采購理念，導致軟件很難從一個ECU很快地移植到另一個ECU。這使得大部分軟件不得不被重寫（據德國汽車工業提供的數據，大部分軟件的改動其實只有10%的差異性。）。隨著車子智能化的發展，底層硬件的通用化，軟件重用的趨勢是必然。如此一來，軟件產品的觀念（見下圖示例圖）急需在整車廠建立并實踐。
軟件產品概念示意圖
五、寫在最后
SDV,軟件驅動汽車，毋庸置疑，已經是實實在地擺在每一個組織，每一位汽車從業人員面前的課題。盡管汽車軟件，相對硬件而言，體量仍然渺小，其在成長的道路上需要“水”，“土壤”和“陽光”，需要企業管理者和每一個汽車從業人員的愛護和澆灌。但是，面對這個汽車產業這個百年未有之大變局，軟件必將撬動整個汽車的產業鏈，在汽車生命周期的各個環節，如下圖所示，產生新的價值，驅動創新與再造。
汽車生命周期生態鏈
在這個過程中，覺醒的OEM開始與外部公司合作，例如零束汽車軟件與愛索管理咨詢的云端發布DevOPS改造；極氪汽車的整車流程優化、再造，軟件審核等。這些都是順應軟件驅動汽車之大變局，通過廣泛的生態連接，構建健康的軟件生態鏈；另一方面，也正反映了企業開始正視面臨的問題，通過價值洞察，積極推進組織變革，思維變革，技術know-how, 人才儲備以及流程制度的建設。
只有這樣，才能構建軟硬融合的產業生態，讓智能汽車，乃至自動駕駛技術越走越遠。
來源：汽車電子與軟件 ，作者宋濤
