自动驾驶软硬件解耦技术及趋势探究
“在软件定义汽车的时代背景下，软件的地位越来越高，智能汽车行业发展需要实现软硬件解耦。”
类似上面这样的话想必大家都不陌生了，在智能汽车发展的这几年里，汽车供应链的构成发生了翻天覆地的改变，而软硬件解耦，则成为了无论是主机厂还是供应商都一直在想办法解决的问题。
但是，标准依旧难以统一，各家的接口依旧各不相同。即便这么些年过去了，软硬件解耦还是面临着重重困难。
01 软硬件解耦的背景
EE架构的演进
（对该部分主题熟悉的读者，可以跳过，直接进入下一小节）
几年前，一辆整车上的ECU仅仅只有十几到二十个，但随着电子娱乐消费主义不断侵入人们生活的方方面面，人们对汽车的功能需求也逐步提升，而在分布式架构的背景下，每新增一种功能都需要不断地增加对应的ECU。对于自动驾驶汽车来说，更是如此，于是，一辆自动驾驶汽车上的ECU发展到了最多近一两百个。
ECU的不断增加使得用于数据传输的线束总长度与总成本也不断增加（根据佐思汽研的测算，如果沿用目前的分布式架构，自动驾驶汽车的线束成本将不会低于 1000 美元），供应商的管理难度也有所增加。
除此之外，分布式架构下，ACC 、AEB这些功能是跟传感器（中的MCU）绑定的，彼此之间也是割裂的（这不符合第一性原理，人开车的时候不是这样），而高等级自动驾驶要求是各功能之间是一个有机体，因此，需要通过同一个SoC来实现。
在这样的背景下，如何在有限的空间里既能提高空间利用率，又能发挥ECU的最大的性能，成为了行业内下一个发展的方向。于是，汽车EE架构开启了从分布式架构向集中式架构演进的大门，为此，域控制器诞生了 ，许多ECU开始被域控制器取代，主控芯片也从之前的MCU升级成SoC。
ECU不断减少，汽车上余下的ECU也由原先需要承担一部分的计算，转变成仅需要承担大部分执行功能并被弱化了处理能力的“螺丝钉”（ECU仍有原先处理计算的能力，只是功能上已不需要它处理部分计算）。
EE架构从分布式向域集中演进、SoC取代MCU，为汽车产业从“硬件为王”时代向“软件定义汽车”时代的跨域创造了前提条件。
SoC芯片上集成了DSP、GPU、NPU等多个模块，不仅拥有控制单元还集成了大量计算单元。这让SoC芯片除了可以多任务并发外，还拥有了处理大量数据的能力。SoC芯片替换部分MCU，就像是一家公司多个部门的普通领导人被1个以一抵百的超优秀CEO取代。
在硬件为王的时代，由于软硬件耦合程度高，整车厂首先会找咨询公司做未来5-8年的汽车功能需求分析报告，然后再根据报告制定一个5-8年的软硬件一体化方案。当软件和硬件投入产线生产，直到整车厂将各种部件装好出车，5-8年之内，这辆车无论是软件还是硬件都很难再发生变化。
在软件定义汽车的时代，如果仍然按照原先车厂的整合流程，一次性定下5-8年的造车方案，那么，在车辆制造的前几年问题还不会太突出，但在这个方案时间区间的后半段，一辆车交付给用户的汽车，车上无论是硬件还是软件都已经远远过时。
因此，在产品设计阶段，就应该考虑到后续的迭代问题。而要解决迭代问题，就得软硬件分开发展。
当各家车厂的硬件配置都已趋同，硬件变得“卷无可卷”，为了实现差异化，主机厂需要能够以非常快速的反应能力去收集用户不断变化的需求，并进行对应的软件迭代。这时，主机厂有两条路可走：一条是自研软件和算法，自己解决所有问题，包括软硬件解耦；另一条则是软硬件解耦后找合适的供应商提迭代需求。
如果要走第一条路，主机厂需要非常强的实力，但并不是所有的主机厂都具备这样的能力，所以大部分主机厂会更偏向走第二条路。于是，软件算法公司地位开始提升，汽车供应链关系由原先具有分明的Tier1、Tier2、Tier3走向边界模糊的关系。
在这样的背景下，各家软硬件供应商之间为了更强的竞争力、更优的独立发展和更好的合作生态，也有软硬件解耦需求。
然而，尽管软硬件解耦的口号已经喊了好几年，效果却并不理想。
传感器、芯片与算法解耦困难
由于算法和传感器高度绑定，在实际应用中，这样的绑定对算法工程师造成了不小的麻烦。比如一辆车之前用的摄像头从200万像素的换成800万像素的之后，算法也不得重写一遍。
另外，某Tier1的算法工程师：
“即使有能力实现感知算法和传感器的解耦，在解耦之后 如何对传感器做标定，也特别难。”
由于软硬件耦合度高，传感器的数据和传感器也是高度绑定的，一旦传感器发生了更换，之前花大价钱做的数据标注就将全部作废，又不得不开始新的一轮采集，这对于算法公司来说是一件非常麻烦的事，但这件事目前并没有太好的解决方案。
此外，每辆车上的传感器配置、安装位置、安装角度都各不相同，因而，算法也不尽相同。感知算法不同，规控算法就不同。
如果说算法与传感器的解耦只是麻烦的话，那么算法和芯片的解耦就显得十分困难。
比如笔者在与诸多算法工程师交流软硬件解耦相关问题的时候，发现他们都有共同的痛点之一就是：由于算法移植困难，导致做了很多额外的工作。
这是由于算法迁移的频率是无法预测的。芯片厂商的竞争与产品迭代时常会影响着市场的偏爱，你无法确定下一个风口是否又会有新的更好用的芯片热卖。
市场偏爱的变化，又会让主机厂指定更换不同的芯片。这时候，对于算法工程师来说，也许你基于这款芯片的算法刚改好，那边又将面临新的算法移植需求。
造成以上现象的原因是算法和芯片的强绑定关系。不同的芯片提供了不同的BSP，这导致用于给芯片和算法解耦的中间件难以复用，必须对不同的芯片进行不同的定制化适配。
某主机厂智能驾驶系统负责人解释道：
“中间件跟下层BSP这一层的适配比较令人头痛。比如座舱芯片用了高通的8155或者8295，而自动驾驶芯片用了TI的TDA4，那么由于它们的芯片所提供的BSP不同，融合时就需要对中间件去做定制化的适配。”
不仅芯片平台的差异导致中间件不能复用，而且两款基于同一个芯片平台做的域控制器，如果硬件架构不一样（有的域控上面，有2颗甚至3颗SoC），对中间件的需求也不一样。
02 软硬件解耦面临的技术困境
中间件是实现软硬件解耦所需的最重要的工具，因此，软硬件解耦的难题，会集中体现在中间件身上。
目前的中间件其实都是需要根据功能、硬件平台、操作系统来进行定制，哪怕是标准化再高的中间件，也是需要算法公司或者主机厂去做适配的，很难说有一个中间件能够cover住所有的东西。因为所有的中间件都会有些限定或者限制，比如有的没办法快速定义通信接口，有的对于一些跨平台的支持不是特别友好，有的则是在其他芯片上匹配不好。
而中间件从数据传输本身，会出现数据偏转、数据错误、单模块失效影响数据传输等问题。比如，数据传输量较大，SOME/IP做数采的时候，很多通信信号采不到，就很容易发生丢包的现象。
另外，数据回传错误还会很容易造成一系列连锁反应，最终影响决策及执行层，引发不良后果。可以说，数据共享有利有弊，理论上可提高效率，但若源头出错，将会引发一连串错误，同时也缺乏有效的诊断及纠正机制。
除此之外，时间和地点对于数据传输也会有影响。比如在高速上，Autosar AP 对数据传输带宽就会有较高要求，这时，带宽传输协议和数据共线传输之间的冲突就会尤为明显。在节假日期间，带宽使用集中，负荷过高，就可能无法满足数据传输需求。
除了以上问题外，目前的中间件，还存在缓存机制没做好、功能组不支持嵌套、状态机协同做的得不好等问题，这些问题都需要算法工程师在已有中间件的基础上再去做修改，这大大增加了软硬件解耦的难度。
03 软硬件解耦面临的商业困境
除了上述技术方面的困境外，软硬件解耦还面临着一系列商业上的困境。
专业中间件厂商
以Vector、 RTI 、EB、易特驰为代表的中间件厂商希望能制作一套标准化、能适配于每一家的软硬件的中间件，一步到位地实现各家软硬件解耦的诉求。
但现实却没有想象中那么美好。一方面，除却几家中间件龙头企业外，大部分中间件公司的的产品一时半会儿很难赢得主机厂的真正信任；另一方面，算法公司大部分也并没有那么愿意配合中间件厂商做标准化，因为一旦接口、得逞系统被中间件厂商统一后，就意味着自家产品的可替代性增强，差异化降低，导致算法公司的竞争压力陡然上升，因此十分抗拒。
此外，在智能汽车的各项技术发展路线尚未明晰的情况下，主机厂是希望自家车的配置跟竞品有差异化来取得竞争壁垒（应用层的差异化也需要中间件的差异化做支撑），而标准化的中间件会与这个愿望背道而驰。因而主机厂宁愿自己开发中间件也不希望使用中间件公司开发的标准化中间件。
最终，这些中间件就变得很难卖出去，只做标准化中间件这件事变得难以为继。
从九章智驾了解到的情况看，除华玉通软等个别专注于DDS等技术壁垒很高的模块、并且已通过长时间的积累建立起一定的竞争优势的公司外，大多数最初定位为“中间件厂商”的公司基本都已在过去一两年内开始转型（向其他领域拓展）。
供应商
算法公司、部分软硬件都做的Tier1和芯片厂商都开始做起了中间件，但在实践中，家家都有一本难念的经。
算法公司
对于算法公司来说，如果他们购买的标准化中间件过于通用，就会有许多适配上的问题不能解决，但如果拿到的是黑盒交付的通用中间件，与算法不够匹配将会给算法工程师造成很大的困难。而如果购买了定制化中间件，算法公司还需要花很多时间跟中间件厂商沟通，成本也会很高。
某算法公司工程总监：
“如果有问题，一般来说，公司会将问题报给中间件厂商，但有的厂商配合度较低，需要算法公司提供实际证据证明是中间件的问题，否则就会扯皮，这时候就比较耗费人力和时间，影响开发进程。
“尤其是，刚刚开始涉足中间件的算法公司对于中间件的理解并不是特别专业，找到实证比较麻烦，将会耗费更多时间；而这个过程如果是几方配合的话主机厂还得出人做协调，这又会导致解决问题的进度被进一步拉长。”
于是，算法公司干脆选择自研中间件来更好地匹配自己的算法。
另外，国际中间件厂商的中间件价格昂贵，而国内初创的中间件厂商做的中间件，可能还比不过自己根据自己的算法所研制的中间件更为适配，也是算法公司自研中间件的原因之一。
“如果自研，我对我项目需求更了解，会不会比让中间件厂商去开发更好呢？”某算法公司系统架构工程师道。
除了以上这些外，算法公司自研中间件还有一个原因：各家算法公司的算法差异小，需要通过自研中间件来形成产品的差异化。
某算法公司高级总监说：
“目前，各家算法的差异性很难体现出来，都是用C、C++编程，要体现差异性就要在中间件上面把性能做起来，要把可靠性做起来，也就是增强功能体验上的一些优势。”
然而，算法公司自研中间件，也遇到了不少挑战。首先，主机厂自研中间件是可以对供应商提标准的，而算法公司如果自研中间件，就很难说服主机厂和其他供应商去适配自己的标准。
正如某L4公司软件总监所说：
“比方像蔚来小鹏他们自己去做中间件，因为他是整车厂，他可以定一套标准去约束他的供应商；但是如果是自动驾驶算法公司去做配套中间件，无论是说服整车厂，让整车厂相信你这套东西可以套用在别的域上，还是说服主机厂的其他供应商去按自己的标准做融合，都很难。”
另外，当算法公司自研中间件之后，如果出了问题，就无法甩锅了 ，因此对于算法公司来说，中间件就需要做得更好。
某主机厂的智能网联总工程师表示：
“我们会和供应商签保底的服务协议，也就是说一旦出了严重的质量事故，尽管车厂是第一责任人，但我们自然也会第一时间让这些供应商负责。所以算法公司如果做了中间件的话，到了该承担责任的环节，他们基本上就逃不了，至少我们也不会让他去跑”
芯片厂商
芯片厂商做中间件的目的是为了展现芯片的性能。
从技术的角度看，芯片厂商做中间件的难度要比算法公司低。因为，算法公司需要针对不同芯片做适配，工作量要远比芯片厂商做中间件更复杂，而芯片厂商做的中间件只要能跟他们自家的芯片适配就好了。
尽管如此，在实践中，芯片厂商开发出来的中间件，用的人却很少。
目前，已知在做中间件的主体就包括了中间件厂商、算法公司、芯片厂商和主机厂，中间件的市场份额是被分割得很细的，竞争激烈。这时候如果要开发完整的中间件，开发出来的中间件该卖给谁？是否能真正通过中间件实现盈利？都成为了在开发中间件之前需要考虑的问题。
某算法公司专家说：
“我们通常不会用芯片公司的中间件，因为他们做中间件更多是为了生态，他们的中间件功能可能更多，但性能不一定最优。也就是说， 中间件做的功能很多，包括AI的抽象、数据记录的回放、点云的处理，可能全部做了，但这种情况下会存在一个问题 —— 本来是算法要做的事情，中间件全部做了，性能就不能完全保证，并且它还要兼顾多家算法公司的需求，灵活度也会变差。”
可以看到，虽然部分芯片厂商是有能力做好中间件的，但是考虑到市场竞争压力大，还需要投入大量的人力物力去研发，有能力的芯片厂商大部分没有动力投入太多去做好中间件，而是更愿意专注于做好芯片本身。
所以，大部分芯片厂商的自研中间件做得很轻，做的基本是能够在芯片上跑起来的demo中间件，以此来向客户展示芯片的性能。这样的demo中间件，当然对软硬件解耦不会起到什么实质性帮助。
主机厂
对于主机厂来说，中间件的定制需求是一直存在的。
某主机厂的智能驾驶系统负责人举例道：
“比方说在写红绿灯识别算法或双目视觉算法时，如果要区别于传统算法或竞争对手的算法，就需要一套定制中间件，这涉及到中间件的数据订阅、共享、录播、回放、发送、存储、诊断等各个功能。但这些功能不能保证在主机厂所需要体系下或功能机制下完美运行，有可能会发生冲突，这个时候就需要中间件供应商来协助打通。”
但是，相比于使用第三方中间件公司或算法公司的中间件，部分能力较强的主机厂会更愿意自研中间件。
首先，购买闭源的中间件如RTI的DDS，往往意味着中间件定制化，不仅会需要更加昂贵的成本，而且项目的对接周期也会拉得很长；相比之下，自研中间件意味着能够完全掌控定制化的方向，拿到自己的数据，使产品不受限制，这样能够更好地掌控产品的开发进程和后期改造，解决可能因为某个中间件供应商掉链子而导致量产交付延期的问题。
其次，自研中间件对于主机厂来说，还可以形成一定的技术壁垒的。对于部分实力强劲的主机厂来说，一些上层的应用层也是完全掌握在自己的手里的，根据自己上层应用的需求去做自己的中间件，能够更好地做一些中间件的定制化，上层应用也能做出一些特色。
其实，在中间件技术尚未成熟，未来趋势尚不够明显的时候，行业内上下游的玩家之所以都在做中间件，一是试探自己能力的边界，二是探索整个产业的边界。
然而，多位主机厂的自动驾驶工程师认为 “跟算法公司相比，主机厂自研中间件优势不大”。
首先，大多数主机厂在算法能力方面并没有多少积累。专门组建一个团队去做中间件所消耗的成本是巨大的，但结果可能还比不过专门做这些的供应商，这样的消耗所带来的痛苦程度已经远远超过统筹数家供应商所带来的痛苦。这就像自己的短板项目带来的苦恼会比自己的强势项目上新挑战更让人感到痛苦。
其次，主机厂自研中间件难以得到足够多的样本反馈,因而不利于产品迭代。供应商的算法和中间件大家用的多，客户基数上去了，那么客户对bug的反馈率更高，更利于产品的迭代进步；然而，主机厂如果自研，产品仅供给自己，便很容易出现缺乏足够的样本数据，因而迭代得比较慢。
另外，主机厂如果要自研中间件，就势必要从其他企业挖技术人才。然而，对于人才来说，在大公司的一个部门里做事，他们也许是没有那么强的使命感的，毕竟总会有种“天塌下来，还有上头的人顶着”的感觉，而最后的结果就是，挖来的人才的能力如果能发挥出80%就算是非常理想了。但同样是这个技术人才，如果出来单干，研究的东西关系到个人的切身利益，他一定会有更大的压力以及动力去做好这件事，这样的环境下往往能够发挥出更多的才能。
最后，自研中间件对于主机厂来说，是需要耗费的大量人才构建研究团队，一旦发现这条路走不下去，这么大量的员工都将面临着全部被裁的风险，，而大量员工被裁又会让在职员工心里认为“公司不稳定”的情绪上涨。
这么看来，主机厂的“自研中间件”更多的时候可能只是个营销口号，但这并不是说所有主机厂自研中间件都是无法成功的，实力够强，能够成功自研算法的主机厂自研中间件成功的概率还是大的。只是相对而言，对于大多数算法难以自研的主机厂们来说多，软硬件解耦需求仍然需要由供应商来满足。
04 中间件正在“背离初心”
中间件的诞生本是为了解决软件和硬件无法分开发展的问题，因此，人们最初是希望中间件能成为一款起到阻隔效果的软件，能够精简流程，并能够适配于所有的软硬件，让上层软件应用工程师可以不去考虑硬件的适配问题，安心做好算法。
然而，现实却与最初的愿望背道而驰。
一方面，中间件呈现出了高强度的定制化。
某算法公司的软件架构师介绍道：
“每一种车型或每一个芯片平台对中间件的适配能力是不一样的，提供的底层软件对中间件的适配能力也不同。如有的车辆使用QNX操作系统，有的使用Linux操作系统，这两个操作系统对于中间件就会有一些定制化的内容。
“除了底层操作系统外，软件应用层对于中间件也会有一些差异化的需求，比如基于某一个平台上面，需要开启某些特殊的通信方式，有的需要传输数据并不是走传统的以太网这种通用的链路，而是走PCIe或者内存等特殊的链路，这就需要对中间件进行定制，使中间件能够支持不同链路的通信需求。
“有的自动驾驶软件厂商或者主机厂有自己的日志记录方式，有的可能没有，就需要有中间件来提供一个日志记录能力，所以根据不同用户自身具备的能力，中间件会产生对应的定制化。”
定制化就意味着，无论是让中间件厂商分人去做标准化之外的需求，还是让算法公司/主机厂派专门的对接算法工程师去做中间件的个性化适配调整，都需要付出额外的人力物力。
而定制化的中间件又让算法对数据的解析产生了新的困难。
某主机厂工程师直言：
“如果量产车上要上V2X，但不同品牌车型上的中间件不一样的话，那它的QoS（服务策略）就不一样，那对数据的解析就存在问题，因而，车车之间的通信可能存在困难。”
另一方面，“越来越多的玩家开始绕开 AUTOSAR的标准自己搞。 即使同样给予AUTOSAR标准做的中间件，定制化程度也很高。”某主机厂系统专家道。在各家都在自研中间件的当下，中间件大多只适配于自家算法、接口等，无法统一的现象也愈演愈烈。
无论是主机厂还是算法公司，比起考虑中间件是否好用、有没有实现软硬件解耦，真正在项目合作时考虑的更多的还是否能解决实际遇到的问题。如果买来的中间件没能解决问题、没有达到想要的效果，那么就还需要合作双方在原本中间件的基础上再修改增加各项内容，也就会形成不断“加耦”的状况，中间件的定制化又成为了一种必然现象。
于是，再回想起中间件最初以简化流程、减少工作量为目的的初心，不由唏嘘。
05 到底如何才能实现软硬解耦呢？
那么，如果要实现软硬件解耦，可以从哪些角度着手去做呢？
一方面，可以从操作系统层面先把硬件虚拟化做好，将接口、通信协议等标准化，这样能够使上层应用无需考虑底层系统的不同问题，但这需要芯片厂商和操作系统厂商深度合作共通完成，或是芯片厂商自研OS，因此还是存在不小的难度。
另一方面，虽然目前中间件的未来形式还尚不明朗，但有一点可以确定，软硬件解耦仍然需要以中间件的形式解决，只是中间件可能会分化成几种方式：
1、中间件厂商基于Autosar本身开发简化Autosar的工具类型中间件。由于Autosar本身十分复杂，工程师的学习难度不小，如果能够提供简化版本的开发工具，把这种工具提供给上下游需要自研中间件的厂商，优化他们自己自研中间件的流程，也不失为一种选择。
2、中间件厂、主机厂和供应商形成中间件联盟，由芯片厂或者主机厂牵头统一规则。在市场边界的试探中，由一家极强的主机厂或者芯片厂牵头，形成行业联盟统一标准，将OS、接口等全部统一，形成行业规范。
3、完全开源，由芯片公司打造专属OS，让上下游公司在此基础上开发。芯片厂商做出类似英伟达CUDA那样的开源工具包，不但自己开发OS和中间件，并且完全开源，帮助上下游的客户共通使用工具进行更好的适配开发，建立良好的生态。
4、作为一种服务，上门给供应商做中间件的定制化服务和维护工作。由于受到市场天花板低和中间件难以统一的影响，中间件也许不会成为一种独立的产品存在，而是成为一种定制化服务。中间件厂商由于具备更优秀的中间件研究经验，是更优于去提供这种定制化服务的玩家。
曾经，各种手机品牌百花齐放，在“板砖机”和智能机并肩齐飞的2005年到2010年，市面上流通的手机接口最多可以高达200多种。不同品牌的手机有着不同的充电接口，不同的耳机接口，形状相同大小不同的大大小小的各种接口，甚至同种品牌的手机也有不同的充电接口。
当时的一位数码达人出差的时候往往不得不带上5、6种充电器和5、6根不同的线。即便后来我们拥有了万能充电器，也只是能把板砖机的电池扒拉下来充电，智能机的充电口和大大小小不同的耳机接口无法统一的问题仍然不能被解决。
这样混乱无序的时期，却又是手机兴起之后，手机科技发展最为灿烂而蓬勃的时候，正如现在智能汽车的发展。而今天，我们看到手机接口已经基本统一，成百上千的手机厂商，在各自自研的过程中，在市场的最终抉择之下逐渐减少，最终形成了标准。
智能汽车行业作为深受电子消费市场的影响，特别是受手机市场影响的行业，这两年行业内的各家都显得十分浮躁，大家都急于去快速进展到一个终局状态，希望能在很短的时间里选出一个集大成者。然而，汽车的制造业实际上又是一个发展缓慢的行业，从车辆的生产到量产再到投放到消费市场，最后从千万用户那收集使用反馈，才能不断优化自身形成标准。而也许只有这个时候，中间件才能真正统一起来形成标准。
而未来技术成熟之后，中间件也许会作为固化在ASIC芯片上的基础软件，不再单独以中间件的形式出现也未可知。
06 最后说两句
不过，话说回来，当前，在各方都困难重重的情况下，中间件到底适合谁来做呢？
总体来看，如果我们是奔着用标准中间件完全实现软硬件解耦这个目标去的话，最适合去做中间件的其实是芯片厂商。
两个理由：一是算法的适配归根结底是要基于芯片平台的，芯片是基石。二是芯片公司相对于算法公司来说数量更少，统一起来难度相对更小。
但目前而言，基于各家都期望定制化的前提下，最适合做定制化中间件的则是算法公司。
“芯片企业更关注芯片本身的应用，如是否加校验机制、BSP如何调度、加速等需求，芯片企业均可实现，但芯片企业并不能对应用软件及中间件提出更好的优化建议，用户端仅能使用其成熟方案，但此方案未必能够满足软件的全部需求。”
可以看到，算法公司是在业务实践中收到定制化请求最多、并被要求最多去做中间件适配的角色，能直接做适配自己算法的定制化中间件是最方便的。
某主机厂总工程师也有着相同的观点：
“就目前而言上层功能服务相对聚焦，自动驾驶方案供应商对功能应用理解较深，从应用层下沉抽象出来中间件，能够更好匹配底层主流的芯片硬件方案商，整体方案较为合理。”
图片使用申明：原创文章图片源自‘Canva可画’平台免费版权图片素材；引用文章源自引用平台文章中所使用的原图。