闲谈智能汽车软件开发流程︱汽车软件开发

在图2中，右侧说明了使用开放标准开发算法和软件的好处。由于硬件和工具的接口由开放标准指定，因此即使在切换一级供应商和底层硬件时，软件IP也可以保留并受益于新一代车辆的增强。这降低了开发成本、缩短了上市时间并保护了重要的公司资产。

由于汽车数量众多，与此类系统的物料清单(BOM)相比，开发工作（和成本）不那么重要。这迫使传统的原始设备制造商通过使用专有方法、硬件和工具来从系统中挤出每一点。这与OEM执行集成的传统关键能力同步，而底层一级供应商及其二级合作伙伴则专注于创新。我们看到标准使集成自动化成为可能。由于许多以前只为高级车辆保留的功能现在甚至在低端（高产量）车辆中也成为强制性功能，因此重新发明轮子的负担和重大创新以及风险成为一个新的因素。对于环绕和座舱内感应（驾驶员监控）而言都是如此，例如受欧洲新车安全评鉴协会(Euro NCAP)需求的推动。

2.2.2 软件开发流程

到目前为止，汽车领域软件开发流程的主要重点是从开发到主力车型开始生产(SOP)的短时间窗口。初始SOP之后，开始进入推广阶段，主要任务是将最终系统集成到其他即将推出的生产线和变体中。一旦汽车到了客户手中，就不再关注，也没有技术可能性来更新某些功能以修复错误或添加创新。虽然远程更新OTA很常见，但很少有汽车可以做到这一点。此外，传统车辆架构及其分散的ECU拓扑不允许进行OTA更新，并且缺少所需的适当网络安全措施，以及任何车辆通信能力。

在车间安装新软件在技术上是可行的，但是来自相应一级供应商的开发资源通常已经专注于下一个项目/下一代，用于可能不同的程序或OEM（关键或立法错误修复除外）。

软件驱动型公司展示了一种不同的方法，其中CD是基本要素。例如，特斯拉汽车都支持无线系统软件更新，无需将汽车送到车库即可安装。这使得整车软件能够快速频繁地改进，从而不断增强运行和用户体验。消费者和智能手机设备的更新周期推动了对集中式软件管理和网络连接的需求，以便访问云。这种转变可能会继续朝着区域和领域导向架构的混合方向发展，其中基于功能或区域的部分更新正在成为一种服务，将使用来自车载传感和车外信息的信息分发给车辆本身的可用设备。汽车的一个关键挑战是功能需要满足车辆寿命长、高质量、功能安全和网络安全的期望。软件和系统失效可能会造成危急状态，最终可能危及人们的生命并造成严重损害。这可能会导致一种两全其美的局面：汽车行业传统的安全和质量导向传统，与对快速发展的复杂软件的新需求相结合。在图3中，生态系统参与者的角色根据他们对持续发展的认识进行分类（因此他们属于图1右侧的“未来方法”类别）。新兴的非传统公司显然不需要进行这样的转变，而是从一开始就从绿色区域开始。

2.3 分布式异构系统

雷达、激光雷达、摄像头、超声波、GPS和地图数据——需要处理、融合和解释如此多的数据源，以生成一组供汽车执行的控件。当包括数据检查、具有冗余的故障安全系统和计算需求时，复杂性的规模将远远超出当前系统所能支持的程度。此外，从高端车辆到系统精简的经济型车辆，都需要一个模块化和灵活的系统架构来应对未来的市场需求。传感器分布在汽车周围，其特性、性能、功能和接口协议各不相同。大多数传感器都集成了分析系统，以减少在车辆周围发送的原始未处理数据量。而是使用经过处理和精简的数据，例如图像或3D变换坐标，以免因所有处理而使集中式网络和计算系统过载。大多数传感器单元都包含一个集成处理单元，该单元本身需要在汽车的整个使用寿命期间进行更新、改进和维护。处理后的数据和警报随后被输入到传感器融合单元，该单元必须理解其输入，使用新数据和先前的历史记录构建运行场景，以建立附近物体类型和意图的模型，然后执行安全的行动方案。“意图”本身是一个极其复杂的主题。仅仅识别物体和位置是没有用的，还需要知道它接下来可能做什么。从基于动物历史运动的行为（指向你的路径或指向你，快或慢，不安或平静，受惊时的行为等），到人、车辆、物体（在风中飘扬的购物袋或固体物体），它们都需要被解释以确定向汽车提出哪种操作。

系统中所有这些不同阶段都有不同的处理需求，需要非常不同的处理器类型，因此需求集成许多不同处理架构的异构系统现在通常用于实现ADAS功能。

最常用和最常理解的ECU组件是CPU，例如ARM或RISC-V提供的CPU。它们擅长按顺序处理简单的数据和不规则的控制功能。许多公司都能够支持将CPU投入生产。它们是可预测的，并且通常可以用汇编语言、C或最近的C++进行编程。

对于使用更复杂算法的实时数据处理，通常使用数字信号处理器(DSP)。这开始给编程带来问题，因为大多数DSP都要求开发人员了解其微架构。这是程序员面临的第一个障碍，同时也是车辆整个生命周期内更新和维护DSP功能的问题。

