干线智能货运正加速进入商业化探索阶段。

 

作为供应链管理中至关重要的一环,干线物流扮演着连接供应商、生产商和分销商之间的纽带。在快速变化的商业环境中,了解干线智能货运的商业模式和面临的挑战对于了解行业发展至关重要。

为此雷峰网新智驾邀请了千挂科技量产技术总监薛毛先生来进分享。以下为演讲内容,雷峰网(公众号:雷峰网)新智驾进行了不改变原意的整理:

大家好,我是千挂科技量产技术总监薛毛,今天和大家交流分享一下我们千挂科技近期的一些量产项目和系统研发的进展。本次的主题是量产研发加商业运营双循环,如何帮助干线智能货运服务加速突围。

首先介绍一下本次交流的内容概况。第一点,我们先会看一下整个干线智能货运当前概况和模式,然后影响干线智能货运落地进展的核心痛点。其次我们会以千挂科技为例,讲我们是如何打造前装量产智能驾驶商用卡车。最后讲讲就是关于在可靠性方面的一些积累。

干线智能货运目前的概况和模式

中国干线物流市场是一个非常巨大的市场,有着 4. 6 万亿的体量,但同时其实也只有 3% 到 4% 的一个很低的毛利。所以不管是车队老板还是个体司机,大家都非常会抠成本,因为这个会明显影响的是大家的一个毛利的高低。

 

再一个从人口的角度,随着出生率的下降,预期在2030年,整个货运市场的人力缺口大概会大于9. 5%。

我们想通过技术改变一些将来这种会出现在运输上的矛盾。

落地进程的核心痛点

下面是我们关于干线智能货运落地进程的一些核心痛点的理解。

 

量产难

首先从量产难的一个角度来讲,大概会分到几个方面,一个是整车功能,包括系统的性能、可靠性,还有前装的规模化、整车成本。

 

从整车功能来讲,需要准确识别应用场景的一些需求。比如在软硬件研发阶段,还有设计的阶段,短期和中期内技术能力其实能达到的一个水平是有预期的,但同时还要符合车规,包括做一个正向开发,这是一个比较有挑战性的事情,需要的团队能力既要有软件开发的思维,也要有传统汽车开发的思维。这个在概念理解、开发模式、工具流程、测试理念、集成理念、交付理念,多个环节都会有碰撞和融合,想要实现一个 1 + 1 大于 2 的效果,还是非常有难度的。

其次在功能和需求准确的前提下,实现优秀的系统性能也是富有挑战的、复杂的工程任务。除了整车功能,其实我们看智驾系统的性能也是有非常高的要求,包括在基础的架构性能、算法性能以及硬件系统的性能。

今天我们先只讲一讲硬件性能方面在量产项目中的一些心得。

首先第一个是智驾域的性能,包括算力、传感器、、通信方案,这些硬件的水平,其实一定程度上和一定时间范围内决定了我们之后的整车功能的一个上限。

其次是,车辆平台的性能,这个性能其实会包含很多部分,典型的比如说线控的性能,车辆自身的性能。举个例子,像我们线控接口的一个丰富程度,还有一个响应速度,包括线控制动力的范围。最典型的像商用车上EHPS的跟随精度,还有响应速度,都直接影响整车的功能表现。

除此之外,在量产的智驾域我们还得考虑提供一定的灵活性,随着目前市面上的传感器性能越来越强大,数据带宽要求越来越高,智驾域如何能对接更多的各种各样的传感器,其实也是一个非常重要的问题。与此同时,我们不仅需要考虑智驾域的数据接入实时性,还要考虑时间同步,包括它的诊断以及在遇到功能降级时候多个方面的影响。

智驾系统的可靠性也是目前量产化难做的但又非常重要的一点。

