隨著軟件定義汽車的持續(xù)走熱，各OEM車企開始建立自己的研發(fā)創(chuàng)新中心，關(guān)注在軟件，人工智能，等創(chuàng)新研發(fā)。近在眼前的案例是，上汽集團成立上汽創(chuàng)新開發(fā)總院。獨立研發(fā)中心的建立，從組織授權(quán)和資金上給予了充分的保障。但是，這樣做就萬事大吉了嗎？我想，答案肯定是“No”

之前的系列文章，我們描述了什么是SDV，澄清了SDV的歷史淵源以及對SDV的一些誤解，并提出了軟件驅(qū)動汽車的概念 。

今天，我們重點談談目前汽車行業(yè)面臨的痛點問題，如何進一步解決，讓軟件真正發(fā)揮其巨大潛能。

通過對不同的汽車軟件開發(fā)者的訪談，以及軟件開發(fā)管理過程中的經(jīng)驗教訓，@愛索咨詢認為，除去組織架構(gòu)的獨立性之外，汽車軟件的轉(zhuǎn)型，目前還存在幾大方面的痛點亟待解決：

1、文化思想層面的沖突

2、人員技能的轉(zhuǎn)型

3、內(nèi)部流程制度的升級

4、成本管理的轉(zhuǎn)變

1.

文化思想層面沖突

一百多年的汽車工業(yè)史，將汽車打造成了高度模塊化的集成。汽車結(jié)構(gòu)與機械工程師，窮盡力量確保車內(nèi)不同的零部件做到最大程度解耦，保持其獨立性。但是，“成也蕭何，敗亦蕭何”，高度模塊化為并行工程及外包奠定了厚實的基礎(chǔ)，但也導致了OEM主機廠更多關(guān)注在產(chǎn)品定義，造型設(shè)計，產(chǎn)品組裝集成和品牌宣傳上。而大量的工程、開發(fā)和制造工作，都交給了供應商來做。

但是，當大量的零部件及軟件產(chǎn)品是來自內(nèi)部開發(fā)團隊時，傳統(tǒng)的工作思維將面臨諸多新的挑戰(zhàn)：

“甲方爸爸思維”與生態(tài)管理思維的轉(zhuǎn)換

在多年的供應商管理過程中形成的“甲方思維”又將如何適應新的情況呢？隨著軟件在整車的比重和重要性的擴大，傳統(tǒng)的客戶供應商關(guān)系將會演變?yōu)樯鷳B(tài)合作伙伴（如車聯(lián)網(wǎng)的各種生態(tài)公司），軟件平臺供應商（如自動駕駛平臺提供商），等等。這些轉(zhuǎn)變，對傳統(tǒng)的供應鏈體系都將帶來很大的沖擊，需要思維上的轉(zhuǎn)變。發(fā)生在2021年的汽車芯片危機，現(xiàn)在還在延續(xù)的，而這，就是對傳統(tǒng)的供應商管理體系考驗的試金石。其次，隨著OEM主機廠內(nèi)部研發(fā)的建立和自主研發(fā)的起步，傳統(tǒng)的，管理供應商的方法將很難套用到內(nèi)部團隊管理上。“甲方爸爸”的管理思維會加劇內(nèi)部的沖突。需要對外、對內(nèi)兩種不同的管理方式和理念，而這需要時間來磨合并消化。

下圖1展示了未來智能車的生態(tài)場景。面向未來的智能駕駛，更多的互聯(lián)網(wǎng)內(nèi)容提供商（ISP）會成為汽車企業(yè)的重要生態(tài)合作伙伴，因為他們同時面對C端用戶（手機或PC端），又面對車廠（車端），所以，既不是傳統(tǒng)的供應商，又不是完全松散的“路人甲”。對于生態(tài)合作伙伴的管理，需要新的創(chuàng)新思維與方法。

“零部件管理”的思維與系統(tǒng)和功能導向的場景的解決方案思維轉(zhuǎn)換

