1.什么是域控制器

過去十多年的汽車智能化和信息化發展產生了一個顯著結果就是ECU芯片使用量越來越多。從傳統的引擎控制系統、安全氣囊、防抱死系統、電動助力轉向、車身電子穩定系統；再到智能儀表、娛樂影音系統、輔助駕駛系統；還有電動汽車上的電驅控制、電池管理系統、車載充電系統，以及蓬勃發展的車載網關、T-BOX和自動駕駛系統等等。

傳統的汽車電子電氣架構都是分布式的，汽車里的各個ECU都是通過CAN和LIN總線連接在一起，現代汽車里的ECU總數已經迅速增加到了幾十個甚至上百個之多，整個系統復雜度越來越大，幾近上限。在今天軟件定義汽車和汽車智能化、網聯化的發展趨勢下，這種基于ECU的分布式EEA也日益暴露諸多問題和挑戰。

汽車分布式EEA

為了解決分布式EEA的這些問題，人們開始逐漸把很多功能相似、分離的ECU功能集成整合到一個比ECU性能更強的處理器硬件平臺上，這就是汽車“域控制器（Domain Control Unit，DCU）”。域控制器的出現是汽車EE架構從ECU分布式EE架構演進到域集中式EE架構的一個重要標志。

域集中式EE架構

域控制器是汽車每一個功能域的核心，它主要由域主控處理器、操作系統和應用軟件及算法等三部分組成。平臺化、高集成度、高性能和良好的兼容性是域控制器的主要核心設計思想。依托高性能的域主控處理器、豐富的硬件接口資源以及強大的軟件功能特性，域控制器能將原本需要很多顆ECU實現的核心功能集成到一起來，極大提高系統功能集成度，再加上數據交互的標準化接口，因此能極大降低這部分的開發和制造成本。

對于功能域的具體劃分，各汽車主機廠家會根據自身的設計理念差異而劃分成幾個不同的域。比如BOSCH劃分為5個域：動力域（Power Train）、底盤域（Chassis）、車身域（Body）、座艙域（Cockpit/Infotainment）、自動駕駛域（ADAS）。

2.ADAS/AD系統方案演變進程梳理

（一） L0-L2級別的ADAS方案

早期大多數L0-L2級別的ADAS系統都是基于分布式控制器架構，整個ADAS系統由4-5個ADAS子系統組成，每個子系統通常是個一體機整體方案（可以被看作是一個smart sensor），子系統獨占所配置的傳感器，通常相互之間是獨立的。

以智能前視攝像頭模塊（Intelligent Front Camera Module，FCM）為例，整個子系統ECU主板上包含2顆芯片：一顆是安全核（Safety Core）；另一個顆是性能核（Performance Core）。安全核一般由英飛凌TC297/397之類的MCU充當，承載控制任務，因此需要較高的功能安全等級需求；性能核通常是具有更高性能算力的多核異構MPU，會承載大量的計算任務。

下面是一個對L0-L2級別方案的總結：

L0級別方案：實現各種ADAS報警功能，比如：FCW、LDW、BSW、LCA等。分布式架構，通常由FCM、FCR、SRRs、AVS、APA等幾大硬件模塊組成。

L1級別方案：完成各種ADAS單縱向核單橫向控制功能，比如：ACC、AEB、LKA等。也是分布式架構，硬件模塊組成與L0級別方案大致相同。

L2級別方案：完成ADAS縱向+橫向組合控制功能。比如：基于FCM+FCR融合系統，融合前向視覺感知和前雷達目標感知信息，實現TJA/ICA等功能；或者基于AVS+APA的融合系統，實現自動泊車功能。

（二）L2+以上級別的ADAS方案

分布式架構的ADAS系統存在兩個致命缺點：1）各個子系統互相獨立，無法做多傳感器之間的深度融合。2）各子系統獨占所配置的傳感器，因此無法實現跨多個不同子系統傳感器的復雜功能。

當整車EE架構演進到域集中式EEA之后，ADAS域控制器中配置了集成度更高、算力性能更高的計算處理器平臺，進而可以支撐更復雜的傳感器數據融合算法，以實現更高級級別的ADAS功能，比如：HWP、AVP等。

