汽车SOA服务设计思路与工程实例

花信风zq 2025-03-05

展开全文

本文约3,500字

作者 | 不可说

出品 | 汽车电子与软件

#01

SOA引入

汽车SOA（Service-Oriented Architecture，面向服务的架构），是一种面向服务的架构设计模式，其目标是创造出高内聚、低耦合的系统。与中间件的软硬解耦目标高度一致；

SOA的特点包括：

1. 服务是核心：在汽车系统中，服务是独立的、可重用的、可开放式的组件，提供了汽车系统中各种功能的基本支持。

2. 灵活的系统架构：SOA设计思路强调将服务与应用程序分离，以实现更加灵活、模块化的系统架构，从而增强汽车系统的可扩展性和可维护性。

3. 标准协议通信：服务之间通过标准协议（如SOMEIP、DDS等）进行通信和数据交换，保证了服务之间的互操作性。

4. 服务注册和发现：SOA中需要实现服务注册和发现机制，以便让服务能够自动加入和退出系统，方便系统的管理和维护。

由此可见，SOA与AUTOSAR各有侧重，SOA提供了一种架构策略层面的指导思想，强调服务的标准化和通信的灵活性；而AUTOSAR则是一种实际的开发方法，通过标准化和模块化来提高软件的复用性和开发效率。不过，也因此，SOA的实现可以依赖于AUTOSAR平台实现！

下面将结合工程实践经验，讲述下在量产车型开发过程中如何进行SOA服务设计的。

#02

SOA服务设计流程

服务设计流程思路

在SOA框架下，服务设计是一项既具战略性又具实践性的工作，通常遵循两条并行不悖的路径：

正向自上而下的开发路径：这一路径起始于汽车产品的宏观愿景，它深深植根于产品规划、市场需求分析以及广泛的市场调研之中。开发者首先需要对这些输入进行细致入微的理解，通过深度剖析与精准拆分，将宏大的产品构想逐步拆解为一系列具体、可操作的需求点。在此基础上，他们运用专业的洞察力和创新思维，对这些需求进行整合与提炼，最终从中抽象出能够支撑产品核心竞争力的服务。这一过程不仅要求开发者具备深厚的行业知识，还需要他们拥有将抽象概念具象化为实际服务的能力。

逆向自下而上的开发路径：与此相对，逆向路径则是从功能系统或硬件系统的具体需求出发，向上追溯服务的根源。它侧重于对现有技术架构和硬件能力的深入理解，通过细致分析系统各组件的功能需求与交互逻辑，从中提取出能够支撑这些需求的服务。这一路径强调对技术细节的精准把握，以及将底层技术需求转化为高层服务的能力，从而确保服务设计既符合技术实现的可行性，又能有效支撑上层应用的稳定运行。

在两条路径的服务设计完成后，SOA架构师将需要对这些服务进行全面的汇总与细致的划分，通过专业的视角和严谨的逻辑，确保服务之间的界限清晰、职责明确，同时避免冗余与冲突。在此基础上，架构师将进一步完成SOA服务的软件架构定义，这包括但不限于接口设计、参数规范以及数据类型的明确。这一系列工作不仅为服务的实现提供了坚实的框架，也为后续的软件组件（SWC）设计奠定了坚实的基础。

#03

SOA服务设计实例

1. 服务能力提取

自上而下：

根据产品需求，提取服务能力，如提供下面氛围灯控制需求场景：

功能系统function owner 提出以下需求：

在电源ON的状态下，需要实现64色氛围灯的开闭控制、颜色控制、模式控制（模式1~4）；

分析如下：

自下而上：

系统负责人system owner提出需求：

我们可以做到和车速、转向联动；

补充上述分析图：

由此可以汇总为下面的能力分析表格

功能	能力	参数类型描述	参数范围
氛围灯	开闭控制	开闭类型	开/闭
	颜色控制	整型	0-64
	模式控制	模式类型	模式1~4
	车速联动	使能类型	使能/非使能
	转向联动	使能类型	使能/非使能

2. 服务分层设计

服务的设计应该具有明显的特点与原则，如：

标准化原则：

需要考虑服务能力的表达方式、数据类型和数据模型等，保证接口设计有统一的标准并且接口有明确的表达方式。

服务抽象

服务只包含基本信息，以及仅能发布在服务调用中的与服务有关的信息，如必要的交互需求、约束和必须的服务数据。

可复用性原则

服务是无关单个应用和业务流程，具有无关功能性和通用性，可以在无关服务环境中被定义，并且可以保证它们能促进必要的复用环境，可以被多个消费者程序提供访问。