與硬件相比較，軟件是無形的，抽象的。在傳統(tǒng)的零部件開發(fā)中，軟件是嵌入到硬件實體里而不可見的，OEM主機廠更多關(guān)注的是零部件如何與整車適配在一起。而各個零部件的開發(fā)是獨立的，相互之間的接口協(xié)調(diào)更多的是通過基于控制信號的整車物理通信網(wǎng)絡(luò)實現(xiàn)。

與之相對應的是，系統(tǒng)與軟件的開發(fā)，則是從客戶需求的功能場景出發(fā)。下圖2展示了典型的V2X的應用場景，需要各個ECU零部件相互協(xié)調(diào)，通過SOA的架構(gòu)，形成有機整體。所以，客戶場景與市場的需求，需要的是跨場景的解決方案，更多的生態(tài)伙伴的參與。從基礎(chǔ)網(wǎng)絡(luò)設(shè)施提供商，城市大腦方案商，基礎(chǔ)公共實施方案商到云端平臺服務商，生態(tài)內(nèi)容提供商，都考驗著汽車企業(yè)的方案設(shè)計與整合能力。

“硬件開發(fā)管理”與“軟件開發(fā)管理”的思維轉(zhuǎn)換

零部件的管理，是通過嚴苛的質(zhì)量閥門的管理，供應商交付的零部件產(chǎn)品（軟件+硬件）將會被組裝到整車上，其生產(chǎn)過程，版本和發(fā)布是嚴格計劃管控的。但軟件產(chǎn)品卻可以做到“柔性生產(chǎn)”。每天甚至每小時“生產(chǎn)”，隨時隨地發(fā)布，更新替代。版本和功能的多樣性，硬件的依賴關(guān)系，等，都帶來與零部件開發(fā)管理不一樣的技能和思維挑戰(zhàn)。

硬件產(chǎn)品開發(fā)過程中，很多依賴是無法調(diào)和的，例如，如果芯片沒有，開發(fā)工程師就無法完成電路板的焊接。但是，對于“柔性”的軟件，很多依賴卻可以找到不同的變通方法，未必是“Hard Dependency”。這需要管理層的敏捷性（Agility）以及經(jīng)驗的積累，團隊的精誠合作。

“硬件產(chǎn)品管理”與“軟件產(chǎn)品管理”的思維轉(zhuǎn)換

硬件產(chǎn)品的“剛性”與軟件產(chǎn)品的“柔性”，決定了二者存在不同的產(chǎn)品策略。未來趨勢的判斷，隨著技術(shù)大鱷的參與，硬件會逐步標準化，通用化；而軟件的柔性卻會因主機廠的不同，客戶及市場的需求不同，展現(xiàn)了其多樣性，成為未來競爭的戰(zhàn)略要地。但正是這種柔性，也必將給OEM主機廠的各個職能系統(tǒng)，如生產(chǎn)制造系統(tǒng)，財務系統(tǒng)，采購系統(tǒng)，質(zhì)量管理系統(tǒng)，技術(shù)中心，甚至人力資源部門帶來思維的沖擊與變革。這里簡單摘取兩點進行描述。

從產(chǎn)品的可靠性來看，硬件產(chǎn)品通常存在“浴盆曲線”，但作為軟件產(chǎn)品，卻是不同的可靠性曲線。隨著軟件產(chǎn)品的獨立發(fā)布與演進，軟、硬件產(chǎn)品的質(zhì)量管理將出現(xiàn)不同的方向和手段。

硬件產(chǎn)品的生命周期與軟件產(chǎn)品呈現(xiàn)不同的形態(tài) – 硬件產(chǎn)品一旦裝配，將伴隨著車輛10~15年而不可更改。如有問題，只能是“召回”，無論是物理召回或返回4S店維修。但軟件產(chǎn)品卻是“發(fā)布”和“更新”?，F(xiàn)代互聯(lián)網(wǎng)的ICT技術(shù)，支持了遠程OTA。在整輛車的生命周期內(nèi)，將會出現(xiàn)多輪新功能的迭代。

