|
8月2日，中国智能网联汽车产业创新联盟基础软件工作组发布了阶段性研究成果《车载智能计算基础平台SOA软件架构白皮书》。 本文节选自此次发布的白皮书，主要介绍车载SOA架构的优缺点及国内外发展的现状。 SOA 架构技术简介集中化的电子电气架构是实现软件定义汽车的硬件基础，而SOA则是实现软件定义汽车的软件基础。 传统分布式电子电气架构下，汽车采用“面向信号”的软件结构（如图 2 所示），ECU 之间的通信方式为通过 LIN/CAN 等总线进行点对点通信。相应的 ECU 信号已在编译软件阶段完成预设，收发关系和路由信息是静态的。如果想要升级或新增某项功能时，需要修改与该信号相关的所有 ECU软件，并修改总线的网关配置和节点数量。因此，在传统的通信及ECU 软件架构设计中，各类信号能否准确、高效地在车内进行收发传导是通讯网络关注的重点。然而，随着汽车智能化升级需求的快速增长，传统通讯网络及软件架构中扩展性差、升级和移植成本高等问题逐渐凸显，当需要新增某项应用软件或服务时，需重新建立一个新的基础软件环境。为解决上述问题，汽车行业基于 IT 行业发展经验，引入 SOA 软件架构设计思想。电子电气架构正朝着以通用计算平台为基础，面向服务架构的方向发展。 
图 2 “面向信号”的架构（Signal-Oriented Architecture） SOA 是一种软件架构，同时也是一种软件设计方法和理念，如图 3 所示。它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。SOA 具备松耦合、标准接口可访问和易于扩展等特点，使得开发人员能以最小的软件变更应对迭代多变的客户需求。 
图 3 面向服务的架构（Service-Oriented Architecture） 在 SOA 中，服务是最核心的抽象手段和系统最基础的描述单元。每个服务组件具备独立的功能，且可被复用。服务组件之间的接口遵循统一标准，可互相访问，可组合扩展。业务过程则是带有状态和服务调度策略的服务组件的组合与扩展。- 易于部署，软件从单一可部署单元，被拆分成多个服务，每个服务都为可部署单元；
- 易于开发，每个组件都可以进行持续集成式的开发，可以做到实时部署，不间断地升级；
- 由于强调互相独立和低耦合，服务可能会细致拆分，进而导致系统凌乱和笨重；
SOA 的灵活性和可扩展性符合“软件定义汽车”的发展趋势。业务需求与硬件资源解耦是应用 SOA 的前提，汽车电子电气架构从分布式逐步向集中式发展，为 SOA 应用提供了基础条件。在智能网联汽车中，大量的功能需要控制器间的协调工作来完成，因此，将SOA 引入到当前汽车软件设计中，将应用程序的不同功能单元（服务）进行拆分，通过定义良好的接口和契约将这些服务联系起来。接口是采用中立的方式进行定义，其应该独立于实现服务的硬件平台、操作系统和编程语言，使得构建在各种各样系统中的服务可以以一种统一和通用的方式进行交互。SOA架构在汽车行业的发展现状SOA 架构平台的发展是汽车行业一场巨大的改革，在 SOA 架构下所形成的产业分工中，车企和供应商纷纷在寻找自己的定位。
宝马对 ECU 按照需求进行分类，如图 6 所示，将分散凌乱的ECU、传感器和执行器按类别定义 ECU 系统需求和统一开发方法，甚至统一管理供应商，最终实现系统优化。在中央计算平台进行整车功能的划分，将功能进行严格的抽取和封装，相互之间独立性强，复杂度大大降低，有利于功能单元的移植和复用。大众率先采用了面向服务的 MEB架构，如图 7所示。MEB架构是一种用于构造服务的架构模式，主要来源于软件技术，独立域操作系统、编程语言和软件框架。MEB 架构初衷是将软件划分为单独的软件组件，通过最小化组件之间的功能依赖性来提高软件的可扩展性和复用性。从 MEB架构的实现来看，SOA架构思想主要是通过不同服务的相互作用实现一个复杂的功能。每个服务都是一个独立可执行的软件组件，被准确描述了功能范围，通过准确定义的服务接口将功能提供给其他软件组件，服务以组合的形式来调动其他基础服务，然后将功能组合起来。大众也是将相关功能逻辑上移至域控制器，在域控制器下接嵌入式 ECUs、传感器和执行器。大众还公开了软件架构，使用 CP 和AP 服务中间件来实现 SOA 通信，其中 CP 连接传感器、执行器和嵌入式 ECU，收集信号，通过服务或者信号发送给 AP，AP 作为封装服务，和云端后台或者其他 AP 节点进行服务交互。丰田电子电气架构经历了简单的 LAN 网络到分层 LAN 网络架构的转变，目前采用中央网关和域控制器架构，用于应对复杂的系统需求和与日俱增的开发量。但随着车型的改进不断产生新的变型，系统和软件也变得越来越大，而且 Tier1 开发过程必须统一管理，基于这些目标，他们提出了 Central & Zone 架构，EE 架构需要引入中控 ECU，所有功能都分配到 ZoneECU。如图 8 所示，在现代的通信架构设计中，CAN 网络会和以太网共存相当长一段时间，但 SOA 并不能直接和这些网络通信，而是采用了 SOA Adaptor 模块来转换其他网络的功能和信息。在和云端交互的时候，SOA 需要使用外部设备来进行服务级别的交互，这样在增强整车数据的开放性的同时增加了信息安全。另外，现代还在车内系统设计了 SOA Gateway 节点，用于升级安全等级。由于服务交互的频繁性，现代采用 SD Proxy 来高效地处理服务相关信息和进行服务更新，即安全或者强相关的服务通过 ServiceRouter 来访问。AUTOSAR 组织为应对自动驾驶技术的发展推出了 AP 架构，如图 9 所示。AP平台采用了 SOA架构，由一系列的服务组成，应用和其他软件模块可以根据需求调用其中的一个或者多个服务，而服务可以由平台提供，也可以由远程其他部件提供，OEM 可以按照功能设计需求定义所需的服务组合。AP 的主要特点是可根据应用需求动态加载，可通过配置文件动态加载配置，并可进行单独更新，相对于 CP，可以满足更强大的算力需求，更安全，兼容性好，可进行敏捷开发。与国外 OEM 不同，国内 OEM 尚未实现能完全自主定义的 HPC平台，仍需要各供应商配合，尤其是传统 OEM，变革涉及太多车型，以及庞大的供应商体系，使得固有的电子电气架构模式极难突破。因此采用更稳妥的循序渐进策略，将 SOA 理念的实施重点放在娱乐系统，以娱乐系统的验证来考量是否有实施整车 SOA 架构的条件。上汽零束提出了 SOA 软件平台，将汽车的各个功能打通，使得他们相互联系起来。另外，上汽零束还打造了一个 SOA 软件平台的开发者平台，开发者平台将提供在线调试工具及仿真环境，在确保代码质量的同时，帮助开发者快速实现车端应用功能开发。此外，通过平台后台管理系统，开发者能对账号权限、应用风控及内容进行管理，实现软件在应用市场的审核、上架等。
华为推出的 MDC 定位为智能驾驶的计算平台。平台基于 CPU与 AI 处理器芯片，搭载智能驾驶 OS，兼容 AUTOSAR。其中 OS 的功能软件采用 SOA 架构，定义了智能驾驶基本算法组件（如感知算法组件、融合算法组件、定位算法组件、决策算法组件、规划算法组件、控制算法组件等）的调用框架与组件之间的软件接口；上层场景应用可以灵活选择不同的算法组件组合，实现具体的场景应用功能。另外，还有一部分主机厂，率先在 ADAS 域内先实现 SOA 通信，将 SOA 融入到自动驾驶中。但在自动驾驶域，目前没有完整的落地解决方案。很多整车厂及方案供应商尝试围绕着服务的定义和部署，通过毫米波雷达、激光雷达和摄像头等多传感器的前融合架构方案，为上层系统开发大量的抽象服务。并通过服务间的组合来定义功能服务，通过敏捷开发以及针对接口的严格的封装和层次化结构，导入标准化的服务接口API，同时软件组件通过”服务总线”的中间件建立通讯（SOME/IP，DDS 等），用这种思想去尝试进行智能驾驶域的 SOA 设计，真正意义的实现软件和硬件分离。
蔚来汽车
另外，由中国汽车协会牵头的中国汽车基础软件生态委员会（简称 AUTOSEMO）于 2021 年先后发布了《车载 SOA 软件架构技术规范 1.0》、《车载 SOA 软件架构技术规范 1.1》与《中国汽车基础软件发展白皮书 2.0》。白皮书首次提出 ASF框架，ASF框架是对通用基础软件的扩充，同时也对 AUTOSAR 的服务管理框架进行扩展，向应用层提供更多基于服务开发需要的功能，其中包括服务转换、服务调试、服务同步，服务权限管理和基于 android 的 SOA 协议栈《车载智能计算基础平台SOA软件架构白皮书》完整版下载地址：现SOA白皮书已上传至中国智能网联汽车产业创新联盟网站，大家如有需要可以登陆下载http://www./material?cid=38
|
