什么是域控制器？OEM为什么要转向域控制器？

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之间的流量。

我们将留给您这张图片，它提供了不同架构的简化视图。