图形处理单元(GPU)经常用于为汽车仪表板提供图形，多年来一直被人们很好地理解如何可靠地实现这一点。虽然GPU已经用于非汽车产品以提供视觉和人工智能功能，但由于其类似矢量的处理架构，它们尚未在车辆的预期图形功能之外得到广泛使用。然而，由于OpenGLTM（图形）和OpenCLTM（计算）开放标准接口以及CUDA（一种成熟的Nvidia GPU专有接口），这些设备的编程很受欢迎。

另一种流行的处理器是矢量处理单元(VPU)，它通常是计算机视觉的核心，因为它能够同时处理图像中的像素阵列。与DSP一样，这些设备的编程并不标准化，需要特别注意微架构和汇编指令才能实现高效的算法实现。通常，这些处理器以黑盒形式提供，即系统开发人员只接受半导体公司提供的产品，无法提供自己的功能或增值。

当前一代处理器和加速器特别适合计算机视觉、人工智能和机器学习。这些是需要满足ADAS处理需求的新技术。它们非常异构，提供不同的加速器和编程接口。

特斯拉的FSD芯片就是这种集成了各种不同处理单元的异构系统的一个例子。它将12核 CPU（分为三个集群，每个集群有四个核）、GPU、图像信号处理器(ISP)和专用神经网络加速器(NNA)集成在一个片上系统(SoC)中。

由于没有针对不同处理器架构的编程模型的开放标准，接口和工具要求制造商完全致力于一种解决方案。这违背了每家制造商实现CD、拥有灵活的供应链和针对每辆车SKU提供最佳解决方案的愿望。

对于所有可用的处理器类型以及ADAS管道内的不同应用程序，它们都存在一个非常常见的问题——软件开发人员如何以一致的方式对ADAS系统进行编程，避免每一代都进行大量重写，以及如何在车辆的整个使用寿命期间不断更新它们？

2.4 什么是持续集成和持续开发？

CI是一种定期将所有开发人员的工作软件集成到共享代码存储库并进行测试的做法。软件的合并包括任何新功能或改进。除了软件之外，数据集、测试单元、配置参数或构建脚本的修改以及支持文档更改也将被集成。随着敏捷软件开发的广泛采用，较长的集成周期正变得过时甚至成为阻碍。1991年，Grady Booch首次使用“持续集成”一词来描述一种有效的、迭代的软件构建方式。该技术很快被纳入极限编程中使用的一组技术中，Fowler于2006年总结了详细的指导方针。

成熟的CI流程通过最大限度地减少构建、测试和发布新功能所需的时间来最大限度地提高效率，同时确保保持质量标准。

CD描述了迭代软件开发的流程，是CI、持续测试、持续交付和持续部署等其他几个流程的总称。

CI周期在每次对正在开发的软件堆栈进行更改时重复。CI管道会立即按顺序开始代码分析、编译、单元和集成测试。应用程序可以包含许多层。堆栈中的每一层都可以包含许多对库的依赖，这些库用于数学、调度或通信协议等功能。对任何一层的任何更改都可能触发新的CI周期。CI管道以对硬件进行集成测试结束，通常是现场车辆中的单个ECU，也称为硬件在环或开环测试台。

请注意这里增加的挑战。纯软件公司的CI/CD是在一台服务器上的一个地方执行（理想化），因此可以在几分钟或几小时内了解最近的提交是否成功。然而，对于汽车而言，CI/CD可能会部署和分布在不同位置的多个物理系统中。在现场的另一个额外挑战是测试数据的使用和生成及其传输。由于传感器带宽可以达到或超过40 GBit/s（≈19 TB/h），测试车辆可以消耗和产生PB级数据。

CD旨在自动化和简化在实时或暂存环境中构建、测试和部署新代码的流程。

CD承诺什么？

• 更快地交付新功能

• 更高质量的产品

• 规避风险

• 降低资源需求

• 提高生产力

汽车开发商面临的主要挑战是汽车被视为安全关键系统，这意味着在部署到生产环境之前必须进行功能安全检查。通常，使用FMEA（失效模式和影响分析）或STPA（系统理论过程分析）等分析方法。这些方法用于进行安全分析，识别可能的危害场景并针对候选发布版本进行测试。

由于ADAS AI计算堆栈中的许多部件来自多个供应商，因此开放标准提供了理想的解决方案。对于汽车中的大多数零部件而言，供应商有责任将任何改进或变更通知OEM，从而确定更新发布周期。

2.5 标准化

与ISO 26262同步发展的是AUTOSAR的进步，它致力于开发系统架构的全球标准，以便汽车ECU的基本软件功能可以标准化。AUTOSAR（汽车开放系统架构）是汽车行业领先的原始设备制造商和一级供应商之间的开发合作伙伴关系。共同目标是为基本功能的行业合作创造一个发展基础，同时提供一个仍然鼓励创新功能竞争的平台。发展伙伴关系的目标是：

• 汽车ECU基本软件功能的标准化

• 可扩展至不同的车辆及其平台变体

• 软件的传输能力

• 支持不同的功能域

• 定义开放式架构

• 各个合作伙伴之间的协作

• 开发高度可靠的系统

• 支持适用的汽车国际标准和最先进的技术。

