汽车领域中GPU的安全相关挑战与机遇

GPU已被证明能够满足自动驾驶（AD）系统的计算性能需求。然而，由于用于自动驾驶的GPU基于主流市场设计，它们可能缺乏在汽车安全法规下正确运行所需的基本特性。本文分析了在硬件和软件设计方面的一些主要挑战，以推动GPU成为自动驾驶的参考计算解决方案，并重点讨论了ISO 26262功能安全要求。

引言

高性能嵌入式系统 increasingly used in 关键领域 such as 交通（道路车辆, air‐planes, 火车）, 工业机械, 医疗设备 and sat‐ellites. Engineers of 关键实时嵌入式系统（CRTES） develop products following commonly accepted best practices and, in the case of 安全关键系统, showing compliance with 法律法规 is mandatory be‐fore they are allowed to operate. This requires going through 由适用的安全标准（例如，道路车辆的ISO 26262 1）定义的认证过程。

在关键实时嵌入式系统（CRTES）中，以“智能”软件功能作为主要竞争因素的趋势持续不断。在汽车领域，主要的软件功能涉及驾驶自动化，其潜在优势包括减少交通事故和二氧化碳排放量，以及通过减少驾驶员驾驶时间来提高人们的生活质量。这些优势推动了全自动化的发展趋势，目前大多数中高端汽车已经配备了某些高级驾驶辅助系统（ADAS），并且首款自动驾驶（AD）3级汽车也已问世。

在大规模生产中（奥迪A8）。请注意，自动驾驶等级从0级（无自动化）到5级：完全自动化，即在道路上人类驾驶员可能遇到的（所有）复杂场景中，驾驶均由系统自动处理。

自动驾驶功能 broadly 可分为车辆周围环境的感知、用于估计车辆位置的定位、规划车辆轨迹以及控制车辆执行器。其中，计算量最大的模块是感知，它基于目标检测与跟踪。在过去几年中，机器学习（ML）技术（例如深度神经网络（DNNs））取得了显著进步，通过实现更高的准确性，极大地改变了感知领域的最先进算法。这使得基于机器学习的感知技术成为工业界的首选方案。另一方面，机器学习技术也带来了汽车领域前所未有的性能需求。仅高级驾驶辅助系统（ADAS）的性能要求就预计从2016年到2024 2增长100倍。

初步的研究 3 和芯片供应商的性能数据显示，GPU 在加速用于自动驾驶的基于机器学习的库方面具有显著效果。这已引起汽车制造商的关注，他们开始分析 GPU 在满足自动驾驶性能要求方面的潜力。

由于面向自动驾驶系统的高端GPU基于主流市场设计，因此在适应汽车领域的特定需求方面可能会遇到一些困难。本文分析了GPU及其运行的软件在符合ISO 26262功能安全标准的安全保障方面面临的一些主要挑战。我们还探讨了其他相关挑战，例如时间可预测性。

具体而言，本工作的主要贡献包括：

1. 在硬件层面，严苛运行条件（例如极端温度）会使GPU更容易受到随机硬件故障的影响。在GPU中采用ISO 26262标准的解决方案（如多样性和冗余）必须谨慎进行。例如，尽管GPU天然具备冗余资源，但必须谨慎利用这些资源，以保持高性能，并防止单个故障在所有冗余实例中演变为共因故障，从而导致系统进入危险情况。

2. 在软件层面，我们识别了这些挑战。

自动驾驶基于通用的（即非汽车专用的）机器学习库。这使得汽车制造商能够享受最新通用机器学习库带来的功能改进（例如更高的目标检测准确性），这些库每隔几个月就会发布新版本。然而，其通用性增加了库中实现难以验证功能的可能性，从而加大了评估这些库是否符合ISO 26262关于软件编码与开发指南的难度。作为一个示例，我们在 YOLO v3（一种先进的目标检测系统）上的结果显示，所达到的代码覆盖率这一基本的软件单元结构覆盖度量指标远低于ISO 26262要求的100%。