高内聚、松耦合

减少服务实现和服务消费者之间的依赖关系，减少服务间的依赖关系，可以提高服务的复用性和可移植性；服务内部可以管理自己业务的实现，服务接口的实现应该依赖于服务本身实现。

服务的分层&定义：

根据开发经验，一般可分为三层：

原子层

每一条服务对应一个具体的功能的实现，是作为信号与服务之间转换的桥梁；

如氛围灯的开闭控制与颜色控制可以放置于这一层；

基础业务层

服务的划分：通常以各个部品为单位作为单个的服务，比如空调服务、车窗服务等；也可以按功能区域划分比如：动力域服务、车身域服务、自动驾驶域服务等；

基础层服务可实现定义的基础功能，通常是这个服务/部品本身具有的能力；

如氛围灯的模式控制可以放置于这一层；

复杂场景逻辑业务层

业务层服务主要是面向当前开发项目的服务，具有较强的针对性，较低的可复用性。

如氛围灯的车速联动和转向联动可以放置于这一层；

对于服务有几点说明可以参考下：

一个服务不仅能够独立地完成其被赋予的任务，还能够作为构建更复杂功能的基石，即一个服务可以嵌套地包含其他服务单元，形成一个层次分明、功能丰富的服务网络。这些服务之间通过精心设计的标准接口进行通讯，这些接口连接着服务的提供者与使用者，同时确保了服务内部实现的细节被封装成一个密不透风的黑盒子，既保护了服务的私密性，又提升了服务的通用性和可替换性。

在SOA的层级结构中，上层服务能够便捷地通过这些标准化的接口调用下层服务所封装的功能，从而实现功能的无缝集成与扩展。这种机制不仅简化了服务的调用流程，还赋予了系统极高的灵活性和可扩展性。

对于SOA而言，服务之间的关系并非随意堆砌的，而是需要通过服务编排这一关键步骤来清晰地定义。服务编排如同一张错综复杂的网，将各个服务Block（服务单元）紧密地连接在一起，明确了它们之间的调用顺序、数据交换规则以及可能的依赖关系。这种明确的定义不仅确保了服务之间的协同工作能够顺利进行，还为系统的调试、优化乃至故障排查提供了有力的支持。

最终，每一个或多个服务内容都对应着一个或多个具体实现的软件模块，也就是SWC，作为服务实现的载体，不仅承载了服务的功能逻辑，还通过遵循SOA的设计原则，确保了服务的可重用性、可配置性和可维护性。

3. 服务的接口设计

服务接口的设计要有一定的原则性，如：

1) 标准化

2) 接口明确（接口名称、数据类型、参数名称中英文对照性强，可读性好）

3) 一个接口完成一个功能

4) 符合需求和定位

根据上面提到的氛围灯服务分层分析，可做如下的服务定义、接口设计与参数定于

功能	服务	接口描述	接口	参数	参数类型描述	参数类型	参数范围
氛围灯	氛围灯原子服务 AmbiAtomicService	开闭控制	setAmbLiOnOffReq	入参：switchSts	开闭类型	Uint8	0：关 1：开
	氛围灯原子服务 AmbiAtomicService	颜色控制	setAmbLiColorReq	入参：color	整型	Uint8	0-64
	氛围灯基础服务 AmbiBasicService	模式控制	setAmbLiModeReq	入参：mode	模式类型	Uint8	1：模式1 2：模式2
	氛围灯逻辑服务 AmbiLogicService	车速联动	setAmbLiSpeedEnableSts	入参：color	使能类型	Uint8	0：非使能 1：使能
	氛围灯逻辑服务 AmbiLogicService	转向联动	setAmbLiSteerEnableSts	入参：color	使能类型	Uint8	0：非使能 1：使能

上面各个服务的各个接口，参数类型均定义为了Uint8，较为通用；不过，如果为了更好的体现参数的含义，可以定义为Enum枚举量，如入参：mode的类型为：

Mode （base uint8）{

MODE1 = 1；

MODE2 = 2；

}

服务接口是一种通信内容定义，其目的在于将服务从功能架构过渡到软件技术架构，且软件模块之间的关系需要被清晰的定义出来（在业务层服务有清晰体现），过程中将服务内容封装成相应的接口被实际调用，如上面表中被定义的服务接口。这种接口定义是独立于通信协议的抽象实体，这种接口可以建立任何两个服务间的通信能力，而使用专有工具链可以由此生成基于特定协议的接口。

在正常开发环节，在这里需要对服务及接口进行通信信息配置，本文主要介绍服务的划分及接口设计原则，暂不对具体通信信息进行配置。