01

域控制器（DC）ECU的功能安全

隨著誘人的用戶體驗、電氣化和汽車ADAS功能的出現，車輛架構正強烈朝向域控制器發展。這篇文章中，讓我們從以下幾個方面來探討：

? 什么是域控制器？OEM為什么要轉向域控制器？

??對于域控制器中的功能安全性，我們應該有哪些考慮？

??如果多個供應商參與域控制器的開發，存在哪些挑戰？如何應對？

??什么是域控制器？OEM為什么要轉向域控制器？

傳統的汽車架構是去中心化和分布式的，一個ECU通常實現一個特性/功能。每增加一個新的功能/特性，就會增加一個新的ECU。這種架構在布線方面極其復雜和繁重（大量的電纜、觸點、熔斷器、繼電器等），使得將所有ECU布置到一輛汽車中非常昂貴。此外，隨著對自動駕駛和用戶體驗的日益關注，汽車正變得越來越以軟件為中心。有必要引入額外的應用程序或新的特性/功能與軟件無線更新，而不必添加或更改硬件。這就促使整車廠轉向集中式車輛架構，其中與單個域相關的幾個ECU被組合成一個ECU。這樣的架構在生產物流流程方面顯著更輕和更簡化，并使得質量得到改進。一個域整合多個功能的ECU稱為域控制器。

下面是一個去中心化的傳統車輛架構的視圖。圖中的每個方框代表一個ECU。

下面是一個基于集中式域控制器的車輛架構的視圖。

有不同域的域控制器:

a.?信息娛樂 DC (示例產品)

b.?ADAS DC（樣品產品）

c.?動力總成 DC (樣品產品)

一個 DC 在一個片上系統中實現所有的功能，它具有多個內核，同時具有所需的實時性和計算能力。

研究預測，到2028年，整體域控制器滲透率將接近60%，盡管沒有朝著基于域的架構的協同努力。

從ISO26262的角度來看，一個域控制器可以被認為是實現幾個“相關項”或幾個“相關項”的一部分。例如，一個ADAS DC實現不同的ADAS功能，如ACC、AEB等，可以被認為是ACC相關項、AEB相關項等的一部分。

02

對于域控制器中的功能安全，我們應該有哪些考慮？

1. DC架構準備好滿足最高ASIL級別要求

域控制器在特性/功能方面不固定，在其生命周期內一定會進行升級、添加和修改。從功能安全的角度來看，OEM/Tier 1應該能夠“預測”DC要求的最高ASIL水平。預測必須根據可能添加的新特性以及它們所需的ASIL級別來進行。DC的軟硬件架構應為達到這一最高ASIL級別的要求來設計。

例如，讓我們以一個目前具有ASIL-A安全目標的座艙域控制器為例。它有一個符合ASIL-A標準的SoC和一個SW架構，該架構有一個ASIL-A操作系統和兩個ASIL-A和QM分區。

現在，如果這個DC在未來實現ASIL-B安全目標，它現有的架構將無法支持它。需要將SoC和OS替換為符合ASIL-B標準的SoC和OS，并為ASIL-B創建一個額外的分區。DC的硬件設計也可能需要修改，以實現所需的硬件指標。

在上面的例子中，這個駕駛艙DC的架構是不可擴展的，以支持在更高的ASIL水平上的新的安全目標。這種預測上的缺陷正是必須避免的。

讓我們再舉一個ADAS域控制器的例子，該控制器目前支持ASIL-C架構，并具備一個ASIL C的攝像頭傳感器。如果這個DC將來必須支持ASIL-D安全目標，它現有的硬件架構不支持它。在這種情況下，DC必須1）升級到ASIL-D級別的攝像頭傳感器，或2）在攝像頭和另一個至少為ASIL-A級別的冗余傳感器之間執行ASIL分解，DC的架構中必須考慮另一個傳感器。

2. 不受軟件升級影響的現有安全功能

當SW升級在道路上進行時，這不應該影響其他已經合格的安全功能，否則即使沒有任何變化的功能，每次都需要重新合格，使其成為一個極其昂貴的事情。

3. 實現多種功能的故障安全、故障降級和故障運行要求

無論是傳統ECU還是DC，實現故障安全、故障降級和故障操作要求的原則都是相同的。然而，對于DC來說有趣的事情是，有幾個安全功能與各種各樣的故障安全、故障降級和故障操作要求共存。在一個單一的系統中實現所有這些功能是很有趣的。

