SOA 服务设计-传统车载架构的迭代升级

1. 分布式ECU-基于信号的架构设计

之前分析了后续车载网络整体架构的升级迁移路线， 智能网联汽车总线发展趋势将会是怎样 ,现在我们来看，在域控制器开发阶段，针对传统车厂，在分布式ECU，或五大域2.5代范围集成，已经有了深厚的架构开发和经验积累的前提条件下，如何转型并进行中央域控的服务设计。

本章节描述现阶段，面对分布式ECU，如何进行基于信号的整车电子电器架构开发。如下为介绍MBSE理论的较为经典文章。

电气架构的正向开发流程

服务设计相对软件架构设计影响较大，接下来着重分析LC 模块的设计及生成。

1.1. 需求分析

现阶段国内整车架构需求为多方工程实践积累产生，其中包含了2017年黄金年代之前从国外主机厂陆陆续续继承过来的base需求，也包含2020年行业轮转，各个车厂knowhow的架构师、技术专家等主要人员的变动带来的不同车厂经验融合积累，还包含了这几年正向开发之后，各个车型反馈回来的实际问题修正以及新四化大家对未来汽车，人机交互的探索。

凡此种种，可以大概归纳为两类需求，一类是不能轻易改动，包含法规、FEMA、等较为重要且基础的功能，一类是与用户交互关系密切，需要与时俱进的功能需求，这两类的关系就如上图所示。

1.2. LC 逻辑功能架构

依据需求工程分析出的两类，可以进行无关硬件，无关软件模块的逻辑功能架构设计，注意，LC是以功能点为第一导向的，需要完整的实现整车的某项功能，比如远程启动这一个功能，实际需要CEM、PEPS\TBOX、VCU、发动机ECU等多个节点参与，并且每个节点里都有相关负责的多个软件模块。但在设计LC时，此功能为一个LC，主要描述功能逻辑的实现链路。

比如在接到钥匙xx信号，车辆处于XX模式，发动机处于XX状态时，进行xx功能实现，来完成发动机远程启动

具体的LC如何进行实现，是通过图中的映射关系，在其它层进行具体实现。

1.3. MBSE 架构开发

如下图所示，为当前MBSE理念的整车电子电器架构开发，且当前市面上有成型的商业化工具对这套流程进行支撑，比如Vector 的PREEvision ，还有SystemWeaver等工具。但这类工具基本都为CS架构，且licence费用昂贵，二次开发不友好，自定义能力较差。

针对其它的正向整车架构开发流程，可以仔细阅读 窦明佳 大佬的专栏文章 汽车电子电气架构

2. SOA架构-服务设计

为了后续方便理解，我们简单粗暴的把国内的整车电子电器架构分为三个阶段:

• 1.0 架构: 以逆向分析为主，整合现阶段市面上供应商的零部件，实现整车功能(典型代表 比亚迪F3)
• 2.0 架构: 以正向开发为主，融合国内外先进经验技术，进行整车多车型的架构开发(典型代表 吉利CMA架构)
• 3.0 架构：硬件上从分布式ECU变为整车域控架构，软件上由基于signal变为SOA ，能够大幅降低车辆上ECU数量，软件迭代速度也由质的飞跃(典型代表 特斯拉)

2.1. 与3.0架构设计差异

最新一代，3.0架构全面采用SOA(service-oriented Architecture)设计思想进行构建，上一代2.0架构可以理解成采用的是 POP（procedure oriented programming）面向过程的设计思想，需要注意的是，在SOA设计中，自上而下的设计方法中，需要引入了OOP（object oriented programming）面向对象的抽象与封装概念，这是为了在现有架构基础上，能够继承原有FR,FDR,LC，然后进行迭代开发。

也就是说通过Class的抽象，在原有LC一层新添加了类图的设计，通过抽象的类进行用例设计进行功能链路实现。后续进行服务化设计，只要满足类中的属性和方法能够实现即可，而不必去关心设计的服务如何支撑整个子系统及功能链路的实现。

• POP 面向过程设计
  在分布式ECU 2.0架构中，首先要进行Composition 功能组合的划分，然后在进行Component 功能组件的划分，每个组件都有相应的输入和输出信号，依据这些来实现高内聚，低耦合的功能点实现，设计好组件/组合之后，然后进行模块间接口信号的设计，每个模块平均有20个左后的输入和输出信号
• SOA 面向服务设计
  在中央域控 3.0架构中，首先要进行服务的划分和设计，每个服务是松耦合的，也就是分治的设计理念，及服务里包含的方法、event、field具备高扇入，合理的扇出，而服务所抽象的数据要与处理的业务逻辑、流程、功能实现三方解耦，所设计的基础服务也要与操作系统解耦。对比上一代的设计，可以类似的理解为传统架构中，先设计软件模块，然后设计信号接口，而soa后先设计服务接口(此接口不仅包含类似信号的event，还包含类似函数的method方法)，有了服务之后，在设计哪些模块提供这些服务，哪些模块订阅服务。
  • 需要注意，SOA后里的软件模块需要严格的区分server 与 client，也就是一个模块要不就是提供某个或多个服务，要不就是订阅了一个或多个服务，不存在既订阅了一些服务又提供了一些服务的情况，这与2.0架构中的swc软件模块既有输入又有输出完全不一样。
• OOP 面向对象设计
  在中央域控架构中，需要借助面向对象的设计方法来辅助支撑，也就是依托现有设计，不进行大范围重构的前提条件下，使用类抽象出所有LC模块，并且通过设计不同类的用例图来实现原LC处理的功能。

2.0架构上MBSE设计图上LC映射实现

3.0架构上MBSE设计图上LC映射实现

2.2. SOA 服务设计方法

• 总体采用自上而下与自下而上想结合的形式进行服务定义。
• 针对网络上全拓补硬件，进行自下而上设计，将其分为传感器，执行器，与单功能ECU三类，分别针对硬件进行设备抽象api设定，与原子服务抽象。
• 针对整车功能定义FR与FDR ，进行自上而下设计，首先使用面向对象的思维进行整车的类抽象，然后设计类的方法与属性，其中属性尽量与 原子服务进行映射，方法需要使用一个或多个原子服务进行实现
• 最终进行原子服务，与整车类的属性与方法进行映射，找出无法实现的类，以及没有使用到的原子服务，此部分进行服务代理设计，及使用传统SWC软件模块实现部分功能，然后代理成组合服务形式，参与整车架构设计。

图中所提到的 API 文档，当前国内已经有行业规范进行发布，而且是新鲜出炉，就在今年11月份发布的。

SDV 设备抽象API参考-车身&热管理(正式稿2021-10-15)

SDV 原子服务API参考-车身&热管理(正式稿2021-10-15)