出于性能提升的考虑，机器学习库基于底层GPU优化库（如cuDNN）构建。然而，这些库的黑箱（即闭源）特性给评估其对ISO 26262软件指南的符合性带来了挑战。这要求库的所有者进行认证过程，或使用与其闭源对应版本性能相似的开源库，以便最终用户自行处理其认证。无论哪种情况，为简化验证与确认而进行的更改都可能降低效率，并导致创建库的ISO 26262专用分支。

• GPU编程语言利用了一些特性，这些特性会阻碍软件（代码）验证活动，而这些验证活动在最高安全等级（ASIL D）下的总开发工作量中已占大部分。作为说明性示例，我们讨论两个众所周知的特性：指针使用（必须避免）和用于预防系统性软件故障的防御性编程（应提倡）。我们指出，符合ISO 26262的编程语言能够在保持GPU的性能优势的同时，阻止（或支持）其中一些不期望（或期望）的特性。

3. 时间可预测性，作为关键实时嵌入式系统的一项基本要求，在GPU中是另一个相关挑战，因为在（复杂的）高性能硬件上实现这一点非常困难。

总体而言，尽管ADAS已实现符合ISO 26262，但自动驾驶（AD）对此提出了挑战。在高级驾驶辅助系统（ADAS）中，计算系统作为故障安全系统运行，一旦出现异常行为，便将控制权交还给驾驶员。然而，自动驾驶使某些系统变为故障运行，无法将控制权交还给驾驶员。这对所采用的安全解决方案带来了严峻影响，以确保系统在发生故障时仍能持续运行（即容错）。

最近，英伟达Xavier被宣布为支持自动驾驶的符合ISO 26262能力的基于GPU的片上系统。

尽管目前尚未公布该片上系统如何实现故障运行能力的详细技术规格，但要达到ISO 26262合规性，需要适当的冗余和多样性策略。据我们了解，在英伟达平台上，这是通过相当程度的功能复制（例如使用GPU和深度学习加速器）来实现的，这可能由于采用了两种不同的软件和硬件实现而显著增加验证与确认成本，或者导致效率低下的解决方案，因为执行时间将由最慢的实现决定。总体而言，目前尚不清楚在支持自动驾驶的片上系统上以具有成本效益的方式高效部署和验证自动驾驶系统能达到何种程度。本文中，我们分析了与此问题相关的一些最重要挑战。

安全与自动驾驶软件背景

硬件加速器可以提供执行实时人工智能应用所需的计算性能，使其成为汽车自动驾驶中的核心要素。特别是GPU，已经出现在许多汽车制造商的路线图中，以满足自动驾驶的性能需求。然而，关于GPU如何满足安全关键系统的其他功能需求和非功能需求，仍有许多基本问题尚未解决。

汽车功能安全标准ISO 26262定义了4个汽车安全完整性等级（ASIL），从ASIL‐A（最低严重程度）到ASIL‐D（最高严重程度）。此外，质量管理（QM）类别涵盖那些在发生故障时不会引起安全风险的组件。

认证需要提供证据，证明系统性故障的风险是残余的，并且由随机硬件故障引起的故障不超过特定的概率边界。通常情况下，严重程度越高，为证明符合安全要求所需的证据就越多，且允许的概率边界越低。此外，系统是故障安全（即系统在发生故障时能够进入安全状态）还是故障运行（即无论是否存在故障，系统都必须保持运行），在确定满足这些故障概率边界所需的缓解技术方面起着关键作用。

ASIL分配

功能安全符合性要求识别系统的安全目标。这些目标随后被转化为安全要求，并随着系统的分解传递给各个组件，直至达到原子软硬件组件，最终实现并集成。严重性越高、危害暴露越大，且可控性越低，则分配给该组件的ASIL等级越高。例如，通常情况下，大多数与转向和制动相关的系统均为ASIL D，因此自动驾驶操作也必须符合ASIL D认证。