掌握未来ADAS日益增加的复杂性需要抽象和标准化、开放的接口，以实现对变化的稳健性，尤其是对单个模块、组件、一级、二级、具有多代相邻系统不同组合（“碎片化”）甚至系统本身的目标汽车系列所做的更改。

因此，标准对于实现这一努力至关重要。

2.5.1 旧标准需要更新

ISO 26262是源自IEC61508的汽车安全标准，于2011年发布，其推动力是软件失效导致的悲惨车辆事故。这包括丰田2005年发生的事故，据称该事故是由于电子油门控制系统故障导致意外加速。ISO 26262的发布旨在提供一个框架，以便识别软件和硬件失效的潜在风险，并应用标准来确保汽车电子和电气系统的功能安全。该标准可用于安全相关系统开发生命周期内的所有活动，包括：

• 管理、开发、生产、运营、服务和退役

• 概述基于风险的方法（通过汽车安全完整性等级- ASIL）

• 识别不合理的剩余风险

• 验证和确认安全目标

• 管理供应商的需求

ISO 26262在欧洲、美国、日本和韩国市场已经很常见了。一些汽车行业层级遵守旧的代码质量标准，这阻碍了当今车辆应用程序的开发，以方便获得公认的基准质量水平。ISO 26262 标准不要求软件开发遵循任何特定的质量标准。它要求根据功能关键性水平来遵循软件需求，而功能关键性水平由车辆乘员受伤的风险决定。功能安全标准在发布时落后于最先进的水平，第二版ISO 26262:2018也不例外。它提出了一个困难的平衡点，即既定的、受欢迎的工作基准与当今新兴的复杂ADAS解决方案之间的平衡。汽车行业已经认识到安全标准中的这些差距，例如：

• 网络安全

• 编程并行性和不确定行为

• 人工智能系统的机器学习和训练

• 人与自主系统的交互

有许多机构和团体制定标准来解决这些差距，并向公众和政府监管机构表明他们正在自我监管和管理自主系统当前和未来的安全问题。其中一些标准列在下面。

已建立的质量标准：

• AUTOSAR（自适应）C++编码指南

• ISO24772避免代码漏洞的指南

• 日本（代码）ESCR指南

• MISRA代码指南

• MISRA汽车安全论证指南

当前功能安全标准：

• ISO 26262:2018

• DO-178C航空电子功能安全标准

• IEC 61508功能安全标准

• ISO 29119软件测试标准

• ISO DTR 4804道路车辆——自动驾驶系统的功能安全和网络安全——设计、验证和确认方法

• PAS 1881确保自动驾驶汽车试验和测试的安全

• SAEJ 3061网络安全

新兴安全标准：

• UL4600草案标准

• PAS/CD 21448预期功能的安全性– SOTIF

• ISO 21434汽车网络安全标准

• IEEE P2864 –自动驾驶汽车决策中安全考虑的形式化模型

• IEEE P1228 –自动驾驶软件安全标准

• IEEE P2851 – IP、SoC和混合信号IC的安全分析和安全验证的交换/互操作性格式。

2.6 经典计算机视觉开发

计算机视觉或机器视觉自20世纪60年代开始被研究。几十年来，计算机科学家一直在尝试让计算机理解图像。这项研究主要采用反复试验的方法。算法开发人员手动确定哪些类型的特征（例如颜色、线条和渐变）对特定问题至关重要。然后将检测到的特征组用作经典机器学习算法（例如支持向量机、Adaboost和随机森林）的输入，以尝试识别图像中的对象。Viola和Jones在2001年根据这些原则发表了一种算法，该算法多年来被广泛用于执行面部检测等。Dalal和Triggs在2005年发表了一种行人检测算法，该算法在该领域领先多年。定义算法应在图像中寻找的特征类型的过程在很大程度上已被基于AI的方法所取代，这些方法使这项工作自动化。我们将在下一节中更详细地描述其中一些。

不过，一些经典计算机视觉领域仍在广泛使用，尚未被人工智能取代。例如，在估算相机自身精确位置以及从图像序列中提取深度信息或3D信息（如点云）的应用中。这些同步定位和地图构建(SLAM)算法逐帧跟踪特征，并根据其位移使用三角测量提取结构。这是一个可以使用可预测、易于理解的数学技术有效解决问题的例子，这些技术比现代技术使用的神经网络消耗的计算资源更少。

2.6.1 专有移植

由于大多数计算机视觉算法主要是手工设计的，而不是像基于机器学习的方法那样经过训练，因此它们以C等编程语言表达，而不是在更高的抽象级别上表达。然后需要手动映射这些程序并进行大量优化以适应复杂的异构计算机架构。算法通常需要在异构处理器之间进行分区。除了标准CPU内核之外，目标架构通常还包括采用VLIW（超长指令字）和SIMD（单指令多数据）处理的多核视觉处理器以及复杂的内存层次结构。优化任务需要深入了解底层计算机架构。必须满足诸如以实时帧速率（例如每秒30帧）运行算法等约束，这进一步使这项任务复杂化。这是一项非常耗费人力、容易出错的工作，并且最终的实现特定于所选的处理器微架构，每个半导体供应商都有自己专有且独特的微架构。此外，还经常使用特定于供应商的编程工具链，这进一步增加了任务的复杂性。因此，花费大量精力开发的计算机视觉软件无法轻松地在一种架构和另一种架构之间移植和重用。

