NESY064A September 2024 – October 2024 DP83TC817S-Q1 , DRA821U-Q1 , DRV81602-Q1 , DRV8161 , DRV8162 , DRV81620-Q1 , DRV8245-Q1 , TCAN1043A-Q1 , TCAN3404-Q1 , TCAN3414 , TPS2HCS10-Q1
每個汽車製造商都有各自的方式來達成軟體定義車輛。前代車輛平台的傳統迫使許多 OEM 逐漸改用電氣與電子區域架構,以進一步配合集中式軟體方法。
雖然大多數 OEM 都在開發區域架構,但在決定控制車輛功能的軟體應位於何處時有不同的方法,如 圖 5 所示。
集中化軟體控制時有三種選擇:中央電腦、中央電腦與區域控制模組之間共用,或分散至少數網域控制器和區域控制模組。部分 OEM 將高效能運算領域集中化,如 ADAS 和車載資訊娛樂,並為其他領域增加額外應用處理。在 ADAS 和車內資訊娛樂領域之外,可在區域控制模組或邊緣 ECU 中執行即時控制。
從 OEM 的角度來看,集中式運算方法可能最具吸引力,因為透過單一電腦即可控制所有車輛功能。如果通訊鏈路發生故障,即時控制迴路延遲 (主動懸吊、車窗防夾) 和功能安全可能還會碰到其他難題。
分散式運算方法採取了一種更為漸進的步驟來實現軟體集中化,將部分應用程式和即時控制軟體保留在區域控制模組中,甚至保留在獨立的領域控制器中。在所有架構中,區域控制模組需求即使在相同車輛內也會有所不同,視 OEM 而定。一個區域可處理部分車身即時控制、暖氣、通風和空調,以及底盤功能;另一個區域可處理額外車身、照明和車輛控制單元應用程式軟體。最終,OEM 必須在硬體與機械致動控制延遲、車載網路功能、功能安全、安全性,以及如何針對所選架構的結構軟體與其特定區域控制模組需求取得平衡。