冗余与多样性

根据自动驾驶系统的要求，在ISO 26262标准下，ASIL C/D可通过冗余和多样化实现来达成。这需要建立项目的冗余实例，使其不受共因故障的影响。多样性可以通过多种方式实现。例如，可以设置执行相同功能的不同系统（如一个基于激光雷达，另一个基于摄像头），或者在同一系统中通过在较低层级引入多样性进行复制（如不同的软件实现、交错执行）。

安全保障：对硬件的影响

A. ASIL分解

传统上，汽车系统被认为是故障安全的，这需要采取较简单的措施来确保符合ISO 26262，例如将控制权交还给驾驶员。然而，向由5级自动驾驶驱动的故障运行系统过渡，显著增加了实现功能安全的复杂性，并阻碍了以往为节省开发成本而采用的某些形式的 ASIL分解。

ASIL分解用于：（i）通过冗余且充分独立的低ASIL组件来实现高ASIL组件（如图1顶部示例所示，两个ASIL B组件可用于达到ASIL D）；以及（ii）允许部分组件子集保持安全，从而维持相应的ASIL等级，而其他组件则被视为质量管理（QM），因为在发生故障时，ASIL组件将检测到该故障并使系统保持安全。这种分解通常用于使监控功能保持在相应的 ASIL等级（例如，如图1底部示例中的ASIL D），而计算组件则被视为QM。当QM组件发生故障时，监控组件会检测到该故障并将系统转入安全状态，从而影响可用性但不影响安全性。因此，故障发生的频率属于可用性乃至商业问题，但功能安全得以保持。

在自动驾驶中，由于一些ASIL C/D功能是故障运行的（例如，与制动和转向相关的功能），实现这些功能的组件必须达到相应的ASIL等级，且无法通过ASIL分解将这些项目降为 QM，因为可能根本不存在安全状态。因此，必须引入某种形式的容错机制，以确保系统在发生故障时仍能保持运行。

B. 冗余与多样性

GPU自然提供了大量可用于实现多样性解决方案的硬件冗余。然而，由于知识产权保密的原因，一些GPU内部行为（例如资源分配）由硬件自动管理，即以黑箱方式进行。不幸的是，这种做法与保证多样性相冲突，因为可能需要通过软件对资源进行底层管理。

然而，我们认为这些问题并不会成为GPU在汽车领域自动驾驶应用中的障碍。也就是说，GPU所提供的同类硬件冗余类型可以通过与锁步模式下运行的同构核心类似的方式，使其符合汽车领域的需求。例如，尽管相同的核心在前端设计上是同构的，但可通过多种方式实现多样性，比如以一定的时间偏移运行，使得在任意给定时刻各核心执行的操作不同，因此当故障影响到两个核心时，其影响必然不同，从而能够及时检测到错误。另一种通常在锁步核心中采用的多样性技术是布局多样性。只要通过构造避免共因故障，例如采用与核心类似的概念（如为每个冗余线程分配独立的资源集并以一定时间偏移运行），此类相似方法也可在GPU上实现。此外，GPU架构未来可能进一步发展并满足ISO 26262要求，因为相关修改对成本和性能的影响预计大致可忽略不计，且NVIDIA等GPU厂商已认识到实现ISO 26262合规性的必要性5。

在ISO 26262背景下，冗余的一个典型例子是锁步执行。以英飞凌AURIX处理器（例如 TC29x处理器系列）为例，该执行采用交错执行方式，使得特定故障不会在两个实例上产生相同的错误输出。然而，常规的锁步设计无法提供故障运行等级。例如，常规锁步系统（称为1oo2，即二取一）依赖于通过比较两个部件的输出来检测故障，当输出不同时即可发现故障。事实上，这两个部件的输出可能都是错误的，但只要由于某种多样性来源（例如交错操作）导致输出不同，就能保证故障被检测到。遗憾的是，故障运行系统只有在满足以下条件之一时才能基于1oo2实现：(1) 故障检测得到保证，并且其中一个部件必然无故障，且能够识别出无故障部件以维持正常运行；或 (2) 在发生故障后，功能可在引发危险之前被正确地重新执行，但这是一种复杂的过程。因此，为故障运行系统实现高效的 ASIL C/D仍是汽车行业的开放性挑战，这可能需要采用2oo3冗余以及某种表决机制，以保持系统的容错能力。

