黃亮：汽車軟件會走向手機和現代軟件行業的發展趨勢

版權聲明：本文版權爲本站汽車所有，轉載請註明出處。

本站汽車11月8日報道

11月3日，2023中國汽車軟件大會在上海嘉定舉辦。本屆大會以“聚軟件之力，創數智未來”爲主題，緊扣新時代汽車產業高質量發展和汽車軟件發展要求，旨在打造汽車軟件領域開放、高端、權威的交流與溝通平臺。

在下午舉辦的“智能重塑生態，軟件賦能轉型”主題論壇上，蔚來汽車有限公司高級總監黃亮發表了主題演講。

以下爲嘉賓演講實錄：

非常高興有機會跟大家分享我們過去的經驗，我分享的題目是《新一代架構下軟件研發管理的挑戰和實踐》。從各車企在軟件定義汽車的研發過程中面對的問題來講，我相信蔚來汽車面臨的問題還是有代表性的，大家知道在智能汽車的軟硬件方面投入了大量的資源，很多內容從供應商也慢慢轉成了自研範圍，但是這也給我們帶來了很多挑戰。

我在NIO負責我們最新的整車數字化平臺NT3的交付管理工作。前段時間NIO新發布了SkyOS數字化平臺化架構，這個架構在汽車的EE軟硬件架構領域，我認爲是非常具有代表性的，體現了下一代軟件定義汽車的整個架構模式。基本上有以下幾個特點。從下層往上層看，有硬件自研和芯片自研，再到上面的操作系統層，大家可以看到SkyOS內核和虛擬化，這也是整個業界的發展趨勢。以前我們談到說操作系統更多的是安卓和座艙系統，但是事實上一個車上整個的所有的軟件操作系統，不只是座艙部分，還有智駕，傳統的車控、底盤、動力也需要操作系統，軟件的比例也越來越大，包括對車上各種功能進行控制的需求也越來越強。再往上是各個域的應用軟件。這個新架構包含異構操作系統的分層化架構、中央算力共享的硬件，我認爲汽車的整個軟件逐漸會走向類似手機和現代軟件行業的發展趨勢。

大家可能還記得這張圖，幾年前流行的關於汽車的分層式架構趨勢，EE架構中已域爲中心架構的特點是域芯片和上層軟件構成了子系統，域周邊是其他的傳感、執行器，供應商供給的ECU也是相當於一個小的計算機，包括硬件、操作系統、軟件，只是軟件的多少不同。嵌入式的軟件在車裡很多，零部件的數量也很大。下一步未來的架構發展是向集中式的、分層式的一個架構演進。但是從今天來看，實際上這個下一代的架構已經不是未來的事情了，當下就在發生了，至少是蔚來汽車就在發生。

新架構把原先的諸多ECU控制器的算力集中在一個硬件和一塊芯片上，業界現在像高通等也在把座艙和智駕的芯片做融合，以前大家是不同的芯片，現在和未來都在一個芯片上跑，越來越像一個手機。這個算力開始集中的話，在集中化的這塊硬件上實際上會形成分層的架構，這個分層架構也是軟件行業裡非常經典的層次化的結構，大家做過軟件的都非常熟悉這個東西，這裡有幾個特點。

首先一個底層的硬件，雖然集中，但是從平臺所支撐的車型來看也是有多種配置變種，不可能每個車都用同一套硬件和同一套芯片，這對從經濟成本或者是用戶需求來講也是不現實的，底層的硬件剛剛也說了，各個主機廠包括自研都在不斷地演進。

在這種情況下，我們依靠的是操作系統層和驅動軟件層，把硬件的差異性和上層軟件隔離開，這是非常重要的架構模式，在軟件領域也非常常見。好比Windows，上層的軟件也逐漸呈現層次化的模式。OS之上有一個SOA架構，SOA架構實際上本質的功能是允許跨域之間、跨芯片之間的軟件模塊能夠共享自己的接口，彼此實現更靈活的控制、信息獲取和調度，完成更上層、更復雜的汽車功能。服務層的類SOA架構，且軟件實現模塊化的分隔這個趨勢也會越來越明顯。

以前在汽車的軟件裡，嵌入式軟件對它的分層和模塊化架構是沒有太多關注的，因爲軟件數量可能很少，也不值得花精力做拆分。要把軟件模塊化，要適應上面各個車型和底下硬件的普遍性，保持長期演進，可以節省將來平臺的造車成本。所以說整個平臺優勢除了性能和功能上的優勢，效率可擴展，還有低成本，是整個平臺數字化建設過程中非常重要的三個指標。

