地平线：面向规模化量产的智能驾驶系统和软件开发

在整个智能驾驶中，如果从大的领域划分，可以看到有、、和几个大领域。如果是根据算法时代来划分，可以划分成和。

是传统的CV，或者是在端到端的深度学习落地之前，基于规则实现的一些面向自动驾驶的软件和算法。是未来可以通过深度学习和数据驱动，端到端的把整个软件算法性能迭代起来。但描述它时都是用软件1.0和软件2.0，这其实是一个广义的软件定义。那对于一个智能驾驶的软件工程师来说，这时就要承载上面所有领域的研发工作。

一个软件研发工程师，他的能力要求该如何被定义呢来看，因为要做嵌入式开发，懂C++就可以。但如果是面向智能驾驶业务开发的工作，那；；；。

1.2 智能驾驶环境感知拆解

主要看下。我们把它做一些简单的拆解：

• 如果做环境感知，首先要有一系列的，有，有、、、、、等。
• 然后，在一个嵌入式SoC上有很多的硬核，需要对，来执行模型。对，比如模型的前处理、后处理。
• 基于底盘信 ，要做自测里程计，用到Odom。有了感知结果和Odom之后，会做感知结构化，进而可以做动/静态的目标重建、自车的位姿估计。
• 同时，为了做软件2.0，整个的数据闭环能够以数据驱动迭代算法，还要在。对于一些特定的数据做，把缓存信 再发出去。

这个过程都是需要软件来做的，后面也会逐一的进行拆解：。

1.3 传感器及数据—时间同步

首先看摄像头，。对于算法的同学，可能只关注ISP Tuning和图像的成像质量，那除此之外还需要关注哪些方面呢p>

在做一些高等级的自动驾驶算法时，目前已经和过去的时代不太一样。在过去传统的视觉感知过程中，经常是由人工标记2D的bounding box，然后做模型训练。而对于未来一些3D算法，像特斯拉最近开放了很多的BEV算法，地平线也实现了BEV算法，这些算法中对摄像头的同步，及其对于时间系统的要求是非常高的。所以软件工程师和算法工程师，都需要理解摄像头的曝光原理。

Global Shutter和Rolling Shutter大家可能都会知道，但是Rolling Shutter的曝光原理到底是什么时间是我们经常提到的ISP曝光控制时间，它和每行传感器的数据生成时间到底是什么关系数据生成，比如曝光时间是10毫秒和一帧数据生成的30毫秒，关系到底是什么器中间的时序到底是如何设置的是后续整个算法设计，视觉和其他传感器对齐中非常重要的一点。

同时摄像头的曝光触发模式，也会是多种多样的。比如一些标准的触发模式，像Shutter Sync。刚才谈到时间同步时有PPS信 ，标准触发模式一般都是接收到PPS信 ，摄像头立刻曝光触发。Shutter Sync会有一个确定性的延迟，然后让数据开始往外传输。这两种模式得到的传感器时间是不一样的，它的物理的意义也是不一样的。

在做多传感器对齐时，不同的曝光模式对后续的算法和软件实现差别都会非常大。对于软件来说，一个摄像头，除了曝光原理、触发模式，还有很多其他的信息需要了解，因为对于摄像头这种高频的数据，还有很多的异常需要做检查。像高速接口MIPI很容易受到外部电磁的干扰；MIPI校验，CRC校验，每一行数据宽度的校验；有了传感器，它会有一些复杂的功能，传感器内部温度是否过高，也需要做校验。传感器是否会被人调包，算法适配的传感器是不是装错了，装成了别的型 ，这时还有一些传感器的identity验证。每帧数据在效应区，如上图左上角的效应区，Embedded Data里有单帧的2A，FuSa等信息，这些都是软件开发者需要关注的事情。

对于模组来说，还要做很多管理相关的事情，像模组的版本管理。因为在量产过程中，模组也会有很多的版本，它是AA对焦的的对焦是什么状态的材质、Lens内参存储在什么位置模型到底用的是什么材质在不同的温度下，镜头内会不会起雾ns的光学特性，Lens会不会出现一些鬼影和擦散光这些都是在自动驾驶开发过程中，软件工程师需要关注的一些点，通过这些才能够把整个系统串起来。