摘要：GPU 的大规模并行性能够支持 NooM（其中 N < M）冗余。然而，仍存在两个关键的开放性挑战。第一，通过避免共因故障来保证多样性；第二，过度使用 1oo2（或 2oo3）可能导致采购和能源成本过高，因此需要提供高效的 NooM 冗余解决方案。

C. 在恶劣环境中运行的能力

适用于汽车应用的硬件需要具备工作温度范围在‐40摄氏度至150摄氏度之间，以满足最高严重程度等级（0级汽车电子）的要求，并提高对软错误的可靠性需求。尽管这些工作条件比服务器或办公电子设备更具挑战性，但通过采用适当的电路设计（例如更大的晶体管和更宽的导线），GPU仍可实现这一目标。然而，这些设计实践可能导致因使用较慢电路而引起的性能下降，同时也可能增加功耗。尽管如此，在我们看来，仍然可以找到合适的权衡方案。

安全保障：对软件的影响

A. 编码标准与架构设计

所有领域的关键软件都需要遵守编码和开发指南，以促进其在特定领域标准下的验证和认证。在汽车领域，例如 ISO 26262 建议限制使用某些会使软件应用认证复杂化的特性，如指针和动态内存分配。同时，该标准还鼓励使用安全语言子集，以限制易出错的语言特性的使用。例如，MISRA C 是 C语言 的一个子集，定义了一组可通过商业工具进行静态检查的规则，从而强制实施这些规则的使用。除了编码标准外，ISO 26262 还定义了（i）关键软件架构方面的需求，该架构必须具备某些属性
如模块化、封装和最小复杂度；（ii）安全要求的验证方法，包括源代码审查（走查和检查）和源代码分析（控制流、数据流、静态代码）；以及用于验证软件并确定其质量的测试方法。例如，在单元测试级别，ISO 26262 要求结构化代码覆盖率，如语句和分支覆盖率。

GPU软件基于CUDA和OpenCL等低端类C API，这在证明符合ISO 26262方面带来了一些挑战。这些挑战包括以下几点：

指针使用。 CUDA和OpenCL程序将其编程模型中的指针作为不可或缺的特性，因为程序员必须显式地分配和维护两组独立的指针，一组用于主机内存，另一组用于设备内存。此外，程序员还需负责在这两个内存空间之间执行内存传输。需要注意的是，CUDA（6及以上版本）和OpenCL（2.0版本）的最新版本分别提供了两个等效的功能：统一虚拟内存和共享虚拟内存。这些功能通过隐式处理内存传输，为用户提供单一地址空间的抽象，从而简化了编程并提高了开发效率。然而，它们可能会带来性能损失，同时在时序和功能行为中引入另一个黑箱，这会使系统认证变得更加复杂，我们将在下一节中讨论这一问题。此外，即使具备这些功能，指针在编程模型中仍然存在。

Brook 是一种面向 GPU 的流编程语言。同样，MISRA C 对 C 进行了约束，Brook Auto⁶定义了一组认证友好的 Brook 规则子集，同时不限制语言表达能力。例如， Brook Auto 不向程序员暴露指针，并自动处理这些任务，从而降低人为错误的可能性。