集中式ADAS域控制器方案從最早的四芯片方案，過渡到三芯片方案，再到當前業界主流的兩芯片方案，如下圖所示：

3.主機廠對于域控的訴求

由于不同類型的域控制器市場定位不同，因此針對于不同類型的智能駕駛域控制器，主機廠在與Tier1合作過程中的訴求也是不一樣的。

中低算力域控制器：主機廠若是在前期沒有做好自研準備，現在多半是不會再去搞自研或者聯合開發。對主機廠來講，做好自己的需求定義，比如在控制器里面，主控芯片選什么，需要有什么樣的功能，然后直接交給供應商去做就好，這樣效率會更高。對他們而言，現在最需要的是能夠快速交付，盡快地把新功能推向市場，以保證產品在市場上的競爭力。因此，對于中低算力域控制器，主機廠大多會選擇讓供應商提供“交鑰匙”的方案。

對于中低算力的輕量級域控制器，行業內有基于TDA4平臺的方案，也有基于TDA4 +地平線J3的方案。不管是哪種方案，產品定位基本相同——主要用于實現L1~L2+級別的輔助駕駛功能。此功能應用場景相對簡單，對功能安全要求也相對較低。對于此類域控制器，主機廠比較看重供應商的成本管控和落地效率，其競爭力在于是否能夠提供一款高性價比的產品。

德賽西威副總裁李樂樂舉例說：“對于中低算力的行泊一體域控制器，比如低速場景只是實現APA和HPA功能 ，不需要人在車外，功能安全等級要求較低。高速場景上做L1到L2+，方向盤不脫手，人可以隨時介入，這種輕量級域控上所集成的功能就需要重點打磨。開發這類域控制器的主要挑戰是如何在算力和成本有限的情況下，把性能做到極致。因為其上層應用算法、中間件和底層軟件要聯合優化，耦合度高，軟硬難以解耦。“

大算力域控制器：在量產時間上還有一個緩沖期，主機廠還有時間和精力與Tier1一起去搞聯合開發。更何況頭部的主機廠大都希望能夠全棧自研，即使自己現在搞不定全棧，也希望在與Tier1的合作中能夠更多地參與進去，從而在雙方的合作過程中去不斷地去補足自己的短板。

大算力域控制器用于配置在中高端車型，是作為技術高點和品牌宣傳的亮點。 因此從受重視程度上來講，是中低算力的輕量級域控所不能比的，這是能夠體現品牌力和影響力的重要因素。

德賽西威李樂樂解釋道：“中低算力域控需要不斷打磨和優化策略來彌補算力的不足，在有限成本下把性能做到最好，也就是追求性能和成本的平衡。但是大算力域控目前不用擔心算力不足的問題，由于算力本身就非常強大，即使不用對算法做特別的壓縮和模型簡化，大網絡也能運行的非常流暢，體現出極強的性能。

“從這一層面來看，可以理解成大算力域控的硬件與算法功能的耦合性相對會低一些，主機廠和Tier1之間的協同性要求比輕量級域控開發低很多。因此，大算力域控制器適合Tier1和主機廠進行協同開發，主機廠可以專心做上層軟件去打造差異化，不用因為擔心算力不夠用而把雙方大量的資源和精力投入到裁剪優化上。”

靈活多樣的合作模式

由于各家主機廠實力水平參差不齊，并且各自的戰略規劃也不同，因此對于域控制器的需求也是多樣化的。Tier1要保證自己的產品能夠盡快量產落地，快速地實現自己的數據閉環，能夠不斷地去迭代自己的產品，就需要盡量地去滿足客戶差異化的需求。

因此，域控制器Tier1在與主機廠合作的過程中，產生了多樣化的合作模式。主要有以下幾種形式：

硬件+底層軟件

硬件+底層軟件+中間件

硬件+底層軟件+中間件+部分應用算法（行車 or 泊車 or DMS）

硬件+底層軟件+中間件+全部應用算法 （全棧交付）

