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

       之前的系列文章，我們描述了什么是SDV，澄清了SDV的歷史淵源以及對(duì)SDV的一些誤解，并提出了軟件驅(qū)動(dòng)汽車的概念 （如何正確理解SDV，感興趣的小伙伴可以參閱公眾號(hào)文章 – 正確理解軟件定義汽車）

今天，我們重點(diǎn)談?wù)勀壳捌囆袠I(yè)面臨的痛點(diǎn)問題，如何進(jìn)一步解決，讓軟件真正發(fā)揮其巨大潛能。

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

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

       1、文化思想層面的沖突

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

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

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

1.

文化思想層面沖突

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

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

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

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

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

圖1

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

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

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

圖2 圖源：信息通信網(wǎng)

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

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

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

圖3

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

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

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

圖4

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

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

圖5

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

       傳統(tǒng)上，OEM主機(jī)廠更關(guān)注的是零部件的成本（Per Unit Cost），軟件開發(fā)成本更多地是分?jǐn)偟搅悴考稀?/span>

       當(dāng)面對(duì)軟件供應(yīng)商提供的軟件產(chǎn)品，Unit Cost又將如何定價(jià)，又如何轉(zhuǎn)化為可盈利的軟件商業(yè)模式呢？同樣，如果是內(nèi)部開發(fā)的軟件產(chǎn)品，開發(fā)成本如何攤銷？軟件資本如何合理配置？因?yàn)檐浖恰叭嵝浴钡?，?dāng)管理不善，軟件的開發(fā)成本將大大超過了零部件硬件成本的節(jié)省。

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

圖6

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

2.

人才技能轉(zhuǎn)型

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

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

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

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

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

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

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

     通過上述簡(jiǎn)單的軟件劃分，我們可以分析：

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

圖8 圖源：QNX網(wǎng)站

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

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

圖9

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

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

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

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

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

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

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

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

 

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

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

3.

管理流程升級(jí)

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

• 需求管理流程

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

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

圖12智能汽車功能需求 

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

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

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

圖13 接口定義將由簡(jiǎn)單的C/S模式向更復(fù)雜的接口定義演進(jìn)

• 代碼與集成流程

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

• 產(chǎn)品與項(xiàng)目管理流程

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

圖14

• 售后服務(wù)的流程

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

圖15 復(fù)雜的智能汽車場(chǎng)景 

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

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

圖16 AUTOSAR工具鏈  圖片源自CSDN

4.

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

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

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

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

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

• 由于代碼的過度優(yōu)化，會(huì)導(dǎo)致后期的代碼維護(hù)尤其困難。復(fù)雜的語句，讓后期維護(hù)人員不敢有絲毫的觸碰。對(duì)代碼的修改成為每個(gè)人心中的噩夢(mèng)。

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

圖17 全生命周期成本 

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

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

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

圖18 某品牌汽車OTA升級(jí)新聞

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

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

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

5.

寫在最后

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

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

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

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

轉(zhuǎn)自汽車電子與軟件