针对ADAS应用优化编译程序性能分析

汽车产业的所有主要原始设备制造商(OEM)和软件供货商都在致力于研发先进驾驶辅助系统(ADAS)。但如果仔细了解，你就会对ADAS应用对编译程序和工具集提出的要求产生诸多疑问。传统的汽车应用和ADAS之间有所区别，为了更好地满足ADAS需求，需要对目前的编译程序进行一些升级改造。

ADAS应用是一种挑战为了更好地支持自动驾驶任务，汽车需要更清楚地了解它们的周围环境。有几种新的传感器如雷达、激光雷达、摄影机等，可用来以高分辨率检测路标、其他车辆、障碍物和其他相关的环境数据(图1)。过去，汽车系统通常只是实时处理来自一些特定执行器(转向角、踏板位置、各种引擎传感器等)的单独测量资料。

图1 基于传感器的不同ADAS应用的监测区域。

然而，与一般的物理测量一样，ADAS应用采集的环境数据存在噪声(图2)和测量误差。因此，这些数据在可以用于最终用途，即自动帮助司机减轻决策负担之前，需要用硬件和软件进行电子后处理。然而，这种后处理并不总是处理像以前那样的单独测量数据，很多时候会将来自不同来源的数据合并(传感器融合)，从而降低误差敏感性。
、

图2 环境传感器产生的有噪声讯号及滤波后的结果。

为了使ADAS能够根据司机行为自动做出决策，ADAS必须能够实时处理大量数据。另外，这些数据很复杂，以前的做法是只处理整数或定点数类型、速率为1~5kbps的单独传感器数据。但今天提供的数据经常是浮点类型(浮点/双精度)，而且速率很高。举例来说，摄影机影像的速率约为340kbps，雷达数据约为1.5Mbps。

很显然，与传统的汽车应用相比，ADAS应用要求更强大的处理能力，但现在很难预测哪种高性能的硬件架构更适合这些类型的应用。由于必须以可重复使用和高成本效益的方式实现ADAS应用，因此很明显对所有架构来说都要求得到编译程序的支持。在这种要求下，必须使用抽象、可移植的设计方法(如C++11/14)、基于模型的设计方法和包括平行程序设计(如OpenCL、Pthreads)在内的其他技术。此外还要求高度优化的、经认证的函式库来高效、安全地实现标准运算，并尽可能地提高硬件的独立性。因为ADAS应用会干预驾驶过程，所以这些应用和执行它们的硬件也必须符合相关的安全标准(ASIL-B或更高阶的ISO 26262)。

寻找一种合适的硬件架构

对于开发ADAS应用的公司来说，直到现在也没有哪种硬件架构成为主流，这使它们面临风险。一般来说，一些主要的硬件加速器——包括NVIDIA GPU的衍生产品(Drive PX)——可以为ADAS应用的资料平行部分提供每秒万亿次浮点运算(Teraflops)等级的足够运算能力。然而，除了缺少足够的安全特性外，这些组件就功耗和购买价格而言成本相当高。另一方面，适合直到ASIL-D(包括AURIX或RH850在内)的安全关键型应用的典型架构，还没有利用到硬件方面的机会来实现更高的数据速率，因为这些架构很难通过ASIL-D的认证。

因此，ADAS系统的OEM或大型供货商存在选择架构的风险，可能会由于架构太大、太昂贵或不能满足安全要求而卖不出去。另一方面，即使选择了一种完全支持安全关键型应用的架构，也存在这种架构太小无法满足更严格的运算要求的风险。在开发过程中，可能会出现预期应用由于效率原因而无法实现的问题。

因此，ADAS项目的要求非常复杂。一方面，开发人员必须创建非常高效的、特定目标的程序代码，满足所有安全目标，并尽量减少上述风险。另一方面，有必要采用可移植的高级设计方法进行高成本效益的应用开发。这些高级设计要求，使得原本为传统嵌入式应用设计的嵌入式编译程序必须作出修改。

程序代码结构的效率