1個功能中的故障不應影響另一個功能，除非它們彼此相關。否則，將導致所有功能的可用性完全喪失。例如，在儀表組-音頻域DC中，如果音頻系統發生故障，儀表組仍應能夠發揮作用，并向駕駛員提供所需的安全通知和指示。在ADAS系統中，如果車道保持輔助功能發生故障，不應影響自動緊急制動功能的性能。

DC的系統架構應識別會影響每個功能的故障，只有當這些相關故障發生時，才將功能轉到故障安全/故障降級狀態，而不是任何其他不會影響功能的故障。例如，如果緊急制動功能使用雷達傳感器，而駐車輔助系統使用超聲波傳感器，則超聲波傳感器的故障只會降低駐車輔助功能，緊急制動功能仍應完全可用。

如果有一個跨功能和影響所有這些功能的共有故障，如CPU故障，這將導致所有功能的整體故障安全條件。

故障操作要求通常只能通過實現硬件冗余來實現。例如，DC可以有2個獨立的SoC執行相同的處理，這樣即使一個失敗，另一個SoC繼續提供功能。必須考慮特性的端到端冗余，以實現失敗的操作行為。如果該功能從傳感器讀取一些輸入，則可以在設計中實現冗余傳感器，以備主傳感器出現故障時使用。兩個獨立的CAN通道接收和發送相同的消息和冗余執行器是具有故障操作功能的DC必須考慮的額外方面。

03

如果多個供應商參與域控制器的開發，存在哪些挑戰？如何應對？

讓不同的供應商開發DC的不同功能是很常見的，這是由于各種原因造成的。其中一個方面是該系統的復雜性和一個供應商開發整個系統所需的開發工作。更大的挑戰是開發每個功能所需的知識/技術專長。單個供應商可能缺乏開發所有功能的知識和專業知識。

無論是DC還是傳統ECU，與供應商打交道時面臨的挑戰都非常相似。然而，我們在這里強調它的原因是因為DC通常有更多的供應商。這使得從每個供應商那里獲得所需的安全檔案，并將他們聚集在一起，以提供整個系統的安全案例顯然更具挑戰性。

第一層通常是安全概念的全面負責人。一級供應商必須知道對每個供應商的要求，以獲得信心，即系統中的風險已得到充分緩解。

與供應商打交道時的典型挑戰是：

1. 供應商的責任定義模糊。

例如：假設供應商為DC提供復雜的IC，例如Micro或傳感器。這個供應商應該只提供硬件嗎？還是說第一層需要他們提供任何支持軟件？

例如2：如果供應商1開發功能1，供應商2開發功能2，誰負責功能2不被功能1干擾？這是供應商1或供應商2或其他任何人的責任嗎？

2. 假設供應商提供的硬件/軟件的ASIL級別。

例如，供應商說他們的硬件/軟件支持ASIL-B，或說他們有ASIL認證的“技術路線”，但一級供應商假設硬件/軟件是根據ASIL-B開發的。

3. 供應商提供所需ASIL軟硬件的時間表不符合項目的最后期限。

這是一個常見的問題，不僅安全，甚至在其他方面。在安全的情況下，經常發生的情況是，硬件/軟件在功能上按時準備好了，但安全檔案的完成被延遲。因此，供應商的安全檔案沒有在項目的最后期限之前完成。

供應商責任的不確定性是因為在DIA中缺乏對每個供應商的角色和責任的明確定義。供應商DIA經常盲目地從以前的項目中重用，而沒有完全考慮當前開發的項目的挑戰和背景。這一定要避免。如果可能的話，必須在RFQ階段對供應商DIA進行評估。在實施安全概念的過程中，所有的實時挑戰都必須預先考慮到。與其在事情出錯后進行事后分析，不如在項目開始時進行預先分析，了解在開始時應該考慮什么是正確的，以防止失敗。

04

總結

域控制器似乎將在未來十年占據統治地位。然而，DC的一個缺點是許多域可能在物理上跨越整個車輛。因此，汽車制造商也投資于區域架構。區域架構通過將物理上接近的ECU組合在一個區域控制器下來解決域架構的缺點。這帶來了減少布線和重量的好處——以增加軟件復雜性為代價。這是因為區控制器必須能夠根據功能來區分與其連接的ECU之間的流量。

我們將留給您這張圖片，它提供了不同架構的簡化視圖。

審核編輯：劉清