2.7 基于AI的软件开发

Alex Krizhevsky和他的团队将三种新技术结合在一起，AI研究取得了重大突破。首先，ImageNet图像数据库已经发布，提供了数百万张手工描述的图像集合。对于每张图像，相应的文件会标记图像中存在的对象。其次，Krizhevsky使用最近上市的强大可编程GPU来运行他的算法。这提供了数量级的计算能力，为使用更多计算密集型算法开辟了道路。

第三，他们开发了一种具有多层的新型卷积神经网络，他们称之为AlexNet。与传统计算机视觉不同，计算机科学家无需手动找出在图像中寻找哪些特征，AlexNet可以自己找出要寻找的特征。AlexNet参加了领先的ImageNet大规模视觉识别挑战赛(ILSVRC)图像识别竞赛，并以41%的巨大优势击败了整个领域。

这种方法遵循两个步骤：神经网络的设计和训练，然后是推理，其中网络执行识别视野中物体的实际任务。我们将在下面详细介绍每个步骤。

2.7.1 网络设计和训练

此步骤从收集车辆中的大量传感器数据开始。拥有数千公里的驾驶数据是很常见的。可以使用来自模拟的合成数据或通过处理原始传感器数据本身来扩充数据集。下一步是标记数据。在此劳动密集型步骤中，收集的数据被手动分类和注释，通常借助部分自动化任务的工具。由于单个摄像头每小时拍摄约100000张照片，因此标记几个小时的驾驶数据需要大量标记人员。然后，神经网络工程师设计网络架构：神经网络层及其配置、它们的连接方式、层数、要使用的激活函数、计算精度等。然后，汽车应用程序将这些网络中的几个组合起来以实现所需的完整顶级功能。在训练期间，数据集在神经网络中运行几次，每次调整系数，直到神经网络的检测性能不再提高。由于计算要求非常高，因此这种训练是在数据中心使用高性能服务器离线进行的。训练一个网络很容易就需要几个小时甚至几天的时间。这个过程的输出是一个经过训练的神经网络，其中包括神经网络配置以及定义网络运行的网络系数。这个经过训练的网络可以很容易地部署在车辆中。由于人工智能算法仍在深入研究和改进中，而且一直在收集额外的传感器数据，因此调整网络架构和用新数据重新训练的过程应该是连续的，而不是停止的。数据管理的任务也变得很重要。收集的数据远远多于网络在合理时间内可以训练的数据，因此必须选择正确的数据子集。此外，需要用训练过的神经网络还没有见过的数据来验证训练过的网络，以确保网络能够充分推广到道路上车辆的新实时传感器数据。数据集会不断用道路上车辆的新数据进行修订，更好地了解训练算法失败的地方，并根据具有不同要求的新算法进行修订。

一个相对较新的研究和开发主题是自监督算法。这是一种无监督学习，其中数据本身提供监督。一般来说，这种方法会保留部分数据，并让网络对其进行预测。例如，如果在帧中检测到车辆，那么该车辆可能也应该出现在先前捕获的帧中。这有可能大大减少甚至消除对标记数据的依赖，从而产生具有更高准确性的算法，并减少标记数据的劳动密集型任务。此外，生成对抗网络(GANs)正在兴起，其中两个并发网络以竞争方式运行：生成网络生成候选者，而判别网络对其进行评估。

2.7.2 推理

一旦算法设计完成并离线训练，它们就可以部署到车辆中。这要求算法能够快速、实时地运行，并且成本比训练低得多。由于将图像从车辆传输到数据中心需要太多带宽和延迟，因此每辆车都必须在边缘（车辆内部的处理器上）运行算法。尽管算法需要大量计算能力才能实时运行，但对低成本、低功耗的需求导致了专门用于运行神经网络推理的新型处理器的设计。

对开发人员来说，一个很大的好处是神经网络算法以高抽象级别表达。网络配置基本上为每个神经网络层定义了一组过滤器，并将它们之间的数据流定义为图形。运行网络的计算原语仅包含几个简单的运行，主要是乘法累加(MAC)，这些运行可以无限重复，并且可以轻松并行化。

将这些AI算法映射到专用目标硬件上通常是一种高度自动化的方法。大多数AI处理器供应商都提供软件工具，这些工具可以读取神经网络描述且并行化和优化网络以在加速器上运行。最终效果是最终用户无需编写一行代码即可在目标设备上运行经过训练的网络。作为额外的好处，这也意味着将在一个架构上运行的更复杂的神经网络添加到下一个架构要容易得多。

图5说明了AI开发流程（训练）的第一阶段，这显然需要传感器系统（传感器/镜头/ISP/软件/…）的可用性和成熟度。

2.7.3 量化计算（效率映射）

图6描述了使用非标准/专有工具向专有目标的转移。首先，工具链覆盖范围有限，通常包括手动和容易出错的步骤。安全上下文丢失。此外，移植到目标隐式地需要某些近似值（例如转换为定点、减少位深度），由于现代（判别性）深度神经网络（DNN）的非连续性，其影响往往是不可预见的。工具开发与项目特定任务之间没有脱钩。相反，必须在此流程中解决挑战。

近似计算是一种主要的研究趋势，旨在以科学和结构化的方式实现这一目标。