一种必要的新的编译程序特性是需要支持ADAS应用的典型程序代码结构，以便为这类应用创建高效的程序代码。ADAS应用中使用的数据结构及其经历的运算与经典应用中的有根本区别，用于传感器融合和分析传感器数据的程序代码通常是用BASELABS等模型化工具生成的。举例来说，ADAS程序代码中与速度有关的部分通常涉及浮点和双精度类型的数组(向量和矩阵)，这些数据会经历诸如矩阵乘法、倒数、奇异值分解(SVD)等线性代数运算。系统透过这些运算将传感器数据数组组合起来运算环境的抽象表述，然后用作决策的基础(例如检查影像中的对象，或跟踪和分配物体的空间位置)。

高度优化的函式库

这种数组和浮点数的大量使用，意味着需要对编译程序进行全新的优化，才能提供有效的结果。举例来说，最常用的线性代数函数一般是由针对特定目标架构高度优化的函式库所提供。因此，函式库中没有包含的所有运算必须用编译程序很好地优化，才能避免这些运算成为瓶颈。

ADAS应用中许多性能关键型运算是基于一套标准的线性代数运算实现的。如果这些标准运算使用标准界面，则可以极大地减少将这些ADAS应用移植到不同目标架构所造成的开销。大多数相关的硬件平台都提供支持标准接口的函式库，以及针对特定目标架构高度优化的函式库，包括Tasking为嵌入式应用开发的LAPACK、NVIDIA的cuBLAS和英特尔(Intel)的Integrated Performance Primitives。

一般来说，这些函式库的速度要比开放原始码产品或公司内部实现快一个数量级。因此基于标准接口的应用可以很快取得很好的效率，即使在新的目标平台上也可以，而且无需程序设计师自己优化和测试特定目标函式库中的性能关键运算。然而请注意，不是所有的函式库都针对安全关键型应用做了充分的认证，也不是所有函式库都适合嵌入式系统。

平行程序设计

嵌入式编译程序要求的一个额外的新功能是支持当前的语言，如C++11/C++14。ADAS设计的目标是提高程序代码的可重复使用性，用更少行程序代码实现更多的功能，而又不放弃接近硬件提供的效率。C++这类和继承是经过时间验证的方法，非常合适在更高、更抽象的层次编写这样的程序代码。

C++11以及后来的版本都支持这些方法，但与更早的C99语言标准相比具有显著的优势。另外，C++11(和C11)最终还能用来编写可移植的平行程序。许多ADAS应用的运算开销在考虑所有响应时间要求后，经常超过在单核心上实现的连续处理能力。因此，平行和多核心处理是常见的ADAS系统要求。

像C99等旧标准不支持平行机制，因此使用这些语言的程序设计师必须具有很好的硬件和编译程序知识，才能正确编写出平行程序。举例来说，程序设计师必须将特定的数据范围和代码段排除在平行访问之外，从而确保不会丢失数据更新或在访问期间错误读取。程序设计师还必须在程序代码中插入屏障(互斥体)，防止关键部分在同一时间被一个以上的核心执行。

然而，屏障插入技术只有在编译程序理解这些屏障时才有用。如果没有这样的概念，那么在编译程序或硬件优化过程中，编译程序会将这段程序代码移出受保护的部分。在C11/C++11发明之前，还没有统一的方式来将这种屏障通知给编译程序，因此程序设计师必须禁止全部重要的优化功能，从而导致严重的效率下降，或者他们会误用诸如「volatile」等属性来限制编译程序的优化功能。现在大家都已知道，使用「volatile」属性对于编写正确和可移植的平行程序代码来说是不够的。

然而，互斥体现在已经是C++标准的一部分，因此C++11编译程序理解所有的屏障概念，编译程序在必要时能够防止应用出现优化，而导致任何不必要的速度损失。与使用优化不同，程序设计师可以使用C++/C++11引入的「atomic」属性，编译程序用「atomic」属性产生的程序代码，可以透过寻址硬件来揭示期望的行为，并产生最小的性能开销。这样，程序设计师就能专注于他们的主要任务，即程序代码功能，而不用试图透过不合适的方式(如「volatile」属性)和优化习惯去产生特定程序代码。