从零部件层面,包括零件资质以及质量标准体系,还有供应链的水平。比如说我们在做一些电子电气设备研发的时候,最基本的要满足一些 ACE-Q 的认证,比如说像汽车集成电路可能要满足AEC-Q100,一些光电部分需要满足Q102,被动的组件需要满足Q200。举个例子,做产品的时候,可能后期我们会做ESD测试,像AEC-Q100就要求你的器件要承受 2KV的放电模拟,在边脚引脚要承担 750V的带电器件模式,还有其他引脚需要承受 500V的电压,这个对于量产都带来了功能、性能、成本等多方面影响。

除了零部件的可靠性,还包括一些功能安全的设计,比如说需要遵守V模型开发,包括V模型里边提到的相关项分析、功能定义、安全概念、安全目标,再到具体的软硬件设计和测试,这部分需要投入非常大的人力和物力成本,也势必影响整个项目的开发周期。所以在量产的项目里边如何去权重它与开发进度,以及它的可靠性,都是需要一些工程积累的。

其次除了这种客观的可靠性,还有主观对可靠性的感知,或者说大众的接受能力。

在司机开车不关注或者无接管的条件下,自动驾驶安全级别量化按理不低于人类司机即可。目前统计的数据是在高速路段平均无事故里程是不少于 53 万公里,这是一个客观指标。但在实际场景中,人们感性上总是难接受这个事情,大家总是希望自动驾驶是绝对安全可靠的,这个也是我们整个行业需要共同去努力提升的。

另外一个决定量产化难做的原因是整车成本。所有的东西都是跟成本挂钩的,工程本质是要求我们收敛到一个最经济的路线上,所以在各种制约的条件下,如何能找到一个量产化的最优解,也是一个非常难的事情。

应用难

从应用难的一个角度分析的话,实际运营场景中遇到会各种各样复杂的问题,比如说对于运力的时效性的要求,这个是在功能设计层面非常难考虑的一个问题,但是在现实场景中就会遇到这样的需求。经济性要求,比如说从软硬件开发成本,像硬件的 BOM 成本这个刨除之后你的商业模型如何能获取利润?这个也是大家目前比较难落地或者难应用的一个点。

 

除了这种客观或者技术的问题,法律法规也是我们必须要遵守的。比如说我们做的车得符合国家相关的认证或者规范,满足相关的测试标准。

还有一些其他的安全问题,比如说我们需要考虑各种各样的环境、道路、场景因素,这个是在概念阶段要做到足够的分析,才能保证功能开发出来是可以解决一些实际问题的。

千挂模式:多拉、多跑、多赚

商用车的智能驾驶应该是一个生产工具,而不仅仅是一个附加的功能,它帮助司机或者车队是挣更多的钱,特别在干线物流行业,这个是最基本的认知。

 

其次,卡车作为一个生产工具,其实多挣钱就是多跑、多拉货,一天能额外跑个 200 或 400 公里,它的生产力一下子就上来了。举个例子,比如说从 a 点到 b 点的 1000 公里,追求高时效性的企业往往会配备两个司机,这样就能确保每天 1000 公里的往返能力。一个卡车司机的成本大概是 15- 18 万元,这和目前自动驾驶硬件系统的成本其实是差不多的,规模起来之后自动驾驶的硬件成本可能会变得更低。所以,对于企业来说,一年可以把这个成本省回来,后面就是净赚,这也是目前客户比较认可的一个商业逻辑。

具体到千挂,我们的切入方式其实就是“双驾变单驾”,通过智能驾驶提升单人日均驾驶里程,按照我们的模式,估算下来一台车一年的利润可达到 15- 20 万元。

除了提升里程之外,在优化排放,提升安全性方面,自动驾驶也有非常大的技术潜力和迭代的可能性。

从长期来看,我们觉得“脱眼脱手”才是自动驾驶干线物流的唯一解决方案。