图6. 顶部：传输间隙。底部：安全上下文得到保留

随着软件复杂性呈指数级增长，理想的目标是缩短开发时间。随着OTA软件更新的预期增加，应用程序的软件开发最近已成为汽车生产线中最具挑战性和最昂贵的部分之一。由于传统的汽车约束仍然必不可少，因此仍需要广泛的安全性、质量和可靠性需求。这会影响创新和成本的速度，给开发团队带来交付压力。此外，软件数量的增加伴随着复杂性的增加，架构受到特定汽车需求的影响，例如硬实时、高可靠性和安全性、有限的资源、成本压力、短开发周期和领域知识的异构性。

3.1 开发流程：V模型

就图7中的ASPICE V模型而言，汽车开发和生产的标准流程，软件应用程序开发只是SWE.3“软件详细设计和单元构建”的一个框，但移植是在SWE.4“软件单元验证”中完成的，涉及整个生产流程。还有许多其他组件需要满足，包括系统、硬件需求、质量保证、测试和验证。整个周期可能需要长达三年的开发时间。实际上，软件解决方案的进步更新迅速，其复杂性显著增加。这意味着在软件技术的快速发展中没有可用且固定的解决方案。这需要一种新的发展策略来赶上快速而复杂的变化。

事实上，多年来，敏捷开发已成为汽车行业的热门话题。然而，在目前的开发流程（V模型）中，敏捷开发只能应对解决方案路径的微小变化或偏差，但这对于解决方案切换或升级来说效率不高。对于一个复杂的问题，如果解决方案没有固定下来，那么在开发周期中必须进行更多迭代，其中软件在环(SIL)和硬件在环(HIL)必须与软件修改和更新一起持续执行。实际上，典型的SIL和HIL活动可能需要数年时间才能使用大型数据集完成，同时可能已经需要升级最先进的解决方案。这加强了高级开发和生产开发之间的共同开发或非常密切的合作。图8展示了V-Model+（或改进的V-Model）的一个示例，该示例更加灵活，符合敏捷开发理念。在这个新流程中，设计了两个循环用于软件的可能更新或升级：

1）第一个循环是不断更新解决方案以满足SIL中给定的KPI；

2）在目标硬件中验证更新的解决方案。

高级开发预计将在小规模数据集上部分加入第一个循环和第二个循环。生产开发将负责对比平常大得多的数据集进行修改和验证。

3.2 人力资源需求和运营挑战

实现非常高的质量保证和安全目标使汽车世界成为一个相当封闭的社区，新手很难加入。此外，许多开发方面只有经验丰富的成员（10到20年的实践经验）才能涵盖，因此寻找训练有素的人员始终是一个挑战。这个传统问题来自各种高度定制和优化的汽车系统，这些系统需要在生产层面拥有非常多的实践经验。解决这个问题的一个明确途径是采用更先进的标准和先进技术，这些标准和技术足够通用，并且为最新一代程序员所熟悉。

3.2.1 需要一种新型的程序员

精通标准现代C++的开发人员可以非常快速地使用SYCL。开发人员面临的挑战是转变思维，在高度并行的编程范式中概念化编程。它需要实践和熟悉新的编程和设计方法，以便创建高效的程序。还有一些并行库正在出现，以减少程序员所需的编码工作量，如并行STL（C++标准模板库）。并行编程带来了新的编程设计模式，这些模式在HPC领域已经存在多年。多年来，人们一直在设计各种模式，例如缩减模式，以最大限度地提高超级计算机等并行计算机系统的性能和效率。这些模式需要高效编码，以降低功耗并缩短任何计算应用程序的执行时间。开发人员可以自由地向其应用程序添加其他库，甚至可以添加非C++库（如Python），而且几乎没有任何限制。这里使用Python来表达Google的TensorFlow库（用C++编写）使用的张量模型。

仅精通 C++ ’11之前的C++的开发人员必须学习使用SYCL编写代码所需的一些现代C++功能。这种类型的开发人员的一个例子是一直按照汽车行业事实上的编码标准MISRA C++编写C++的开发人员。他们还需要学习使用C++模板和一些更通用的良好实践，如RAII（模式资源获取即初始化），或熟悉支持的STL资源管理功能。

仅精通使用全局变量和戳寄存器的接近硬件的“C”编程的开发人员将面临更陡峭的学习曲线。他们需要熟悉面向对象编程(OOP)并练习使用其所有功能（如类继承和模板）编写C++，同时注意不要继续编写“C”风格的代码。此外，还需要在现有的“C”编程复杂性之上学习所有额外的C++编程复杂性。

图9显示了不同级别的标准及其与硬件、软件和库的解耦/适用性的比较。

根据Khronos Group的说法：“SYCL是一个基于C++的标准异构并行编程框架，用于在各种处理器架构（包括CPU、GPU、FPGA和AI处理器）上加速高性能计算(HPC)、机器学习、嵌入式计算和计算密集型桌面应用程序。”

3.3 芯片依赖性

由于成本和性能限制，汽车硬件高度专业化并针对某些特定用例进行了优化。它通常不灵活，有时甚至不可编程，开发人员只能使用一些可配置参数调用现有函数。这严重限制了可扩展性以及新创新解决方案的适用性。事实上，由于许多硬件限制，大多数最先进的技术无法移植到部署的平台上。例如：