同时，多传感器曝光在曝光原理部分就能很好地体现出来。如上图右下角所示，一个传统的机械激光雷达，处于一个360度扫描的状态。Lidar在0时刻扫描时，摄像头到底从哪个时刻要触发曝光，到底是选择用Standard trigger还是Shutter Sync，这都是整个系统中软件工程师需要明确讨论的内容。

对于激光雷达来说，有哪方面的应用呢自动驾驶可能会选择激光雷达作为感知传感器，低阶自动驾驶会使用激光雷达作为一个真值系统。而现有的2.5D/3D算法方案，都会使用激光雷达真值做自动化的数据标注方案。

激光雷达有很多不同的种类，比如有，如上图左下角所示，是一个360度旋转的激光雷达。激光雷达可以接收时间同步的PPS信 来调整马达转速，让激光雷达在它的坐标系定义的0度上，和0时刻对齐。还有一些。。旋转镜跟机械激光雷达的精度差不多，也是旋转的形式，从左至右扫描过去。也有一些非重复的、非规则的扫描，而得到的点云对于人来说，直观理解会比较困难。也有纯固态的Flash激光雷达，激光点阵模拟camera曝光方式进行扫描。

对于激光雷达的扫描方式，也都需要时间同步。通过PPS调整激光雷达和不同摄像头曝光时刻的角度去对齐，达到右下角图所示的情况。每一个点经过时间对齐、传感器之间的标定，能够让激光雷达的点云与视觉实现一个完全对齐的方案。

激光雷达在部署过程中，也会经常会遇到很多问题。激光雷达目前，UDP协议 络带宽的负载会比较高，使用时也需要设置 络环境/VLAN隔离；Lidar 络包比较小，一般是一个MTU发一包数据，这就会导致 络包非常多， 络中断响应也会非常多，影响整个系统的响应能力；未来征程芯片也会支持硬件 络拆包来解决这些的问题。

激光雷达在使用的过程中，也会遇到非常多的问题。虽然激光雷达的精度是比较高的，但使用过程中会碰到各种的镜面反射，你将会得到一些预期不到的点。。激光雷达在高速上比较不幸时，有些小虫子可能会撞上激光雷达，导致传感器出现一些故障；以及激光雷达对不同的物体，反射值也是不一样的。通常我们也会设置不同反射值的映射，对于不了解激光雷达的开发者来说，有时拿到一些反射值可能会觉得比较奇怪，为什么有的反射值这么高，有的反射值这么低。

对于非纯固态激光雷达，供电稳定性也会是一个很大的问题，。如果做不到稳定的激光雷达供电，有可能也会导致光头或者机械元件出现异常，从而导致点云出现异常。同时，也需要关注多传感器对齐，这些对于软件开发来者来说，都是非常重要的工作。

激光雷达在高频的UDP数据包情况下，协议解析如何做到非常低的延迟，尽可能地降低CPU负载，都是软件开发者需要关注的事情。同时，传感器和算法之间达成一致，也是在整个自动驾驶系统软件开发过程中，需要上下游不停拉通、对齐的事情。

对于激光雷达，地平线也有很多合作伙伴，都能够比较好的支持地平线的感知系统构建及真值数据构建。

1.6 传感器及数据—其它传感器

多传感器标定对系统的时间精度要求非常高，如果所有的传感器不在一个时间系统下，很难获得比较精确的时间；同时，摄像头、激光雷达的扫描方式不同，需要理解多传感器数据的生产原理，保障多传感器的时间是对齐的；也要理解应该如何做传感器数据的时间补偿，如何让多传感器达到对齐的效果；最后，还需要多传感器的联合标定算法。

在这个过程中，一方面是标定算法的精度，另一方面，工程化是非常重要的，特别是在产线标定过程中，如果工程化出现了问题，产线会被block，非常影响效率。

1.8 传感器及数据—数据采集及标注

那有了数据文件之后，该怎么把它用起来呢还需要很多的数据工具，需要开发各种数据访存SDK，像视觉数据、雷达数据，它们的文件size都是非常大的，在数据的访问、查询、跳转、反序列化过程中，或解码过程中，效率是否足够高。对于数据的统计能力，数据帧率、延迟、关键信 的稳定性，底盘数据是否丢失，数据转码效率是否会很高，是否能够很明确的给这些数据一些label，让下游真正的把数据用起来。

