直播回顾丨百度ACU开启2020年首个量产车型交付新篇章
百度ACU（Apollo Computing Unit）是Apollo面向量产的自动驾驶车载计算单元，根据不同需求场景的计算能力要求，分为多个系列产品。ACU-Advanced是行业首创的自主泊车产品Apollo Valet Parking专用车载计算平台，目前已量产下线用于客户的量产车型中。
ACU-Advanced软硬一体的解决方案：
能够支持5路摄像头，12路超声波雷达，预留毫米波雷达和激光雷达接口；
基于Xilinx ZU5（FPGA）设计，适配百度PaddlePaddle深度学习框架；
全面部署AUTOSAR，全车规基础软件开发；
严谨的软硬件安全合规设计，全面满足AVP场景需求（ASIL-B）；
100%全车规元器件，抗冲击震动，耐电磁干扰，全面胜任车载环境；
-40℃~85℃超宽工作温度，自然风冷无需风扇或水冷；
设计流程，供应链和生产管控基于IATF16949质量管理体系。
为了让客户、合作伙伴以及开发者能够更加深入了解百度ACU（Apollo Computing Unit），本次公开课邀请了百度ACU核心技术团队的工程师，为大家准备了4期公开课直播。今天为大家送上第四期直播内容回顾，如果你错过了直播，那么这次的直播回顾你一定不能错过。阿波君给大家整理好了笔记，快来一起学习吧！
上期我们为大家整理了《直播回顾丨百度ACU安全如何做到业内领先》，本期公开课由百度Apollo Computing Unit车规量产技术经理——曹文锋为我们讲解《百度ACU开启2020年首个量产车型交付新篇章》。
ENJOY THE FOLLOWING
如何看待自动驾驶和汽车电子这两门技术？自动驾驶更偏向于机器人工业。看待无人车和传统车视角是不一样的，无人车更像一个机器人，不像一个车。传统汽车电子是基于比较确切的规则、长时间经验积累的一种技术，两者技术差异较大。自动驾驶和汽车电子的专注领域、迭代的频率、速度，适合这种技术的开发模式、方式、流程之间都有很大的差别，甚至有很多矛盾的。在推动自动驾驶的过程中，一直在磨合矛盾和冲突。
怎样才能变成一个量产的自动驾驶完整的形态？第一个是需要稳定、安全的载体，需要底盘、方机舱去承载一个算法。车稳定的控制器，它提供足够的算力，也比较符合车规，而且比较坚固，成本权衡。单有发动机、底盘和载体是不够的，因为怎么才能把一个性能这么好的发动机的动力能与驱动轮关联一起，车上其他的零部件链接起因为怎么才能把一个性能高的发动机的动力能与驱动轮关联在一起，与车上其他的零部件链接起来？这里面需要一个传动轴，来解决怎么才能赋能发动机，怎么变成一个有机的整体。这里面其实是一个传统整车技术，包含AUTOSAR，需要有一个自动驾驶赋能具备这种汽车电子的一个东西，这样的话变成一个汽车电子的产品才能跟其他的东西有一个互动，这样既能发挥性又能做一个友好的握手。除了这个以外，怎样用一个框架捏合在一起，这实际上需要一个规范，现在说的一个流程与功能安全，一个大家适用的流程和方法，这样的话就是相对完整的一个整体，比较完善的量产的状态。
为什么需要AUTOSAR？因为AUTOSAR做了严谨的分层，隔离性好，其特点有以下几方面：
软件的可移植性。
多供应商联合开发。
标准化基础软件。
软件模块耦合度很低，复用性高。
天然符合功能安全的架构。
为什么自动驾驶需要AUTOSAR？其主要原因有以下几点：
快速拉平几十年的行业差距，使用成熟的汽车软件。
解决最复杂的基础软件安全问题。
自动驾驶和整车其他控制器实现握手。
AUTOSAR开发过程。AUTOSAR的开发方式是很传统的，对于自动驾驶也通用。其主要有2种，一种基础软件开发，一般跟OA对接，会给我们一个企业标准，根据企业标准对我们的性能、参数要求需要分解成AUTOSAR各层级参数的组合来达到现在的性能。在AUTOSAR工具里配置，生成代码，再编译，变成可呈现代码，就可以去跑。这是比较经典的BSW开发，不单这个，还有操作系统配置、MPOS操作手册、文件接口的一些定义做一些配置。
这个也是很传统汽车电子AUTOSAR应用层的开发，其实现在大部分车厂APP的应用实际上都是基于建模的开发方式，会用Simulink来搭模型，生成代码选成AUTOSAR接口的这种代码生成方式，然后把生成的SWC文件导入到AUTOSAR配置工具，显示出框架和接口。最后把底层的数据跟接口在RTE层做一个关联，这样数据流就打通了，再导入到SWC代码编译工具，这是最常用的方式。当然还有其他自下而上的开发方式，在AUTOSAR工具生成框架，在框架里面填代码。
AUTOSAR的缺点有哪些？
集成效率低下。
工具链之间的兼容性影响了AUTOSAR软件宣传的复用性效果。
自动生成代码调试问题，这个不是AUTOSAR问题，是自动代码生成的供用性问题。
自动驾驶怎么才能用好AUTOSAR？第一，汽车行业标准的理解。AUTOSAR开发其实是有些门槛，它的标准有上千页，跟汽车标准是有关联的，需要有开发的经验，算是技术门槛。
第二，利用脚本解决集成效率问题。解决DVC的技巧，一种找到DVC生成的ismail的关系，通过脚本识别DVC对ismail的修改，解决这个问题。另种可以加一层代码。
第三，功能安全模块的应用。对于Timing Monitoring， Program flow monitoring大家在用的时候需要思考几个问题，做这个监控是对一段功能还是对代码监控，或者为了去做多核运用的时候不同运行错序的监控。这个是可以解决问题，但需要知道怎么用，哪些是安全的，大家的安全是怎么结合的。MPU是比较复杂的应用，其目的是功能安全，做的时候有低安全等级和高安全等级，低安全等级的调用不能去污染高安全等级，做个内存隔离的应用。
第四，多核OS任务分配。需要关注怎么分配资源是最优的，然后一些安全等级模块，应该怎样分配到各核里去。
第五，Classic Autosar平台以太网的应用（Someip/DDS）。现在的EE架构的话基于看为主，分布式的EE架构，它是基于信号。
第六，RTE or Not RTE。RTE是AUTOSAR里很精妙、巧妙的设计，当时没有达到预期的设计状态。
现在自动驾驶控制器在分布式、集中式EE架构处于中间一个状态，所以不但要兼顾基于看以太网、看为主要网的东西，后续会慢慢转入很多基于以太网的应用。但是传统的ECU不具备基于服务的方式，百度是全球首家把DDS协议集成到AUTOSAR平台。
在开发阶段，做量产的时候需要跟上很多关联件做交互，量产的线控和Demo线控有什么差别？量产的线控可能是Demo线控超过5倍信号关系。实际对于量产来讲，如果只是做Demo是很容易就做，但是要卖车厂，车厂要卖给客户，还要关联到生产，需要考虑非技术人员怎么检查控制器的好坏？车在下线的时候怎么获取它的颜色，高低配置？比如说轮胎的半径，怎么来获取这些信息？然后是售后，售后人员怎么才能帮助定位这个问题呢？车出问题了，4S店维修好的车怎么恢复自动驾驶功能？
需要诊断。诊断贯穿整个开发流程，不是主要给开发人员用的，是给非技术人员用的，是为了在生产或者售后的时候，让非技术人员对于上百个控制器，可以拿着仪器做下线定位故障、配置、刷新，售后人员也可以反馈一些故障，帮您解决这些问题，这也是诊断的核心和意义。诊断的话，大家一般用的时候会拿着仪器，在COM上面会有个OBD接口，通过这个仪器可以读到车上、网端上所有节点通信的信息，通过这个来判断有无问题，或者对这个控制器做一些简单的配置，也可以通过这个来刷新软件。
诊断的开发过程会贯穿在整个需求阶段，再到生产阶段。会有很长的一个链，车厂会有诊断工程师，我们要有诊断工程师，诊断工程师会调度硬件工程师、软件工程师、安全工程师来完成诊断的过程。
百度诊断是一个大诊断的概念，不仅仅是售后、生产关注的一些应用故障，AUTOSAR底层的一些模块异常、算法都在做一些管理和处理，已经把诊断跟云端共同来支持售后分析，做整体的调度，这是百度的诊断机制。
诊断与研发、生产都相关，下面讲的这个下线标定，主要有2种，与生产相关的，在整车下线的时候需要做的一件事情。平常的开发拿标定板就可以标定了，但是做量产需要一个很标准化的流程，相对自动的流程去把所有的车辆摄像头、传感器做一次标定。如下图所示，前面工序完成了以后，一般在四轮定位工序，标定间布置在工序里面做下线标定，把下线标定的软件结合诊断协议来实现这样一个功能。
这个是百度标准化的下线标定的过程，有标定间的产品化的制作，也有做完标定后仿真的结果，是百度产品化后下线标定方案。
接下来看另外一个场景，假如我们车已经卖出去了，开着车摄像头撞歪了，去4S店换了摄像头，换完摄像头其实自动驾驶工程师是开启不了的，因为摄像头处在没有标定的状态，或者是假如能驾驶但是安装位置是不一样的，有可能导致自动驾驶处在不稳定、不安全的状态。在4S店没有标定间，不可能每个4S店都做个标定间，成本太高了。其实这里面要做一个在线标定的过程，百度做了在线标定软件在里面跑，这样有标准的售后标定的规定，选择一条直路，对场地、驾驶方式做一些约束要求，跑完这个区路后，把摄像头标定完成后，自动驾驶就能正常运行了。
车钥匙的上电、下电实际跟电的开关一样，开一下是上电或者下电。自动驾驶上下电管理都做些什么？其实分两个部分，一是对外部而言，会跟整车上下电进行握手，不能一意孤行的去上电或者下电，需要上下电配合。二是对内部而言，下电的时候需要对此项做处理，这样可以延长控制器存储寿命，另外里面是更多状态跳转的机制，功能安全里面有多点功能，多点故障属于单循环做一次就可以了。大家需要思考的是单点火循环故障应该是放在上电还是下电?放在上电考虑上电会影响上电时间，放在下电的话，考虑怎么样保证现场，在下次上电的时候要知道上电的状态，这些都是上下电处理的事情。
与上下电强相关的网络管理，车的钥匙上电或者下电实际上不同状态，其实有三类控制器，一类还是在跑的，下电了还是在运行的。二类是临时下电，需要做互间配合，配合完了后才做下电，整车在设计的时候会对每个控制器交互都会做一个规定。三类直接下电，与其它间没有交互。当然自动驾驶ACU的控制器属于临时下电类的，它是要与网管做网络唤醒/协同睡眠的过程，网络管理是通用的名词。
后面这个讲的是量产线控，线控是很关键的地方，做量产的时候，做Demo的时候需要关注纵向、横向能不能握手，能不能控制，这样让自动驾驶跑起来。实际上真正在做量产时，线控关键的点是怎样来保证安全，关联件状态反馈时做些降级处理，做些operation的动作。之前有统计过，做Demo信号与量产信号数据量相当于5倍的差异。这个需要考虑的因素是很多的，也是逐渐在跟车厂合作中有更多积累，行业类的对这块的认知和理解性没有到一个完整的状态，所以在迭代的过程中我们也是在持续在完善做安全线控的机制。
另外，市面上有很多种线控的接口，有可能基于ACC结合等等。百度有做这样一个控制这个接口层，线法底盘抽象通过这层来管理。现在自主国车产品实际上在适应各种之间加、减速度的接口，具体的这种接口都是适配的，也能做到好的效果，这也是一个量产核心能力。
好的EE架构会影响整个车辆，整个平台的延续、可扩展性，延续多少年，如果EE架构设计不好的话，车型、平台的发展是比较窄的。所以适合自动驾驶EE架构是有挺多考量的，考量它的拓展性、功能安全要求，还有信息安全相关联的地方。
百度在做控制器经历了几版迭代，不管从算力、成本权衡、功能安全验证做了很多版的迭代才有现在缩减的状态，希望大家对做百度做量产硬件的事情有更多的认识。
ACU-五仁控制器，说下它的一些技术参数，做了高低温的测试，高温下是28W，主要在自然散热的情况下完成。室温下是20W，均满足AEC-Q标准，静态功耗达到0.1mA，也是车辆的要求。
作为完整的DV测试，DV测试是最关键的门槛，DV测试已经完成，包含有EMC测试报告、可靠性测试、环境测试报告、电性能测试报告。
ACU接口，做自主泊车产品时5B12S方案，蓝色部分是4个圆相同的接口，还有潜水管脚的接口，视频输出的接口，CAN留有4路，3路是预留的，还有1路是选了1个比较Safety CAN来支持连接底盘监控、中央网关，这是主要的一些接口。
这个是我们做了一个比较完善的功能安全设计，除了这些基础的、通用的硬件上电源的隔离，安全电源监控的设计，时钟的监控以外，还设计了一个安全岛的概念，这里面如果监控一些异常的话会可以通过安全岛走光道路径保证整个泊车处在安全的状态，这是很核心的概念设计。
另一个是整个设计流程做的很严谨，是按功能安全设计的，这边是FMEDA与DFMEA的一个表格。例如，DFMEA有分析看到，故障案例有876条。刚提到故障管理的地方，会拆检到故障管理所有软件相关，需要软件来实现的在故障管理都会实现。最后通过硬件注入测试来把整个闭环做完，大家知道很多厂家是没有做硬件注入测试的，因为这不是一个必须项，而是高投入、低产出的事情，会损坏很多板子。百度为了让做的东西更严谨、更安全，花了很多精力把整个闭环给打通。
下面是自动驾驶的控制器相比于传统的控制器有更多高速信号，传统控制器就4层板或者8层板，而自动驾驶控制器到14层板，所有就有很多高速信号，和信号完整性的问题，在前期也做了信号完整性的仿真。我们把车规电器测试的接口按标准测试，很多测试报告提供给车厂的，需要他们的认可，所有的接口也做了车规EE测试。
最后一个DV测试，图上是DV测试时的实际场景图片。做DV测试我们是插不了手的，我们是第三方，做不了什么东西，所以很具备客观性的。这个是整体我们硬件的状态，就是载体的部分最关键是硬件的整体。
传统V流程结合，关于神经网络这块的需求，训练模型结合到V流程里面做的一次融合。
第一个观点是传统的观点，以前在车厂的时候实际上假设控制器到了SOP的阶段，这里面任何一次软件升级都可能是一次召回事故。对这个事情有个敬畏型，车会有它自己的规则。比如像过去其他有OTS，对OTS的技术程度越来越高，但没有OTS的时候，比如有SOP要做一次ESN，做一次变更，把车拖到4S店做升级，这里面不单是成本和人力的消耗，对品牌声誉也是致命的打击，所以大家对软件升级不要太草率。
第二个是自动驾驶开发是矛盾的产物，首先自动驾驶技术还处在一个快速迭代的过程，它是必须要用敏捷开发的，它的迭代技术升级是很快的。然后自动驾驶跑不开一定是一个汽车电子的东西，所以必须遵循汽车电子V流程的开发，这几十年，V流程已经验证过能保证汽车的安全和稳定，自动驾驶兼具这两种属性，所以既要用瀑布式的开发，又要满足快速迭代的需求，需要做一个结合才能把自动驾驶得更顺畅。
第三个是不用工具的流程都是耍流氓，不要总觉得流程就是写文档，用的WORD、EXCEL都串起来，这样对流程理解是很浅薄的。例如，怎么做敏捷开发呢？敏捷开发的至少有几个基础，模块之间需要足够的解耦，它们之间的依赖是比较少的，这样才能在自己的模块在迭代的过程中不会影响别的功能。敏捷开发每次提交代码需要走持续集成的过程，提交一次代码，它会静态检查代码铲除，然后再跑起来做基本自动化的测试，这样可以做到一次从提交到测试很快的循环就完成了。这里面其实是这样的，如果你要做这种状态的话，没有工具怎么可以，至少有个很完善的流水线这样一个工具，需要把自动化的测试提交的整个过程连接在一起。所以没有工具肯定做不到这些的，特别检查VO端到端的验证方式，也是需要有一个很强的追溯性风险，必须跑不开有工具来支持的。
这个是百度对于敏捷开发与V流程结合的应用方式，可以这样来讲，小循环是需要敏捷开发的，大循环是很支持严谨追溯的端到端V流程的测试，这样的话既能保证自动驾驶快速迭代，又能交付时经过完全验证的过程，比较安全、稳定地做一次交付。
首先是传统的一个概念，只有硬件才有故障，软件是不存在故障的。功能安全的基本概念是硬件是随机性失效的，软件是系统性失效的，随机性失效是不可避免的，只能减少它的概率。系统性失效全部通过测试来覆盖，只要软件出现bug，不应该存在故障，存在故障全部是bug。我们也知道神经网络实际是天然存在转召率的，它是存在随机性失效的，对于里面的认知还是不够全的，所以不能完全用传统的观点去认知这个事情。具体说怎么保证自动驾驶或神经网络的安全。
另一个是复杂系统与确定性系统的功能安全，传统的意思是基于一些确定性规则的功能安全，比较容易分析和拆检。复杂系统这块，其实现在的自动驾驶一般都顺利达到，怎么去保证一个关键链部或者模块的稳定性和安全性还是整个系统呢？这个需要做个取舍，也是大家需要思考的问题。
最后一个自动驾驶的功能安全更依赖于整体协同，因为整个自动驾驶的功能安全更依赖于车厂的认知，实际上经常获得很多的标书对于零部件功能安全很粗暴的，这些应该来讲是不太合理的，整个自动驾驶安全实际是需要更多的零部件做配合，需要在拆检的时候去兼顾哪些零部件是不能实现功能安全，对于一些车速因素等。百度在这方面有很多的经验和思考的，在帮助很多的车厂做自动驾驶的功能安全的分析和拆检，大家有机会的话可以一起来讨论这个话题。
这是百度做安全的里程碑，有ISO26262、ASPICE认证，发布了很多关于自动驾驶相关的一些白皮书。最后是很重要的标准，百度作为一个出让成员，现在在跟很多核心自动驾驶制定一个标准4814、4804。怎样让自动驾驶做到安全、标准，需要去关注下这个标准，然后更合理、更完善地去讨论这个事情。
以上就是我们讲解的百度ACU开启2020年首个量产车型交付新篇章课程的全部内容，更多系列主题讲解，请持续关注Apollo开发者社区。
点击文章左下角『阅读原文』
可观看直播回放