东软睿驰刘威：端云协同助力实现高等级自动驾驶
2021年6月17日-19日，由中国汽车工业协会主办的第11届中国汽车论坛在上海嘉定举办。站在新五年起点上，本届论坛以“新起点 新战略 新格局——推动汽车产业高质量发展”为主题，设置“1场闭门峰会+1个大会论坛+2个中外论坛+12个主题论坛”，全面集聚政府主管领导、全球汽车企业领袖、汽车行业精英，共商汽车强国大计，落实国家提出的“碳达峰、碳中和”战略目标要求，助力构建“双循环”新发展格局。其中，在6月18日下午举办的主题论坛“智能网联汽车产业生态的融合与升级”上，东软睿驰汽车技术（上海）有限公司副总经理刘威发表了演讲。以下内容为现场演讲实录：
很高兴到这个时间还有这么多同仁在这里听我分享。
我演讲的题目《端云协同的自动驾驶解决方案》，之所以做这个主题演讲，也是来自于我们的实践和思考。大家都在谈论自动驾驶，首先从趋势和现在目前我们面临的问题来入手，说我们需要什么样的技术，什么样的解决方案，才能真正的最终走到高等级的自动驾驶。
从整个E/E架构来看，从过去传统的单体式架构，一个整车上百个ECU或者70、80个ECU是面向过程的开发模式的形态逐渐过渡到今天是什么样的架构呢？很多都在提域控制器，我们有座舱的域控制器，有车身的控制器，也有支架的控制器，开始做整合，目前很多还是在分布式，但是已经出现了一些座舱和支架放到一个控制器里面，车控和座舱放在一个控制器里面，已经开始逐渐演进，出现了面向对象分布式的架构。
未来我们会走到中央计算单元，现在已经有一些车企考虑说随着算力的提升，我做5G硬件的预埋、软件架构的预埋，我们可以做一个中央计算持续不断地迭代升级，面向提供服务的架构，未来通过软件订阅的方式，整车售后产生价格，今天演讲嘉宾也说了，特斯拉是4%的收益是来自于售后软件的收入，也有一些数字。实际上对于车企和供应商来说，很可能是改变商业模式，我们车卖出去之后，很可能不能通过预付大额的开发费，也不是预先支付产品的成本，整车也不是一开始卖出去单车盈利，这种商业模式的变革通过技术的演进发生。
另外就是开发模式的变革，过去总结成平面式的开发模式，每个控制器都是独立进行开发的，今天大多数量产车可以看到多个控制器，从自动驾驶的角度来说，比如说有泊车控制器、有行车控制器，还有疲劳监测、座舱控制器、OMS的控制器，这么多控制器都是平面式开发的，有不同的供应商独立开发，最后由整车厂进行集成，这些功能和硬件都是在独立的做开发，是建立在信号的架构上，这是我们今天的开发模式。
但是实际上我们现在已经在中国的车厂开始了新的架构，新的开发模式，把它总结成总体的立体的开发模式，但是局部又是平面的开发模式。
随着今天摩尔定律硬件的算力提高得非常快，硬件已经开始军备竞赛了，硬件已经达到上千T了，软件的架构如何对应呢？分散的又被整合到一块，不可能是独立的软件架构，一个硬件平台上只有一个独立的软件架构，这个架构怎么支撑这么多功能的开发，而且不是独立的供应商完成，一个框架下集成多个供应商，要接口定义、开发模式都不同。整车又要求两年或者一年半快速的开发出来，硬件不断地迭代，如果软件、架构不能够支持变革，开发的工作量就非常之大，很可能在你规定的量产周期内完不成量产的开发。
面对这些问题怎么解决这个挑战呢，需要一个稳定的架构，这个稳定的架构里面要解决几个问题，第一是分层次，所谓的分层次就是硬件的变化，因为芯片总是在演进，算力总是在提升，能不能做出软件的架构屏蔽硬件的变化，硬件的变化对我软件上层的开发所带来的变动的工作量尽可能少，这是一个挑战。
另外，我在这里面除了做软硬的分离之外，我们会适配不同的车型，搭载不同的操作系统，也可能连接不同的云，也可能是车厂自建的云，这些所有的变化能不能不影响我原来开发过的部分，对我的功能影响尽可能的小，这也是一方面的诉求。
再有就是软件两年迭代周期非常短，自动驾驶技术是不是成熟，是不是经得起大规模的验证，时间非常短，虽然你有仿真的手段，真正的仿真不能带给路测，这么短的时间内功能开发不完，后面要做OTA的升级，要做服务的订阅，你的架构必须要支持这些开发的诉求，两年之内没有开发完，后面可以做不断地功能迭代升级，我可以基于我原来软件的模块衍生出新的服务，通过新的服务在整车售后之后，还可以源源不断地产生服务的价值来赢得利润，整个架构要做好这些适应的变化。所以你要有一个灵活、稳定、可扩展的中间件的平台厂。
另外整个上面我们说还是要开发一些功能的软件，比如说泊车、行车、疲劳的，控制器变成一个，但是这些功能模块仍然存在，但是这些功能模块存在耦合，过去是独立的，我们通过看总线来交互，但是交互的信息非常有限，你做的功能是受限的。但是一旦统一的架构下面，一个控制器上面，这些软件模块的交互，交互的信息量比原来放大很大倍，如何利用好这些交互的信息，把功能和体验做得更好，这也是一个诉求，这里就涉及到了我们要分层次的达到一个立体的软件架构，解决刚才我们所说的问题。
另外自动驾驶里面大家都在谈有一个长尾的问题，我们在量产初期或者量产之后解决的也是高频出现的场景，一些L2的功能或者L2+的功能更多的是适用的高频通用的场景，真正的交通场景当中仍然会有一些长尾的、低频的小概率发生的场景，但是这些场景不代表没有，但是一旦遇到，你的ODD或者时效处理里面没有设定的处理之后，很可能会发生交通事故。你怎么才能解决这样一个长尾的问题？简单通过仿真测试的场景是有限的，生活当中的场景是无限的，你不可能用有限的场景代替无限真实道路工况，所以长尾效应一定会一直存在，它会随着自动驾驶等级的提高，其实更多的工作量是解决5%、2%，甚至1%的问题，但是这5%、1%的花费的工作量比前面95%的场景所花费工作量大得多，而且它很难收集，因为不是高频的场景，你整车、软件一旦上市之后怎么解决这样一个低频发生长尾的场景也是一个挑战。
这里涉及到一个问题，就是算法自我进化，自我进化首先就是你得能够进化，你得有支持你软件进化的架构。另外要有支持进化数据的收集，就是长尾的数据是非常难收集的，是可遇不可求的。所以大家最终比拼的就是你有多少长尾数据，真正长尾数据的收集是有很多东西，一开始软件架构，控制器里面有没有这样的机制，研发阶段、路测阶段都可以收集这些数据，但是不同的阶段收集的不一样，你的模块怎么完成这些功能是在你一开始做产品的时候就要思考好。
我们提了一个概念叫端云协同的自我进化，其实很简单，我们在控制器中嵌入多级触发器，价值数据触发后同步至云端进行迭代训练。这些长尾有价值的数据通过软件模块和数据通道上传到云端之后，在云端才可以做自我迭代、更新、训练、调度，仿真去做迭代，迭代之后测试，然后部署，这是一个闭环。这里面涉及到一个问题就是如何用量产低成本的控制器，我们不可能用一个40、50万的控制器去收集数据，如果在量产的产品上做这样一个事情是非常关键的。
刚才我们提到了你的软件在两年的周期内功能不可能完全成熟的，一些有价值的功能，很可能通过订阅的方式，后面才衍生推出来的，你整个软件架构要SOA化的，就是面向服务的，后期才能通过订阅的方式来做价值的收集。
我们也列了SOA具体的要求，比如说服务的通讯、通用，无论是车厂还是供应商，不能开发每一个车型，每一个预控制器都是从0到1，重新开发，这个工作量太大了，每一个企业都是受不了的，你如何做集成，这里面有很多的问题，你原来开发的AI的模型可能是在8tops算力上面做的，可能是200万的摄像头收集的，那能不能迁移到一个800万的摄像头上面去，能不能迁移到100T的算力平台上去，所有的东西，包括过去收集的长尾数据能不能嵌到新的硬件平台上，这些东西都是要被解决掉，不能从0到1。
另外就是自进化，车端价值数据发现、数据采集及上传，在云端做配置的访问和升级。另外就是功能安全、信息安全、端云协同，你在车端有工具链，你在云端也要有相应的工具链，如何来实现一个闭环生命周期的开发，这是很挑战的。我们也是通过实战自己摸索出来一个自动驾驶SOA的软件架构，目前也是在迭代产品里面在用。
首先下面是一个硬件厂，无论你将来的硬件算力如何升级，换成谁家的芯片，我们有一层自己AUOTSAR，我们管它叫NeuSAR，我们通过ACore和CCore来做软硬的解耦，这样尽可能的减少你预控制器升级、芯片变动所带来的开发的工作量。
在整个架构里面，我们有一个自己的Framework来完成基于流水的实时调度，这里面还有一个ELA的模块，比如说操作系统换了，整车的探头矩阵变了，你的车型变了，这些变化对其他的功能模块所产生的影响最小，甚至于不要产生影响，所有的东西都是封装，通过原始服务进行封装，这样可以做成独立化解耦，减少变化的影响。
另外Core和Module里面我们也封装了一些相关原则的服务。这里面很重要的就是你的架构必须是考虑信息安全，这里面我们嵌了两个专门的模块去做安全的启动和信息安全相关的东西。
在服务层，这是我们客户主机厂非常关心的，这里有传感器的服务，你如何换传感器，换一个激光雷达、毫米波雷达或者换摄像头，对我整个架构没有产生影响，对我的功能模块产生的影响最小，这些东西都要考虑。
另外就是场景服务，在自动驾驶量产过程当中，你会遇到场景，会遇到一些长尾的场景，怎么收集这些价值的数据，在场景服务里面封装了一些相关的服务，你可以把有价值的数据源源不断地传自云端，触发器的设计在不同的量产的阶段，所收集有价值的数据也是不同的。
我们重点讲一下架构里面左下角蓝色的部分叫中间件，有四个大的模块，第一个就是Framework完成的是任务的调度，线程之间的同步和通讯，任务的监督。在ELA里面主要完成系统接口的抽象，包括通信的抽象，包括车控接口的抽象，包括云端交付，后台可以可以接不同的云，可以是公有云，也可以是私有云，接入云的不同并不会对功能产生影响，这些东西都已经封装上了。
另外在Module和Core里面封装了很多的原则的服务、感知的服务、微控的服务。
我们刚才讲了有价值的数据之后怎么高效地传输到云端，在ELA和Core中间件里面我们有一些端云服务的服务，能够打通车云协同的价值数据通讯的链路，无论是在量产之前配置价值数据收集器，还是说量产之后我想开通新的价值数据的收集器都是可以实现的，对整个软件架构是不产生影响的。我们的ELA模块也提供了云端的服务负责数据的上传和OTA更新。
功能安全大家谈的就很多，我就不再详细地展开了，除了硬件功能安全之外，在软件的架构里面每一个模块都是按照功能安全的标准开发的，考虑了很多机制。
我们有两个信息安全的模块，有很多东西，比如说安全检测，不能对我传输的数据进行篡改，我要加密。存储的数据不能被破坏，不能劫持，安全的OTA，甚至于我是片上通讯都要做保护，因为刚才有很多演讲嘉宾也讲了，我们整个预控制器是多核异构的状态，是不同的芯片，不同的芯片之间、SOC和SOC之间，SOC和MOC之间都会做通讯，通讯的过程当中，这些数据是要被保护的，不能够被篡改，大家更注重的是功能，但是这些数据传输如果被篡改了以后，如果没有校验机制实际上是不能保障功能安全的，虽然有备份了，也有不同的降级处理了，但是这些数据也是要被保护起来的，否则功能安全很难实现。
再就是整个软件架构里面嵌了多级触发机制，那些有价值的数据，可遇不可求的数据，怎么样在量产当中能够很快的收集起来，这是宝贵的财富，但是可遇不可求，所以我们的软件架构可以支持触发器灵活的热插拔，就是类似于鼠标，插到PC机上，无论买谁家的鼠标都可以无感的插到PC机上。但是触发器不可能一开始写一个规则，比如说到什么入口也要触发，这个规则提前写死了之后，将来新的规则没有办法做，因为随着自动驾驶功能升级，还有场景扩展所要收集的数据不一样，如何在你量产以后还可以收集不同的数据，不是一开始你设定的那些数据，其实这是在对整个架构，包括价值数据的收集是有一些规则的，这里面可以收集不同的数据，比如说感知的、微控的，甚至于位置的，很多模式。怎么量产之后还能够收集数据，我可以随意的开关插拔这些触发器，这是架构里面要考虑的问题。
刚才我们讲整个控制器里面的东西，我们也做了云端的东西，我们有自己的数据平台，有自己的训练平台，也有自己的仿真平台，我们自己开发了在云端、PC机上并行好的轻量化的仿真软件，如果大家感兴趣，也可以私下交流。
我们做了自动驾驶的平台软件生态包，我们知道整个车企也好，还有供应商之间的合作模式TL1、TL2，还是说车企边界线开始逐渐模糊，有了0.5的概念，未来一段时间内还是混乱的局面，开始逐渐走向稳态，这个过程当中合作的边界不是十分的清晰，我们也是把自己做成一个弹性，不是一成不变的的TL1，不是过去的黑盒，我们可以白盒，可以灰盒，可以是部分的模块，也可以全栈，所以这样比较灵活的跟车企服务，所有的东西动都是我们自己开发的，包括底层的算法、操作系统，包括AP、CP都是自己开发的，也是造就我们今天灵活性对应量产很重要的原因。
最后通过这张图把今天讲的内容总结一下，大家都说作为自动驾驶本身是数据闭环，从我们的理解来看，第一就是在车端有一个域控制器，右边是载体，但是我们今天讲的更多的是软件的架构，是一个满足功能安全、信息安全的、软硬分离的、可解耦、自我进化的可以收集价值数据的软件的架构。通过这个架构可以收集长尾的数据，收集数据之后我们在云端有个云平台的供应链可以做数据管理，可以做数据标准，也可以做数据训练，这是一个云平台，这里面有很多供应链可以向其他的合作伙伴进行开放的。
通过我们智能驾驶跟传统车企的智能网联云，可以做个性化的东西。今天演讲嘉宾也说了，可以用手机，也可以用数字钥匙，我们把它作为其中的一端。另外就是传统的车企和TL1也好如何有效地连接起来，达到端云协同自我进化的系统，我们正在落地做实践，有很多量产的项目，不同形态的产品，无论是智能摄像头，还是舱内的DMS，还是域控制器都是在走这条路。
以上就是我的介绍，谢谢！
