BB娱乐平台登录艾弗森与智能汽车相见恨晚的SOA到底是什么？

　　“软件定义汽车”最关键的环节是SOA（Service-Oriented Architecture，面向服务的架构）。基于硬件算力提升、车载以太网的发展，以及汽车网联化带来的影响，SOA在二十年后将被重新召唤。

　　张航，中科创达智能汽车事业群首席架构师兼工程VP。2003年获得武汉大学计算机专业硕士，曾经就职于IBM、NEC等国际知名企业。2008年加入中科创达至今，参与了多款智能手机、智能平板、IoT设备的研发项目，历任研发总监、架构师等职务。2015年加入智能汽车部门，专注于智能汽车操作系统的研发和技术预研。

　　“软件定义汽车”是近来很火的概念。2016年，前百度高级副总裁王劲提出“软件定义汽车（Software DefinedVehicle，SDV）”。在2019年达沃斯论坛上，大众CEODr. Herbert Diess宣布，大众要转型成为一家软件驱动的公司，并且发布《软件定义汽车》的文章。此后整个2020年，SDV这个词一直萦绕在汽车行业的各种会议和论坛上。但事实上，整个行业对于软件定义汽车的认识是不太一致的。

　　首先，在未来的汽车中，软件部分的价值会逐渐提升，这在行业内已基本达成共识。根据普华永道的预测，到2030年，汽车软件占汽车总价值的比例将会达到60%以上，开发成本增加83%以上。在智能座舱、自动驾驶、ADAS（Advanced Driving Assistance System，高级辅助驾驶系统）、能源管理等方面，软件部分的创新将占整体的90%以上。因此，整个2021年上半年，汽车行业内呈现着软件人才紧缺的现象，各个整车厂和零部件厂商都在大力筹建自己的软件研发团队。

　　然而，并非所有人都赞同“软件定义汽车”，有一种意见就认为，这不过是IT行业进入汽车领域的宣传，硬件和制造仍然是汽车行业赖以生存的基础，或者认为软件必须要基于电子电气架构的算力才能充分发挥作用，所谓软件定义汽车才能实现。

　　那么，到底谁对谁错？其实刨除“决定脑袋”的言论，“软件定义汽车”这件事情正在发生。华为智能汽车解决方案BU CTO蔡建永曾说：“软件定义汽车，即软件将深度参与到汽车的定义、开发、验证、销售、服务等过程中，并不断改变和优化各个过程。实现体验持续优化、过程持续优化、价值持续创造。”应该说这个解释是目前为止比较客观、中肯和实际的。

　　换句话说，软件并不会取代硬件和制造环节，但软件会成为其他环节改进、发展和演进的方向标，包括电子电气架构（EEA）、汽车研发过程等都在发生着的变化。

　　例如，EEA的演进方向从分布式ECU（Electronic ControlUnit，电子控制单元）阶段，到域融合，再到中央计算平台阶段。这个演进过程，一方面是为了提升电子电器元件的集成度，降低成本的同时节约空间；另一方面也是为了提升硬件的标准化程度，方便软件更新迭代，加快汽车驾乘体验的改进和迭代。因此，软件只是“定义”了汽车，但并不会“实现”汽车。

　　另外，“软件定义汽车”不仅仅对于汽车的定义和开发阶段有影响，也会延伸到销售和服务阶段，甚至改变汽车的商业模式，如特斯拉的辅助驾驶包和自动驾驶包付费升级模式。同时，越来越多的车厂计划把收费模式延伸到销售以后，如资讯订阅、车主团购服务等。再比如，如果可以通过OTA升级软件就能实现召回，成本可以降低90%以上，整车厂就能承受更多的试错成本，从而改进用户体验。