軟硬件的解耦，形成獨立的產(chǎn)品路線圖（Roadmap）；而獨立演進，導致產(chǎn)品生命周期的不同，演化為不同的思路：硬件產(chǎn)品的標準化，通用；軟件產(chǎn)品的多樣化。這必將產(chǎn)生新的問題，如軟硬件兼容性的問題，后向兼容等，這都是對傳統(tǒng)零部件產(chǎn)品管理的思維挑戰(zhàn)。而這點，也同樣沖擊著OEM主機廠的生產(chǎn)制造系統(tǒng) – 是要求軟件功能面面俱到還是“最小可靠”軟件？OEM主機廠的財務系統(tǒng)，如何更好地定義及使用軟件資本？

“硬件成本”的管理思維與全生命周期成本的思維轉(zhuǎn)換

傳統(tǒng)上，OEM主機廠更關(guān)注的是零部件的成本（Per Unit Cost），軟件開發(fā)成本更多地是分攤到零部件上。

當面對軟件供應商提供的軟件產(chǎn)品，Unit Cost又將如何定價，又如何轉(zhuǎn)化為可盈利的軟件商業(yè)模式呢？同樣，如果是內(nèi)部開發(fā)的軟件產(chǎn)品，開發(fā)成本如何攤銷？軟件資本如何合理配置？因為軟件是“柔性”的，當管理不善，軟件的開發(fā)成本將大大超過了零部件硬件成本的節(jié)省。

BMW公司的Christian Salzmann曾經(jīng)提供過一組數(shù)據(jù)：對于每年需求量為500K的一款ECU，如果每年降低硬件成本20Euro每件，在7年的生產(chǎn)周期內(nèi)，共計可以節(jié)省70MEuro。但是，如果軟件開發(fā)沒有做到更好的重用，卻會浪費額外的100MEuro。

另外，“開源節(jié)流”，傳統(tǒng)的硬件成本的管理模式關(guān)注的是“節(jié)流”。但是，作為前車之鑒的ICT行業(yè)，如摩托羅拉，諾基亞，蘋果公司，汽車界的“鯰魚”（見上圖6），特斯拉，他們的軟件銷售卻打開了一扇“開源”的窗戶，通過硬件的預留，雖然短期內(nèi)硬件成本上升了，但是，通過軟件的OTA迭代升級，卻創(chuàng)造了更大的銷售收入。這種全生命周期的成本考核，是對傳統(tǒng)汽車人的新的思維和管理體制上的挑戰(zhàn)。

2.

人才技能轉(zhuǎn)型

汽車軟件相對而言是復雜的，并且是分布式部署的。其應用領(lǐng)域，覆蓋了從車機娛樂軟件到安全實時控制軟件，跨度大且分散。根據(jù)其應用領(lǐng)域及對安全實時性要求來劃分，汽車軟件可以概括為這些領(lǐng)域（如圖7示例）：

車內(nèi)多媒體及HMI相關(guān)的軟件開發(fā)。這部分通常對實時性要求不高，也是目前車聯(lián)網(wǎng)軟件的重點域

車內(nèi)智能駕艙相關(guān)的語音識別，手勢識別等AI軟件。這部分通常對實時性要求不高，更多的是基于事件的處理，部件之間的通信是通過服務請求與反饋的形式實現(xiàn)

車輛底盤、動力控制，車內(nèi)通信等相關(guān)的軟件及算法。這部分通常對實時性和安全要求高，需要非常高的可靠性。部件之間的通信是基于信號的控制來實現(xiàn)

車內(nèi)與自動駕駛相關(guān)軟件，如ADAS， AVP等。這部分通常對實時性要求高，需要安全設(shè)計的考慮；同時，對算力有更高的要求，需要高性能的處理器來滿足系統(tǒng)功能的要求

云端軟件及移動通信基礎(chǔ)架構(gòu)：這部分通常不依賴于具體的硬件，根據(jù)應用場景，對實時性要求各不相同。同時，通信網(wǎng)絡(luò)的開放，對信息安全的要求日益苛刻。