這樣一個新架構聽起來是非常美好，也很炫酷，但是在實際的研發過程中給我們的研發管理帶來了很大的挑戰。我認爲對汽車行業來講，不管是蔚來，還是其他的車企，還是供應商會，都會面臨顛覆性的挑戰，這個挑戰剛剛開始，主要有這些方面的幾個變化。

首先你會發現從下往上看，我們的算力資源走向集中以後，各個域，各個原來分散的甚至是不同的供應商之間用的硬件，現在要跑到一個硬件上，這意味着要在同一個硬件上做更大範圍的子系統設計，這是非常大的協作上的改變。以前是ECU軟硬縱向一體化，彼此通過Can等信號協議定好了，大家放到一起集成，現在要在同一塊算力硬件上跟不同域去共同分享。此外軟硬解耦是個趨勢，我們的硬件還在不斷迭代研發，怎麼管理研發的變動性？當前的硬件在研發這款車，但是還要眼看着下一款車用新的軟件，同樣的架構在不同的配置和車型上，芯片的數量和傳感器的規格，是不是用激光雷達都不一樣？所以下面的差異化是另一個挑戰點。

第三個是上層的異構OS也是一個特點，這是什麼意思，好比你在汽車上既跑了安卓，還跑了其他的嵌入式等操作系統。當前還沒有辦法在汽車上用統一的操作系統，因爲不同功能域有不同需求例如部分有安全、實時等方面的要求，異構的操作系統帶來的問題是不同OS上的軟件不同，不同的域基於不同的操作系統開發軟件，這對於不同的操作系統的層次上，我們研發的整個工具鏈建設，是非常大的挑戰，集中在軟件架構能力上。

所以總結下來第一個ECU的軟硬一體化縱向被打破了；第二個跨域融合，對於工具鏈，橫向的標準化增強很多；第三個支持多車型，並行開發；最後軟件架構複雜化，加大對軟件能力的挑戰。

這些問題我們怎麼解決？我認爲組織流程和賦能我們做了這些工作，第一從組織上，必須讓交付的研發組織去匹配新的軟硬件架構，因爲這個是康威定理，從過去上一代的域縱向一體化團隊，開始轉向分層化、模塊化的交付團隊。比如說把整車平臺解耦，硬件，OS，還有軟件的模塊分層解耦，這樣的過程。第二個很重要的是，我把它解耦以後，橫向要建立橫向的標準化知識團隊，包括架構、工具鏈都要有，我不能每個域做自己的工具，將來這個東西就沒有平臺的標準化和工具性，很難維護。在流程上對於新的平臺研發還要有一套流程框架，類似於華爲的IPD框架，要有一套評價體系，要建立層次化的多版本的火車和敏捷迭代的協同機制。從賦能上，架構、開發、集成、測試、交付全方位的工具體系。

接下來簡單看看這些細節的內容，以前的域的縱向一體化，智駕座艙是一個團隊，職能上也是一個部門，這種方式對老的架構適合，對新的架構要把整車和平臺的交付分開，平臺裡面分層、分模塊。這是非常關鍵的，建設複雜的異構的數字化平臺是非常關鍵的。我們最開始做一個平臺一輛車的時候，整個公司相當於是一個交付團隊，我們只按架構劃好職能部門就可以。我們在去年、前年碰到了這個情況，加起來十幾款車怎麼管理，不可能一個人讓他在不同的項目條線獲取信息，所以就分平臺化站隊。

在未來交付研發體系裡，我們的交付團隊結構一直在不斷地演進，適應多平臺和新架構的變化。新平臺的研發和量產是貼的很緊的，第一個量產車在這個平臺上，整個量產的車子本身端到端的生命週期，跟我們平臺的生命週期要緊密配合，我們NTDP這套體系是用來設計需要哪些點，檢查平臺是不是達到了既定目標，跟整車的關鍵節點怎麼配合，這個流程都已經基本上落地了，我們現在的階段已經是相當於過了VB，已經走向量產階段了。

在這個基礎上我們剛剛說不同層次的軟件的版本管理，它本身就是大的話題，下層例如OS軟件的版本火車，跟整車的軟件版本、平臺的軟件版本，以及每個模塊的軟件迭代開發，這幾個流程之間的關係也是非常重要的，我們也做了相應的設計，現在我們的版本火車和迭代都能匹配軟件版本的進展。

我們也梳理了一套評價體系，用來評價這個平臺做的好不好？從四個維度來評價，即功能交付維度、平臺性能維度、使用效率維度和效益維度。最後工具建設方面，也分爲整個管理類的工具，還有工程技術工具，數據的管理。其實工程技術這塊怎麼集成打包，怎麼構建怎麼測試，在新平臺上尤其重要，因爲管理的工具或多或少過去都會用，這個是整個相當於展開一下。

謝謝大家！