驾驶自动化安全经济工程

自动驾驶的主要目标是消除人为错误造成的事故。在全自动驾驶汽车中，在系统发生故障时恢复驾驶员控制不是一种选择;没有驱动程序，也没有提供手动控制来接管。安全关键系统必须采取行动，而不是使用“人为后备系统”作为故障保险。虽然这可以通过系统的完全冗余来实现，但需要替代架构来最大限度地减少功能和系统的重复，以避免增加成本和重量。

汽车网络架构正在采用分区结构来减轻车辆重量和成本，从而提高燃油经济性、节省空间和经济性。

域和区域体系结构

图 1 比较了域和区域车辆架构的典型拓扑。在左侧基于域的架构中，传感器和执行器根据它们所属的功能域进行连接。每个域都有一个专用处理器作为域控制器的一部分。在右侧的区域架构中，传感器和执行器根据其在车辆中的物理位置进行连接。区域控制器、中央计算模块或两者的组合处理传统上由域控制器和中央网关执行的处理任务。

图 1：域和区域车辆架构的典型拓扑。

高优先级数据通信量（如安全关键型控制命令和某些类型的传感器数据）必须在特定的最大时间范围内到达目的地并做出响应。对于中等优先级的流量，例如车载娱乐数据，可以通过确保通信子系统中平均有足够的传输带宽来保持可接受的传输和响应时间。尽力而为的数据流量没有特定的延迟要求。数据最终“尽可能快”地到达就足够了，包括在通信子系统达到限制的情况下重新传输信息。

演进与功能安全

研究自动制动系统（图2）有助于解释域和区域架构对ISO 26262中定义的所需汽车安全完整性等级（ASIL）等级的影响。

图 2：典型自动制动系统中的数据流方案。

图2中的黑色标记框是电子控制单元（ECU），灰色标记框表示ECU之间交换的信息。雷达单元将雷达数据发送到目标检测功能，该功能提取有关检测到的对象的数据，这些数据是距离阈值功能的输入。距离阈值计算与前方车辆保持距离所需的减速，并在距离低于预定义限制的情况下向制动ECU发送适当的制动命令。

该系统的安全目标旨在避免意外制动，并避免在需要时无法获得所需的制动扭矩。由于在发生故障时可能会危及生命或致命伤害，因此根据ISO 26262，这两个目标都应满足ASIL D的要求，这是最高的完整性要求。

领域和区域车辆架构对这些安全目标的影响不同。图3显示了基于域的架构中自动制动的相关部件示例。

图 3：基于域的自主制动控制。

在这里，雷达、制动器和域控制器通过单个CAN总线连接。雷达模块从雷达前端接收数据，执行目标检测，并执行距离阈值任务。制动控制命令通过CAN总线发送到制动模块，制动模块执行命令任务。

图 4 显示了如何在区域架构中实现相同的功能。雷达和制动单元通过两个独立的CAN总线连接到两个独立的区域模块。这些模块都连接到中枢大脑，也可能连接到车辆内的其他区域模块。雷达模块仅包含一个传感器，制动模块包含一个执行器。与基于域的体系结构中的雷达和制动模块不同，区域体系结构中的这两个模块中都没有主要处理。相反，中央计算模块执行对象检测和距离阈值（计算）。因此，此体系结构称为具有中央处理的区域体系结构。

图 4：具有中央处理的区域架构中的自动制动。

可以采用其他方法，例如在区域模块A和/或B内执行目标检测和距离阈值任务。此类变体称为具有本地区域处理的区域体系结构。

计算 ASIL-D 合规性的 FIT

硬件故障概率指标 （PMHF） 是公认的 ISO 26262 安全指标，是违反安全目标的平均概率，表示为时间故障 （FIT）。ISO 26262 要求 ASIL D 的 PMHF 低于 10 FIT（每小时 10-8 次故障概率），ASIL C 的 PMHF 低于 100 FIT（每小时 10-7 次故障概率）。