• 有些（如深度学习）需要太多的吞吐量，超出了当前硬件的范围。

• 有些（如SLAM）不需要强大的处理单元，但需要CPU和GPU之间的快速内存复制，而大多数汽车硬件并不支持这一点。

• 有些（像素处理，例如光流）由硬件加速执行，但精度有所降低，这不允许开发人员实现他们想要的/更新的/创新的算法。此外，低级像素处理需要硬件加速单元的支持，而硬件加速单元是由不同的公司异构设计的。开发人员甚至可能需要学习一种针对特定硬件的新型低级编程语言，例如EVE、FPGA等。

• 有些（如传感器融合或优化求解器）需要高精度分辨率，而硬件对分辨率有很强的限制。

从所有硬件依赖性的例子来看，很明显，切换到新硬件几乎总是需要从头开始软件开发。在这种硬件受限的依赖性下，重用或CD是不可能的。

3.4 处理软件错误

最近，OEM因错误修复问题而召回的次数增加可能是由于生产前开发时间的减少，而系统的复杂性却显著增加。事实上，异构集成设计解决方案可能会解释更多问题，例如，一些部分继承自SoC库，一些来自一级开发。此外，许多可用的解决方案都是在许多狭隘的假设下设计的，这些假设在现实生活中很容易失败，例如完全平坦的道路、结构化环境等。设计问题没有简单的修复方法，通常会导致产品失效。或者，大多数小错误可以通过应用新的软件更新来更轻松地修复。这个问题的主要原因应该是质量保证、测试和验证不足。由于成本和时间压力，没有多少一级/二级甚至OEM能够严格应用A-SPICE 3标准或没有完全执行功能安全。后一种问题类型的现代方法是进行OTA软件更新。这在一定程度上存在争议，并且经常被认为在未经完全验证的情况下可能会影响车辆的安全性。

最近观察到的一个重要趋势是转向强大的集中式控制器。过去的车辆使用数百个小型ECU，每个ECU通常专用于一项任务，而现代车辆则使用数量较少、功能更强大的集中式域控制器。例如，特斯拉使用单个域控制器，大众ID.3使用两个控制器。

由于它们使用集中式域控制器，它们现在主要负责执行同时执行的任务，并且还需要满足具有此类需求的任务的实时约束。这些控制器需要提供大量的计算能力，这通常不仅通过扩大处理器核心的数量来实现，而且还通过部署异构系统来实现，将CPU与各种专用处理器和加速器相结合。

此类加速器的示例包括GPU、FPGA或用于图像处理或AI任务的定制处理器。对具有各种不同功能单元的异构系统进行编程对汽车行业提出了新的挑战，因为迄今为止，汽车行业主要依赖于固有的顺序编程模型。为了充分利用平台提供的计算能力，汽车行业需要采用能够充分利用此类平台上的并行性和各种专用加速器的编程模型。然而，没有必要重新发明轮子，智能手机、个人电脑和高性能计算(HPC)等其他领域已经研究和建立了并行和异构编程模型，其中许多模型是汽车软件开发的良好起点。然而，选择一种或多种编程模型，再加上专有标准还是开放标准，是一个至关重要的决定。

4.1 专有标准

最流行的专有编程模型之一是CUDA编程语言，由Nvidia开发和维护。CUDA允许使用基于C/C++的编程语言在异构系统中高效地编程GPU。调查发现CUDA生态系统非常丰富，包括编译器、分析器和用于AI训练和推理等任务的专用库。与开放标准OpenCL及其多样化的硬件支持相比，CUDA的重点完全是使用Nvidia GPU的官方支持的Nvidia设备。然而，这确实允许更一致的开发环境和良好的性能。CUDA程序仍然需要重组才能实现并行性并快速卸载计算。

然而，与任何其他专有标准一样，CUDA有一个主要缺点，即潜在的供应商锁定的危险。生产就绪的编译器仅由Nvidia提供，并且仅适用于Nvidia设备（目前仅限GPU）。这使得汽车公司最重要的资产之一，即其生产软件代码面临高风险，因为转向Nvidia以外的供应商可能会使整个现有CUDA代码库几乎毫无用处。除此之外，专有编程模型通常仅在非常有限的一组设备上可用。就CUDA而言，编程模型和API只能用于Nvidia GPU，而不能用于异构系统的其他重要组件，例如多核CPU、FPGA或专门用于AI的定制加速器。

4.2 开放标准

开放标准的一个关键优势在于其多样性：它需要来自许多不同公司和领域的许多专家（每个人都有不同的经验）来设计API的规范。因此，在如此多的利益相关方共同努力实现互利的情况下，可以快速进行改进以解决问题并扭转修订后的规范。不同的供应商提供开放标准实现。软件API为他们的产品提供了适用于各种设备和架构的通用编程接口。OpenCL就是此类已建立的标准之一，该标准可在多种设备上使用。OpenCL不仅被大多数GPU供应商使用，还可用于对多核CPU、FPGA（英特尔和赛灵思）和更专业的处理器（例如瑞萨R-Car）进行编程。