对于数据调试和profile工具，当拿到一个数据时，可以构成各种信 的topic，是否能够很好的关注这些topic的波形图。对于数据来说，是否能够分析实际运行过程中的WCET，进而分析执行时间。由于数据都是在后台运行，所以也需要展示工具，展示图像、感知结果、3D信息、点云。在车内也需要有HMI，如上图右半部分所示，是点云数据和HMI的展示状态。

接下来讲解和部分的内容。

硬核调度如上图所示，今天简单讲解两个部分，首先是Codec。

征程3和征程5提供4K@60fps Codec + 4K@60fps JPEG编码能力。对于Codec，如果只是使用它，不会有什么问题，我们的软件工程师需要看Codec编码到底是做什么用的。对于数据采集来说，Codec要尽可能的调高图像效果。

Codec码率应该如何设置，QP值该如何调整。如果是JPEG，quality配置究竟调成什么质量，才能够满足后续算法的迭代过程。除了给算法进行训练，Codec还有一些DVR数据回传的需求，当带宽不足时，又要权衡究竟设置什么样的码率和图像质量，能够满足数据传输的size要求。

通常Codec在单SoC只有一个加速硬核。但单SoC有6V、10V、11V的系统，虽然Codec能力很强，但Codec也需要一个比较好的调度器。如上图下半部分所示，是一个简单的调度器，它主要是在硬件响应过程中，与硬件交互，让中断更加及时响应到用户层。

在传统的感知方案中都是一些2D的方案，而现代的一些算法方案，不管是3D方案，还是未来的BEV的方案，都需要在模型后期，再增添一些传统的CV算法。在感知模型基础上，进行感知结构化处理。

• 首先，要有一个自车的位姿估计。位姿估计可以使用车辆底盘积分，对于简单的行车模式下，Speed+yaw rate就足够了。而对于一些低速场景，还需要引入轮脉冲轮速、方向转角等方法。对于每辆车的yaw rate，即横摆角速度，也会存在一些bias。当车辆处于静态时，就会有一个静态偏置，动态时也可能会有一个动态偏置。把 bias估计好才能够得到一个更好的自车里程计。

• 同时，也可以使用IMU和GPS来提高里程计的精度。上图右上角是一个行车的轨迹图，它有两种颜色，一个蓝色和一个橙色，通过Odom的提高，展示出了两种不同方法的实现结果。

使用IMU，还能够进行3D姿态估计，特别是在跨层辅助泊车的场景。在这个过程中，也会遇到很多工程上的问题，对于CAN数据、底盘数据到SoC系统里，它的链路是比较长的，如何更好的提高系统的响应，保障Odom延迟在一个可接受的范围内，这也是软件工程师需要解决的一些问题。

• 在动态目标建模方面，要处理的是一些多目标跟踪、运动学的建模，（CV、CA、CTRA等），以及不同的滤波器（EKF、UKF、PF等）。在处理过程中，也需要图像空间与3D空间进行交叉验证。同时，动态目标建模也是一个时间敏感的系统。对于场景的不同，会有一些不确定性。因为传统CV和多目标跟踪，它的耗时是随着目标数量而增长的。而对于深度学习，耗时的确定性是比较高的。对于软件工程师来说，一方面需要用数据工具，profiling整个系统，能够动态的调整数据流，让整个系统尽可能压低负载和延迟。

• 同时，也要去考虑对于确定性和不确定性，后面应该如何解决它。对于软件2.0的系统，或端到端的系统来说，需要把更多的传统CV部分，转移到深度学习模型或BPU模型，能够被硬件确定性执行的部分，来提高整个系统的确定性、稳定性和延迟优化。

1.12 软件调度框架

Bole也会提供Zero-Copy共享内存通信机制，同时也会内置一些自适应通信策略，来保障节点部署是一个最佳通讯的模式。Bole提供多平台的支持。开发者除了在地平线的芯片上开发，还会在不同设备上进行开发。很多的算法开发者在做算法开发时，不管是调度框架还是通讯框架，在个人的电脑集群上都需要提供编译、调试能力。同时，对于通讯来说，算法在集群上做模型训练，也可以通过Python接口，让算法简单的替换嵌入式模块的一个程序，这样也能够快速的进行算法原型验证。

