从自动驾驶重卡落地希迪智驾看系统架构标准问题

1、从自动驾驶重卡落地希迪智驾看系统架构标准问题峰会主要聚焦 自动驾驶的量产时代、单车智能和车路 协同的共演之路、新型的车内交互探索”三大主题，共同探讨 了智能驾驶的未来发展方向。来自主机厂、国内外一级供应商、自动驾驶解决方案商、 自动驾驶核心零部件、由行运营商等智能驾驶上下游企业， 车路协同专家学者、代表企业等1500余位业内人士莅临现场。大会现场，希迪智驾工程副总裁黄英君发表了智能网 联助力重卡自动驾驶应用场景实践的主题演讲，主要介绍 了智能重卡商用落地的情况。黄英君表示，自动驾驶在场景 落地方面或多或少都会碰到一些问题。目前更多的挑战在于 计算平台和系统架构层面，这体现在配套开发工具链是否足

2、 够可靠，成本是否可以承受等等。黄英君认为，自动驾驶仍处于群雄并起时代，系统架构 并无统一标准。每个系统都有自己的操作性问题，以智能重 卡来说，一个车型面临的具体场景也已经十分复杂。由于每种场景所适用的感知算法、决策和规划算法差距非常大，因此很难有一套满足所有场景的通用L4级自动驾驶架构。止匕外，主机厂非常注重成本控制。汽车行业不景气，影 响最大的是供应商。以计算平台为例，越来越多的解决方案 都会采用异构的多域控制器方案，目前汽车行业在这L2以下的控制器软件开发技术已经非常成熟。但目前大规模应用 的控制器有限的算力限制导致无法支持更高级别自动驾驶， 最多能做L2,至U L2+算力已经不足。以下

3、为黄英君演讲全文，雷锋网新智驾进行了不改变原 意的编辑：我今天主要分享希迪智驾通过智能网联助力重卡进行 场景落地的内容。我之所以提落地”，是因为还没有达到量产的阶段，很多方面目前正处于爬坡阶段。在场景落地上，自动驾驶或多或少会碰到一些问题，我 们称之为难点、挑战或者是痛点。希迪智驾内部正在召开全 体吐槽大会，从零部件、线缆、安装、软件框架，到编码规 范，各个方面都让大家吐槽。目前为止，我们已经收到了20页吐槽。首先是传感器。不管是激光雷达还是摄像头，都非常复 杂，今天不做展开讨论，上半年希迪智驾花了好几个月时间 在我们的平台上来调一款定制设备的同步驱动。今天我想着重分享一下计算平台和系统架构落

4、地时碰 到的一些问题，以及相关的解决方案。自动驾驶计算平台里 每个架构师碰到都会碰到的问题是，应该使用什么样计算平 台？能不能给提供足够的算力？配套开发工具链是否充 分？可靠性如何？对于价格内部和商业合作伙伴能不能承 受？最后是供货问题，看起来虽然简单，但最后实际操作时 反而是最困难的，因为这超生了我们的掌控范围。很多好的 设备和芯片只有大的主机厂才能拿到，一般供应商很难拿 到，或者说很难用量产的价格拿到设备。从系统架构来看，我认为自动驾驶还是处于一个群雄并 起的时代，并没有完全统一的标准。因此这也给我们的架构 师带来一些困惑，要么选用一个架构进行参考设计，要么完 全自己解决平台硬件与软件架构

5、的问题。目前L4级自动驾驶方案大多都是基于 C&C （计算机和 网络）的分布式体系，涉及大量的数据交换，更多采用网络 模式。在数据交换时，在应用层功能软件之下离不开通信中问件的支持。目前几种通信中间件我们都用过，一种是广泛 使用的Ros,它提供的调试工具非常多，而且也是开源的, 很多平台和设备厂家都支持。ROS但在时间响应的确定性上 存在先天不足。Ros2.0采用DDS方式有很大改进，但是应 用在汽车上还是有一些缺陷的。百度阿波罗开放的 CyberRT也是一个很好的中间件， 在调度效率和可靠性方面有独到之处，在Apollo中已经全面应用，完全脱离的 ROSo最后就是商用中间件，如 RT

6、I DD So 一般航空航天，包括部分车企也会用这样的中间件。选 择种类多是一个优点，但同时也在量产过程中会造成一些彼 此不兼容的问题。其次在操作性上，每个系统都有自己的问题。即便希迪 智驾专注于重卡车型，但面临的具体场景变化也非常多，如 专用道路场景、专用场区场景、港口场景、矿区场景、跨口 岸编队场景。每种场景的感知算法，决策和规划算法差距非 常大，很难有一套适合所有这些场景的通用全栈L4级自动驾驶架构，因此要针对具体场景甚至是具体车型进行定制化 设计与部署。如何提高定制效率，如定制时算法的切换、功 能裁剪、设备适配，实现基础解决方案能够迅速、低成本的 来适应不同场景、适应不同芯片 /平台，