为什么说是唯一?这里有一些具体的说明,是关于辅助驾驶现阶段存在的一些问题。德国布伦瑞克柏林工业大学曾联合保险事故调查公司,做过一个关于辅助驾驶的研究报告,通过对照试验发现,随着驾驶时长的增加,驾驶员是更容易犯困的。这个实验虽然是基于模拟仓的一个统计,但是有一定的说服力。

如果说大家有开过带辅助驾驶功能的车,也不难发现,在长时间驾驶的情况下,如果只是脱手,但不脱眼的话,随着驾驶时长的增加,自己会变得更容易犯困,某种程度上反而会带来更大的安全隐患。

所以,我们要做到“脱眼脱手”这个级别,它对于系统的要求就是:只要车还在动,那就需要保证智驾的系统是相对安全的。

对比纯无人模式,“脱眼脱手”模式是更容易落地的。

首先第一个点是场景的需求,比如在干线物流场景,驾驶员不仅要处理驾驶本身问题,可能还会有很多关于货或者关于收费等各种各样的问题,这些问题属于自动驾驶ODD范围之外的事情,中短期来看,这个目前都依然需要人去解决。

其次是技术能力的要求,如果系统的ODD定义准确,那么在ODD之外的情况下,人类驾驶者可以帮助车辆提前安全停车,从而保证在当前整体理论和行业水平没有突破的情况下,智能驾驶可以顺利落地。

从经济层面来来看,单车每年大概是多出15- 20万元的毛利率,如果算上5年的折旧,这个利润率明显要比自动驾驶系统的硬件成本要高。

可以说,这些维度支撑起了千挂的核心模式,下面来讲一讲我们是如何做的。

如何打造前装量产智驾卡车?

千挂采取的是和主机厂一起做整个智能驾驶商用卡车的量产。主机厂是帮我们提供整车的一个平台,千挂提供智驾部分的软硬件方案,然后我们共同去做整车的定义和开发,再基于整车厂的强大的整合和量产能力,帮助我们从概念设计到验证评审再到市场量产,是一个非常深度的合作。

 

区别于传统的 Tier 1 加 OEM 的模式,千挂科技本身在商用车自动驾驶量产的事情上其实是建立了一套灵活且高效的合作模式。从定义整车的功能概念,再到具体的软件设计,都是完全参与。

除了和主机厂对接整车的需求和功能定义之外,我们其实也会和很多 Tier 1 去直接沟通某些零部件的技术指标和性能,比如深入了解电液助力转向,还有甚至eps的一些趋势。同时作为智驾方案商,我们也会和一些国内外领先的传感器和芯片公司有一些深入的交流,比如说评测一些最新的传感器和半导体芯片等。

概念阶段

在概念阶段,我们希望达到的效果是让司机“脱眼脱手”之后能够安全放心的水平。这个从技术层面讲是一个非常难做的事情,但我们在技术层面已经有一些非常不错的积累。同时我们的ODD里边是会搭配一个司机使用,全程是有一个双重的保障。

 

概念分析完,自然就决定了我们会选的传感器、需要的算力,技术路线以及最后出来的效果要求。千挂跟很多单纯追求低成本的辅助驾驶会有不同,在功能定义上完全走的是两个不同的路线。这也体现在概念阶段的定义,决定我们追求目标的下限是不一样的。

干线物流ODD

下面讲关于干线物流ODD的理解。ODD 的定义直接关系了后面所有的整车功能定义,以及后续所有的软硬件开发。我们理解ODD开发并不是一个从 0 到多的枚举或者头脑风暴,而是基于各种客观的因素做排列组合,一一确认,然后做减法的一个过程。

 

千挂的概念分析阶段,其实针对 ODD 总共大做了 5 大级别的一个运行情景的分析,涵盖从静态、实体环境条件、驾驶人员状态、车辆状态、道路状态以及多个层面的组合分析,尽可能减少对不安全的场景的特性理解。这样的分析之后,才能帮助我们针对这种特性去做系统级别的设计。