调度和通讯是大的框架级别，再深入是每一个Node。如果一个Node的运行时间过长，什么样的调度框架和通讯框架都很难进一步的提升性能，所以软件性能优化也是整个软件团队非常重要的一部分，这一块也需要非常深入的了解才能够完成。

做软件的性能优化，需要理解芯片的一些架构设计。首先，需要理解整个Memory Hierarchy，即整个内存的层级系统，也需要理解总线带宽、DDR带宽、DDR控制器到底是如何运作的，还有DDR工作模式。因为现在大算力的SoC，DDR通常是双通道和多通道，DDR到底是运行在并发模式，还是在其他的模式下运行，DDR的QoS到底给哪个硬核才能让它的响应最高，这些都需要考虑到。

对于CPU来说，CPU L2 Cache，L1 Cache工作模式是什么，各级Cache Size对系统性能影响是什么中什么样的数据需要自动去刷新，什么样的数据不需要BPU来说，一个模型有多级的SRAM，它的工作机制、模型调度与IO之间的overhead到底是什么样子的p>

对于DSP来说，又会出现一个TCM，TCM和DDR之间使用DMA。对于TCM的使用，到底是使用什么样子代码固化在TCM上，什么样的代码固化到DSP的cache上。

以上这些对整个的系统，整个Memory带宽、软件性能有非常大的影响。

同时，要理解整个芯片设计的Interrupt Hierarchy。当一个系统里有十几个摄像头、几个激光雷达，整个系统的中断是非常多的。我们的软件究竟如何配置中断，中断和CPU之间中断响应是如何绑定的p>

也需要在纯计算优化的方式上，深入理解向量化编程。向量化编程一般都称它为SIMD，在ARM上有NEON，在PC上有SSE以及DSP这种SIMD指令，这都是非常重要的软件优化手段。

内存访问需要静态化。因为现在大家开发都在 OS以上，不管是Linux也好，QNX也好，对内存的静态化非常重要。特别是在QNX系统上开发，QNX对内存每次申请释放都会有很多的安全性校验，如果是太多的碎面化内存，整个系统的overhead会非常重。

CPU计算的定点化。定点运算肯定比浮点运算要快，什么样的算法能够定点化，这也是软件工程师和算法工程师需要去深入沟通的。系统里到底哪一部分算法是非常重的overhead，能否把它定点化实现。

对于整个复杂的自动驾驶系统，像11V、3L的系统，它的线程/进程非常多。线程和进程的优先级到底是什么样子个实时系统里面，不同的功能模块的实时优先级配置，线程是否能够合并、绑定。

在系统整个的通讯优化方面，因为系统里面会有各种各样的信 ，可能会有非常高的高频信 ，也有一些低频信 ，哪些信 是可以合并的，哪些高频信 可以做一些打包。例如可以把一些高频信 ，比如每个信 都是100赫兹，有几十个信 能否把它们全部打包成一个100赫兹，减少通讯的开销。

更高要求是一些算法复杂度的优化。算法复杂度的优化，通常有可能把一个算法耗时降低一个数量级。

最痛苦的有可能就是纯代码级的优化。因为需要在代码中一个点一个点去check，发现到底有哪些点可以再进一步的优化，能够把系统的性能进一步的提升。特别是量产的最后阶段，有可能花很长的时间都是零点几个点的CPU降低，但这也是非常值得的。

综上所述，在地平线各代的征程芯片上，上面讲到的各种软件相关的开发事项，遇到的各种问题，以及问题的解决，它们在地平线的量产落地的项目中都有体现。

过去地平线已经完成了从0到1的突破，现在也准备和行业伙伴一起实现从1到N的开放共赢。大规模量产是验证智能驾驶产品技术领先性的首要标准，刚刚讲到了很多在量产过程中遇到的问题和解决这些问题的经验。而把这些问题和经验分享出来，也是希望能够帮助大家在后续量产的过程中更好地应对这些问题。

2. 软件视角的“软硬结合”与“软硬解耦”

因而，从芯片到上层的操作系统，基础中间件、应用中间件的软硬结合，再向上提供给我们的应用开发者，去开发各种各样的智能汽车应用，达到软硬解耦。

3. 智能驾驶软件开发平台Horizon TogetherOS Bole?