圖源：瑞薩網(wǎng)站

通過上述簡單的軟件劃分，我們可以分析：

和整個汽車軟件關(guān)系最大的，可能就是OEM主機廠的電子電氣架構(gòu)部門。但是，觀察一下各大車企技術(shù)中心、研究院的負責人，基本都是傳統(tǒng)底盤、發(fā)動機等領(lǐng)域出身。他們對智能駕艙，自動駕駛和云端及移動通信，以及信息安全的知識短板需要補足（見圖8）。

圖源：QNX網(wǎng)站

目前，OEM主機廠基本是提供類似“Black Box”的零部件規(guī)格（SOR或RFQ），具體的實現(xiàn)和技術(shù)上的Know-how，基本上都掌握在供應商手里。

如圖9所示，是來自O(shè)EM主機廠的典型VDC （Vehicle Dynamic Control）子系統(tǒng)功能規(guī)格書，除了這種黑盒的接口定義，軟件與硬件的實現(xiàn)，基本掌握在供應商手中。所以，傳統(tǒng)汽車產(chǎn)業(yè)鏈當中，對軟件了解最多的，應該是Tier1供應商中的汽車電子軟件部門。而知識產(chǎn)權(quán)從供應商手里轉(zhuǎn)移到汽車OEM開發(fā)人員手里，幾乎是不可能的。尤其是，傳統(tǒng)上的汽車OEM企業(yè)，基本不會為軟件開發(fā)單獨支付NRE成本 （某種意義上講，就是“白嫖”）。所以，要獲得這部分知識產(chǎn)權(quán)，更是難上加難。

受限于整個行業(yè)的發(fā)展趨勢，汽車電子軟件的主流開發(fā)大部分還局限在微控制器（MCU）層面。最近五、六年，隨著車聯(lián)網(wǎng)和自動駕駛的發(fā)展，逐步轉(zhuǎn)向了基于ARM的SOC平臺，多核的芯片處理器。

目前汽車行業(yè)的從業(yè)人員，基本是利用基于AUTOSAR的自動代碼生成工具，如Etas， Mentor Graphic， EB Tresos等，通過圖形化的界面配置應用程序，自動產(chǎn)生代碼。但是，隨著自動駕駛，智能駕艙的新功能出現(xiàn)，汽車對算力的要求越來越高，分層的軟件架構(gòu)，操作系統(tǒng)和高性能SOC平臺的采用成為常態(tài)。之前的開發(fā)工具鏈開始面臨挑戰(zhàn)，新的工具鏈還不成熟。這對于傳統(tǒng)汽車行業(yè)軟件從業(yè)人員，將是新的挑戰(zhàn)。多年使用類似于AUTOSAR CP的工具鏈，已經(jīng)讓大部分汽車軟件開發(fā)人員淪為了簡單的配置工程師，逐步喪失了底層軟件0到1的開發(fā)能力；對底層芯片的理解更是捉襟見肘。這種挑戰(zhàn)將觸及靈魂。缺少必要的，成熟工具鏈來支撐代碼的自動生成與測試，將會產(chǎn)生發(fā)自內(nèi)心深處的焦慮感。

圖10是節(jié)選自互聯(lián)網(wǎng)的一張HPC的系統(tǒng)架構(gòu)圖。復雜的系統(tǒng)結(jié)構(gòu)，對傳統(tǒng)ECU的從業(yè)人員的挑戰(zhàn)是巨大的。代碼運行從傳統(tǒng)的單核到現(xiàn)在的多核，如何合理地，動態(tài)分配資源而不是之前的靜態(tài)資源分配，都對傳統(tǒng)汽車電子軟件開發(fā)人員帶來挑戰(zhàn)與技能的轉(zhuǎn)型。

圖源：互聯(lián)網(wǎng)

汽車電子軟件屬于嵌入式軟件開發(fā)范疇，是在專用計算機系統(tǒng)上進行軟件開發(fā)，一般要求開發(fā)人員具有一定的硬件基礎(chǔ)。主流的嵌入式平臺包含ARM、DSP、FPGA等，開發(fā)語言主要是匯編/C/C++。