举个例子,干线物流肯定会遇到一些车辆启停的场景,极端情况是这个场景可能会出现一些小动物,或者说小孩子在车身附近,我们的ODD必须要包含这个场景。所以我们引入了在商用车上并不常见的传感器。举例子也是想说明我们做的事情并不是传统的 L4 或者 demo 驱动的开发模式。

设计阶段

具体到设计阶段,千挂科技和东风柳汽的前装量产项目,已经是顺利完成了 A 样车的试制和整体的测试任务,在线控性能、外观结构、整车电子电气适配、标定优化等多方面其实取得了不错的进展。同时 B1 样车也按项目计划改制中。借助于东风柳汽强大的整车集成和先进整车制造能力,我们预期是在 2024 年将正式下线我们前装量产车型。

 

千挂科技已经从底层到应用软件,从基础架构到量产工具,在各个方面取得了一些不错的工程积累。今天也是针对整车智驾功能中的硬件系统做一些分享。

整体架构

首先是智驾域控硬件层面的整体架构,面向整车前面提到的功能定义,我们做的相关项分析示意框图大概如这个图所示,ADCU是我们整个方案的核心,它一方面是承担着左侧传感器的接入,同时右侧接入的话是我们的线控以及车辆底盘的一些执行器,它是一个承上启下的作用。这个ADCU 的设计需求其实完全是根据我们自己对于 ODD 以及运营场景里面遇到的一些问题的理解,纯定制研发的一个产品,目前已经完成了原理图阶段的设计。

 

传感器方案与布局

我们在认真严谨地评测了前装市场的一些传感器之后,选定了多款半固态激光雷达作为我们量产项目里边的一部分的传感器,因为它的成本已经被乘用车的量产项目带下来了,并且在质量和供应链上面有更加有优势。加上业内比较成熟的摄像头,还有毫米波传感器,全套配置下来,为我们后续的感知研发还有性能提升奠定了非常充分的基础,也兼顾了量产在性价比和质量方面的综合性要求。

 

不同的传感器有着不同维度的感知特性,为了保证ODD场景内硬件感知层面做到可“脱眼脱手”的功能完备和功能备份,我们搭建了一个 360 度的冗余环境感知系统,包括激光雷达、摄像头、毫米波、雷达。其中激光雷达我们用了6颗,它们所实时产生的感知数据是一个非常大的数据量,大概是在 400 Mbps,前向激光雷达最大探测距离能达到 500 米,角分辨率在 ROI 可以做到一个 0. 08 * 0. 08 度,这是一个非常夸张的水平,为后续的复杂场景,包括远距离或者一些小物体的识别,在硬件层面提供了可能性。

前向的摄像头,最大有 800万像素和30FPS的环境感知能力,同时摄像头在硬件层面也支持HDR、LFM,针对特定场景例如高动态,还有定制和优化。

这张图是我们最终的激光点云在真实场景下的效果,可以看到车身 360 度都是完全的覆盖,前向能提供500 米范围的超远距感知(绿色点云)。这里要想分享一个点,如何在整车上适配多个传感器,这个非常考究团队的工程能力和合作能力。比如说从早期的 FOV 覆盖,到结构设计仿真,理解传感器的工作原理(安装倾角问题),样件快速成型,法律法规方面的约束、不同挂车差异、工业设计能力、感知模型效果等。

比如说半固态雷达,它的寿命或者它的功能在实际的装配中肯定会受到倾角的影响,这些需要我们去理解传感器的原理细节。

这上面的每一环都是必不可少,且是环环相扣的,如果做不好,影响可能是一连串的。比如说激光雷达的测距或者扫描方式发生改变,摄像头的分辨率或者fov或者它的触发时序发生改变,这个都可能会导致感知此前积累的很多数据无法复用,算法需要额外多次迭代,这个都是有工程成本在里面。

