6月7日，地平线「你好，开发者」技术公开课在智东西公开课顺利完结直播。公开课由地平线TROS.A系统架构师傅亚涛主讲，主题为《基于TogetheROS.Auto的智能驾驶软件开发范式》。

本文是此次技术公开课主讲环节的实录整理。如果对直播回放以及QA有需求，可以点击阅读原文前去观看。

大家好，我是来自地平线的架构师傅亚涛，主要负责TROS.A的技术规划和系统设计，很荣幸有机会和大家来分享《基于TogetheROS.Auto的智能驾驶软件开发范式》。

首先，我会简单介绍智驾开发中遇到的各种问题，然后会基于这些问题来看如何从设计角度将问题做简化；然后，我会把TROS.A基于这些设计方式和设计思路所做的相关设计及实践进行分享；最后，我会分享智驾软件开发的发展趋势，以及智驾中间件的发展方向。

01智能驾驶软件研发的易与难

智驾已经发展很多年，近几年也越来越热。最开始我们做的时候，做一个智驾的demo都会非常困难。当时做一些AI应用，最开始是在一些通用的CPU上，之后是在一些类似于FPGA板上做智驾开发。当时参加各种展会的时候，如果有一套基于FPGA板的算法demo，且整体效果OK，就已经非常亮眼了。而近两年参加智驾相关的展会，如果拿不出一个实车的demo，然后做一些试驾评测的话，在整个展会上看起来会薄弱很多。

为什么现在整个智驾开发较之前成熟且看起来简单了许多，我简单总结了一下。

一是智驾开发生态百花齐放。大家可以看到，目前基于智驾的各种开发生态环境以及开源软件发展地非常好。一个典型的例子，比如说ROS2。可以看到基于ROS2往上，做的感知、规控这种智驾的服务，以及往下的厂家硬件接入，现在已经发展得比较成熟了。此外，目前各种开源软件在智驾里面使用很成熟，并且经过了多轮迭代，比如DDS、FASTDDS、CycloneDDS。同时，有多家DDS商用的开发商在开发这种功能安全的DDS版本。另外一个就是AUTOSAR。最近几年，AUTOSARAP的标准发展非常快，可以看它最近的一些更新。实际上，它对于智能驾驶往上的AI开发，会变得越来越友好。现在很多特性，都已经很贴近上层的应用开发了。算法的话，基本上每过一两年，算法都会有一个大的迭代。从原来的最早的检测模型，到BEV，再到Transformer，算法的迭代非常快。而且，基本上是业界有什么新的算法，大家很快就能跟上。硬件平台算力方面，每年都可以看到哪个厂家的算力破新高，发了新的计算平台。二是智驾开发能力快速提升。可以看到，整个智驾，从研发的投入上来说，增长非常明显。这周我用智驾这一关键字查了一下相关的企业，大概有多家，但里面有一些可能和智驾关系也不大，但相较几年前来说，这个数量增长的非常快。而且，涉及到智驾的开发人员也大幅增加，大家从技术栈上，成长也非常快。然后，从平时接触到的各种相关厂家，比方说OEM、Tier1、Tier2，现在基本上都把自己的能力栈建立起来了。原来很难搞定的一些事情，现在来说可能都是一些基础的事情。算法原型以及工程的原型，现在也有各种开源的实现、各种样板间。算法的迭代方法，包括方法论，也不是一个新鲜的话题。有很多的公司实际上都建立了类似的能力，让整个算法迭代越来越快。最后，可以看到，目前做智驾已经初步形成了一些分工。往往在做一个量产产品的时候，会遇到好几家方案解决商，然后多家协作，这家做感知，那家做规控，另一个做硬件加集成。整个量产好像变成了一个拼图游戏，相对来说，难度大幅降低。相对于几年前，智驾开发难度低了很多。但从目前来看，是不是真的低到了大家都可以去做，并能做完整的量产，也是不一定的。我和很多OEM的小伙伴聊过，得到的一个反馈是：现在和任意一家方案解决商或者其他从业者，去聊有个东西能不能做？能做；但是能不能量产？现在还没有验证过。所以，基本上是一问就会，但真正到量产的话，还有很多困难。这就是为什么从做一个智驾的原型到量产会这么难。

首先，从开发模式上，我们常见的智驾开发模式，这里写了主要的两种：

一种是典型的V模型。做过智驾开发的应该都会比较熟悉。这个V模型，一般是从研发侧，基本上是从系统需求、系统架构，再到子系统的设计研发。相对于常见的V模型，从需求，到设计，到研发来说，智驾会复杂很多。

基于智驾的软件规模，基本上经常做的是一个大的系统需求，从顶层的架构，再分解到多个不同的模块或公司。这个公司本身会再去做顶层的系统需求的分解，然后再去做设计。这种层级可能有两到三层，导致的一个问题是：在需求设计上经过层层分解，而这个分解的过程和软件研发其实是分离的。需求设计可能更多停留在文档上，研发基本上就到了整个系统的设计，然后再到编码。这个过程其实是分离的，流程越长，分离的越开的话，会造成在真正开发过程中，越容易造成变形。有可能做着做着就做歪了，有一些东西可能会漏掉。

反过来做这种集成的时候，又会发现有这么多层这么多组在并行开发，反向去层层做集成的时候，集成的成本非常高。遇到一个小问题，可能都需要拉一大拨人去长时间的定位。一个问题当涉及到跨团队跨公司的时候，来回踢皮球的情况，其实非常常见。

另一种开发模式其实也很常见。我们一般会去做一个原型系统，其实是用来做算法验证快速迭代的。基于这个原型系统，并对效果做了一定迭代之后，再往量产的环境上迁移这时候会面临很多问题：

一是原型系统和量产环境的架构差异很大。在原型上，可能是怎么快怎么来，比如说基于ROS2，或者基于Python来写；但在量产上，比方说，可能需要一个功能安全的软件底座，为了性能的话，可能会基于C++，甚至写一些性能更高的定制化实现。这就导致迁移过程很重，软件的效果一致性以及算法的一致性很难保障。此外，在原型开发的时候，大家更多

转载请注明:http://www.aideyishus.com/lktp/8218.html