OpenMP是并行编程的另一个成熟且成功的标准。尽管OpenMP最初主要设计为同质多核CPU的共享内存编程模型，但在该标准的最新版本中，它已扩展到异构加速器。如今，OpenMP设备卸载支持可用于许多不同供应商的GPU，包括AMD、Nvidia和英特尔，以及其他专业加速器（如矢量引擎）。

SYCL成为使用现代标准C++和单一源编程模型的开放式并行编程模型主体的新成员。SYCL的设计初衷是作为OpenCL的精神继承者，它避免了早期研究中发现的OpenCL的许多缺陷，例如需要在不同的编译单元之间分配主机和设备代码，或者使用极其冗长的主机API。SYCL还被设计为与C++（作为底层编程语言及其机制）进行极好的互操作。这允许开发人员重用现有顺序实现的重要部分，这已被证明非常有用，可以避免在OpenMP环境中并行化时将错误引入代码中。

尽管SYCL是一个相对较新的标准，但它已受到越来越多的关注，各种供应商都已宣布或已经发布了对SYCL的支持，包括CPU和GPU供应商（AMD ROCm、Intel）、FPGA供应商（Xilinx、Intel）和其他供应商，例如，Renesas/Codeplay为R-Car提供支持。这种广泛的采用以及适用于许多不同平台和架构的特性，使SYCL成为未来汽车软件开发的一个非常有趣的候选者。第6节将更详细地讨论SYCL。

本节中提到的所有开放标准的共同点是，它们都由多党派机构维护，例如架构审查委员会(ARB)或SYCL和OpenCL的Khronos工作组。这些开发和维护开放标准的机构为利益相关者提供了一个参与这些标准开发的合适平台，并为汽车行业提供了一个提高对其特定需求的认识的机会。

4.3 开源安全问题

计算堆栈不断发展，一些软件成为“遗留”，算法得到改进，新的算法被发现来取代不再适用的算法。在动态世界中，对安全需求的考虑很少，技术及其软件将发展得非常快，这是一件好事，因为它推动了创新。更快的创新和迭代开发是汽车行业视为开发消费者想要和法规规定的下一代汽车功能的方法。研究人员使用的许多开源项目并不是按照功能安全标准开发的，但它们很可能也会发展到可用于安全关键环境。一旦这项技术被引入汽车领域，推动快速技术研究的发展速度就会停滞不前，因为它必须遵循安全流程并满足特定的运行安全需求。在开源社区工作的开发人员不一定对安全应用有既得利益，虽然他们帮助开发软件，但他们可能没有考虑支持安全目的的软件。现在，工作负担落在了安全应用程序开发人员身上，他们需要开发工具和软件，而通常只需要更少的人员。

众所周知，汽车是人类最复杂的大众产品，创新呈指数级增长。汽车系列和汽车系列变体的数量不断增加，带来了额外的复杂性。几十年前，OEM专注于三条汽车系列（例如梅赛德斯C级/宝马3系、E级/5系、S级/7系），而现在，可供选择的车型种类越来越多。每条汽车系列中的选项变体也是如此。同一车辆实例与其他系统的连接性和交互性不断增加，进一步增加了复杂性。此外，子系统/组件的设计周期也不同，因此组合集进一步加剧了复杂性的自由度，从而导致“不受控制的增长”和碎片化。根据康威规则，最终产生的ADAS受到公司给定的组织/沟通结构的限制：“任何设计系统(广义定义)的组织都会产生一个设计，其结构是该组织沟通结构的副本”。

5.1 如何管理

汽车行业正在应用多种质量措施来控制软件复杂性和管理软件开发。

5.2 CI/CD挑战

5.2.1 它们是什么？

• 破坏软件API（不遵循商定的开放立场）

• 破坏库的应用程序二进制接口（不遵守C++指南以防止出现问题）

• 大量应用程序数据的存档、管理和传输

• 汽车CI/CD的手动元素

• 应用程序开发中的多个供应商

• 开源和开发方向以支持汽车的需求

CI意味着对ADAS应用程序计算堆栈的所有部分进行高频率的更新。

开放标准和API规范的吸引力之一是它们确保应用程序可以使用已证明符合要求的任何实现。对于开发人员来说，这意味着他们的应用程序不需要为不同的目标重写。但是，新版本的库需要在堆栈内进行测试，以确保应用程序仍按预期运行。支持性开发计划可能会要求使用综合测试套件。

对于一些开发人员来说，跟上堆栈中其他地方的最新变化所涉及的工作可能太多了，因此他们可能会选择推迟升级。这样做的缺点是，开发人员越是推迟，他们在采用更高版本时需要进行的更改就越多。车辆中的OTA更新等技术可以提高更新频率。这非常有吸引力，因为它允许安全更新或错误修复快速到达车辆，而无需召回、增加成本和延迟，但这确实引发了人们对如何在短时间内验证如此复杂的软件的担忧。

虽然开放标准确保了主要版本之间的一致性，但这并不意味着实施者的次要版本始终兼容。如果应用程序升级，第三方软件库可能会通过两种方式破坏应用程序：

1)库对面向应用程序的API（应用程序编程接口）进行更改

2)库内隐藏的ABI（应用程序二进制接口）更改

