所謂智能座艙域控制器（Smart Cockpit Domain Controller，后文用CDC指代）是在以前車載娛樂系統（IVI）的基礎上整合了多個獨立的控制單元（如Cluster），并集成了更多的智能化的功能（如DMS），使車內功能和用戶體驗變得越來越豐富，同時變的更復雜。
座艙域控制器的主要功能：
1. 信息娛樂系統：
- 即原來的IVI的功能。
2. 行車電腦數據顯示：
- 實現數字儀表盤的顯示內容，如速度、里程、油量、電池狀態等。
- 輸出抬頭顯示（HUD）所需要的信息。
3. 空調系統：
- 控制車內空調系統，包括溫度調節、風速控制、空氣質量監測等。
- 實現更智能化的區域溫度控制，提升乘坐舒適度。
4. 駕駛輔助系統：
- 集成泊車輔助功能，如倒車影像，AVM等。
- 隨著NPU在SOC的集成，CDC也可以集成行車輔助功能，如車道偏離輔助，車道居中行駛。
5. 車內連接：
- 實現與智能手機、平板電腦等設備的連接和互動，支持Apple CarPlay、HUAWEI HiCar等功能。
- 提供Wi-Fi熱點、藍牙連接等車內網絡服務。
CDC域控供應商在和主機廠（OEM）合作的過程中，產生了多種多樣的合作模式，主要包括如下三種形式：
1. 硬件+底層軟件（BSP）
2. 硬件+底層軟件+中間件
3. 硬件+底層軟件+中間件+上層應用
表：CDC主要供應商及其方案。本調查基于2023年的車型數據和供應商銷量排名情況，更新了部分基于高通8295的方案信息。
CDC的硬件是服務于功能而存在的。為實現上述簡介中提及的功能，目前CDC硬件主要包含SOC、MCU、Display系統、Camera系統、Audio系統、導航系統、以太網、車內通訊等等。
以QAM8295為例，框圖簡圖如下：
毋庸置疑，SOC是CDC最最最重要的元器件，它決定了CDC的性能和功能，還影響其可靠性、安全性和未來擴展能力。CDC硬件首先需要確定的就是SOC，一旦SOC型號確定后，基于SOC供應商提供的原型（prototype），SOC周邊的元器件，如RAM等也就差不多確定了，本文重點介紹在CDC中需要基于features確定的硬件系統構成。
（一）SOC
全稱SystemOnChip, 即單片系統，集成了包括處理器、存儲器和其他部件在內的較完整信息處理系統的半導體芯片。
SOC選型需要考慮多個關鍵因素：
1. 處理性能
在決定SOC選型時，算力是否能支撐規劃的feature的實現是最主要的考慮因素，需要進行業務-算力資源分析，基于worst case確定最低的算力要求。
- CPU性能：選擇具備足夠通用處理能力（DMIPS）的SOC，確保可以支撐座艙所有功能的實現。
- NPU性能：如果CDC需要處理語音、圖像（如DMS功能）等，需要根據算法要求考慮NPU算力（TOPS）。
2. 圖形處理
- GPU性能：評估GPU（圖形處理單元）的性能，確保能夠支持高分辨率顯示、3D圖形渲染和流暢的用戶界面。
- 多顯示屏支持：考察SoC能夠支持的顯示屏數量（同時需要考慮搭載屏幕的最大分辨率），包括主儀表盤、抬頭顯示（HUD）和信息娛樂顯示屏。
- 多個功能顯示區域和HMI交互：需要了解video pipeline，評估UX交互的最大能力。
3. 內存和存儲
- RAM容量：考察需要的RAM容量，以支持高性能應用和復雜軟件運行。
- 存儲接口：考察SoC支持的存儲接口（如eMMC、UFS等），確保具有足夠的存儲帶寬和容量。
4. 連接性
- 接口類型：考察SoC提供的接口類型，包括USB、Ethernet，DisplayPort，CSI，GPIO，SPI等，以滿足各種外部設備和系統的連接需求。
- 網絡連接：評估SoC是否支持必要的網絡連接功能，如Wi-Fi、藍牙和V2X通信。
5. 功耗和散熱
- 功耗管理：考察SoC的功耗，確定散熱類型，評估是否能滿足布置要求。
6. 軟件支持
- 操作系統兼容性：考察SOC支持的操作系統（如Linux、QNX、Android等），確保軟件開發和集成的順利進行。在決定操作系統時，需要考慮CDC APP生態多樣性。
- OTA升級支持：確保SoC支持OTA（Over-the-Air）更新，以便于未來的軟件升級和功能擴展。
- 快速啟動：選擇支持快速啟動的SoC，確保用戶上車的體驗。
7. 安全性
- 功能安全：根據CDC集成功能的功能安全等級，選擇符合汽車功能安全標準（如ISO 26262）的SoC，確保系統的安全性和可靠性。
- 網絡安全：評估SoC的網絡安全功能，包括硬件加密、安全啟動和安全存儲，以防止黑客攻擊和數據泄露。
8. 可靠性和長期供應
- 環境耐受性：選擇能夠在廣泛溫度范圍和惡劣環境條件下可靠運行的SoC，即車規級芯片。
- 供應鏈穩定性：評估SoC供應商的長期供應能力，確保能夠持續獲得所需芯片，避免供應中斷。
9. 成本和性價比
- 采購成本：綜合考慮SoC的采購成本，確保在預算范圍內選擇最佳方案。
- 整體性價比：評估SoC的整體性價比，包括性能、功能、安全性和可靠性，以做出最優選擇。
通過綜合考慮這些因素，可以選擇最適合的SoC，用于座艙域控制器的設計和開發，確保其在性能、功能、安全性和成本等各方面達到最佳平衡。
例：QAM8295P的一些參數
算力：220kDMIPS CPU /40 TOPS NPU
Display：
6x4k simultaneous output support. Synchronized DP outputs up to 39 MP (x2). Up to Total of 64 MP across all displays 6x DP MST2 (DP0 is alt-mode USB), 2x DSI. 2x eDP Support for 3x MST2 simultaneously (x2)
Audio：
7x TDM/I2S + 3x High Speed I2S for Audio Front-end
Camera：
Up to 16 cameras Maximum resolution 8MP 4x CSI2 4-lane (C/D-PHY combo）
（二）MCU
全稱Microcontroller Unit，它提供與車內其他ECU之間接口的作用，所以也叫VIP，Vehicle Interface Processor
MCU選型需要考慮多個關鍵因素，以確保所選方案能夠滿足車輛的功能需求、性能要求和未來擴展的可能性。
1. 功能需求
- 集成能力：確定CDC需要集成哪些功能，如信息娛樂系統、儀表盤顯示、空調系統、駕駛輔助系統等，確定上述能力的實現方案和功能分配。簡單來說需要確定哪些是由SOC實現，哪些是MCU實現。
2. 性能要求
- 處理能力：考察MCU的處理器性能，確保其能夠處理所有必要的功能和數據流。
- Memory：評估內存和存儲容量，以支持復雜的軟件和數據存儲需求。
- 實時性能：確保CDC具備實時處理能力，以滿足駕駛輔助和安全系統的要求。
3. 可靠性和安全性
- 系統穩定性：評估MCU在各種工作條件下的穩定性，確保其能在不同環境中可靠運行。
- 功能安全等級：對于有功能安全等級要求CDC，需要考慮MCU需要滿足的ASIL等級
4. 兼容性和標準
- 接口和協議：確保MCU支持必要的接口、接口數量和通信協議（如CAN、LIN、Ethernet等），滿足車輛EE架構的需求。
- 操作系統：選擇支持汽車行業標準化操作系統（如autosar）的MCU。
5. 供應商選擇
- 供應商信譽：評估供應商的市場聲譽和歷史表現，選擇有經驗和可靠的供應商。
- 支持和服務：考慮供應商提供的售后支持和服務，包括技術支持、培訓和維護服務。
- 成本和性價比：綜合評估MCU的采購成本和生命周期成本，選擇性價比高的方案。
6. 未來擴展性
- 硬件擴展：確保MCU具有硬件擴展能力，以適應未來可能增加的功能需求。
表：基于自動輔助駕駛功能的功能安全角度評估MCU對標數據。
（三） DSP和音頻輸入輸出
系統方案
考慮到部分audio產品可以在多個軟件系統實現，對于音頻系統的規劃和選型，首先要確定產品分配方案，基于功能集合，綜合考慮算力需求、延遲需求、可能的算法提供方。
*本算力評估基于ADI Shark系列（1MHz/6MFLOPS）進行的評估。同一種算法在不同的DSP上算力數字會有不同。
A2B bus目前是Audio系統內部/外部常用的傳輸方式，在確定功能分配方案后，需要形成audio routing，支撐DSP選型，A2B Transceiver數量、外部A2B總線數量和SOC與DSP之間A2B&SPI總線數量確定等。
隨著汽車涉及audio的功能越來越多、功能越來越強大，CDC需要連接的麥克風也越來越多，有些車型會達到12個之多，這就需要計算每個A2B總線的帶寬，確定每個A2B節點供電和“Bus Activity”是否能達到要求。
如果涉及多個外部A2B總線的輸入輸出，需要合理分配每個節點，基本思想是:
1）相同功能的節點在一個總線上；
2）當任一節點異常時，能最大化的保留更多功能。
DSP選型
因為A2B總線的關系，ADI的DSP是市場占有率比較高的，其他的可選供應商包括AKM等。
當然也可以考慮使用SOC內置的dsp，但是部分模塊會收License費用。
圖：Qualcomm對高級音頻處理模塊的費用
DSP選型需要考慮的因素包括：
1. 處理能力
- 計算性能：評估DSP的處理能力，尤其是在處理音頻和視頻信號時的性能表現。
2. 接口和連接性
- 通信接口：確保DSP具備豐富的通信接口（如TDM、I2S、SPI、UART等），以便與CDC其他系統和外部設備連接。
- 數據吞吐量：評估DSP的數據吞吐量能力，確保其能夠處理大量實時數據。
3. 音頻處理
- 音頻處理能力：選擇支持高品質音頻處理的DSP，滿足車內音響系統、降噪和回聲消除等需求（或者尋求集成第三方的音頻算法）。
4. 開發工具和生態系統
- 開發環境：確保DSP供應商提供完備的開發工具、SDK和調試工具，以支持開發和集成過程。
- 生態支持：評估DSP是否有良好的生態支持，確保提供audio算法的第三方公司在選型DSP上有移植經驗。
5. 供應商選擇
- 供應商信譽：選擇具有良好市場聲譽和長期穩定供貨能力的供應商，以確保持續的支持和供應鏈穩定性。
- 技術支持：評估供應商提供的技術支持和售后服務質量，確保在開發和維護過程中能夠獲得及時幫助。
6. 成本和性價比
- 成本效益：綜合考慮DSP的采購成本和整體性價比，選擇能夠在性能、功能和成本方面達到最佳平衡的方案。
- 生命周期成本：評估DSP在整個產品生命周期內的成本，包括開發、維護和升級成本，以實現更高的經濟效益。
注：最好同時關注供應商的產品系列，這樣后續迭代升級的產品的AUDIO方案有延續性。
（四） 視頻輸入輸出
常見的視頻傳輸協議有 TI FPDLink和 Maxim GMSL，它們的串形器 Serializer&解串器DESerializer一般成對出現。
串形器和解串器的選型主要需要考慮傳輸視頻的視頻碼率 Link Bit Rate：
假如視頻分辨率為 1920 x 1080、位深為 8 bits、幀速率 60 fps 的視頻，無壓縮狀態下的碼率應為 2848 Mbps，約 2.78 Gbps。即串形器和解串器需要支持的碼率最少為2.78Gbps。
計算公式：(1920×1080)×(8×3)×60fps÷1024÷1024[Mbps]
假定傳輸24位色（真彩色）色彩深度的RGB圖像，R、G、B各8bit，所以需要乘以系數3
不同圖像格式因為表達和傳輸色彩方式的不同需要乘的系數不同。
需要考慮攝像頭的供電方式，供電包括POC供電和獨立供電2種。
（五） 其他
1. 以太網SWITCH
Switch選型需要考慮以太網速度和帶寬、端口數據和類型、QoS和安全性、TSN、可靠性等技術要素，以及成本、生命周期、供應商因素（信譽、技術支持）等因素。
在硬件回路設計時，需要考慮診斷、時間同步和OTA的方案，以確定QNX、Android、VIP是否需要單獨的IP地址。
2. 定位系統
定位系統包含GPS和IMU，首先確定整車是否提供GPS和IMU數據，提供的數據是否滿足精度、延時、時間同步等的要求。
如果無法使用整車其他系統提供的數據，GPS定位模塊需要考慮是否需要支持RTK，而IMU需要基于功能對于加速度/角速度數據需要確定選型6軸、5軸抑或更少數據的元器件。
3. 總線Transceivers & USB
CDC需要搭載的總線類型主要取決于整車EE拓撲，并基于客戶硬件DPR考慮擴展性。
USB也是如此，在USB回路設計中需要考慮供電方式和相關回路設計。
CDC硬件設計和零件選型涉及到方方面面，是一個系統工程。根據實踐經驗，CDC硬件的最終方案會根據功能和系統的定義逐漸完善，而這些“完善”內容會造成每次layout的變更，產生資源浪費（特別是錢），所以經驗豐富的系統架構，在A樣時就提供高帶寬、高靈活的方案設計以支撐硬件工程師的硬件設計工作，減少后續的變更。即解決了開發成本，也可以節省開發時間，后續我們會在《智能座艙之軟件系統》中進行探討。
轉自汽車電子與軟件