遗憾的是，一般不可能检测出所有对平行访问保护错误的程序段和数据。有时保护错误的程序不会产生任何编译程序错误，看起来似乎工作正常，但这些程序可能会因为不明显的时序问题而自发产生错误的结果。这些错误一般只出现在很长的测试时间之后。另外，它们也很难重现，因为它们取决于相应的运行时间以及系统内与时间有关的干扰。

因此，即使是用C11/C++11编写正确的平行程序代码，也不是小事一桩了。自己编写的平行程序代码也可能存在虽然正确但只比更易维护的、功能相当的顺序程序代码快一点点(甚至更慢)的风险。幸运的是，像EMB2和LAPACK等函式库用起来相对风险就很小，因为它们都是这个领域中的专家编写的。作为额外的优势，这些函式库由于其平行机制及优化，可以确保相对较大的速度提高。

硬件加速器支持

编译程序还需要具备一些新的功能来满足越来越异构的硬件架构要求。这些架构拥有差别很大的核心(ARM、AURIX、RH850、NVIDIA等)和补充的加速器(如AURIX中的FFT、ARM和NVIDIA中的SIMD)，也有多种解决方案。一种方案是原生支持，最直接的方法是支持硬件加速器。这些构造可以用来处理来自C/C++的特殊硬件指令。

更高级的编译程序可以支持加速器供货商提供的特殊高级语言(大多数类似于C)，从而说明程序设计师高效满足硬件要求。例子包括NVIDIA的OpenCL(NVIDIA的编译程序)、GTM的C(Tasking的编译程序)和德州仪器(TI)的EVE扩展C语言。虽然这些高级语言要求编译和优化，但它们与底层硬件的接近简化了整个过程。

作为最后一个选项，编译程序可以自动检测可被加速器高效执行的程序代码区域，以便自动生成合适的程序代码，如同Intel的icc之于SIMD架构。然而，在大多数情况下这种全自动的发现是受限的，因为标准C/C++程序代码不是明确为特定加速器编写的。不过，只需修改少量的程序代码，编译程序的自动发现就能产生很好的结果，尽管为了在合理的开销条件下寻找和实现必要的修改，一款合适的调节工具是必不可少。

遗憾的是，许多异构硬件架构强制要求用自己的编译程序寻址每个可程序设计单元。为了避免应付过多的不兼容工具，防止产生新的安全风险，建议使用能够寻址所有可程序设计单元、确保工具之间互相兼容的工具环境。比如Tasking提供的英飞凌(Infineon)AURIX/TriCore工具环境，就可以在一个集成开发环境(IDE)中程序设计和调试架构中的所有单元。因为符号信息在不同单元之间是兼容的，所以可以更安全地控制和监视单元之间的交互。

ADAS应用的安全要求

为了满足ADAS应用的特殊安全要求，所有工具(包括建模工具、编译程序和分析工具)，以及与这些应用相关的软件组件(操作系统、函式库等)必须依据ISO 26262进行开发和认证。

一些较新的安全要求可以利用神经网络来理解(图3)。神经网络是一些软件组件，经常用于检测和处理ADAS应用中的传感器数据。虽然市场上有许多基于神经网络的有趣原型，但仍然不清楚如何确保这些网络在极端情形下有正确的行为。

图3 一些较新的安全要求可以利用神经网络来理解。

目前还没有已知的过程可以确保神经网络的行为一直正常，而对道路使用者来说没有风险。因此，如果没有合适的监控实体，就不能让神经网络做出安全关键型决策。除了神经网络自己用的硬件外(这些硬件会根据输入数据提出难以预测的决策建议)，必须有一个在硬件上运行的、具有最高安全认证等级(ASIL-D)的监控实体。这个监控实体会使用可预测的算法工作，检查由神经网络做出的建议是否能被安全地执行，或者是否应该选择更安全的方案(图4)。举例来说，监控实体会检查由神经网络建议的通行方案是否能够在没有风险的条件下执行，出于这个目的，它会使用自己的、可预测的运算来检查是否没有障碍物等。为了创建有效的监控实体，人们仍在努力研究某些领域(比如资料融合)中的可预测算法。