我们早期是评测过很多家的感器,也得到了非常多的供应商的大力支持,在双方紧密的技术合作之下,我们在如何快速地、低成本、高质量做整车传感器的软硬件适配方面是积累了不少经验。

  • 自研域 ADCU

ADCU 是我们从整车的功能定义出发,提出了需要满足对应场景解决方案的计算平台的设想,包含了从算力、传感器接入能力、车身控制、智能网关、智能电源,还有热管理以及最小安全系统等各个模块。

 

我们对于域的理解是CPU 和 GPU 的算力是同等重要的,在感知预测、深度学习、Resolution、Feature map size等方面对于GPU是强需求,在运动规划、SLAM、Fusion和Tracking 方面对 CPU 的能力会有强需求。所以在的研发和设计层面,我们会兼顾 CPU 和 GPU 的整体的算力需求。

目前我们的能做到整机的GPU等效算力大致于 6颗Orin, CPU 是等效于 8颗Orin;三层异构计算控制系统,支持多路相机和车载以太网设备接入,同时支持TSN 时间敏感网络。

除了接入能力方面,我们在可靠性冗余方面也做了很多的设计,比如典型的像双路冗余电源输入,不同物理和数据链路的传感器接入。此外还增加了集成式智能电源管理单元,高速信号的传感器管理单元等等。

这样复杂的域控制系统,它的散热系统也是非常麻烦的事情,我们联合东风柳汽对域控的水冷散热也做了正向的开发,不仅实现了小体积高密度,同时满足了车规级对于散热系统的液冷管路和驱动设备的可靠性和稳定性的需求。

  • 电源管理系统

商用车在实际运营过程中会面临很多工况和环境条件,比如说加速、减速、制动,还有一些高功率的负载的开关,包括说因为线束较长存在的线束电感,在大电流的情况下可能会导致的高压脉冲危害。

 

虽然这些波动会在ISO 16750-2、GB 28046-2 电性能测试里面覆盖到,但是涉及到整车级别需求来看,可控、精细化配置以及可诊断的电源管理,还是一个大趋势。典型的像特斯拉已经在他们的整车电源管理系统实现了这种相对比较智能的设计。

使用Smart HSD、MOSFET+采样逻辑代替传统保险丝加继电器的模式,在过流、过压、 短路、过温、开路等检测和耐受性能上有着数量级的提升,典型Smart HSD开关次数在 10^15次以上且保证性能无衰减,而传统继电器只能做到10^5左右。除了基础层面的提升,还会有很多数据分析和数据挖掘的价值在里面。

人机交互部分

传统车辆的人机交互系统更多是功能属性,而自动驾驶系统的人机交互的并不只是简单的功能完成,实则某些场景中与安全强相关。如合理的接管逻辑、方式和阈值判断,以及简洁易懂、有效及时的提醒及提醒闭环或不必要的误触发,这些在预期功能安全中都需要被分析到。前面提到我们的 ADCU 的性能是非常强大,足以支撑人机交互对于硬件性能方面的需求,但我们从可靠性角度出发,还是会做一个智驾域和座舱域在硬件上的一个隔离。

 

典型的比如我们的ADCU之外,我们针对人机交互部分会有一套单独的硬件系统,这个能保证整车的概念安全和设计解耦。

如何提高可靠性?

零部件和供应商

内部角度,比如说我们自己做的的芯片选型,首先它要满足AECQ100的要求,在开发模式上要遵从V模型的开发+验证的方式,同时生产制造也要符合汽车行业规范,这个是对于内部研发项目的一些基本要求。

 

外部看的话,我们会有很多传感器选型和功能性能评测、 DVPV 测试报告的审核,再到供应商质量体系审核以及定点。

内外双抓手保证零部件层面的自研和外购件符合规范。另一个角度就是自研和外购件在零部件层面的可靠性要求在我们看来并不是隔离的,反而对于自研项目中的原理细节的理解,能帮助我们去更专业的评价外购件的能力水平。