當然，提供多樣化的合作模式也給供應商帶了一定的壓力和考驗。畢竟開發需求越多 ，資源投入就會越大。反過來講，能夠經受住這些挑戰，并充分利用自身有限的資源去滿足主機廠的需求，也有利于Tier1提升其自身競爭力。

德賽西威李樂樂告訴九章智駕：“ 對于智能駕駛域控制器，客戶在軟硬件層面均會存在一些差異化的需求。”

“在軟件層面，有的客戶希望短平快，選擇Linux操作系統，因為Linux的生態系統比較完善，可以滿足功能快速實現。但是選擇Linux，功能安全就沒辦法實現，這種情況我們會盡量增加一些冗余設計，包括芯片內部的出錯診斷，做一些能做的安全相關的設計。當然，也有些客戶基于功能安全層面的考慮會選擇QNX實時操作系統。同樣，除了需要提供底層軟件外，有的客戶希望我們提供中間件，也有客戶需要我們提供全棧工程的交付。這就需要我們基于客戶的不同需求去做好邊界的劃分和接口的定義。

“在硬件層面，基于算力需求的不同，客戶會選擇不同類型的芯片或不同的組合形式。有的客戶選擇單Orin 110TOPS，也有選擇單Orin X的254 TOPS，更有選擇雙Orin X的508 TOPS，甚至有客戶要求兩個雙Orin X的板子背靠背集成到一起達到1016TOPS算力。

“另外，從整車架構集成角度來看，不同的OEM也有不同的規劃，有一些客戶希望在大算力自動駕駛域控平臺上集成網關、VCU，也有一些客戶希望能集成IMU、GPS定位模塊，甚至也有一些希望能集成V2X模塊。這些都可以配合客戶去提供差異化定制開發的支持。”

總之，主機廠需求不同，域控制器供應商Tier1在服務客戶的方式上也會存在差異。無論雙方選擇哪種合作模式，最終都是以硬件為載體，并以產品的形態給到主機廠，只是在分工上會有差別。

對Tier1的挑戰在于前期做系統需求設計的時候，需要能夠結合客戶的差異化需求，提供一個完整的平臺化設計，并且能夠在平臺基礎上可進行差異化定制的更改，確保能提供一個最適合客戶需求的設計方案。

4.域控制器設計開發和量產落地面臨的挑戰

1） 硬件層面

傳統分布式ECU對接口、功耗或者算力相對來說要求不高，而現在的域控制器集成了更多的功能，需要處理的數據越來越多，所要求的的算力越來越大。因此，域控制器變得更加復雜，需要的電子元器件非常多 。做好內部所有硬件功能安全上的Fail-safe設計是比較有挑戰性的工作。同時，在電磁抗干擾能力、信號完整性層面也面臨很大的難題。

另外，大算力的芯片會產生新的功耗，產生較大的熱量，需要做好尺寸和散熱之間的平衡。

德賽西威副總裁李樂樂告訴九章智駕：“大算力域控制器用到的元器件物料數量要遠超于過去任何車上ECU內的元器件數量。在功能安全方面，需要做好WCCA（最壞情況電路）分析和失效概率分析以及對應的備份設計，在元器件非常多且系統復雜的前提下，要做好它的功能安全設計是非常有挑戰的。

“其次，由于整車本身布置空間比較有限，在充分滿足可靠性、電磁兼容和環境試驗要求的情況下把域控制器的外形設計控制在較小的尺寸范圍內也比較具備挑戰性。

“對于大算力域控制器往往發熱也比較高，目前的主流解決方案都是通過水冷的設計來解決散熱問題。這要求有很強的熱仿真能力，才能做好很精巧的水冷散熱管道方案，同時又能通過軟件監控主要芯片內溫度，并根據這些芯片內溫度來控制水冷系統入水溫度和流速。做好這樣一套溫度監控、入水溫度和流速的控制閉環系統，需要建立一套模型，并做好仿真和測試，避免水冷液過冷或過熱導致控制器內部凝水或無法及時散熱的問題。”

2）軟件層面

