導(dǎo)讀
“?軟件定義汽車給汽車產(chǎn)業(yè)帶來了新的機遇，同時它也給汽車研發(fā)帶來了新的危機。我們希望能去掉“危”而抓住“機”，追趕汽車研發(fā)變革的風(fēng)口。”
參觀了2023年的上海車展，新汽車的展臺摩肩接踵，傳統(tǒng)汽車的展臺熱度不敷往年。又看了同期紐約車展的視頻，暮氣沉沉的紐約車展與新銳的上海車展好像處在不同的時空位面。面對這樣的場景，內(nèi)心真是無限感慨。近些年，中國汽車行業(yè)將是一個高度“卷”的時代，“卷”完國內(nèi)再“卷”世界，大家都在拼命狂奔向前。軟件定義的新汽車就如同一輛漂亮的跑車在一路狂奔，然而它的前路可能是水坑，也可能是泥潭。我們需要看清前方的道路，把握好汽車的方向，才能避免狀況的發(fā)生，最終在“卷”的狂潮中幸存下來。為了成為存活最久的那個人，我們需要擦亮雙眼，探索發(fā)現(xiàn)問題，再分析問題找到問題的答案。我們先從軟件定義汽車的定義入手：軟件定義汽車(Software Defined Vehicles，SDV)即軟件將深度參與到汽車的定義、開發(fā)、驗證、銷售、服務(wù)等過程中，并不斷改變和優(yōu)化各個過程，實現(xiàn)體驗持續(xù)優(yōu)化、過程持續(xù)優(yōu)化、價值持續(xù)創(chuàng)造。這里可以看到，軟件定義汽車有別于傳統(tǒng)汽車，它的典型特征是軟件的“深度”參與和“持續(xù)”變化，也就是說汽車相關(guān)軟件的變化會深度參與到汽車的整個生命周期中。軟件定義汽車的新特性給汽車產(chǎn)業(yè)帶來了想象空間。正如現(xiàn)在人們常說的，軟件定義的汽車等于加了四個輪子的手機。汽車也可以與手機一樣，產(chǎn)品交付到用戶手中的時刻，不再是產(chǎn)品研發(fā)的終點，反而是汽車軟件研發(fā)全新的起點。在汽車的生命周期中，各種汽車的應(yīng)用會如同手機應(yīng)用一樣被安裝到汽車上，給汽車賦予全新的能力。既然汽車是安裝了四個輪子的手機，那么我們是否可以用手機生態(tài)的研發(fā)邏輯來指導(dǎo)軟件定義汽車的研發(fā)呢？顯然是有問題的。軟件定義的汽車既有計算機相關(guān)的部分，也有“四個輪子”的機械部分，汽車產(chǎn)品是一個高度復(fù)雜的綜合體。并且，汽車是交通工具，它具有很高的功能安全要求，這也是手機產(chǎn)品不具備的特征。顯然，這些特征決定了手機研發(fā)模型無法完美支撐軟件定義汽車的研發(fā)過程。理論的危機
“理論來源于實踐，但科學(xué)的理論形成之后又對實踐產(chǎn)生重要指導(dǎo)作用，對人們從事新的實踐活動提供必要理論指導(dǎo)” 。軟件定義汽車是新生事物，一切都在發(fā)展中。現(xiàn)在，軟件定義汽車研發(fā)不缺少實踐過程，然而理論創(chuàng)新也需要提到議事日程上來，為研發(fā)實踐提供必要的指導(dǎo)。
我們知道，傳統(tǒng)汽車研發(fā)有成熟的理論模型即V模型。V模型是對瀑布模型的細化和完善。它本質(zhì)上是測試驅(qū)動的研發(fā)模型，每個開發(fā)階段都對應(yīng)一個測試階段。V模型是一個高度嚴格的模型，下一階段依賴上一個階段的輸出，工作必須一個階段一個階段地進行。V模型為傳統(tǒng)汽車產(chǎn)品的高質(zhì)量交付提供了理論支撐。V模型是基于SOP（start of production）為研發(fā)終點而建立的過程模型。V模型為傳統(tǒng)的汽車制造提供了很好的面向終點的過程約束。但是，V模型繼承于瀑布模型，因為瀑布模型的特征，導(dǎo)致研發(fā)開始之前，必須有非常明確的需求，這也導(dǎo)致需求的變更會帶來非常昂貴的研發(fā)代價。不得不承認，V模型在汽車行業(yè)的影響是非常深遠的。比如汽車行業(yè)非常流行的ASPICE和各種基于V模型的汽車相關(guān)標(biāo)準。但是，對于軟件定義汽車，V模型的影響力反而是新汽車研發(fā)的負擔(dān)。汽車行業(yè)研發(fā)人員在V模型的影響下思維模式根深蒂固，面對軟件研發(fā)敏捷性的要求，這里需要的是改變，首先是思想層面的轉(zhuǎn)變。傳統(tǒng)汽車研發(fā)理論無法適應(yīng)新的挑戰(zhàn)，那么他山之石可以攻玉嗎？從2023年上海車展博世公司的展臺可以看出，汽車行業(yè)正在借用“他山之石”，如下圖。圖中莫比烏斯環(huán)的造型，正是互聯(lián)網(wǎng)生態(tài)流行的DevOps研發(fā)模型。圖2：2023年上海車展博世展臺的DevOps造型
我們先看看DevOps的定義：DevOps（Development和Operations的混成詞）是一種重視“軟件開發(fā)人員（Dev）”和“IT運維技術(shù)人員（Ops）”之間溝通合作的文化、運動或慣例。通過自動化“軟件交付”和“架構(gòu)變更”的流程，來使得構(gòu)建、測試、發(fā)布軟件能夠更加地快捷、頻繁和可靠。
圖3：DevOps模型
DevOps強調(diào)使用敏捷的方法提供更快的產(chǎn)品交付的速率，比如可以支撐業(yè)務(wù)部門“每天部署10次”的要求，為了支持這個過程，強大的自動化手段是一切的根本保證。DevOps理論是經(jīng)過實踐的，是在現(xiàn)今互聯(lián)網(wǎng)世界行之有效的生產(chǎn)利器。DevOps在互聯(lián)網(wǎng)世界的成功，正是很多汽車企業(yè)爭相引入DevOps研發(fā)理念的根本原因。互聯(lián)網(wǎng)世界的DevOps，誕生于互聯(lián)網(wǎng)，服務(wù)于互聯(lián)網(wǎng)，水乳交融。但是，面對汽車的世界它卻有些水土不服。互聯(lián)網(wǎng)的DevOps是工作在可控的計算機環(huán)境中，它是一種全部電子化的，純數(shù)字化的，“軟”的生產(chǎn)空間。它是環(huán)境可控，輸入輸出可控，自身模型已經(jīng)數(shù)字化的工作環(huán)境，這是人類現(xiàn)今最理想的數(shù)字生產(chǎn)環(huán)境。然而，軟件定義的汽車，除了“軟”的一面，還有“硬”的一面。不能忘記，軟件定義的汽車是加了四個輪子的手機，除了“手機”之外還有“四個輪子”。汽車是復(fù)雜的軟硬件結(jié)合的混合體，它“硬”的一面就導(dǎo)致了它驗證成本會成指數(shù)級的增加，DevOps的循環(huán)速率會被嚴重拖慢，甚至成為斷裂的莫比烏斯環(huán)。汽車是運行在開放環(huán)境的物理實體產(chǎn)品。汽車與環(huán)境，汽車與人，都發(fā)生復(fù)雜的交互和反饋。換句話說，汽車被復(fù)雜的物理環(huán)境和人類活動等因素擾動，再加上無法量化的汽車自身的物理模型，這些都導(dǎo)致了DevOps閉環(huán)運行的挑戰(zhàn)。DevOps源于互聯(lián)網(wǎng)，它并不是為解決汽車問題而開發(fā)的方法論，簡單的全盤采用一定會帶來問題。很多車企在宣講自己是面向軟件定義的車企，是DevOps支撐的研發(fā)體系。但是，在實際工作中由于缺乏可以落到實處的方法論，面對汽車特有的實際問題，DevOps無法覆蓋或簡單套用。這就如同穿著室內(nèi)用的拖鞋去跑山路，“鞋”不對“路”，腳一定會痛。V模型和DevOps都有可取的地方，也都有其自身的不足。但無論哪個方法論，無論什么系統(tǒng)體系，“測試驅(qū)動”和“測試先行”的理念并沒有過時。“沒有測試的系統(tǒng)都是有問題的系統(tǒng)！”這句話是不變的真理。軟件定義汽車的危機，本質(zhì)上是測試的危機。這是批量化的工業(yè)產(chǎn)品與個性化的使用的矛盾導(dǎo)致的危機。這里所講的測試是更廣義的基于車輛的問題發(fā)現(xiàn)和問題修復(fù)的工作，即包括傳統(tǒng)的驗證測試，標(biāo)定，也包括研發(fā)狀態(tài)的集成測試和問題的定位。批量化的工業(yè)產(chǎn)品與個性化的使用的矛盾，這就導(dǎo)致測試永遠是不充分的。測試是資源和范圍的平衡，如下圖所示。理想的測試覆蓋是對每一個所發(fā)布產(chǎn)品進行全面的測試。比如猛士軍車，每一輛都是跑過一萬公里的路試后才會交到部隊的手中。是的，部隊拿到的永遠是二手車，但它是最穩(wěn)定最可靠的二手車。但對普通的消費類產(chǎn)品，我們不可能對每輛車進行一萬公里測試，這是資源和成本不允許的。測試永遠是在做一個平衡，用最少的資源可以驗證最大化的目標(biāo)系統(tǒng)。
目標(biāo)系統(tǒng)本身的差異性影響測試的范圍。我們知道手機的眾包測試，它是為了驗證適配不同類型手機而進行的海量測試。如果汽車系統(tǒng)可以提供百分之一百標(biāo)準化的抽象層，汽車應(yīng)用只要兼容這個抽象層就可以運行在所有的汽車系統(tǒng)上。這樣就只需要測試一個目標(biāo)系統(tǒng)，就可以代替全體目標(biāo)系統(tǒng)的測試。然而這是不現(xiàn)實的事情，在高度標(biāo)準化的Android生態(tài)下也需要眾包測試來驗證目標(biāo)系統(tǒng)的類型差異。何況汽車的復(fù)雜度遠遠大于手機，其標(biāo)準化的道路會遙遠而漫長。因此，眾包測試也可能是軟件定義汽車需要采取的測試策略。
目標(biāo)系統(tǒng)與外部交互的差異性影響測試的范圍。汽車系統(tǒng)會與環(huán)境和人進行交互，并且做出響應(yīng)。時間，空間和人的交互都會改變汽車系統(tǒng)的響應(yīng)行為。這就要求我們，只有汽車系統(tǒng)進行了全空間域和全時間域的測試才是完備的驗證測試。也就是說，在所有時間和空間發(fā)生的事情都測試一遍，邏輯上才是全域覆蓋的完備測試。但是我們知道這是不可能做到的事情，汽車系統(tǒng)測試必須做出妥協(xié)：一種方式是時間和空間變化對目標(biāo)系統(tǒng)的擾動很小可以忽略不計；另一種方式是我們在時間上和空間上目標(biāo)系統(tǒng)都一直伴隨存在一個測試系統(tǒng)，發(fā)現(xiàn)問題就及時修正，當(dāng)修正地足夠快且足夠多的時候就可以無限逼近測試的全覆蓋了。
軟件定義的汽車隱含地提供了個性化產(chǎn)品服務(wù)的特征，“持續(xù)”導(dǎo)致研發(fā)態(tài)永遠在路上，個性化導(dǎo)致測試資源需要分布更細的粒度和更大的范圍。我們知道資源永遠是有限的，那么在現(xiàn)有的資源下我們提供的測試方案：
- 在空間域上，目標(biāo)對象符合標(biāo)準化的部分盡量做大，同時為標(biāo)準化部分提供最大的資源，覆蓋最多最重要的內(nèi)容；
- 在空間域上，目標(biāo)對象擁有公共屬性的小集合，我們提供較多的資源覆蓋測試；
- 在空間域上，目標(biāo)對象個性化的內(nèi)容，投入最少的資源捕獲最不常見的邊緣場景。
- 在時間域上，測試伴隨軟件定義汽車的全部生命周期。在時間軸上，資源的投入梯度遞減。
多種因素導(dǎo)致軟件定義汽車測試的危機，測試的危機嚴重影響了DevOps的循環(huán)，嚴重的以至于撕裂莫比烏斯環(huán)。難道我們必須退化到傳統(tǒng)的瀑布模型嗎？顯然不是，我們需要新的方法處理汽車研發(fā)的新問題。
V模型側(cè)重流程和驗證，屬性偏“硬”；DevOps側(cè)重文化和慣例，屬性偏“軟”。俗話說：“量體裁衣，看菜吃飯”，我們需要的是軟件定義汽車自己的研發(fā)理論模型，而不是簡單的拼接或縫合。面對軟件定義汽車這樣新的研發(fā)場景，我們需要尋找的是一種具有高度復(fù)雜硬件，在高度復(fù)雜交互環(huán)境和高度安全要求下實施軟件研發(fā)的工作模型。當(dāng)然，這里一定有繼承，這里也一定有揚棄，在“不斷推進實踐基礎(chǔ)上的理論創(chuàng)新”的指引下提出我們的思考。
前面我們論述了“軟件定義汽車的危機，本質(zhì)上是測試的危機”，所以，首先我們要繼承“測試先行”和“測試驅(qū)動”的核心理念。接著，我們試圖尋找一個簡單的，直觀的，可運行的測試驅(qū)動模型，裁剪繁瑣的流程過程，追求極致敏捷，追求自動與智能。我們先從“測試驅(qū)動”的理念入手，觀察軟件定義汽車研發(fā)，探索我們的思考。我們從兩個視角進行觀察，一個是從空間視角，另一個是從時間視角。
我們先從空間的視角觀察軟件定義汽車研發(fā)。一切的來源還是需求，根據(jù)測試驅(qū)動的理念，需求經(jīng)過演化在空間上我們得到一個二元系統(tǒng)，一個是面向最終產(chǎn)品功能的目標(biāo)系統(tǒng)；另一個是面向產(chǎn)品支持運作的支撐系統(tǒng)。無論是目標(biāo)系統(tǒng)還是支撐系統(tǒng)，都是可運行系統(tǒng)。這里所說的可運行系統(tǒng)強調(diào)的是系統(tǒng)的可執(zhí)行性，即被萬物皆代碼驅(qū)動的（萬物皆代碼，everything as code），而不是文檔驅(qū)動的系統(tǒng)。測試驅(qū)動且測試先行的二元系統(tǒng)模型如下圖。
圖5：測試驅(qū)動的二元系統(tǒng)
支持系統(tǒng)是測試驅(qū)動且測試先行的系統(tǒng)，是以測試為主體，包含研發(fā)運維的綜合系統(tǒng)。支撐系統(tǒng)優(yōu)先于目標(biāo)系統(tǒng)進行部署和執(zhí)行。根據(jù)這個模型，汽車產(chǎn)品是目標(biāo)系統(tǒng)與支撐系統(tǒng)的統(tǒng)一體。基于測試先行的原則，支撐系統(tǒng)的生命周期不但早于而且長于目標(biāo)系統(tǒng)。軟件定義汽車產(chǎn)品是符合冰山模型的產(chǎn)品，一部分在前臺，一部分在后臺。前臺是冰山露出水面的部分，后臺是冰山水面下的底座，底座的支撐系統(tǒng)才是整個產(chǎn)品的核心競爭力。
圖6：海中冰山理論
我們再從時間的視角觀察軟件定義汽車研發(fā)。從空間的角度我們獲得了一個二元結(jié)構(gòu)模型。二元模型是一個中心兩個系統(tǒng)的模型。一個中心就是以產(chǎn)品需求為中心。這里的需求不是封閉的需求，而是在汽車整個生命周期持續(xù)變化的需求。全生命周期持續(xù)變化的需求要求我們必須面對時間域的變化，并且必須提供可持續(xù)性的解決辦法。二元結(jié)構(gòu)模型結(jié)合可持續(xù)的解決方案，我們得到下圖的太極模型：
我們回憶一下中國古人的智慧——認識世界的方法論。“無極生太極，太極生兩儀（兩儀即陰陽兩個系統(tǒng)）”。這里借用“太極兩儀”理論，我們賦予它現(xiàn)代的解讀：無極即客觀世界，太極即人類對客觀世界觀察獲得的認知（需求的認知）。太極是由兩個系統(tǒng)構(gòu)成的，它們是人類認識世界的兩個方面，它們互為存在條件，互相轉(zhuǎn)化，互相推動運轉(zhuǎn)。無極到太極是一個持續(xù)的人類認知過程（從客觀世界歸納需求），太極到兩儀也是一個持續(xù)變化的系統(tǒng)（從需求演變?yōu)閮蓚€系統(tǒng)）。也就是說無極到太極和太極內(nèi)的兩儀都是動態(tài)發(fā)展變化的過程。我們把太極模型應(yīng)用到汽車產(chǎn)品的研發(fā)過程中。目標(biāo)系統(tǒng)是實際參與汽車產(chǎn)品運行的運行時系統(tǒng)，它與駕駛者和駕駛環(huán)境進行互動，并且執(zhí)行駕駛動作。支撐系統(tǒng)伴隨目標(biāo)系統(tǒng)，為目標(biāo)系統(tǒng)提供研發(fā)、驗證、測試，標(biāo)定等環(huán)節(jié)的支撐。支撐系統(tǒng)與目標(biāo)系統(tǒng)一樣是全技術(shù)棧的，并且在硬件量產(chǎn)前，可以使用更多的技術(shù)棧和算力來搭建面向自動化和智能化的研發(fā)環(huán)境，提供更精細的調(diào)試，測試和標(biāo)定等服務(wù)。支撐系統(tǒng)不但在研發(fā)態(tài)的環(huán)境下運行，也與交付態(tài)的目標(biāo)系統(tǒng)伴隨運行，與目標(biāo)系統(tǒng)處于相同的算力空間，獲得相同的信息輸入。但是，支撐系統(tǒng)和目標(biāo)系統(tǒng)是被隔離的，通常支撐系統(tǒng)不參與執(zhí)行的過程，以保證汽車產(chǎn)品的功能安全特征。無論是目標(biāo)系統(tǒng)還是支撐系統(tǒng)，我們強調(diào)的是“可運行的”和“代碼驅(qū)動”的軟件可定義。以軟件定義的支撐系統(tǒng)支持軟件定義的目標(biāo)系統(tǒng)，即以“軟件定義”支持“軟件定義”，是太極模型的根本特征。測試應(yīng)用與目標(biāo)應(yīng)用是能夠互相轉(zhuǎn)化的。根據(jù)測試驅(qū)動的原則，當(dāng)一個軟件應(yīng)用發(fā)布到目標(biāo)環(huán)境以前，都必須通過測試才能安全地發(fā)布到目標(biāo)系統(tǒng)。由于軟件定義汽車帶來的面向個體的軟件定制，基于兩個系統(tǒng)的原則，我們就需要為個體提供研發(fā)測試環(huán)境，這樣才可以保證個性化軟件的高質(zhì)量發(fā)布。對于軟件應(yīng)用，這個過程相當(dāng)于應(yīng)用從支撐環(huán)境向目標(biāo)環(huán)境的流動，再從目標(biāo)環(huán)境升級到更高版本進入到支撐測試環(huán)境。這就是應(yīng)用在兩個系統(tǒng)中的互相轉(zhuǎn)化，并且是持續(xù)的螺旋上升的過程。太極模型也體現(xiàn)了兩級應(yīng)用轉(zhuǎn)化的過程。我們總結(jié)一下，太極模型是從一個需求中心演化出的二元系統(tǒng)模型，它是即有系統(tǒng)結(jié)構(gòu)特征也有動態(tài)行為特征的可執(zhí)行模型。太極模型是面向全生命周期的動態(tài)模型，它的服務(wù)對象是動態(tài)變化的需求。太極模型中的元素可持續(xù)改進并且可以互相轉(zhuǎn)化。太極模型可以幫助我們梳理汽車研發(fā)的思路。比如，我們在規(guī)劃汽車域控的時候，面對個性化的軟件定義需求，是不是在硬件層就需要考慮目標(biāo)系統(tǒng)和支撐系統(tǒng)在域控內(nèi)的預(yù)埋？是不是在軟件操作系統(tǒng)層或中間件層就考慮兩個系統(tǒng)的隔離和分割？是不是也要考慮應(yīng)用在目標(biāo)與支撐系統(tǒng)中的轉(zhuǎn)化問題？我們將持續(xù)探索太極汽車研發(fā)模型來解決這些問題。從汽車研發(fā)實踐中來，到汽車研發(fā)實踐中去，在本系列文章【極限汽車研發(fā)】實踐中，我們會不斷思考，不斷完善。
更多的思考
理論是基礎(chǔ)，也是我們邁出的第一步，然而只有理論是不夠的，“知行合一”才是面對問題的根本方法。軟件定義汽車研發(fā)的挑戰(zhàn)是全方位的，理念的挑戰(zhàn)，流程的挑戰(zhàn)和工具鏈的挑戰(zhàn)，這一切都需要我們通過思考和實踐來一一解決。
軟件定義汽車改變了汽車軟件的生命周期，這里一定需要一個嶄新的流程，一定需要引入全新的角色才能適應(yīng)新的變化。新的情況也會帶來工具鏈危機，沒有趁手的工具一切理論都只能停留在理論。我們會在本系列的其它文章中詳細討論這些問題。最后，最核心的危機是人才的危機! 傳統(tǒng)的車企需要跨領(lǐng)域的高級人才，沒有人才，一切理論，流程和工具都無法發(fā)現(xiàn)和創(chuàng)造。我們相信隨著汽車產(chǎn)業(yè)與軟件產(chǎn)業(yè)的高度融合，人才也會在這個過程中逐漸培養(yǎng)出來，理論也會從實踐中完善起來，只要我們不斷努力探索，一切的危機都不再是“危機”，而是新的機遇。—END—
添加下方信加入汽專業(yè)交流群
（僅限專業(yè)人士）
