1.序言

一听到SOA！脑壳大！搞传统方向的工程师开始是比较难理解的，甚至说有点排斥，我也不例外。大家都在说这是互联网玩剩下的，但是SOA毕竟是行业趋势所在（跟随以太网进入汽车而出现），也不得不去理解，当自己完整的做过一遍后，发现理念确实是先进的，但是它的优势可能还需要长时间去验证。

2.SOA到底是个撒

经典Autosar一个主要功能就是软硬分离，大家都往上提供标准接口，这样OEM更好去选择“小三”，Tiger1也更好去认“干爹”，这样大家都方便了，实现了底层的标准化，从而实现软硬分离。

SOA其实就是实现了软软分离，相当于把软件打碎，用专业的语言讲，这叫提高颗粒度（哈哈哈），然后每个颗粒之间都要留标准接口，这样大家都可以随意调用。举个例子：有个软件需求让做一个汽车灯光秀，先让左大灯闪2下，再让右大灯闪2下，然后喇叭响一下。如果用MBD来做，我可能会做个状态机来控制，但是如果这时候又新增了一个需求，让主动悬架跟着车灯一起舞动，这个时候的第一个动作可能就是去前处理里面拉出对应的信号，然后一直连线连到状态机里面，如果前处理里面没有相关CAN控制信号，还要去新增CAN接口。但是，如果用服务化去实现，直接调出相关接口就可以，类似于一个全局的Goto，From，从而提高软件的可扩展性和复用性。当然，这只是一个最直观的优势，服务化的优势还有很多，就这个例子而言，增加需求只需要编译一个小模块就行，而传统方式需要去编译全部软件，从而也提高了开发效率。

3.SOA到底怎么做

3.1 服务分层架构设计

举个例子，见下图（为了保密需要，关键信息已被隐去），根据整车系统架构，我以VIU域控为例，把控制分为基础服务-原子服务-增强服务-系统服务，以下是各功能介绍：

基础服务：CAN，I/O 信号转服务，服务转信号（类似于CAN信号前处理）

原子服务：一般以控制器最小功能划分，划分得越细，控制方式就越多，同时这层服务起到了整车隔离作用（因为以最小功能划分，如果做平台化了，不同车型只用改这一层就够了）

增强服务：图示比较简单，这一层是控制核心，也是最难的，一般是把算法集中在这一层，融合平台化策略，他会对上面下来的需求进行优先级仲裁，当外部输入同时到来，会根据事先设定好的有限权重去执行

系统服务：处理外部需求的输入，例如：驾驶员操作，云端输入等等

图1：控制分层架构

图2：华为 SDV服务软件架构

3.2 服务接口设计

接口定义是服务化关重环节，主要是定义各软件颗粒的接口，根据不同控制方式以及重要程度区分接口类型，以及定义它的名字，数据类型，精度，偏移量等等基本信息，其中最主要的就是接口类型和名字，这个跟软件设计输入输出相关，以下介绍主要的几种接口类型，这几种类型其实也就是基于SOME/IP（基于以太网的通讯协议，全称为 通过网络提供面向服务的通信，可私聊“SOME/IP获取”）的消息类型，SOME/IP一共有三种通信方式，分别是Method、Event和Field。（下面开始科普，很无聊，开发中用得最多的就是RR,Get,Set,Notifier这几个重点看）。

Method

RR：Request & Response，此类型用于要求有反馈的消息，Client（客户端）发送请求，Server（服务器）回复响应，属于同步调用，也是最常见的。例如：制动压力控制，当需求压力出去之后，发出模块需要知道反馈从而达到闭环控制。

FF : Fire & Forget，可以直译成点火即忘，触发了但不在乎结果，Client发送请求，但不需要服务器的响应，属于异步调用。这个类型在博主的开发中几乎没用，属于异步调用。

图3：Method图示

Event

图4：Event图示

图中Event报文上方还有两个SD报文，SD是服务发现Service Discovery的缩写，它SOME/IP的一个模块，Event类型通信的前提是通过SOME/IP SD进行发布和订阅，在SOME/IP中，定义了三种Event发送的策略：

Cyclic update

周期发送，以一定的周期发送通知。

Update on change

变化后发送，当该事件发生变化时，进行发送。

Epsilon change

变化超过阈值发送，当较上一次的变化超过预先设置的阈值时，进行发送

这些发送策略都需要在接口定义里明确，最后都要体现在软件配置中。

Field

Field，可以用来表示具体的“属性”，比如状态、模式或者数值等。Field是一个合集，里面包含了Getter、Setter和Notifier三种方式，Client可以用Getter去主动获取，可以用Setter去设置，也支持当满足一定触发条件时，Server主动发出通知，即Notifer。

Get：获取某个服务的某一接口的信息，一般为查询消息

Set：设置某个模块的状态，此类型消息一般为从上至下设置（上层服务调用下层，类比市政府命令县政府，反过来命令的很少），常用于布尔类型开关设置

Notifier：通过Event的方式来实现，发送策略与Event一致，不同的是当第一次订阅成功后，Server会主动发送一次Notifier，携带当前Field的值，即订阅成功后，Client可以立刻获得Field的初始值，而不用等待事件触发。除此之外，相较于Event，Notifier更适合具有“属性”的值。举个例子，开门、碰撞、报警等瞬间发生的事件，一般可以定义成Event；而车速、温度、音量等即便没有事件触发，本身也有含义的内容，用Notifer会更加合适。

图5：Field图示

服务接口设计一般通过一个Excel表格来进行管理，见下图所示，命名规则：接口类型_控制量（一般使用驼峰缩写），此表非常重要，在协同开发时，需要同步更新该表格，不然别人拿着表格定义软件输入的时候常常因为名称不对导致开发延误（TM的，开发的时候经常改半天，最后发现与对手组件的命名大小写没有保持一致，导致编译报错一直无法集成）

图6：接口定义表（部分）

3.3 软件配置

服务化的代码生成一般选择是AUTOSAR代码

图7：AUTOSAR配置界面

服务化最难配置的，也是最繁琐的，就是代码接口，模型其实跟常规模型没什么区别，上文中讲到，我们常用的输入输出就是RR，GET，SET，Notifier，Event

图8：演示模型

Event&Notifier：模型的输入都可以直接新建一个Inport/output,命名按照接口定义表的来进行就可以

图9：Event&Notifier模型

RR/GET：使用Trigger，设置函数为调用，命名为对应的RR/GET

图10：RR/Get模型

Set：使用Function Caller，命名为对应的SET

图11：Set模型

当模型配置好了后，需要配置下图中的Autosar component，说白了就是模型中的输入，需要告诉Matlab，这个名字是什么，他是接收还是发送，给他定义一套规则，比如：软件运行的周期，函数/变量初始化值等等，其中S-R代表Send-Recive，Notifier和Event类型的输入输出归类在里面，C-S代表Client-Service，RR，Set和Get类型的接口归类在这里面，下面圈出的就是需要配置的点。

图12：Autosar component

3.4 SOA配置过程中的注意点

1.数据名称，数据类型，大小写，偏移量等等基础信息一定要一致

2.对于库函数，不同模块的工程师偶尔会使用相同的库文件，但是又是分开生成C代码，会导致最后集成的时候编译报重定义。这个问题有很多解决办法，比如预处理指令，但是目前还没研究出来永久的解决办法

好了，就讲这么多，这只是我对SOA的个人理解，讲了个大概。很多理解不对的还请各位多多指点。