重点希迪智驾看系统架构标准问题.docx

重点希迪智驾看系统架构标准问题.docx

《重点希迪智驾看系统架构标准问题.docx》由会员分享，可在线阅读，更多相关《重点希迪智驾看系统架构标准问题.docx（5页珍藏版）》请在冰豆网上搜索。

重点希迪智驾看系统架构标准问题

希迪智驾看系统架构标准问题

希迪智驾工程副总裁黄英君发表了《智能网联助力重卡自动驾驶应用场景实践》的主题演讲，主要介绍了智能重卡商用落地的情况。

黄英君表示，自动驾驶在场景落地方面或多或少都会碰到一些问题。

目前更多的挑战在于计算平台和系统架构层面，这体现在配套开发工具链是否足够可靠，成本是否可以承受等等。

黄英君认为，自动驾驶仍处于群雄并起时代，系统架构并无统一标准。

每个系统都有自己的操作性问题，以智能重卡来说，一个车型面临的具体场景也已经十分复杂。

由于每种场景所适用的感知算法、决策和规划算法差距非常大，因此很难有一套满足所有场景的通用L4级自动驾驶架构。

此外，主机厂非常注重成本控制。

汽车行业不景气，影响最大的是供应商。

以计算平台为例，越来越多的解决方案都会采用异构的多域控制器方案，目前汽车行业在这L2以下的控制器软件开发技术已经非常成熟。

但目前大规模应用的控制器有限的算力限制导致无法支持更高级别自动驾驶，最多能做L2，到L2+算力已经不足。

以下为黄英君演讲全文，雷锋网新智驾进行了不改变原意的编辑：

我今天主要分享希迪智驾通过智能网联助力重卡进行场景落地的内容。

我之所以提“落地”，是因为还没有达到量产的阶段，很多方面目前正处于爬坡阶段。

在场景落地上，自动驾驶或多或少会碰到一些问题，我们称之为难点、挑战或者是痛点。

希迪智驾内部正在召开全体吐槽大会，从零部件、线缆、安装、软件框架，到编码规范，各个方面都让大家吐槽。

目前为止，我们已经收到了20页吐槽。

首先是传感器。

不管是激光雷达还是摄像头，都非常复杂，今天不做展开讨论，上半年希迪智驾花了好几个月时间在我们的平台上来调一款定制设备的同步驱动。

今天我想着重分享一下计算平台和系统架构落地时碰到的一些问题，以及相关的解决方案。

自动驾驶计算平台里每个架构师碰到都会碰到的问题是，应该使用什么样计算平台？

能不能给提供足够的算力？

配套开发工具链是否充分？

可靠性如何？

对于价格内部和商业合作伙伴能不能承受？

最后是供货问题，看起来虽然简单，但最后实际操作时反而是最困难的，因为这超出了我们的掌控范围。

很多好的设备和芯片只有大的主机厂才能拿到，一般供应商很难拿到，或者说很难用量产的价格拿到设备。

从系统架构来看，我认为自动驾驶还是处于一个群雄并起的时代，并没有完全统一的标准。

因此这也给我们的架构师带来一些困惑，要么选用一个架构进行参考设计，要么完全自己解决平台硬件与软件架构的问题。

目前L4级自动驾驶方案大多都是基于C&C（计算机和网络）的分布式体系，涉及大量的数据交换，更多采用网络模式。

在数据交换时，在应用层功能软件之下离不开通信中间件的支持。

目前几种通信中间件我们都用过，一种是广泛使用的Ros，它提供的调试工具非常多，而且也是开源的，很多平台和设备厂家都支持。

ROS但在时间响应的确定性上存在先天不足。

Ros2.0采用DDS方式有很大改进，但是应用在汽车上还是有一些缺陷的。

XX阿波罗开放的CyberRT也是一个很好的中间件，在调度效率和可靠性方面有独到之处，在Apollo中已经全面应用，完全脱离的ROS。

最后就是商用中间件，如RTIDDS。

一般航空航天，包括部分车企也会用这样的中间件。

选择种类多是一个优点，但同时也在量产过程中会造成一些彼此不兼容的问题。

其次在操作性上，每个系统都有自己的问题。

即便希迪智驾专注于重卡车型，但面临的具体场景变化也非常多，如专用道路场景、专用场区场景、港口场景、矿区场景、跨口岸编队场景。

每种场景的感知算法，决策和规划算法差距非常大，很难有一套适合所有这些场景的通用全栈L4级自动驾驶架构，因此要针对具体场景甚至是具体车型进行定制化设计与部署。

如何提高定制效率，如定制时算法的切换、功能裁剪、设备适配，实现基础解决方案能够迅速、低成本的来适应不同场景、适应不同芯片/平台，都是要解决的问题。

最后难点来自于主机厂和用户。

