如何在现有整车架构和软件资产下进行SOA的设计开发

如何在现有整车架构和软件资产下进行SOA的设计开发

1.0 架构: 以逆向分析为主，整合现阶段市面上供应商的零部件，实现整车功能(典型代表 比亚迪 F3)

2.0 架构: 以正向开发为主，融合国内外先进经验技术，进行整车多车型的架构开发(典型代表 吉利 CMA 架构)

2.1. 服务设计依据

总体采用自上而下与自下而上想结合的形式进行服务定义。

针对整车功能定义 FR 与 FDR ，进行自上而下设计，首先使用面向对象的思维进行整车的类抽象，然后设计类的方法与属性，其中属性尽量与 原子服务进行映射，方法需要使用一个或多个原子服务进行实现

最终进行原子服务，与整车类的属性与方法进行映射，找出无法实现的类，以及没有使用到的原子服务，此部分进行服务代理设计，及使用传统 SWC 软件模块实现部分功能，然后代理成组合服务形式，参与整车架构设计。

2.2. SOA 设计区别

SOA 面向服务设计 在 3.0 架构中，首先要进行服务的划分和设计，每个服务是松耦合的，也就是分治的设计理念，及服务里包含的方法、event、field 具备高扇入，合理的扇出，而服务所抽象的数据要与处理的业务逻辑、流程、功能实现三方解耦，所设计的基础服务也要与操作系统解耦。 对比 2.0 中的设计，可以类似的理解为 2.0 先设计软件模块，然后设计信号接口，而 3.0 soa 后先设计服务接口(此接口不仅包含类似信号的 event，还包含类似函数的 method 方法)，有了服务之后，在设计哪些模块提供这些服务，哪些模块订阅服务。 需要注意，SOA 后里的软件模块需要严格的区分 server 与 client，也就是一个模块要不就是提供某个或多个服务，要不就是订阅了一个或多个服务，不存在既订阅了一些服务又提供了一些服务的情况，这与 2.0 架构中的 swc 软件模块既有输入又有输出完全不一样。

OOP 面向对象设计 在 3.0 架构中，需要借助面向对象的设计方法来辅助支撑，也就是依托现有 2.0 架构，不进行大范围重构的前提条件下，使用类抽象出所有 LC 模块，并且通过设计不同类的用例图来实现原 LC 处理的功能。

2.3. 接口命名规范

在进行 SOA 服务设计时，需要遵循如下命名规范

2.3.1. 基础规范

尽量采用单词全称，名称过长后才使用缩写

名称不包含特殊字符 ,./~

名称如果过长，需要参考常用单词缩写表中内容进行缩写

考虑服务和参数的复用性，各类命名中不应带有拓补节点信息

不同层级的各类名称不能重复

命名中不能使用如下系统关键字:

skeleton

proxy

internal

resources

method

event

field

input/output

ara

com

someip

base

vac

std

2.3.2. Service Instance 服务实例

服务实例及指代定义的服务实现，后文若单独写服务，则意为服务实例

服务名采用首字母大写，全英文名称

服务名不能有下划线

服务名后缀需要以 Srv 结尾

eg. LedControlSrv

2.3.3. Service Interface 服务接口

SOA 平台上服务之间通信接口有 Event、Method 和 Field 三种形式, ServiceInterface 用于定义 Event/Method/Field 消息类型和具体的命名空间，与具体的通信协议无关。

服务接口名采用首字母大写，全英文名称

服务接口名不能有下划线

服务接口名需要以 SrvIf 结尾

eg. LedControlSrvIf

2.3.4. Event

2.3.5. Method

Mehtod 接口表示某种控制，通讯方式采用 RPC 远程调用，通常有动词行为，比如控制，状态查询，传输，注册，设置等。其中 Method 又分为 F&F,与 R&R 两类，FF 为单次调用，不需要反馈，RR 为 request resoponse，需要反馈。

请求-响应（request/response）: R&R

请求-响应流（request/stream）

发后不管（fire-and-forget） : F&F

通道模式（channel）

get 获取状态

set 设置状态

report 传递信息

judge 判断事件，返回 boolean

create 创建线程/进程/动态服务/文件/事件 等

delete 删除线程/进程/文件 等

2.3.6. Field

Field 表示一种属性，通常指状态值或某种信息，名称应该清楚的表达该属性的含义。 Field 包含如下三类信息：

getter : 只读接口，原型为 method，获取服务端信息

setter : 写入接口，原型为 method，设置/修改服务端相关信息

3. 服务设计方法

针对大部分 OEM，需要在现有整车架构上进行服务设计升级，也就是已有 base 的 LC 需求，和工程级的软件 swc，需要依据这两类已有资产，使用 OOP 面向对象的抽象与封装手段，进行 SOA 服务化重构。 本章节以车身控制器中 危险报警 软件模块为例，说明如何在已有 LC 需求和软件模块前提下，使用 gitee，进行 SOA 设计。 需要注意的是，在设计服务接口时，要清楚的知道不同接口的实际特性和性能消耗。Event 为 服务端主动向客户端 发送请求，而 Method 恰好相反，为 客户端主动向服务端 进行请求调用。根据如上接口描述，整体服务设计遵循如下方案要点。

原 2.0 平台中信号尽量保留，作为 Event 接口类型进行预留

服务设计包括 类抽象-服务接口设计-服务实例设计-设计具体的进程/线程 运行此服务实例

每个抽象好的类，对应一个服务接口 : XX_Class -> XX_SrvIf

类中的属性对应 Event 接口类型 XX_Class::value -> XX_SrvIf-valueEvt

类中的方法对应 Method 接口类型 XX_Class::fuction -> XX_SrvIf-valueMtd

尽量不要设计 Field 接口

每个服务接口由一个具体的服务进行实例化 : XX_SrvIf -> XX_Srv

每个实例化的服务，都要设计哪个进程/线程/软件模块/ECU 来提供，哪些 App 会订阅

App 使用/设定服务里的数据/功能，需要通过 CM 通讯管理进行服务的订阅

实例化的服务之间，数据/功能 传递，则直接调用相互暴露的 api，可以不用 CM 参与（即组合服务和原子服务的关系）

App 之间不能直接进行数据传输，需要调用专有的服务进行数据传递（即服务代理模块）

3.1. 需求分析

3.2. 类的抽象和封装

使用 OOP 手段，根据需求和已有的软件模块，进行类的抽象，并将有可能被多次调用的软件逻辑进行类方法的封装，后续多次执行的代码逻辑，仅在实例化的类中执行一次即可。

类抽象，将整车从多个角度抽象成不同的类，每个类都可以映射成一个 service 的实体，不同的软件模块调用相同逻辑时，可以直接订阅此 service，使用 service 中的 method、event、field。

类方法封装，将接口进行泛化，封装成通用类的方法，达到松耦合的效果

3.3. 服务设计

上一章推导出，所设计的类就是一个需要实现服务，根据此原则，在 gitee 中进行服务设计。 服务设计包含如下步骤和要素：

服务接口设计(method/event/field)

接口变量设计(method 的入参出参及数据类型，event 变量名及数据类型)

服务实例设计(发布者，服务 ID 等信息)

3.3.1. 数据类型设计

3.3.2. 服务接口设计

在 Gitee-Service 接口 中进行 service 接口设计

3.3.3. 服务实例设计

3.3.4. 配置文件导出以及代码框架生成

通过 gitee 能够导出所有服务 list 的 csv 文件，基于此开发工具进行 arxml 文件和代码框架的转换生成，最终进行基于 SOA 服务化的软件开发。 代码框架可以参考笔者之前的回答。

4. 小结

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。