相對應的是，IT與互聯(lián)網(wǎng)大部分的軟件開發(fā)人員，都屬于在通用計算機系統(tǒng)上的軟件開發(fā)，一般是在某種操作系統(tǒng)上，如Windows，Linux，Android，IOS等，進行應用軟件開發(fā)，主要包含電腦端，手機端，服務器端等設(shè)備，以X86與ARM架構(gòu)為主。大部分開發(fā)人員都會使用某種高級語言，如C++，JAVA，JS，PYTHON，MySQL，等，進行特定任務的開發(fā)。

但是，對來自汽車產(chǎn)業(yè)外部的互聯(lián)網(wǎng)開發(fā)人員，雖然人數(shù)巨大（據(jù)估計，有100萬的從業(yè)人員），但如果從事汽車電子軟件的開發(fā)，卻需要了解整車架構(gòu)及汽車本身的know-how（圖11）。這個限制了互聯(lián)網(wǎng)軟件開發(fā)人員的選擇。

ICT行業(yè)與智能硬件的公司，以及芯片公司，也培養(yǎng)了大量的通信精英（移動通信，Wifi，Ethernet 等）和底層BSP或Firmware固件開發(fā)團隊，他們屬于軟件團隊中最懂電子硬件的人。這部分人將是汽車電子軟件開發(fā)的最佳人選。但是，對整車架構(gòu)和汽車本身的know-how的理解（圖11），也同樣限制了這部分嵌入式軟件開發(fā)人員能夠快速上手。

復雜的整車架構(gòu)，需要多年的知識沉淀與積累 圖源：互聯(lián)網(wǎng)