图2（左）展示了一个Brook Auto的示例，突出了其部分优势。该示例程序启动一个 GPU内核，对两个输入数据向量（在Brook术语中称为流）进行操作，并将结果生成到第三个数据向量中。在调用该内核的程序中，每个向量都需要有两个版本，一个用于主机（后缀为“h”），另一个用于设备（后缀为“d”），分别如第14和15行所示。用 CUDA编写的相同代码，见图2（右），显示了在GPU端需要使用指针以在内核中传递数据（第1行），同时在主机端也需要指针来进行内存分配（第14‐16行）以及管理主机与 GPU缓冲区之间的传输（第18‐19和21行）。需要注意的是，OpenCL版本的代码具有与 CUDA相同的特性，但更为冗长，因此为了清晰性省略了该版本。Brook使用静态定义的流，避免了显式内存分配（cudaMalloc）和底层内存管理，从而防止因错误提供的尺寸参数或内存耗尽而导致的编程错误。流无法从主机端直接访问（例如索引），因为这会导致编译错误，只能通过特定的API调用（streamRead和streamWrite）来从主机缓冲区复制数据或向其中复制数据。流大小集成在这些调用中，从而防止从主机端发生越界访问。

从内核角度来看，流可以通过两种方式访问。一种是常规流，其中每个GPU线程访问数组中对应的元素，声明为‘<>’；另一种是gather流，声明为‘[]’。在前一种情况下，Brook Auto负责访问正确的元素；而在后一种情况下，它会抑制潜在的非法越界访问，确保故障隔离。

其他动态特性。 Brook Auto 还限制了可能导致死锁或使软件 WCET 分析复杂化的动态语言特性。例如，注意到 Brook Auto 示例中的内核在循环中包含了一个额外的防御性编程条件（第 6 行）。该条件将内核的迭代次数限制在一个静态定义的上限范围内，尽管主循环条件依赖于输入。如果缺少这种静态计算的条件，则会导致编译失败，从而强制执行此规则。相反，CUDA 版本没有对此类编程风险进行防护，这使得 GPU 软件的 ISO 26262 认证变得更加复杂。

B. 通用机器学习和黑箱CUDA库

通用机器学习库。 机器学习在各个领域的使用显著增加，导致领先的人工智能公司提供了多种广泛使用的框架和高度优化的库，以促进并更好地利用现有平台和架构⁷。与许多其他领域一样，最先进的自动驾驶系统严重依赖这些库，并广泛使用它们。然而，不仅算法本身，这些框架和库也具有很强的通用性，其设计基于与关键实时嵌入式系统总体上以及自动驾驶系统特别不同的目标，这给证明软件满足其安全要求带来了挑战。事实上，据我们所知，尚未开展关于这些库是否符合ISO 26262软件要求的研究。

例如，我们重点关注语句覆盖率，这是一种在软件单元级别上的基础结构覆盖率度量。具体而言，我们运行了YOLO v3（一种最先进的目标检测器，广泛用于包含20多个函数的实际自动驾驶系统中）。我们执行了多个真实场景测试，并使用低开销的覆盖分析工具 RapiCover测量简单的语句和分支覆盖率⁸。前者表示测试中执行的静态指令（二进制中的指令）所占的比例，后者表示测试过程中触发的程序分支或条件状态所占的比例。获得的结果如图3所示。

每一列代表每个文件中的所有函数。需要注意的是，尽管排除了所有未被调用的YOLO函数，分支覆盖率和语句覆盖率仍然非常低。语句覆盖率和分支覆盖率的平均值分别为83% 和79%，而在个别文件中分别低至19%和37%。虽然ISO 26262并未明确规定覆盖率目标，但其基础标准IEC61508（电气/电子/可编程电子安全相关系统的功能安全）建议所有度量指标均达到100%覆盖率。因此，对于任何ASIL等级而言，YOLO所表现出的覆盖率水平都是不可接受的，因为在所有ASIL等级中，分支覆盖率或语句覆盖率都被高度推荐（‘++’）。

值得注意的是，代码覆盖率这一概念甚至尚未针对GPU代码进行定义。由于GPU指令采用单指令多线程（SIMT）架构，并且存在线程束分支（谓词执行）的情况，使得将中央处理器的代码覆盖率简单地扩展到GPU变得复杂。