汽车行业非常讲究成本，目前业内的看法是，今年以来汽车行业不太景气，受影响最大的还是零部件供应商。

自动驾驶方案供应商也必须要面对设备成本的问题。

目前业内已经普遍接受的观点就是，未来的汽车一定是软件定义的汽车，软件在汽车中占的地位越来越重要。

个人认为自动驾驶方案供应商与汽车零部件供应商在架构上是有非常显著的差异的，车企广泛使用控制器（MCU、VCU）进行功能开发，特点是用量非常大，一辆车上可以有几十个乃至上百个，价格便宜，算力很低，以控制功能为主，一般是单核，新一代的控制器已经有三核CPU。

这种控制器的优点在于，它有非常完善的工具链，用于开发软件都有非常明确的标准，如已经被汽车行业广泛接受的autosar，但是有限的算力导致无法支持更高级别的自动驾驶，最多只能做L2级，甚至L2+需要的算力都不太能够满足。

与此同时，在很长的一段时间内，L4级自动驾驶基本都是PC方案。

几个著名的开源框架，如autoware，Apollo，都是PC机+ubuntu的架构。

Apollo系统推荐的设备是专用的车载工控机，已经是目前能够可用的最好的计算设备，支持双显卡，算力很好，功耗比较高，放在卡车上进行功能开发与验证足够，但是长期运行则是有很多隐患。

根据我们的体验，一般半年左右就会出现各种各样的可靠性方面问题，比如硬盘震坏，显卡接触不良，温度过高都会导致显示失灵等，也不支持休眠、唤醒、自我诊断、看门狗等汽车功能软件所必须的这个功能开发。

还有就是系统的集成、布线方面，工控机与汽车专用的线束是不兼容的，需要各种各样的转接，各种插口和转接口的可靠性是维护工程师的噩梦。

在展会现场看过各种各样的自动驾驶解决方案，很多设备舱都是比较凌乱，从某种意义上来说，从设备舱的凌乱程度就可以判断这家公司的方案技术水平情况。

计算平台的问题解决依赖于汽车芯片公司的进展。

目前芯片这方面很多公司都在开展工作。

自动驾驶车辆计算平台有非常苛刻的要求，不同的功能模块方案要用于不同的冗余方式。

系统架构师最关注的是软件架构、基础软件组件、确认的内核调度时间、端到端时延、开发工具链这些方面。

汽车软件开发，要求遵循功能安全规范，如ISO26262（对应的国标为GBT34590）。

功能安全在嵌入式软件开发方面有专门的规范，比如很简单的一个规定就是要能够随时检测故障，必须具备诊断功能。

检测故障之后，要能够进行系统降级，自动驾驶汽车软件必须实现这点。

一个好的计算平台，应该能够在功能软件、基础组件、设备驱动方面进行很好的分层，在设备层和基础组件层提供诊断功能，这样可以降低功能软件开发的复杂度，使得自动驾驶方案供应商更专注于功能软件和预期功能安全方面的开发。

这种模式在传统的控制器软件开发方面已经非常成熟，autosar标准已经被广泛接受，功能软件开发商和基础组件开发商的分工非常明确，所以主机厂和零部件供应商进行功能开发和更新的效率非常高。

但这样的模式在L4级自动驾驶领域还没有很好的实践。

最近发布的华为MDC平台是一个很好的开端，这个平台提供完整的autosar工具链，基于这个标准，自动驾驶企业可以专注于功能软件开发，基础组件的工作由平台供应商提供，能够实现软件的基于配置的快速部署。

主机厂对软件有很多要求，其中一个就是控制器要有多种选择，在autosar体系中，控制器的细节是被封装的，功能软件开发商基本不需要面对控制器的差异。

这也是L4级自动驾驶供应商所希望的实现方式。

最后简单介绍一下希迪智驾的几个实践案例，第一个是低成本的专用道路自动驾驶，使用的方案是用V2X路侧感知，使用5RIV的感知方案，遵循autosar标准进行开发，基于V2V的支持进行编队行驶，样车已经研制完毕，进行了大量的测试和验证。

第二个案例是重型工程车辆，使用11V+3L+5R+18S的感知方案，具备完整的多重冗余的感知和决策能力，能够适应无差分信号、GPS信号干扰、无标准化道路等各种复杂场景。

我们的自动驾驶解决方案是维护一个不断迭代演进的L4级解决方案，我们已经全面采用autosar架构，构建我们的自动驾驶解决方案，通过配置来部署，能够快速裁剪适配各种定制场景，实现L2~L5的同架构平滑演进。

迪智驾基于全新平台架构的样车已经推出，这是一个基于量产的国产计算平台，遵循autosar标准的可量产方案，通过了开放道路测试规程的考核，已经开始在开放道路（长沙时绕城高速）进行路测。