系统概念

举一些例子,比如说我们自己在做自研ADCU过程中,我们采用 ASIL-D 等级的MCU作为最底层的安全保障,然后摄像头和雷达都会在数据层面分在不同的物理和协议链路,接入不同的异构计算域进行传输和处理。对于MCU和一些关键的外设会采取双电源冗余的设计。再比如,像在线控通信矩阵层面,对于制动信号,我们会要求从多个不同的传感器采集点的报文。

 

功能安全的导入

车规级选型只能保证器件的相对可靠,但元件的可靠其实并不代表系统功能是可靠的。系统的功能首先要从系统功能定义出发,合理的拆解分析,我们对于智驾系统的功能进行了危害分析和风险评估之后,大致得出了智驾系统需要满足的安全目标共21 条,并且针对每一个safety goal均有明确的 ASIL 等级以及它的安全状态定义,还有故障容忍时间FTTI的明确定义。对于每一个安全目标也相应完成了它的FTA故障数分析,我们在概念阶段做了非常详细的工作。

 

明确定义的报警和功能降级也是我们实现后期安全停车或者最小安全策略的一个必要的输入。我们前面提到的 21 条的功能安全目标,拆解到700多条的FSR,再导出到指导设计的技术安全需求的TSR和硬件层面的HSR,指导我们具体的软硬件设计。

整车测试验证

可靠性其实既是设计出来的,同时也是测试出来的,而整车级别的测试反而是更接近于最终用户或者客户的验证工序。从台架加速试验到载荷路谱试验,以及后期的长期真实道路测试,对于加装智驾系统的整车可靠性都是终极大考。

 

寻找干线智能货运真正应用的痛点

现阶段我们的理解是实践出真知,我们已经从身体力行的在落地一些真实的运营,并且在实际运营中迭代产品,比如路测过程中发现的实际场景的问题和需求,我们都会高优处理和思考,并将这些需求纳入之后的开发需求,真正的从实践或者运营场景出发,再回到运营场景中去;除此之外,我们研发也正向的基于OOD的功能开发需求,在不断提高我们自动驾驶解决干线物流的技术指标,提高真实场景中的自动驾驶率,提高运营的效率。这两方面是一个双向奔赴的过程,相互促进才能提速量产化和批量化运营的一个进度。

 

好的,然后今天的交流分享先到这里。

QA环节

Q:有做驾驶员的疲劳测试吗?

 

这是一个好问题。我们在研发测试,包括运营测试阶段,在车上都是有装了类似于DMS 或者说手环这样的设备,都是在监测或者采集一些测试场景的数据,然后也在联合一些外部高校在做驾驶员疲劳度的数据采集和分析的工作。这个对于我们后续去量化这些指标,包括说我们的系统能在多大的程度给驾驶员提供休息的时间等问题上提供一定的理论和数据依据。

Q:千挂科技招人会比较关注什么样的点?

首先基础的一点,对专业能力或者说是技术能力有一些基本的要求,除此之外我们也会看重一个团队合作能力或者解决问题的能力,这里也欢迎大家多看一下我们在招聘渠道的公开岗位。

Q:请问现在的卡车线控技术已经足够成熟量产了吗?

这个并不是一个单纯的技术问题,而是一个工程问题,是工程就得考虑成本,并不是说现阶段技术做不到。据我们了解,在电源冗余、转向冗余、制动冗余等方面有很多这种方案,但现阶段它是不是最经济的方案,我们还在实践和讨论的过程中。

Q:自研的ADCU内部有冗余吗?

有冗余的,前面有提到我们的ADCU,它不仅是在系统架构上是有一个三层的冗余,而且在与外部传感器设备接入上也是有三个不同的链路和协议,保证不会因为某一个链路有问题,导致不同维度探测感知的传感器也出现失效。同时在ADCU内部也会有电源部分或者重要外设部分的冗余。