7、都是要解决的问题。最后难点来自于主机厂和用户。汽车行业非常讲究成 本，目前业内的看法是，今年以来汽车行业不太景气，受影 响最大的还是零部件供应商。自动驾驶方案供应商也必须要 面对设备成本的问题。目前业内已经普遍接受的观点就是，未来的汽车一定是 软件定义的汽车，软件在汽车中占的地位越来越重要。个人 认为自动驾驶方案供应商与汽车零部件供应商在架构上是 有非常显著的差异的，车企广泛使用控制器（ MCU、VCU ） 进行功能开发，特点是用量非常大，一辆车上可以有几十个 乃至上百个，价格便宜，算力很低，以控制功能为主，一般 是单核，新一代的控制器已经有三核CPU。这种控制器的优点在于，它有非常完善的工具

8、链，用于 开发软件都有非常明确的标准，如已经被汽车行业广泛接受 的autosar ,但是有限的算力导致无法支持更高级别的自动 驾驶，最多只能做 L2级，甚至L2+需要的算力都不太能够 满足。与此同时，在很长的一段时间内，L4级自动驾驶基本都 是PC方案。几个著名的开源框架，如 autoware , Apollo , 都是PC机+ubuntu的架构。Apollo系统推荐的设备是专用的车载工控机，已经是目前能够可用的最好的计算设备，支 持双显卡，算力很好，功耗比较高，放在卡车上进行功能开 发与验证足够，但是长期运行则是有很多隐患。根据我们的体验，一般半年左右就会由现各种各样的可 靠性方面问题，比如

9、硬盘震坏，显卡接触不良，温度过高都 会导致显示失灵等，也不支持休眠、唤醒、自我诊断、看门 狗等汽车功能软件所必须的这个功能开发。还有就是系统的 集成、布线方面，工控机与汽车专用的线束是不兼容的，需 要各种各样的转接，各种插口和转接口的可靠性是维护工程 师的噩梦。在展会现场看过各种各样的自动驾驶解决方案， 很多设备舱都是比较凌乱，从莫种意义上来说，从设备舱的 凌乱程度就可以判断这家公司的方案技术水平情况。计算平台的问题解决依赖于汽车芯片公司的进展。目前 芯片这方面很多公司都在开展工作。自动驾驶车辆计算平台 有非常苛刻的要求，不同的功能模块方案要用于不同的冗余 方式。系统架构师最关注的是软件架构、

10、基础软件组件、确 认的内核调度时间、端到端时延、开发工具链这些方面。汽车软件开发，要求遵循功能安全规范，如 ISO 2626 2 （对应的国标为 GBT34590 ）。功能安全在嵌入式软件开发方面有专门的规范，比如很简单的一个规定就是要能够随 时检测故障，必须具备诊断功能。检测故障之后，要能够进 行系统降级，自动驾驶汽车软件必须实现这点。一个好的计算平台，应该能够在功能软件、基础组件、 设备驱动方面进行很好的分层，在设备层和基础组件层提供 诊断功能，这样可以降低功能软件开发的复杂度，使得自动 驾驶方案供应商更专注于功能软件和预期功能安全方面的 开发。这种模式在传统的控制器软件开发方面已经非常成

11、 熟，autosar标准已经被广泛接受，功能软件开发商和基础 组件开发商的分工非常明确，所以主机厂和零部件供应商进 行功能开发和更新的效率非常高。但这样的模式在L4级自动驾驶领域还没有很好的实践。最近发布的华为 MDC平台是一个很好的开端，这个平 台提供完整的autosar工具链，基于这个标准，自动驾驶企 业可以专注于功能软件开发，基础组件的工作由平台供应商 提供，能够实现软件的基于配置的快速部署。主机厂对软件有很多要求，其中一个就是控制器要有多种选择，在autosar体系中，控制器的细节是被封装的，功能软件开发商基本不需要面对控制器的差异。这也是L4级自动驾驶供应商所希望的实现方式。最后简单介绍一下希迪智驾的几个实践案例，第一个是低成本的专用道路自动驾驶，使用的方案是用V2X路侧感知，使用5RIV的感知方案，遵循 autosar标准进行开发，基于V2V的支持进行编队行驶， 样车已经研制完毕，进行了 大量的测试和验证。第二个案例是重型工程车辆， 使用11V+3L+5R+18S 的感知方案，具备完整的多重冗余的感知和决策能力，能够适应无差分信号、GPS信号干扰、无标准化道路等各种复杂场我们的自动驾驶解决方案