如何做好SOA服務化？多個核或者是多個SoC之間如何做好協同通訊、高速計算、算力的部署、實時調度等？如何保證軟件架構的靈活性以及軟件的功能安全和預期功能安全？這些都是域控制器設計開發在軟件層面面臨的挑戰。

東軟睿馳劉威博士提到：“從整個軟件的功能上來看，現在大家都在做SOA。實際上SOA服務化對算力是有影響的。雖然大家都說自己在做SOA，但差異還是挺大的。比如，哪些信號能夠服務化，哪些信號不能服務化，到目前為止尚無統一的定論。因為，第一，它要依賴于整個的應用需求；第二，需要依賴于整車架構；第三，還需要依賴于整個硬件的算力性能。”

從整個軟件的實現角度來看，除了硬件考慮功能安全，軟件的功能安全也是必須要考慮的，并且工作量非常大。從底層的驅動到基礎軟件，再到上層一些中間件，一直到最上層的應用，所有的這些軟件都要考慮功能安全。并且，對于高階自動駕駛功能，還要考慮軟硬件的預期功能安全。

3）技術工程化層面

智能駕駛域控制器系統相對來說比較新，對系統化的設計能力要求很高。如果系統在開發的過程中出現問題，需要有能夠透過問題的表象，看到問題本質的能力，能夠把產生的問題逐層分解下去，最后把它解決掉。這對于整個團隊的技術工程化理解能力的要求還是很高的。

福瑞泰克喻清舟認為：當出現功能和體驗問題的時候，團隊是否能夠從應用算法端一直挖到最底層的傳感器。問題的根源有可能是芯片驅動導致，或者感知導致，能不能在這個鏈條里面從前到后把所有鏈路都打通，對團的能力是最直接的挑戰。”

4）開發周期層面

在軟件定義汽車的時代，明顯可以看到，產品迭代速度都在加快。為了將其快速地推向市場，主機廠在拼命地想辦法壓縮新車的開發周期，因此Tier1不得不去改變其傳統的開發模式，借鑒互聯網科技公司的開發理念去形成自己新的開發模式，來進行快速響應。

智能駕駛域控制器作為一個比較新的軟硬件一體的產品，牽涉的合作方也比較多。當問題出現的時候，需要有人能夠把問題定位出來，然后再進行拆解分配給不同的責任方去解決。尤其是一些深層次的問題，定位問題本身就比較消耗時間，同時對于新系統，后期出現的問題也會很多。這在一定程度上也耗費了很多開發周期上的時間。

宏景智駕蔡文利講到：“由于主機廠都有嚴格的量產時間節點，所以很多ADAS項目都對工期要求特別緊張，這對ADAS服務商是一把雙刃劍。我們需要具有為客戶定制化開發的服務意識和技術能力，又要有資源調配的靈活性，愿意配合自己的客戶，共同打磨出一款能夠量產并且讓客戶滿意的產品。這里面的挑戰主要還是在于如何協調好企業內部的資源，有條不紊、把握節奏按時保質保量地交付產品。這是對整個企業系統設計經驗、項目管理、資金投入等全方位的挑戰。”

知行科技硬件研發總監認為：“在短開發周期的壓力下，Tier1的工程基礎能力是否足以來應付開發過程中出現的問題，并快速地解決。同樣也考驗Tier1的生態，你的合作伙伴能不能快速地來支撐你，以及是否有資源來支持你去解決這些問題。”

5）供應鏈保障層面

較大的市場需求導致半導體供應鏈和產能緊缺，包括疫情在內的各種“天災人禍”不斷擾亂半導體的正常生產節奏，而需求與產能之間的矛盾在短期內難以解決。在全球芯片供應鏈如此緊張的背景下，對于域控制器供應商而言，供應鏈的保障也是十分的具有挑戰性。整車廠在選擇域控制器供應商的時候，其合作伙伴芯片廠商的供貨能力也是重要的考量指標。

總結：工作需要，梳理了自動駕駛域控制器的發展歷程、行業分類、量產落地挑戰等信息。梳理完，思路清晰多了。真的是站在前輩的肩膀上，才能看得更遠！

審核編輯 ：李倩