根据其ASIL等级和ISO 26262标准为每个安全目标分配最大PMHF值。该值分为示例体系结构中区分的三个不同组件组：传感器融合和处理、通信和执行器组件。

这些单独的组件组中的每一个都有自己的故障概率 PMHFx，其中“x”是组件的订购号。应用程序的总体 PMHF 值是各个组件的 PMHFx 值的总和。为了满足应用的整体功能安全要求，总和应小于或等于与ASIL安全目标相关的最大PMHF值。

在从域体系结构过渡到区域体系结构的过程中，体系结构更改和相关任务重新映射会影响应用程序的 PMHF 值。在区域体系结构中，与基于域的体系结构相比，执行同一应用程序需要更多数量的通信和处理组件。

我们在示例应用程序中计算了安全目标的总体 PMHF，从而将基于域的体系结构与我们之前描述的区域体系结构的两种变体进行了比较。然后计算每个组分组对整体PMHF的相对贡献，结果如图5所示。该图证实，更加分散的区域架构导致车载网络（IVN）通信对整个应用PMHF的贡献显着增加。还发现处理的贡献没有显着变化。这是因为处理总量在不同的体系结构中不会改变。

图 5：每个组件组和架构的相对 PMHF 贡献。

自动驾驶的故障运行

当乘客在发生故障时无法接管时，全自动驾驶需要故障操作系统，以确保在发生故障时功能完整或降级。各种架构都可以实现这一点，尽管每种架构都有优点和缺点。

架构变体 1

同构冗余将系统复制到两个独立的并行实现中（图 6）。此变体在两个实现之一中存在随机故障时提供故障操作行为。目前只有一个并行实现处于活动状态，尽管备用（冗余）路径可能会定期自检以检测潜在故障。如果主路径发生故障，可以选择第二条路径以确保可用性。

图 6：全冗余架构。

这种方法基于这样的假设，即系统故障不太可能同时影响两个实现，但通过在两条路径中使用不同的组件，可以将系统故障的影响降至最低。这被称为多元化。缺点包括硅元件数量翻倍，因此增加了整体系统成本。

架构变体 2

第二种变体（图7）使用单个CAN总线连接传感器融合、处理和执行器组件。这避免了重复CAN总线结构（即电缆），而是使用新型CAN收发器，允许在网络结构内的单个故障下运行。区域内CAN可用性得到提高，而骨干网络保持完全冗余。它节省了与冗余收发器相关的费用和布线的重量，同时允许与完全冗余架构相同的可用性。

图 7：CAN 和主干网提高了可用性。

架构变体 3

第三种变体的特点是不重复处理模块和以太网交换机，如图8所示。

图 8：处理器可用性改进和完全冗余网络。

并行运行的第二个处理器提高了处理模块的可用性。此处理器可能具有较低的性能规格，因此必须采用故障降级的操作模式。对于某些用例，这是可以接受的，例如安全地将车辆移开道路。

架构变体 4

第四种变体（图 9）将区域内 CAN 和处理可用性改进与完全冗余的主干网络相结合。这种布置提高了CAN和处理可用性，从而节省了变体2中的电缆，减少了变体3中的控制器模块数量。

图 9：使用冗余主干网提高区域内 CAN 和处理器可用性。

车辆网络架构的未来

更高水平的车辆自主性避免了人类参与驾驶过程。在这些更高的级别上，自动驾驶系统必须无法进入运行状态。尽管完全冗余是满足此要求的不切实际的解决方案，但深思熟虑地采用可用性改进的通信和处理功能可以以较低的总体系统成本实现相同的可用性。

车辆网络架构正在转向区域架构，旨在支持更强大的功能，同时最大限度地减轻车辆重量和成本。另一方面，区域化需要仔细设计，以确保安全关键系统（如自动制动）能够达到所需的ASIL。我们已经表明，与传统的车辆网络拓扑相比，区域网络中由于车载网络的贡献而违反安全目标的平均概率显着增加。