　　在“软件定义汽车”的推动下，汽车电子电气系统的演进呈现两大新趋势：一方面是用户体验上的提升，包括对用户行为的感知能力提升和交互能力的智能化改进，如DMS（Driver Monitor System，驾驶员监测系统）、语音交互、炫酷的HMI（Human Machine Interface，人机界面）等（见图1）；另一方面是整车异构系统趋向标准化、虚拟化和服务化，如EEA架构的集中化和软件架构的SOA化。大量ECU将被集成到中央计算平台上，变成一个独立的Service加子板上的一个外设。

　　总体来说，前者更类似于消费类电子的发展趋势，尤其像手机。这也是为什么Android在智能座舱中的占有率逐年上升，大有一统江湖的趋势。而后者更像边缘计算乃至云端系统的技术演进趋势，如虚拟化、容器、SOA。两个趋势有共同的路线，如对于大算力、虚拟化、高吞吐量总线的要求，以及信息安全和网络安全的要求。但其中也有一些差异点，如对于功能安全、低延时、界面响应速度的要求等。

　　由于这些差异性，到目前为止整车系统的融合没法做到彻底，这也是为什么大部分车厂的EEA、架构要分三步走，因为智能座舱域和其他要求功能安全或实时性要求高的域还无法完美融合。而比较激进的特斯拉，将这些异构系统整合到AutoPilot系统中，导致了其系统安全性、实时性等均受到影响。目前，绝大部分整车厂下一代车型的EEA虽然选择了中央计算平台的架构，但智能座舱部分要么是以外设子板的形式存在，要么还是独立的域。

　　相对于硬件架构，软件，尤其是操作系统的集中化趋势比较明显。在中控娱乐系统领域，Android的优势愈加明显，除了国内几乎全线使用Android外，欧美的几大车厂都开始放弃原来的自有系统或GENIVI系统，转向Android。国内的斑马OS背靠少数几家车厂和阿里的生态，维持着一定的份额，丰田还在坚守自己发起的AGL（Automotive Grade Linux，面向整个汽车行业的开源平台）联盟，Windows、QNX等系统则基本退出这个领域了。不得不说，Android依靠手机市场培育出来的开发者生态，基本可以碾压其他OS，尤以中国市场为最。试想一下，某互联网企业开发出一款Android版的手机App，通过简单适配就可以移植到车机上，这个性价比可以接受。但假如需要投入大量人力、物力，去重新开发一个Linux版，却只能获得最多几十万用户，这个账肯定不划算。AGL就面临这个问题，它的生态环境不足以支撑OS继续下去，也许学学Windows和鸿蒙，兼容Android应用是条活下去的路。

　　座舱以外的系统我们一般会从内核和中间件层来分析。这些域用的都是实时操作系统（RTOS），如BlackBerry的QNX，Green Hills Software的INTEGRITY、RTLinux等。出于功能安全的要求，这些系统中大部分设计和实现都是“久经考验”的商业操作系统。例如，QNX就通过了ISO26262的ASIL-D级别认证（D级为最高等级要求）。当然RTLinux不属于“大部分”，因为Linux的数百万行代码，如果都按照ISO26262的要求过一遍，合格的最后剩不了几行，单就内存静态分配这一条就过不去。

　　而中间件层，针对自动驾驶域，目前有ROS2（RobotOperating System，机器人操作系统）、Autoware、Apollo等架构。由于自动驾驶对于大数据量（图像数据和雷达数据）的传输和低延时（10ms级）的要求，这些架构都专注于数据传输和实时性上，使自动驾驶域的感知、决策和控制部分能够更好地协作。

　　对于传统车身控制这部分，仍然是AUTOSAR（汽车开放系统架构）的天下，只不过慢慢从AUTOSAR ClassicPlatform（AUTOSAR CP）演变为AUTOSAR AdaptivePlatform（AUTOSAR AP）。说起AUTOSAR，可以算是“软件定义汽车”的原始版本，研发人员用开发工具把汽车信号、硬件环境等配置写到配置文件，通过AUTOSAR的编译器，生成一堆代码和中间件模块，再自动编译成MCAL（Microcontroler Abstraction Layer，中间件模块），与BSW（Basic Software，硬件支持模块）RTE（Runtime environment，运行环境）和App一起链接成ECU的固件（Firmware），可以说研发人员就是通过一堆参数，“定义”了一个汽车的部件——ECU。