图4 资料融合单元。

针对ADAS应用的许多可预测算法都是基于LAPACK和其他函式库支持的线性代数运算实现的。可以用优化的解决方案在各种目标平台上高效安全地实现这些算法。

ADAS应用的其余部分可以用有助于满足各种ISO 26262要求的多种工具和技术进行认证。简单的程序设计错误(包括没有初始化的数据)可以用静态分析工具(Polyspace、Klocwork等)实现高效检测。为了检测与安全相关的访问违例(具有不同ASIL类别的软件组件彼此访问，并在内存保护单元(MPU)中创建保护故障)，使用编译程序整合的安全检查器扩展是很有好处的——它能用来定义不同的安全类别(比如ASIL-A到D)，将项目中用到的数据和函数分配到不同的安全类别，并管理这些类别之间的访问权限。

然后，这个信息可以用于两个目的。首先，编译程序无法执行某些优化(反向程序代码嵌入、程序代码压缩)，因为这些优化在执行时，如果没有考虑访问权限问题，可能会导致安全访问违例。其次，可以用安全检查器工具，将这个相同信息用于识别可能产生MPU例外、未检测到的访问违例，而不会有任何额外的测试开销，而且有很高的程序代码覆盖率。

为了依据ISO 26262对工具(建模工具、编译程序、静态分析、安全检查器等)进行认证，大多数制造商提供可极大简化必要过程的ISO套件。在这种情况下，选用在汽车领域中具有悠久历史的工具和制造商会很有帮助。出于这个目的，ISO 26262-8使用了术语「久经考验(proven in use)」，它的假设是，一款在很长时间内得到频繁使用而且几乎没有问题的工具，与新工具相比可能不太容易出错。

除了解决上述安全风险外，编译程序及其相关工具有助于减轻与ADAS应用有关的设计风险。

控制设计风险

如果选择不合适的硬件、函式库和开发工具组合，可能会在ADAS领域产生较大的设计风险。目前针对特定的ADAS应用，基本上无法预测特定软硬件组合的效率。

举例来说，可能存在所用硬件太大、太耗能或者太小的风险。遗憾的是，目前没有连续的系列可用：结果证明太小的硬件无法用尺寸稍大一些的兼容硬件直接替换。设计人员可以在具有较低安全认证等级的很大配置和具有较高认证等级但小得多的配置之间做出选择。目前两种选择之间的转换会产生过多的开销，因为在架构及其最佳使用所要求的程序代码结构之间存在显著的差异。

目前这个问题可以用编译程序单独解决。然而，如果有配套的合适软件环境的话，编译程序可以使得这种风险完全可控。如果能够将基于特定硬件、高效线性代数函式库的良好建模解决方案与能够满足ADAS应用典型要求的编译程序环境结合起来使用，那么得到的综合解决方案将胜过两者的简单迭加。

ADAS应用很大程度上可以使用建模解决方案并以独立于硬件的方式实现。底层的编译程序和函式库支持将基于模型的通用实现移植到有很大差异的硬件平台上，并且开销很小，效率很高。由此导致的少量效率不高可以透过性能分析(profiling)来实现快速识别和消除。

对通用程序代码来说，这种组合方案可以在各种目标平台上提供实现最佳效率的确定性快捷方式。透过利用一组额外的、根据目标硬件和输入数据分辨率记录有所有工具的组合效率的基准，这些数据可以用来预测新的ADAS应用在新的目标硬件上的期望效率，并且具有较高的精度。这将极大地降低选择到不适合预期ADAS应用的目标硬件风险。

目前市场上的编译程序没有哪种能够满足所有要求，完整解决方案所要求的一些工具和函式库也不是唾手可得。因此，编译程序的路线图很清晰：必须在不忽略整体解决方案的条件下满足剩余要求。举例来说，Tasking正在规划新的产品，包括用于AURIX的认证过的LAPACK函式库，这些产品得到了工具合作伙伴和用户的大力支持。