夜雨聆风
一文搞懂汽车SOA软件架构与开发方法︱汽车软件开发
会议推荐
1
2
3
4
2026第五届中国项目经理大会
5
2026第三届中国医药企业项目管理大会
本 文 目 录
1
汽车SOA开发方法和实践
2
软件定义汽车：SOA架构驱动的未来趋势
3
汽车SOA架构应用的现状、难点、价值
4
一些关于实现整车级SOA软件架构的建议
5
我们究竟为什么要用SOA？
一、汽车SOA开发方法和实践
（原创 Ai赋能汽车 作者刘佳熙）
在未来，智能化和网联化是汽车技术发展的核心引擎，将使能汽车领域的主要创新，包括进一步节能减排、自动驾驶和新出行方式等。智能网联汽车的功能特性多是依靠软件实现的，但传统嵌入式汽车软件开发方法，难以支撑汽车软件规模和复杂度的指数级增长。汽车产业也在从 IT 技术领域引入先进技术，其中面向服务架构（SOA）被认为是能够支持未来汽车软件发展的核心技术之一。
面向服务架构软件是一种软件设计模式，自 20 世纪 90 年代被提出后，在 IT 技术领域获得了快速发展和广泛应用。SOA 具有松耦合、可重用、易集成等优点，能够支持智能网联汽车软件发展的需求，AUTOSAR Adaptive 平台也提供了 SOA 软件在汽车中实施的技术方案。在现有文献中，关于 SOA 软件开发方法的研究多集中在 IT 业务领域，在汽车领域的研究多以技术实现或个别开发案例为主，少有对 SOA 汽车软件开发方法的探讨。
SOA 不仅是一种软件实现技术，更重要的是一种软件设计模式，只有采用合适开发方法，才能有效发挥 SOA 的优势。本文讨论 SOA 汽车软件的开发方法，并付诸实践：第一部分提出一种 SOA 汽车软件分层模型；第二部分基于分层模型，介绍两种 SOA 汽车软件开发方法；第三部分相应介绍基于两种方法的开发实践；第四部分介绍 SOA 汽车软件在域控制器上的部署；最后进行总结。
在术语中，将客户的特定需求称之为业务需求，将描述业务需求的一种形式称为业务用例，将业务用例的实现过程称为业务过程，将业务过程中完成特定任务的一部分逻辑称为业务逻辑。在面向服务架构中，“服务”是对业务逻辑的封装，具有明确定义的接口，并被独立的实现；“面向服务”定义了一种方法，这种方法通过连接多个“服务”实现业务需求。
“服务”所封装业务逻辑的大小，决定了“服务” 在业务过程中涉及的范围，直接决定了“服务”的自治、重用等关键特性，是 SOA 架构设计的核心问题。在 SOA 汽车软件设计中，必须有清晰的模型作为依据，才能有效地发挥 SOA 的优势。参考 IT 领域良好实践，本文提出一种 SOA 汽车软件分层模型，如图 1，包括元服务、基础服务和应用服务三个层级，使不同层级的“服务”分别对应不同层级的汽车业务逻辑。
图 1 SOA 汽车软件分层模型
1）元服务
元服务是最小单元。从业务角度，元服务是对底层逻辑的封装，不具有再拆分的意义和价值；从架构角度，元服务是高度通用、高度自治和可重用的功能单元，构建了整个 SOA 架构的底层基础结构。汽车的传感器、执行器等基本接口和车辆基本参数可封装为元服务，例如，将车速、车辆惯性状态等参数封装为“车辆状态”元服务，可以对上层服务架构提供支持。
2）基础服务
基础服务是分层模型的中间层服务。从业务角度，基础服务封装了更多的业务逻辑，即组合了若干元服务；从架构角度，基础服务可以访问和调用元服 务以实现更大范围的业务过程。基础服务应是足够自治和可重用的。在利用元服务的基础上，可重用的汽车业务逻辑可封装为基础服务，例如，在利用自车车辆状态服务、雷达等传感器信息服务以及其他信 息的基础上，可构建“环境信息融合”服务，作为基础服务。
3）应用服务
应用服务是分层模型的最顶层服务。从业务过程角度，应用服务可以包括一个业务过程的全部业务逻辑，封装了与特定业务有关的基础服务；从架构 角度，应用服务可以访问和调用基础服务以帮助其解决业务问题。元服务和基础服务更强调架构的灵活性，而应用服务则更强调商业意义，和业务需求有非常紧密的联系。具有客户价值的业务用例可作为应用服务，例如，“能量预测管理”是一个应用服务，它利用车辆状态元服务、环境信息融合基础服务和其他服务，从而实现了通过智能管理降低车辆能耗这一具有商业意义的业务需求。
在设计中，上层服务调用下层服务，下层服务不调用上层服务，这一原则有助于构建清晰简单的 SOA 汽车软件架构。参考以上分层模型，可以有效定义 SOA 汽车软件的开发方法，从而有效地发挥和获得 SOA 的优势。
基于 SOA 汽车软件分层模型，结合汽车领域软件开发的工程实际，可定义 SOA 汽车软件开发方法，典型的有“业务驱动型”的开发方法和“平台驱动 型”的开发方法，两种方法适用于不同的应用场景。
2.1 业务驱动型开发方法
业务驱动型指从业务用例出发，以服务为导向，正向设计 SOA 汽车软件的开发方法。此方法应用于业务用例已知，需要设计 SOA 汽车软件以实现业务用例的开发场景。在设计过程中，通过“业务过程分析”、“服务操作分析”、“候选服务分析”三个步骤，解决“应该构建哪些服务？”、“每个服务应该封装什么逻辑？”两个核心问题。
1）业务过程分析
业务过程分析指的是充分理解具体使用场景下的真实业务过程。本文采用了用例驱动的方法来分析业务需求和过程。用例驱动指从用户使用的角度而非开发人员的角度考量功能需求和系统实现，重视从系统外部观察对系统的使用。由用例驱动的开发活动，可以建立需求和服务操作之间清晰的追溯关系，为抽象和封装服务提供充足的语境信息。
2）服务操作分析
服务封装的业务逻辑，由服务操作实现。服务操作代表了服务所执行的特定动作，可类比软件中的方法或函数。面向服务的分析包括了识别候选服务 操作并将其分组的过程，这些组最终成为候选服务，我们将这个过程抽象为服务操作分析和候选服务分析两个步骤。
服务操作分析是从业务过程分析的产物向服务过渡的过程，目的是得出构成候选服务的服务操作。服务操作分析具体可描述为：对系统用例逐个进行分析细化，描述系统如何与参与者一起实现每个用例，从而得到系统与参与者、与外部系统的界限及信息交互，最终得出对系统的功能要求，这些功能要求是系统必须实现的功能点，在下一步将直接作为组成服务的候选服务操作。
3）候选服务分析
候选服务分析的目的是对业务逻辑进行抽象和封装，从业务角度寻找最优的服务操作划分方式，所提出的“SOA 汽车软件分层模型”为候选服务分析提供了有价值的参考。根据重用性和自主性的面向服务设计原则，参考图 1 三层模型设计元服务和基础服务。对元服务和基础服务的设计，SOA 鼓励即使没有立即重用的要求，也要根据服务导向的设计原则促进重用，因此潜在的重用也要考虑在内。通过良好的 SOA 设计，当业务用例增加，或原有业务用例发生变更时，良好的基础服务和元服务设计，保证了重用性和较少的软件变更，从而实现更快速高效的功能迭代和清晰明确的版本管理。
图 2 业务驱动型开发过程
2.2 平台驱动型开发方法
平台驱动指从汽车已开发完成的物理逻辑出发，将物理逻辑封装为元服务，也可将部分元服务进一步组合为基础服务。平台驱动型开发方法适用于如下场景，即业务用例尚不十分明确，但需建立 SOA 汽车软件基础平台，以支持潜在应用服务的快速引入，利于未来快速软件创新。在实施平台驱动型开发方法过程中，通常需要对汽车物理逻辑进行收集，并根据物理逻辑的潜在 服务价值，优先选取潜在服务价值较大的部分，将其封装为元服务，并适当组成基础服务。在未来应用服务构建时，可利用已构建的元服务和基础服 务，实现快速的软件创新。基于平台驱动型开发方法，可提供车辆软件系统的开放性，最终实现汽车的“操作系统”。
在实际汽车软件工程开发领域，以上所述业务驱动型和平台驱动型开发方法均有应用需求。本章分别描述基于以上两种开发方法的 SOA 汽车软件开发实践。
3.1 业务驱动型开发方法实践
图 3 业务过程分析案例
图 3 展示了一个业务过程分析的例子：以一辆混合动力的汽车为例，终端消费者的期望是提高驾驶经济性，这是一个长期目标，需求分析人员针对该 目标，挖掘消费者的使用场景，结合该车混合动力的特点，发现了在驾驶过程中优化动力来源分配策略这一短期目标，通过短期目标的累积最终实现长期经济性目标的整车需求。功能开发人员针对该需求提出了融合网联提供的前方道路信息和历史数据信息对汽车动力来源进行预测性优化的解决方案。
首先进行业务过程分析：在充分理解该方案提出的问题背景下，采用用例驱动的方法，分析和设计了该方案的业务过程，得到了系统用例。接下来进行服务操作分析，对系统用例逐个进行分析细化，描述系统如何与参与者一起实现每个用例，从而得到系统与参与者、与外部系统的界限及信息交互，最终得出对系统的功能要求，这些功能要求直接作为候选服务操作。图 4 展示了对“确定导航路径”这一系统用例的分析示例。
图 4 服务操作分析案例
最后进行候选服务分析。图 5 展现了一个案例，在得出候选服务操作的基础上，初步抽象出了候选服务，并定义了每个候选服务应具有的服务操作。综 合实际业务情况等多方面因素，运用面向服务的重用性等原则进行综合分析，我们对这些初步候选服务进行了多次评估和调整，得到了如图 5 右半部分所示的候选服务。
图 5 候选服务分析
3.2 平台驱动型开发方法实践
在实际工程实践中，面向客户需求的业务用例往往不是一次性开发出来的，而整车架构必须事先布局，以使未来业务用例明确时，软件能够快速构建，以在有限的时间窗口内进入市场，实现更大的商业价值。因此，平台驱动型的开发方法是必要的。
如下是一个平台驱动型开发方法的实践。
图 6 平台驱动型开发方法实践案例
如图 6 所示，通过对已存在的车辆物理逻辑及其潜在服务价值的分析，认为电池管理系统 （Battery Management System, BMS） 电池剩余电量 （State of Charge, SoC）、电池均衡状态、电池高压互锁状态等信息具有潜在的应用价值，未来基于这些信息可构建多种有商业价值的业务用例，因此，将这些信息构建为元服务。在进一步整合封装后，形成“BMS 电池状态”的基础服务，同理，经过同样的评估，可得到如下基础服务内容：
1）BMS 电池状态服务
2）整车热管理服务
3）车辆动力系统驱动服务
在完成上述基础服务单元后，业务逻辑可被进一步灵活拓展。BMS 电池状态服务可与车辆动力系统驱动服务进一步扩展结合，组建优化电池充电曲 线的应用服务。同样，随着未来业务场景的不断清晰，这些有潜在价值的基础服务与元服务，可以不断扩展、组合，灵活的应对业务需求的迭代更新。
4.1 SOA 汽车软件的部署平台
随着汽车电子电气架构向集中化发展，域控制器将成为部署 SOA 汽车软件的最优选择，其原因如下:
1）域控制器采用多核微处理器并搭载多进程 （RichOS）操作系统，其高算力、多线程、可并发运行于多核处理器的特性使大量边缘触发型的数据处理功能在汽车软件中得以实现，而边缘触发逻辑是 SOA 软件部署的重要特性之一。
2）域控制器平台间通过以太网进行数据传输，高带宽赋能了基于以太网的、面向服务的通讯机制，让 SOA 软件的跨域合作成为可能。
3）域控制器平台可搭载 AUTOSAR Adaptive 中间件，保证了应用软件可以直接调用 AUTOSAR 组织提供的公共标准的接口（ARA::API），代表应用软件不再需要为不同操作系统的不同接口做适配和变更，从而使得 SOA 软件“软硬分离”的特性得以实现。
4.2 SOA 汽车软件的部署方法
AUTOSAR Adaptive（AP）作为 AUTOSAR 组织发布的面向 POSIX 操作系统的标准中间件，提供 SOA 汽车软件部署的整体解决方案。AP 中的 Communication Middleware（CM）组件实现了服务中间件的功能，服务中间件解耦了服务接收方和发送方，并与服务接收、发送方一起，实现服务的注册，订阅，提供和查找功能；同时，AUTOSAR 组织定义了基于 ARXML 文件的服务架构模型（SCA – Service Component Architecture）描述规范，该规范描述了图 7 中 SCA 中接口和消息的部分，并提供对于这些描述文件的代码生成工具。当前，我们将 AP 中间件集 成于联合汽车电子有限公司开发的域控制器（XCU）平台，并使用 AP 中间件，完成 SOA 汽车软件的实现和部署。
图 7 服务组件内部结构
无论是元服务、基础服务还是应用服务，都具备接口标准可访问、自治、可组合扩展等特性。这些特性源于 SOA 汽车软件的架构模型。
SCA 将服务组件划分为业务逻辑、服务接口和服务消息三个部分，并确保三者相互独立：
1）服务消息的内容取决于 SOA 软件绑定的消息机制，即通讯协议，汽车软件当前主流应用是 SOME/IP 协议，该协议栈已被集成于 AP 中的 CM 组 件单元。
2）服务接口是服务组件有别于传统软件单元的核心部分，服务接口调用消息机制，让每个服务软件对外都可以标准且相同的方式被访问。AP 提供了 基于 ARXML 的标准接口描述规范以及相应的代码生成工具，服务提供方与服务接收方以 AUTOSAR 组织标准约定的描述文档进行服务内容的交互。
3）业务逻辑展现了每个服务组件的具体功能，业务逻辑独立于消息和接口而存在，可单独进行开发，且不依赖于特定的编程语言。
设计与部署一个 SOA 汽车软件分为以下几个重要步骤。通过这些步骤，我们可以实现和部署出一个 SOA 汽车软件在域控制器平台上。
以 3.2 节 BMS 电池状态服务为例，BMS 电池状态服务为基础服务，用于提供电池包的状态信息，其由剩余电池电量、电池均衡状态以及电池包高压互 锁状态这些元服务组合而成。因服务用途，BMS 电池状态基础服务的 SOA 软件以固定周期向订阅者提供该服务中的数据信息。
上述电池状态服务的 SOA 软件开发步骤如图 8 所示。
图 8 汽车 SOA 软件的开发和部署步骤
1）服务接口开发
服务接口开发用于完成 SCA 架构中服务接口部分的部署，是 SOA 软件开发的第一步且是关键一步。其过程主要可分解为如下步骤：a）服务的数据类型定义；b）服务端口设定；c）服务端口与软件单元（SWC）以及软件进程（Executable）的绑定。这些接口信息在 ARXML 文档中被描述，并通过 AUTOSAR Adaptive 中间件供应商提供的工具生成为代码和配置信息（Manifest）。
对应电池状态服务的 SOA 软件，首先定义包括 电池包剩余电量、电池均衡状态以及电池包高压互锁状态信息的数据类型，并采用 Field 的 Notification 方式周期性推送上述服务信息；由于是服务提供方，因此服务端口设定为提供端口（Provide Port）；将该 Provide Port 绑定至电池状态服务 SOA 软件的可执行进程。
2）业务（应用）逻辑开发
业务（应用）逻辑开发用于完成 SCA 架构中服务软件单元的实现。其过程是实现 1）中定义的服务接口，业务逻辑的编写可通过手工代码的方式或沿 用 基 于 模 型 的汽车 建 模 软 件 （ 例 如 Matlab/Simulink），最终产出 C/C++ 逻辑源码文件。
对应电池状态服务的 SOA 软件，在 1）设定的服务接口函数中，完成电池状态服务提供的业务逻辑代码。
3）集成
集成工作一方面用于集成 SCA 架构中服务接口和业务逻辑的代码；另一方面，用于完成电池状态服务 SOA 软件向目标中间件环境（AP）的适配。其过程主要可分解为如下步骤：a）SOA 软件进程的运行资源，调度机制和起动选项配置；b）服务提供和查找的参数配置，服务环境的 IP 地址，端口号信息；c） SOA 软件运行的系统状态。4）编译和部署 在完成上述工作后，选择 XCU 平台的目标交叉 编译器，对上述 SOA 软件进行编译和链接，并通过 SFTP 客户端软件 WINSCP 将编译产物可执行文件 （Executable）以及相关配置文件（Manifest）按系统要求安装于域控制器 XCU 平台相应的文件系统上。
面向服务架构（SOA）被认为是使能软件定义汽车的关键技术之一。本文给出了一种 SOA 汽车软件分层模型，依据该模型，提出了两种 SOA 汽车软件开发方法，并分别进行了实践，将所开发的 SOA 汽车软件案例，部署在联合汽车电子有限公司开发的域控制器（XCU）中。本文所提出的两种开发方法，分别适用于从汽车业务用例出发的正向开发，以及从汽车物理逻辑出发的平台构建，在 SOA 汽车软件开发中将并行使用，以使 SOA 的主要优势在汽车软件研发中得到体现。
本文由刘佳熙，施思明，徐振敏，薛涛联合创作
参考文献
[1] KUGELE S, OBERGELL P, BROY M, et al. On Service-Orientation for Automotive Software [A]. IEEE. 2017 IEEE International Conference on Software Architecture（C）. Gothenburg: IEEE, 2017.
[2] ERL T. Service-Oriented Architecture: Concepts, Technology, and Design [M]. Prentice Hall PTR, 2005.
[3] AUTOSAR. Adaptive Platform [OL].
https://www.autosar.org/standards/adaptive-platform/.
[4] SADTLER C, CALCAGNO L, COX R, et al. Pattern SOA Foundation Service Creation scenario [M]. IBM. 2006.
[5] KEEN M, ACKERMAN G, AZAZ I, et al. Pattern SOA Foundation-Business Process Management scenario [M]. IBM. 2006.
[6] WAGNER M, ZOEBEL D, NEROTH A. Model-driven development of SOA-based Driver Assistance Systems [A]. ACM SIGBED Review. 2013. Volume 10 （1）.
[7] 宋杰静，马云杰，田鹏飞. 基于 PREEvision 的以太网 SOA 设计方法[A]. 中国汽车工程学会. 2019 中国汽车工程学会年会论文集[C]. 2019. 1275-1278.
[8] 刘佳熙，丁锋. 面向未来汽车电子电气架构的域控制器平台[J]. 中国集成电路, 2019, 9: 82-87.
二、软件定义汽车：SOA架构驱动的未来趋势
（路浩智能）
“软件定义汽车”（SDV，Software Define Vehicle）这一概念最早于2007年4月在IEEE会议上被提出，随后在2016年由百度自动驾驶事业部总经理再次推广，自此在汽车行业内广泛流传，并逐渐成为智能汽车演进方向的共识。
软件定义汽车的驱动力
软件定义汽车之所以成为整车厂、传统Tier1及互联网科技公司等多数企业的共识，主要源于以下两大驱动力：
1.特斯拉的示范效应
特斯拉作为智能电动汽车的先驱，成功实践了“硬件为流量入口、软件为收费服务”的模式，对产业界产生了显著的鲶鱼效应。特斯拉凭借现有的数据闭环和软件架构，实现了快速的软件迭代升级（OTA），并建立了软件付费模式，进一步拓展了盈利空间。这一成功模式促使传统整车厂加速转型，积极布局车载软件领域，推动了软件定义汽车时代的到来。
2.软件的差异化竞争力
在智能化转型的浪潮中，OEM及Tier1纷纷意识到，软件层面的竞争更能体现出差异化的竞争力。与硬件配置竞赛相比，软件的边际开发成本更低，更能满足用户千人千面的需求。同时，完善的软件生态也能为OEM树立更加牢固的护城河，打造差异化的品牌特征。因此，软件定义汽车已成为产业界的共识，车载软件需求大幅提升。
（注：车载领域软件研发模式主要包括成立子公司、成立软件研发部门以及与软件供应商合作等三种方式。）
SOA架构在软件定义汽车中的核心作用
集中化的E/E架构是实现软件定义汽车的硬件基础，而SOA（面向服务）架构则是实现软件定义汽车的软件基础。
传统分布式E/E架构下，汽车采用“面向信号”的软件结构，ECU之间通过LIN/CAN等总线进行点对点通信。这种架构下，ECU的信号收发关系和路由信息是静态的，新增或升级功能需要修改多个ECU软件和总线配置，扩展性差且升级成本高。
为解决这一问题，汽车行业借鉴IT行业发展经验，提出了SOA软件架构。SOA并非一类特定的软件产品，而是一种软件架构设计的理念。其核心思想是将每个控制器的底层功能以“服务”的形式进行封装，每个服务是一个独立可执行的软件组件，具有特定的IP地址和标准化接口，可以随时调用。通过对这些底层功能的自由组合，可以实现复杂的智能化功能。
以新增ModelX“跳舞”功能为例，在传统软件架构下，需要修改与该功能链路上所有相关的控制器软件，并通过总线实现信号传递。而在SOA软件架构下，只需将各个控制器所能贡献的部分抽象为“服务”，如“灯光控制服务”、“语音交互服务”等，然后编写“跳舞”APP，调用这些基础服务即可实现功能。
SOA软件架构下的底层软件具有接口标准化、相互独立、松耦合三大特点。各个服务间功能范围清晰，留有标准化访问接口；每个服务相互独立且唯一，属于汽车软件架构中的基础软件；服务间具备松耦合特性，独立于车型、硬件平台、操作系统和编程语言。这使得汽车可以快速响应消费者需求，新增或更新功能，实现千人千面。
车载软件架构的长期趋势
在SOA软件架构设计理念下，汽车软件架构走向分层化、模块化，应用层功能能够在不同车型、硬件平台、操作系统上复用，并通过标准化接口进行快速迭代升级。
我们可以将软件架构按层级自下而上大致划分为系统内核层、中间件层和应用程序层（这三者仅为粗略划分，实际开发中并无绝对边界）。短期来看，要在汽车上真正落地SOA软件架构，操作系统（系统内核部分）和中间件的引入及优化至关重要。长期来看，在SOA架构构建成熟后，丰富的应用生态将具备更大的价值空间。
结论
短期内，系统内核和中间件在车载软件架构中举足轻重；长期来看，应用层将具备更大的价值量。软件定义汽车时代已经加速到来，传统整车厂需加速转型布局车载软件领域，以应对未来的挑战和机遇。（内容由AI生成）
三、汽车SOA架构应用的现状、难点、价值
（原创 不可说 汽车电子与软件）
众多主机厂及供应商在推介自家的电子电气架构平台时，除了详细介绍网络架构、功能架构及硬件架构外，无一不强调其软件架构的优势，而当前他们宣传的主流软件架构几乎一致指向了SOA，这无疑体现了行业内对于SOA技术路线的普遍认可与一致规划。在车载电子领域，一个被行业广泛接受且普遍适用的软件架构方案，或许正是SOA。
SOA架构的诞生及其核心目的，正是为了应对当前车载通信带宽日益紧张的问题。它通过将服务进行抽象和封装，实现了更为高效、灵活的信息交互。值得一提的是，由于SOA架构通常是建立在AUTOSAR AP或CP平台之上的，因此它能够充分利用这些平台的模块化开发特性，达到高度的解耦效果，进一步提升了系统的可扩展性和可维护性。
小鹏的X-EEA3.0架构中应用了SOA架构：
小鹏汽车深刻认识到不同类型软件使用需求之间存在的差异性，因此，他们对整车软件进行SOA服务化与细致的分层定义，具体划分为系统软件平台SOA服务、基础软件平台SOA服务以及智能应用平台SOA服务等层级。通过这样的分层架构，他们旨在实现智能功能的快速开发与高效迭代。这包括但不限于自动驾驶技术、智能语音控制车辆及车载设备的功能，以及能够根据用户行为和场景变化而自动调整的智能场景模式等。这样的策略极大地提升了软件开发的灵活性和响应速度，使得小鹏汽车能够持续为用户带来更加先进、便捷的智能出行体验。
蔚来的下一代中央计算EEA架构中，即NT3技术架构中，也应用了SOA通信架构：
蔚来坚信，汽车软件的未来发展必然趋向于采用SOA，并且在这一架构中广泛地应用中间件技术。基于这一前瞻性的认知，蔚来在对汽车软件进行开发与调整时，决定对现有的软件架构进行彻底的重构。这一重构的核心在于引入远程调用方式（RPC），通过RPC实现服务之间的有效沟通与协作，从而真正践行面向服务的架构（SOA）理念。
吉利GEEA3.0 EEA系统也是基于SOA实现和完成的：
吉利GEEA3.0车云系统架构
吉利在SOA生态构建方面展现出了相当程度的完备性。公司不仅成功基于SOA理念打造了专属的操作系统GeelyOS，而且还推出了一系列相应的服务设计技术规范，从而极大地丰富了其开发环境，使之更加成熟和完善。在此基础上，吉利有条不紊地推进服务库的设计工作，目前已经完成了包含超过300项核心服务以及2000多个服务接口的服务库构建，这一成就彰显了吉利在推动SOA生态发展方面的深厚实力与前瞻视野。
Geely SOA规范
长城汽车GEEP 4.0架构也有SOA的应用：
长城汽车GEEP 4.0架构
长城汽车的第四代电子电气架构采纳了先进的SOA设计理念，通过开放标准的应用程序编程接口（API），能够全方位地满足用户对车辆智能化的多样化需求。在此基础上，长城汽车对于未来有着更为深远的规划，他们致力于打造的第五代电子电气架构将实现100%的SOA化转型，标志着长城汽车在智能化领域的又一重大突破。这一转型不仅意味着技术上的全面革新，更代表着长城汽车将依赖SOA全面完成整车标准软件平台的搭建工作，为用户带来更加智能、便捷、高效的出行体验。
从上述整理的信息中我们可以清晰地看到，不论是新兴的造车势力，还是沉淀多年的传统主机厂，都已经纷纷引入了SOA这一先进的软件架构理念。除了之前已经提及的实例之外，众多车企在宣传其最新技术架构时，也明确强调了SOA软件架构的研究与应用。例如，广汽推出的星灵架构、理想汽车所打造的LEEA 3.0、岚图汽车所推出的中央集中式EEA，以及长安汽车所构建的SDA“中央+环网”EEA等，这些架构在各自的宣传资料中都显著地指出了对SOA软件架构的深入探索与实践应用。这一趋势着重体现了SOA软件架构在汽车行业中的重要地位，.或许这也预示着未来汽车智能化、网联化发展的必然趋势。
尽管众多企业在对外推广时，均将SOA作为核心亮点加以强调，但在具体实施开发的过程中，它们普遍遭遇了诸多挑战与争议。因此，若决心沿着SOA架构的路径持续前行，企业势必要承担相应的成本与代价。
首先，在从非SOA架构向SOA架构转型的过程中，对工程师的技术能力提出了全新的要求。他们需要掌握AUTOSAR的基础知识，熟悉面向服务的通信设计原理（如SOME/IP或DDS），以及服务设计的相关理论。这些新技能对工程师而言无疑是一大挑战，同时，对于主机厂来说，培养具备这些技能的专业人才也需投入较高的成本。
此外，工具链的适配问题同样不容忽视。SOA架构是面向服务的，而传统的架构则主要基于信号，相应的工具链也主要服务于信号处理。若现有工具链不支持服务的设计与管理，企业就需对其进行修改或替换。这一过程不仅耗时费力，还需投入大量资金来完成工具的更新，并组织相关人员进行工具使用培训。
在软件构建层面，企业也需做出相应的调整。面向服务的软件架构在消息接收方面与面向信号的架构存在显著差异，因此，服务化后的软件需进行重构。同时，由于SOA架构的推进是渐进式的，在转型过程中，基于信号与基于服务的软件架构可能会并存一段时间，如何适应并存状态，也是需要软件来进行适配开发的。当然这部分的软件变更成本，依然需要主机厂来承担。
另外，新的SOA软件架构的开发必须有新的规范来约束，包括服务设计规范、服务划分规范、服务通信设计规范以及编码规范等。这些规范的制定同样需要投入大量的时间成本，以确保架构的稳定性和高效性。
最后，在测试环节，企业也需针对服务通信进行软件单元测试和单品测试。这对测试人员提出了更高的要求，他们需要革新测试方法、流程及手段等。同时，针对SOA服务所需的以太网通信，还需进行一致性测试、黑白名单测试、网络攻击测试等一系列专属测试。这部分的投入与开发成本相比，同样不容小觑。
从上述详尽的分析中，我们可以清晰地看到，SOA的实际部署需要承担一系列不菲的成本，这涵盖了人员配置的调整与学习成本、开发测试工具链的构建、软件开发的额外投入、严格规范的设定、以及测试范围与手段的扩展等多个层面。然而，它表面上所带来的直接收益，仅仅是解决了通信带宽的瓶颈问题，并提升了系统的可维护性与可移植性。
但若从技术演进的长远视角来审视，赋予软件架构以高度的可维护性和可移植性，其核心目的在于有效应对硬件迭代升级时可能引发的软件适配难题。而值得注意的是，这一目的并非只能通过SOA来实现——基于AUTOSAR标准的中间件同样能够达成这一效果。换言之，即便是在传统的基于信号的软件架构之上，借助AUTOSAR的中间件技术，我们依然可以享受到良好的可维护性和可移植性。这无疑揭示了SOA在这一方面的优势并非独一无二，而是存在可被替代的解决方案。
再来看通信带宽的问题，这确实是一个不容忽视的硬性挑战。随着车辆电子功能的日益丰富与复杂化，所需传输的信息量无疑将持续增长。然而，通过增设几条CAN/CANFD通信通道，同样能够在一定程度上缓解这一压力，而且所需付出的代价要远远小于全面推行SOA所需的成本。
此外，从用户的角度出发，他们往往对电子电气架构、软件架构这些并无直接感知，这些架构的优劣最终会以成本的形式间接地反映在购车价格上。而在SOA转型的初期阶段，由于技术成熟度、规模效应等因素的限制，成本并不会立即下降，因此用户层面并无法直接感受到任何实质性的收益。至于整车OTA升级的功能，其实基于信号的架构同样有能力实现，只是目前业界尚未广泛采用这一路径罢了。
综上所述，我认为在当前阶段，对于大多数车型较少、体量较小的公司而言，盲目加入SOA架构的成本过高，并不适宜直接涉足。相反，这可能会导致单车成本的显著上升。当然，如果未来能够进一步挖掘出SOA其他不可替代的独特优势，并且随着相关技术的不断成熟与成本的逐步降低，那么选择在合适的时机以较低的成本入局，无疑会是一个更加明智的选择。
四、一些关于实现整车级SOA软件架构的建议
（原创 傲T供稿 汽车功能安全）
整车级SOA软件架构
-
深入理解 SOA（面向服务的架构）的核心原则，将车辆功能抽象为独立的、可复用的服务。例如，把车辆的动力系统控制、底盘系统调节、智能驾驶辅助、信息娱乐等功能划分为不同的服务模块。在设计之初就要确保服务之间的低耦合性，使得每个服务可以独立开发、测试和部署，同时又能方便地与其他服务进行组合和交互。 -
参考行业最佳实践和标准，如 AUTOSAR（汽车开放系统架构）等。AUTOSAR 提供了一套标准化的软件架构和开发方法，对于实现整车级 SOA 软件架构具有重要的指导意义。例如，可以借鉴 AUTOSAR 的分层架构理念，将软件系统分为应用层、运行时环境层和基础软件层，每个层次负责不同的功能，提高软件的可维护性和可扩展性。 -
基于车辆的功能需求和未来的发展规划，全面规划服务的范围和功能。考虑到汽车行业的发展趋势，如自动驾驶、车联网等，预留一定的扩展空间。例如，在智能驾驶服务的规划中，除了现有的自适应巡航控制和车道保持辅助服务，还应考虑未来可能增加的自动变道、自动泊车等服务，并提前设计好服务接口和数据交互方式。 -
对每个服务进行详细的定义，包括服务的功能描述、输入输出参数、服务质量（QoS）要求等。例如，对于车辆状态监测服务，明确其功能是实时采集车辆的速度、油温、胎压等参数，输入参数可能是传感器信号，输出参数是经过处理后的车辆状态数据，QoS 要求包括数据的实时性、准确性和可靠性等方面。 -
设计合理的系统集成方案，确定服务之间的集成方式和交互顺序。可以采用消息中间件等技术来实现服务之间的通信，确保通信的高效性和可靠性。例如，在智能驾驶辅助系统和底盘控制系统的集成中，通过消息中间件传递控制指令和车辆状态信息，使得两个系统能够协同工作，实现车辆的自动转向和加减速。 -
考虑通信协议的选择，根据不同服务的需求和数据特点，选择合适的通信协议。对于实时性要求高、数据量小的控制指令，可以选择 CAN（控制器局域网）或 CAN – FD（具有灵活数据速率的 CAN）协议；对于大数据量的信息传输，如地图数据更新、多媒体文件传输等，可以采用以太网协议。同时，要确保通信协议的兼容性和可扩展性，以适应未来的技术发展。
-
建立严格的软件开发流程，遵循敏捷开发或其他适合的开发方法。在开发过程中，注重代码的质量和可维护性，采用代码审查、单元测试、集成测试等质量保证措施。例如，规定开发人员在完成每个功能模块的代码编写后，必须进行单元测试，只有通过单元测试的代码才能提交到代码仓库进行集成测试。 -
制定统一的软件开发规范，包括代码风格、命名规则、注释规范等。统一的规范有助于提高团队的协作效率和代码的可读性。例如，规定代码的缩进采用四个空格，变量命名采用有意义的英文单词组合，函数和类的注释要清晰地说明其功能和参数等。 -
根据服务的定义和功能要求，选择合适的技术栈进行服务开发。对于计算密集型的服务，如自动驾驶中的目标识别和路径规划服务，可以选择高性能的编程语言（如 C++）和计算框架（如 CUDA 用于 GPU 加速）。对于信息娱乐服务，可以选择更适合快速开发和跨平台的技术，如 Java 或 JavaScript 等。 注重服务的性能优化，在开发过程中考虑如何减少资源消耗和提高响应速度。例如，在服务的算法设计中，采用高效的数据结构和算法，避免不必要的计算和存储。同时，合理利用硬件资源，如利用多核处理器进行并行计算，提高服务的执行效率。 -
按照系统集成方案，逐步将开发好的服务进行集成。在集成过程中，要注意解决服务之间的接口匹配问题和数据交互问题。可以使用调试工具和日志系统来帮助定位和解决问题。例如，在集成智能驾驶辅助系统和车辆状态监测系统时，通过调试工具检查两个系统之间的接口是否正确连接，数据是否能够准确传输，并通过日志系统记录集成过程中的问题和调试信息。 -
进行系统级的调试，通过模拟各种车辆运行场景和用户操作，检查软件系统的整体功能是否正常。例如，在车辆启动、行驶、停车等不同场景下，测试各个服务之间的协同工作情况，包括动力系统控制服务与智能驾驶辅助服务在加速、减速过程中的配合，以及信息娱乐服务与车辆状态监测服务在显示车辆信息方面的协调等。
-
开展全面的功能测试，覆盖所有规划的服务和系统功能。采用黑盒测试和白盒测试相结合的方法，从用户角度和代码实现角度分别验证功能的正确性。例如，对于自动紧急制动服务，通过黑盒测试模拟不同的交通场景，检查制动功能是否正常启动和执行；通过白盒测试检查制动服务的代码逻辑和算法是否正确。 -
进行性能测试，评估软件系统的响应时间、资源利用率、吞吐量等性能指标。性能测试可以在实验室环境和实际车辆环境下进行。例如，在实验室中使用专业的测试工具模拟多个服务同时运行的情况，检查系统的响应时间和资源消耗；在实际车辆中，通过实际驾驶测试，收集数据并分析系统在不同路况和驾驶模式下的性能表现。 -
重点关注软件系统的安全性测试，包括网络安全和功能安全。通过渗透测试、漏洞扫描等方法检查软件系统是否存在安全漏洞。例如，对车联网系统进行渗透测试，模拟黑客攻击，检查系统的安全防护机制是否能够有效防止数据泄露和非法访问。对于功能安全，通过故障注入测试等方法，模拟硬件故障和软件异常，检查系统是否能够正确地检测和处理故障，保证车辆的安全运行。 -
进行可靠性测试，通过长时间的测试和模拟各种复杂场景，评估软件系统的可靠性。例如，进行耐久性测试，在车辆连续运行一定时间或里程后，检查软件系统是否出现故障；模拟恶劣的天气条件、复杂的交通场景等，检查系统在各种情况下的稳定性和可靠性。 -
充分认识到测试环境和实际车辆使用环境的差异，尽量在测试环境中模拟实际环境的各种因素。例如，在测试环境中可以通过模拟器模拟不同的天气状况、道路状况和交通流量等。同时，要在实际车辆中进行足够的测试，以验证软件系统在真实环境中的性能和可靠性。例如，在实际道路测试中，收集车辆在不同季节、不同地理位置的运行数据，分析软件系统的实际表现，并对测试环境中的测试方案进行调整和优化。
-
制定合理的软件部署策略，考虑软件更新的方式、时机和流程。可以采用 OTA（Over – The – Air）更新方式，方便用户及时获取软件更新。例如，对于非关键的软件更新，如信息娱乐系统的功能优化，可以通过 OTA 自动推送更新；对于涉及车辆安全的关键软件更新，如自动驾驶系统的安全补丁，可以在用户确认后通过 OTA 更新或要求用户到服务站进行更新。 -
建立软件更新的测试和验证机制，确保更新后的软件不会引入新的问题。在软件更新前，要在测试环境中进行充分的测试，包括功能测试、性能测试和安全性测试等。例如，每次软件更新后，都要在实验室的测试车辆和部分实际用户车辆中进行小规模的试用，收集反馈信息，确认没有问题后再进行大规模的推送。 -
建立系统运维机制，实时监控软件系统的运行状态。通过在车辆中安装监控软件和传感器，收集系统的运行数据，如服务的运行时间、资源消耗、故障次数等。例如，利用车辆的远程监控系统，将系统的运行数据发送到后台服务器，运维人员可以通过数据分析及时发现潜在的问题。 -
制定故障处理流程，当系统出现故障时，能够快速响应和处理。对于软件故障，可以通过远程诊断和修复技术，如软件复位、远程代码更新等方式进行处理。对于硬件故障，及时通知用户到服务站进行维修，并提供相应的技术支持。例如，当车辆的某个传感器出现故障时，系统能够及时检测到故障信息，通过车载系统或手机应用通知用户，并提供附近服务站的位置和维修建议。
五、我们究竟为什么要用SOA？
（原创 海角 焉知汽车）
END
1、如您转载本公众号原创内容必须注明出处。
2、本公众号转载的内容是出于传递更多信息之目的，若有来源标注错误或侵犯了您的合法权益，请作者或发布单位与我们联系，我们将及时进行修改或删除处理。
3、本公众号文中部分图片来源于网络，版权归原作者所有，如果侵犯到您的权益，请联系我们删除。
4、本公众号发布的所有内容，并不意味着本公众号赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本公众号证实，对本文全部或者部分内容的真实性、完整性、及时性我们不作任何保证或承诺，请浏览者仅作参考，并请自行核实。