在大型C++代码库中，组件之间有许多内部接口，无论是内部开发还是由开源社区开发，版本之间破坏二进制兼容性的机会都很高。这些不兼容性更改的根源在于C++语言的使用以及C++编译器编译代码的方式。许多破坏C++的代码更改可以很容易地识别出来，并且通过使用良好的编码开发策略，开发人员可以避免ABI不兼容性更改。

应用程序开发人员投入时间并对他们选择使用的库充满信心。当API或ABI更改破坏他们的应用程序时，他们必须转移资源来调查问题，如果这种情况发生得太频繁，就会削弱信心。库更改和修复的频率意味着有更多新版本的应用程序进入该领域。支持语义版本控制的实现将允许从业者追踪车辆的变化。

SYCL是未来应对并行和异构系统编程挑战的有希望的候选者。它旨在支持从HPC和嵌入式应用程序到强大的机器学习框架的各种应用程序。该开放标准得到了许多公司在各种平台上的支持，例如CPU、GPU和FPGA，旨在为C++带来并行和异构编程功能，并最终与ISO融合。

SYCL不需要任何额外的语言结构（例如编译指示），并且依赖于纯C++。这还允许重新使用现有的串行代码库作为并行实现的起点，并且不需要对代码进行广泛的重构，这两个编程模型的属性在研究中被证明是非常有益的。SYCL运行时将根据数据访问规范将不同的内核组织成一个任务图，并自动处理调度、同步和数据管理。内核本身使用数据并行执行模型，类似于OpenCL或CUDA内核。

6.1 SYCL培训和使用

正如所强调的，SYCL正在发展成为异构编程的行业标准。有大量的培训材料可用。作为主要信息来源，SYCL生态系统网站可用。在这里，可以找到最新的更新、研究活动和代码。对于程序员，可以在Codeplay的SYCL指南中找到更多信息。

图10说明了具有标准化接口的通用流程。

6.2 SYCL现状

尽管SYCL开放标准规范于2014年首次亮相，但它仍在稳步发展以满足其Khronos工作组成员的需求。SYCL正在引起汽车、HPC等许多行业的关注。英特尔最近将SYCL作为其oneAPI计划（英特尔的SYCL实现和支持工具）的核心，为该标准提供了额外的要求。该行业的主要关注点之一，尤其是在汽车领域，是功率和硅效率。如前所述，这迄今为止一直是新芯片和底层硅加速器IP的关键决策标准之一。有不同的实现可用，如图11所示。它们都遵循开放和公共标准，不同的层在不同的硬件上运行，如图12所示。此外，SYCL内核可以同时在CPU以及多个目标分立设备（如GPU、DSP或FPGA）上运行，这进一步提高了其性能和可移植性。SYCL规范在其设计中解决的另一个因素是能够以一种对开发人员不具侵入性的方式管理主机和目标设备之间的数据移动，并证明其成功。SYCL管理主机和设备之间的多个数据依赖关系，并在开发人员提交内核以供执行后同步数据。对于SYCL采用者来说，一个有趣的点是，虽然存在SYCL规范，但采用者或SYCL实现开发人员不必完全遵循该规范。可以根据客户的需求定制实现，这意味着在必要时可以采用更轻量的实现。如果产品要通过认证并作为具有SYCL实现进行销售，则SYCL实现必须遵循Khronos规范。

有多种性能数据和基准测试活动可供使用，它们侧重于特定用例和场景。有研究显示了SYCL和CUDA之间非常相似的性能结果。它展示了高度参数化的SYCL内核如何比手动调整的库（如clBLAST等）具有竞争优势。对OpenCL和OpenMP进行了比较。在这里，结论表明SYCL的性能差距仍然存在，但强调了进一步缩小的潜力。使用SYCL编写内核程序以通过使用并行性来加速计算密集型任务的ADAS或AI应用程序，开发人员可以在图12中所示的任何目标设备上执行他们的代码（在每个不同的实现下方），而无需重写内核程序。借助SYCL的单一源应用程序开发模型（内核和主机代码并排），可移植性是关键。所有SYCL内核程序都将计算相同的结果，无论它在哪个设备上执行，尽管它们的执行速度可能会有所不同，这是预期的。到目前为止，CUDA的表现也优于SYCL，但跨平台SYCL应用程序的优化才刚刚开始。公开数据源得出的明确结论表明，SYCL的性能非常接近专有和硬件特定的实现。汽车行业对高度优化的实现有着明确的需求，这将进一步加速这条道路上的进展。

在开发周期中，需要各种KPI来评估、量化和评定汽车软件项目的能力。这种多维KPI需要分数权重来汇总为一个分数。权重可能取决于项目目标、供应链角色和用户范围。然而，人们强烈地感觉到，以下项目与该领域的大多数用户相关，其中人工智能、计算机视觉和可维护性的重要性权重越来越大。图13描绘了主要相关KPI领域的高级概述。

不仅这些技术方面，而且组织、法律和商业方面也需要考虑和衡量。越来越短的开发周期最终将导致对持续开发的需求，并且至关重要的是优化开发时间。虽然库的可用性至关重要，但它们的底层成熟度才是关键。使用此类流程的人越多，开发流程的成熟度就越高。相应的汽车KPI与组件/子系统级别相关，也与系统级别相关，如图14中的仪表所示，其中每个组件都经过测量并且对整体系统性能有很大贡献。