底层CUDA库。 在自动驾驶中用于人工智能和机器学习的库——作为GPU上大多数广泛使用的操作的基础——依赖于高度优化的闭源库（例如cuBLAS和cuDNN）。从功能安全的角度来看，这些库是黑盒，缺乏关于其实现、代码和算法的详细信息。这可能会阻碍最终用户对其开展安全分析，例如源代码分析和代码覆盖率，而这两项是ISO 26262的强制性要求。在我们看来，克服这一限制需要采取以下措施之一：

• 使用必须提供具有竞争力性能的开源库。例如，结果表明，CUTLASS⁹（NVIDIA 的 CUDA C++ 模板和用于实现高性能 GEMM 计算的抽象集合）在性能上与 cuBLAS 非常接近。
• 闭源库的所有者会经历认证过程，并将其库进行调整以满足 ISO 26262 需求。

然而，为实现 ISO 26262 合规性而进行的代码更改可能会导致相对于原始以性能提升为中心的代码出现性能损失，这在这些库所使用的其他非关键领域中是不可接受的。这可能导致为汽车领域创建特定的代码分支，从而增加开发和维护成本。

C. 领域特定优化

人们提出了大量方案来优化深度学习模型（例如，层移除与融合）。其中，对神经网络模型进行低精度校准（即量化）是一种常用的方案。通常，这些优化旨在为深度学习推理应用提供更低的延迟和更高的吞吐量，和/或降低能耗特征。然而，其中一些优化可能会增加应用程序产生错误结果的概率。因此，这些方法会根据输入数据的不同，在较大且广泛的范围内直接影响应用程序的准确性。对于汽车这样的关键领域，这些方案会降低应用程序的决策性。因此，在自动驾驶中使用此类优化时必须谨慎，需考虑其对应用程序整体准确性的影响。

D. 时间可预测性

在关键实时嵌入式系统（CRTES）中，功能必须在特定的时间范围内完成，这些时间范围称为截止时间。CRTES中的硬件和软件架构需要具备时间可预测的行为，以便推导出紧凑且可靠的最坏情况执行时间（WCET）估计值¹⁰。针对GPU软件的最坏情况执行时间分析仍处于非常初级的阶段¹¹。静态时序分析仅在非常有限的场景下进行，例如假设内核在单个流式多处理器上执行；而基于测量的分析则缺乏足够的证据表明已覆盖最坏情况场景。

由于GPU架构和软件中存在大量未记录的特性，上述两种方法均受到负面影响，使得对其实时特性分析比传统中央处理器（CPU）架构更加困难。我们认为，解决这一问题的一种方法是提高GPU可观测性。特别是，一组强大的WCET感知监视器（性能监控计数器）有助于在目标硬件上运行时提供关于应用程序最坏情况行为的深入信息，作为构建安全论证的关键要素¹²。在时间分析方面，基于统计的方法正日益受到关注，因为它适用于复杂处理器（如GPU）上运行的应用程序所面临的不断增加的执行时间变异性³⁻⁴。

结论

随着汽车中实现安全相关功能的软件组件不断增加，其性能要求以及对正确行为所需提供的保障也在持续上升。前者通过部署最初为其他高性能（即非关键）领域设计的软件和硬件加速技术，以具有成本效益的方式得以满足。正如本文所讨论的，该方法的可持续性取决于能否开发出精心设计的适应性方案，以应对满足安全监管标准过程中的关键挑战。整体而言，ISO 26262 的理念基于定义一组需求以及源自这些需求的一组测试，用于评估特定软件实现是否正确。然而，由于在界定例如目标检测软件是否正常工作以及如何定义相应测试方面存在困难，这种方法能否直接适用于基于机器学习的代码仍是一个开放性问题。

总体来看，可能需要对现有 ISO 26262 框架下的软件认证方法进行新的解读与分析。