AI智能的發(fā)展，互聯(lián)網(wǎng)公司培養(yǎng)了大量的算法人員(圖像/語音/數(shù)據(jù)）。開放的互聯(lián)網(wǎng)精神，也培養(yǎng)了一批技術(shù)深厚的信息安全團隊。而應用軟件的多樣化和成熟的C/S框架，如Restful，RCP等，也練就了一批優(yōu)秀的前端和后端開發(fā)人員。因其更多的獨立于具體的硬件，或者傾向于云端和熟悉的PC及移動端打交道，切換成本會很少。這部分人才是實現(xiàn)車聯(lián)網(wǎng)的云端軟件，以及大數(shù)據(jù)分析的專業(yè)人才。當然，對于整車的架構(gòu)，汽車產(chǎn)業(yè)法令、法規(guī)的了解以及B端市場的規(guī)律，仍然需要一定時間的磨合與歷練。

3.

管理流程升級

百年的汽車工業(yè)開發(fā)，形成自己特色的，基于質(zhì)量閥門的整車開發(fā)流程。通過這種流程，把OEM主機廠和其Tier1，Tier2供應商密切地聯(lián)系在一起，形成有機的開發(fā)整體。但是，隨著基于功能和場景的解決方案逐步發(fā)展，軟件占據(jù)主導地位，現(xiàn)有的OEM開發(fā)流程卻不能很好地適應軟件系統(tǒng)與軟件工程，流程面臨巨大的挑戰(zhàn)，需要全方位的系統(tǒng)建設(shè)。這種流程的系統(tǒng)化建設(shè)，需要流程的架構(gòu)與設(shè)計，它涵蓋了組織制度，角色和職責等維度(具體參閱公眾號文章：行云流水般的流程)：

需求管理流程

傳統(tǒng)的開發(fā)模式是OEM主機廠負責系統(tǒng)和子系統(tǒng)的功能及接口定義。但是，很多子系統(tǒng)的劃分是根據(jù)物理的機械件（ECU）及接口進行了劃分，相應的負責工程師也跟隨相應的硬件耕耘多年，形成自己的專業(yè)know-how；但是，專業(yè)化的分工，形成“I”字型的知識架構(gòu)。不同的零部件之間的技術(shù)壁壘逐步產(chǎn)生，甚至各自為政，“老死不相往來”。問題是，如圖12所示，基于場景的需求開發(fā)需要多個子系統(tǒng)的聯(lián)動；需要“T”字型的知識架構(gòu)。如何分解需求；如何進行需求管理；分層管理；如何做到需求的重用；如何減少各功能之間的依賴，都對原有的流程產(chǎn)生新的挑戰(zhàn)。

汽車OTA功能的實現(xiàn)，如何管理汽車上市后的OTA功能與需求，如何連接運營，4S售后服務等功能需求，如何隨時提供云端服務功能，都需要對原有基于零部件開發(fā)的流程進行改造。

智能汽車功能需求

架構(gòu)設(shè)計與接口定義流程

汽車工業(yè)的傳統(tǒng)模式，軟件的know-how 基本被有實力的供應商把控，具體的軟件實現(xiàn)，接口定義，對OEM是不可見的。所以，如何確保不同的ECU軟件有機結(jié)合，協(xié)調(diào)實現(xiàn)必要的場景，相應的工作機制需要建立。

而車、管、端三位一體的未來發(fā)展方向，三者的聯(lián)動的架構(gòu)設(shè)計，同樣需要合理的流程機制來保障。伴隨著SOA架構(gòu)的逐步實現(xiàn)和車內(nèi)通信線路的以太網(wǎng)化，接口的定義將逐步從基于信號的定義或者簡單的消息結(jié)構(gòu)的定義C/S模式轉(zhuǎn)向更復雜的SOA架構(gòu)與接口定義（如圖13所示）。當沖突發(fā)生，需要相應的技術(shù)仲裁流程進行合理評估。

接口定義將由簡單的C/S模式向更復雜的接口定義演進

代碼與集成流程

汽車的造型設(shè)計形成不同的車型及零部件的Fit和Form。傳統(tǒng)的零部件開發(fā)模式，不同F(xiàn)it的零部件的軟件代碼各不相同。如何有效地重用代碼；如何構(gòu)建軟件架構(gòu)平臺；如何將不同代碼集成在一起，成為新的挑戰(zhàn)。需要新的流程來確保軟件代碼的重用性及軟硬件的集成。

產(chǎn)品與項目管理流程

傳統(tǒng)的零部件產(chǎn)品與項目常常合二為一。一旦硬件最終認可，軟件將隨之凍結(jié)，直至生命周期的終結(jié)。但是，智能車的軟件產(chǎn)品卻可以隨時增加新的功能，形成新的版本，通過遠程OTA進行更新?？梢韵胂?，未來同一款硬件，將會預裝不同的軟件版本，在市場上銷售。如何管理客戶車輛的軟件版本，如何管理軟件的兼容性，等等，需要新的流程改造。而項目管理，如圖14所示，可能會以軟件開發(fā)管理為主，在硬件產(chǎn)品的生命周期內(nèi)，通過項目的模式組織軟件的交付。

售后服務的流程

隨著軟件遠程診斷的開啟，以及AI及IOT技術(shù)的落地，基于數(shù)據(jù)的售后服務體系終將建立。傳統(tǒng)的4S服務的模式將逐步轉(zhuǎn)移到線上。如圖15所示的遠程服務體系的場景將成為常態(tài)，相應的流程體系的改造也勢在必行。多生態(tài)合作伙伴的介入，如何管理端到端的場景解決方案，提供更高的服務質(zhì)量，都是OEM主機廠面臨的問題。

復雜的智能汽車場景

開發(fā)工具鏈的挑戰(zhàn)

各種自動駕駛，人工智能，軟件算法，云端軟件的開發(fā)訴求，將會促使新的開發(fā)工具鏈?；蛘邆鹘y(tǒng)的工具鏈進行演化，如基于AUTOSAR CP開發(fā)的工具鏈將進一步進化為AUTOSAR AP等（見圖16）。而流程的優(yōu)化和改造，同樣需要類似JIRA，禪道，Synopsys，RobertFramework之類的軟件開發(fā)測試驗證等工具鏈的引進。

AUTOSAR工具鏈 圖片源自CSDN

4.

成本管控方式轉(zhuǎn)變

做過汽車Tier1供應商的小伙伴，我相信都經(jīng)歷過那種血淋淋的汽車零部件的商務報價過程 – “沒有最低，只有更低”。最后的后果，不管你是否相信，會是產(chǎn)品質(zhì)量的喪失。這從一個維度，充分反映了目前傳統(tǒng)OEM主機廠的思維定式：一輛汽車的功能決策，更取決于零部件的價格。在過去以機械結(jié)構(gòu)為主的汽車中，這個做法可以理解。但是，隨著軟件驅(qū)動汽車的發(fā)展，如前面幾篇文章所述，全生命周期的成本的權(quán)重要遠大于目前單件成本的爭奪。對比來看，在新勢力造車的蔚小理中，交付讓消費者眼前一亮的功能卻被視為更為重要的決策依據(jù)。

在零部件采購中，這種“砍到骨頭”的低價策略，會帶來負面影響。工程師們，不管是來自供應商或者OEM主機廠，會不斷地降低處理器的算力，內(nèi)存，通信帶寬等關(guān)鍵計算資源，從而降低硬件成本。如此一來，卻對軟件帶來根本的損害及不可預測的后果：

軟件工程師們將不得不優(yōu)化軟件代碼，以適應有限的計算資源。但因為系統(tǒng)的復雜性，這樣的后果是，在未來的性能測試中發(fā)現(xiàn)各種莫名其妙的問題，導致很難查找根本原因，從而增加了工程成本，甚至延誤了產(chǎn)品的上市周期。另一方面，盡管沒有找到問題的根源，迫于項目的進度，工程師們也是“拆東墻補西墻”，采用臨時方案應對項目的交付，為量產(chǎn)后的產(chǎn)品質(zhì)量種下隱患，增加了售后服務的成本。

軟件工程師不得不壓縮他們的代碼，確保其足夠的小，可以被調(diào)入有限的內(nèi)存運行。代碼要足夠地精簡，確保內(nèi)存的每一位（Bit）都能被充分利用。如此一來，任何新功能的增加將變得幾乎不可能。更有甚者，甚至缺陷的修復也將無從下手，而不得不進行硬件的召回。這些，在增加了工程師成本同時，進一步加劇了公司的售后服務成本，消減了公司的軟件銷售收入來源。

由于代碼的過度優(yōu)化，會導致后期的代碼維護尤其困難。復雜的語句，讓后期維護人員不敢有絲毫的觸碰。對代碼的修改成為每個人心中的噩夢。

過度精簡代碼，將會很難做到代碼的重用及其可移植性。也無法做到功能的預埋。如此一來，唯一的途徑是通過OTA進行從上到下的固件和應用軟件的更新。從客戶成本的角度，浪費了客戶的時間，增加了流量成本。從業(yè)務的角度，增加了內(nèi)部的運營成本及軟件工程成本。

這里，我們并不是強調(diào)傳統(tǒng)的Cost Per Unit的成本管控不重要。我們強調(diào)的是全生命周期的成本概念。所以，在評估零部件的單件成本時，除了零部件相關(guān)成本之外，必須考慮其帶來的項目延遲風險，產(chǎn)品上市窗口，工程成本，調(diào)試成本，售后服務成本，代碼復用以及未來新的銷售收入增長的機會成本。

消費者需求的多樣性和定制化的訴求，驅(qū)使主機廠在配置上形成不同的配置版本，產(chǎn)生不同的汽車Variant。以“簡單的動力系統(tǒng)控制的應用功能來講，會有3488中不同功能配置”（注：來自Manfred Broy）。而目前的奢華車，基本配備120個左右的ECU，簡單的“有”或“沒有”的配置，會有2120種Variants，供消費者選擇。除了市場和用戶的驅(qū)使，在整車長達10~15年的生命周期內(nèi)，各種小改款，中期改款，大改款，VAVE層出不窮，同樣結(jié)構(gòu)的ECU，會有不同的FIT，F(xiàn)ORM，也可能預裝了不同的軟件版本。如此眾多的Variant，需要巨大的驗證與確認工作，必將產(chǎn)生龐大的汽車工程成本。同樣，龐大的汽車Variant，也對售后服務的備件，服務技能和召回預算形成巨大的壓力 。

汽車行業(yè)的“賴特定律”（注：萊特定律由美國航空工程師西奧多·賴特在1936年提出，他將制造效率和制造經(jīng)驗聯(lián)系起來，其核心是每生產(chǎn)一定單位的產(chǎn)品，其制造成本將下降恒定的百分比）指出，“單個型號的汽車產(chǎn)量每累計增加一倍，成本的價格就會下降15%”。這終將會驅(qū)動硬件的標準化，降低汽車的Variants，從而降低汽車工程成本；功能的差異化實現(xiàn)，則更多地通過軟件來競爭。

然而汽車軟件帶來的成本增加，將越來越顯現(xiàn)。如何管控軟件的劣質(zhì)質(zhì)量成本，將成為擺在每一位汽車從業(yè)人員面前的一道關(guān)卡。圖18是關(guān)于某品牌汽車的OTA升級的一則新聞（德國《汽車與體育》(Auto Motor und Sport) 報道），12小時的升級過程，7.5小時的軟件安裝過程。按4G網(wǎng)速計算，升級包高達30G，單車流量費將高達三位數(shù)。更令人大跌眼鏡的是，電池電量居然被耗光，這讓消費者情何以堪？

汽車工程成本的另一個維度，是汽車軟件的Variant。傳統(tǒng)的ECU零部件，在整車的生命周期內(nèi)，會有不同的FITs，F(xiàn)orm等。但是，不同外觀尺寸的ECU與ECU之間的軟件差異可能不超過10%。不幸的是，因為軟件的不重用性以及單位硬件成本的管控理念、采購理念，導致軟件很難從一個ECU很快地移植到另一個ECU。這使得大部分軟件不得不被重寫（據(jù)德國汽車工業(yè)提供的數(shù)據(jù)，大部分軟件的改動其實只有10%的差異性。）。隨著車子智能化的發(fā)展，底層硬件的通用化，軟件重用的趨勢是必然。如此一來，軟件產(chǎn)品的觀念（見圖19示例圖）急需在整車廠建立并實踐。

軟件產(chǎn)品概念示意圖

5.

寫在最后

SDV,軟件驅(qū)動汽車，毋庸置疑，已經(jīng)是實實在地擺在每一個組織，每一位汽車從業(yè)人員面前的課題。盡管汽車軟件，相對硬件而言，體量仍然渺小，其在成長的道路上需要“水”，“土壤”和“陽光”，需要企業(yè)管理者和每一個汽車從業(yè)人員的愛護和澆灌。但是，面對這個汽車產(chǎn)業(yè)這個百年未有之大變局，軟件必將撬動整個汽車的產(chǎn)業(yè)鏈，在汽車生命周期的各個環(huán)節(jié)，如圖20所示，產(chǎn)生新的價值，驅(qū)動創(chuàng)新與再造。

汽車生命周期生態(tài)鏈

在這個過程中，覺醒的OEM開始與外部公司合作，例如零束汽車軟件與愛索管理咨詢的云端發(fā)布DevOPS改造；極氪汽車的整車流程優(yōu)化、再造，軟件審核等。這些都是順應軟件驅(qū)動汽車之大變局，通過廣泛的生態(tài)連接，構(gòu)建健康的軟件生態(tài)鏈；另一方面，也正反映了企業(yè)開始正視面臨的問題，通過價值洞察，積極推進組織變革，思維變革，技術(shù)know-how, 人才儲備以及流程制度的建設(shè)。

只有這樣，才能構(gòu)建軟硬融合的產(chǎn)業(yè)生態(tài)，讓智能汽車，乃至自動駕駛技術(shù)越走越遠。

審核編輯 ：李倩