在征程5代芯片发布时，也发布了TogetherOS，Bole是TogetherOS中的应用中间件部分，即软件开发平台。Horizon TogetherOS Bole?是面向高等级自动驾驶的软件开发平台及中间件。

首先，介绍下高等级自动驾驶系统面临的难点与挑战。第一，自动驾驶车载软件的架构复杂度是陡增的。在过去的两三年，L2级别单目的视觉系统比较主流。而从2021年开始，一辆车装载多个摄像头，完成NOA（领航辅助驾驶）等功能，已经逐渐开始是一个标准化的过程。未来到城区自动驾驶，传感器会越来越多，整个自动驾驶的车载软件架构设计，复杂度也是陡增的。在快速迭代过程中，如何能够提高开发效率，实现快速的复制，加速量产开发的进程，都是会变得非常重要。

第二，自动驾驶平台软件关键技术还没有标准化。传统车载应用软件的开发范式，很难做到以数据为中心的数据闭环。整个数据闭环过程中，传统的软件开发方式会显得比较困难。AutoSAR AP、ROS等高等级自动驾驶场景还处在初期摸索阶段。在落地过程中，各有千秋，目前行业中还没有形成统一的面向高等级自动驾驶的软件开发平台及中间件。

第三，高等级自动驾驶也需要更高的安全性保障。关于功能安全部分，此前也有同事有过相关的分享。

最后，高等级自动驾驶也需要高算力的支撑。L3+自动驾驶算法复杂度及功能安全的冗余设计，随着自动驾驶等级的提高，其所需算力呈指数提升，需要BPU/DSP等异构执行单元对算法进行加速。同时，当前单芯片的很难满足算力要求，多个异构芯片混合，软件与计算平台协同也变得越来越困难，自动驾驶计算平台的有效算力很难得到充分发挥。以上这些都是高级自动驾驶系统面临的一些难点和挑战。

总结一下，需要安全可靠、极致效能，简单易用，而且也要面向下一代智能驾驶，是一个能够很好达成软件开发的系统，而且也需要是一个开放且兼容的系统。

Bole会产出一套面向高等级自动驾驶的开发范式；BoleStudio IDE，能够把不同的模块、不同的node，以DAG的形式展现出来；BoleViewer，能够完成数据可视化；还有一些数据工具，像Recorder、Repaly、SensorCenter；包括车身的一些通讯VehicleIO；也有之前谈到的Bole Dataflow调度框架，通讯框架Communication，BPU调度框架EasyDNN等，它们都是为了能够快速的开发和集成。同时，HobotCV也是面向征程芯片不同的硬核计算单元，提供高效的接口抽象。

数据闭环，也是以数据驱动开发，助力自动驾驶应用快速落地。在实车的环境下，要实时抓取传感器的数据，在实车的应用软件下，能够把传感数据与日志进行录制，包括传感器的标定、常规数据采集。数据回来之后，刚才也提到数据工具也会非常重要。在云端要有数据回灌的能力，特别是在云端和艾迪的配合，对于批量的数据、批量的设备来说，艾迪平台和Bole一起协同，能够把数据的开发、回灌、回归、数据可视化总体整合起来。同时，也提供一个BoleStudio的AI应用开发集成环境，能够做到持续的改进与开发。

4. 智能驾驶应用软件开发趋势展望

基于整个开发框架，会有各种各样不同的模块。上图所示蓝色的部分是地平线所做的开放框架，把在软件框架以及量产工程实现过程中，遇到的一些经验和问题抽象出来，作为一些开放的框架。同时，用户也可以自定义的完成各种不同模块，包括一些新传感器的接入，一些新的传统CV算法的实现，以及不同模型的前处理、后处理，都可以在我们的调度框架下完成。

同时，在整套框架的定义下，也能够把这些感知模块、融合模块、规划模块、控制模块的接口很好的定义抽象出来，帮助开发者快速实现全栈的自动驾驶开发过程。一方面，能够在一个相对比较成熟的软件baseline下，完成自动驾驶量产的开发；另一方面，把我们实现规模化量产过程中的一些经验也分享出来，通过协同开发，大幅提升开发效率，从而达到一个开放共赢的状态，加速智能驾驶应用落地。

我今天的讲解就到这里，谢谢大家。