　　然而，这个理念跟我们提到的“软件定义汽车”是背道而驰的。AUTOSAR体现的是软件决定论，也就是研发人员决定了定义，定义决定了汽车，这背后是工业时代技术人员的傲慢。而“软件定义汽车”是适者生存论，所谓的“定义”是动态的，会根据外部的反馈不断调整、改进，达到更优的状态，这背后是信息时代的新思维。

　　AUTOSAR AP也没有从根本上改变AUTOSAR，因此我个人的观点是：在目前域融合阶段，智能驾驶和车身控制分开的情况下，自动驾驶系统和AUTOSAR系统会各司其职。到中央计算平台阶段，AUTOSAR的地位会逐渐不保，有可能会被SOA取代。

　　既然提到了SOA，我们就展开来说说汽车系统中的SOA。SOA并非新概念，在2000年左右IT界就已经存在，那为什么在时隔20年之后又被提出来了？综合内外部因素，有以下几个原因。

　　因为传统ECU一般都是MCU（Microcontroller Unit，微控制单元）主控，算力不足，甚至都没有操作系统，不足以支撑SOA这种沉重的架构。随着汽车智能化和网联化，汽车芯片的算力大大提升，新的域或中央计算平台都是基于SoC（System on a Chip，系统级芯片）的，算力已经超过手机，直逼PC，因此能够支撑SOA架构。

　　原本大量ECU分布式的系统，通过不同的总线CAN（Controller Area Network，局域网）、LIN（Local Interconnect Network，区域互联网络）、Flexray等和特定的通信协议栈连接到一起，连接复杂度随着ECU数量增加呈指数级上升。一方面，通过减少ECU的数量，集中到域和中央计算器，这是一个方法；另一方面，车载以太网相关的技术，如TSN（Time Sensitive Network，时间敏感网络）/AVB（AudioVideo Bridging，数字音频传输网络）等技术，使得原本以太网上车的问题（延时高、丢包率高等）得到一定程度的解决，基于IP的通信会取代原有大部分的CAN、LIN总线，减少线束成本和空间。相应地，软件上需要配合这个变化，将这些ECU的功能集成到系统中，这就是SOA起到的作用。

　　在智能座舱概念刚刚兴起时，可以看到整个座舱域里充斥着各种RPC（Remote Procedure Call，远程过程调用）的方法，每个原本的ECU都在按照自己的方式搭建与其他ECU的连接。SOA的优势在于，它可以用统一的方式将原本ECU的功能定义成一个个Service，并且通过注册、发现的方式集成到系统中，让其他的组件可以调用。

　　随着车云连接，呈现的车、云、路、人一体化的趋势，对系统架构提出了新的要求，原本只是汽车内部的架构已经无法解决这个问题。例如，在车上播放音乐，以前只有CD、U盘时比较简单，本地实现两个播放器引擎就可以。但现在加入了大量的在线音乐服务提供商，还可以通过手机播、车机放，这样情况就会复杂很多，如果每一种音乐源都要重新开发一套软件，开发维护成本会倍增。

　　前面提到过，传统车厂和供应商还在用RPC解决问题。但既然车云一体了，为什么不试着用云的方式解决问题？

　　干脆把云端的SOA拿到终端来，大家一致搞服务化。这样，前面音乐源的问题，就可以按照如下方式来解决：

　　现在只需要一个统一的播放器，就可以自由切换音乐源和对应的服务。这样，音乐源管理的问题就被简单化了。当然，实际的使用场景要复杂得多，但越复杂的场景，越需要简单，因此SOA的用武之地会越来越多。

　　事实上，SOA的思想在很多OS内部已经深入渗透。例如，Android的核心就由几十个原生服务和Java服务构。