SOME/IP协议详解「1.1·面向服务与面向信号」

SOME/IP协议详解「1.1·面向服务与面向信号」]
+   [1 SOME/IP使用举例](#1_SOMEIP_13)
+   [2 面向信号CAN的做法](#2_CAN_27)
+   [3 面向服务SOME/IP的做法](#3_SOMEIP_41)
+   +   [3.1 事件发送](#31__44)
    +   [3.2 方法调用](#32__47)
    +   [3.3 字段处理](#33__50)

* * *

对于ECU间的行为目的，无外乎两种情况：

+   要求对端ECU执行某个动作

+   要求对端ECU给我某个数据

给数据这里又有两种场景：**情况1**. 我每次跟你要一次数据你给我一次 **情况2**. 我不想每次要数据你才给我，而是我只给你说一次我要数据，你定期给我，或者发生某个事件后给我

* * *

### 1 SOME/IP使用举例

大家可以想象一下，其实万变不离其宗，通信行为的目的也就只有上诉两种。我们举个例子，基本包含了所有ECU间通信行为目的。下图中是有三个ECU，我们有一个物理的换挡杆。

- 当换挡杆在前进D挡时，需要不断的给ECU1发送转速数据，对应的是**ECU1要求ECU0给某个数据**（当然也可以要一次数据给一次数据）

- 当换挡杆在R挡时，ECU3能要求ECU1进入节能模式，对应的是**ECU3要求ECU0执行某个动作**

- 最后还有一种组合情况，比如当挡杆在N挡时，ECU2可以设置ECU0的时间 **（对应执行动作）**，或者获取ECU0的时间 **（对应获取数据情况1）**，或者是让ECU0主动通知我时间 **（对应获取数据情况2）**

![](/media/202408/2024-08-07_131507_9877580.11825623004667907.png)

那么目的知道了，面向信号和面向服务就是两种实现目的的手段

- 面向信号是将应用层要想传达给对端的内容通过信号的形式告诉对方，信号设计的时候，会设计每个字段代表什么意思，对端通信人员按照规定解析后就知道我要干嘛了

- 面向服务是将上述行为设计成服务，分为服务端和客户端。客户端可以请求服务端给数据，或者执行动作。通信中发送/接受的仅仅是服务接口的数据字节流。只有应用自己知道里面内容的含义，通信过程只能知道那是一堆字节流

* * *

### 2 面向信号CAN的做法

![](/media/202408/2024-08-07_131623_1728400.5494144114825857.png)

面向信号（或者说S2S）比较典型的就是过去几年汽车里面常使用的CAN通信，在使用CAN总线通信的时候，一般都是将上层应用和下层通信接耦。上层如果需要发送数据，那么会先发送到一个缓存buffer中，buffer中的值会按照CAN总线配置好的周期不断的发送给对方；而接受方收到数据后也是存放到buffer中，当应用需要该数据的时候，再向buffer里取出。这种信号设计和上层应用设计完全隔离的做法就是面向信号的主要思路，在链路可靠，不会经常动态变更的场景下的确是不错的选择。拿上面的变挡举例，ECU0会和其他ECU不断的通信，来告诉其他ECU自己的状态；假如当前ECU3收到了ECU0进入倒挡状态的标识，那么它为了让ECU0进入节能模式，就要不断的发送请求节能模式的报文（如果只发送一次，一旦丢报文，是很危险的；或者也可通过借鉴面向服务应答ack的形式避免）。对于上面的几种场景，都可以分配到信号上去，通过数据交换间接的完成应用层想要的目的

![](/media/202408/2024-08-07_131731_2797350.43612662987025896.png)

不过随着汽车行业的不断发展，ECU的逐渐变多，功能的不断增加，固定通信的做法暴露出来了越来越多的瓶颈：

1.  某些内容接受方在某个阶段根本不需要，但是发送方不知道对端不需要，还是无脑的不断发出去，甚至可能会发一堆0出去，极大浪费总线资源
2.  发送的数据一直都没有变化，实际上没有必要再继续发送相同数据
3.  另一方面，面向信号的发送通常来说信号都有一个周期，假如周期为1秒钟，那么从应用层发送数据给buffer的时候开始，对端接受到该数据很可能有极高的延迟；为了减少这个延迟时间，总线周期就得提高，那么负载又会增加

当然上述场景在`AutoSAR`中也做了很多的优化，比如发送相同数据的时候，可以动态的减少发送次数；对于延迟问题也可以通过单条报文触发发送的方式来弥补，但是这种方式会增加通信设计人员的工作量，且无法彻底解决。随着未来功能的进一步增加，面向信号的做法会越来越不能满足当前汽车行业的发展，面向服务的变革势在必行

* * *

### 3 面向服务SOME/IP的做法

![](/media/202408/2024-08-07_131829_7190190.07929100956943047.png)

面向服务不需要像面向信号一样再通过信号去缓冲一层，导致数据强行变成异步更新。服务的通信都是直来直去，可能会有一些底层发送FIFO的缓冲，但是延迟时间通常会很小。而针对上面的两种场景，someip设计了三种服务模式以满足通信目的：

#### 3.1 事件发送

这是一种服务端主动发送的机制，可以一个Server（服务端）发给多个Client（客户端）。当然前提是需要订阅，这个将在后续的服务发现章节中详细讲解。事件发送可以是周期的，也可以是触发的，根据应用需要设定

![](/media/202408/2024-08-07_131856_5339030.393301804201006.png)

#### 3.2 方法调用

方法调用有点像是去调用一个函数，函数可以返回数据回来（对应下图【1】），也可以没有数据返回单纯像让它干个什么事（对应下图【2】）。被调用的函数是Server，一个Server可以被多个Client调用（为避免同时调用的冲突，可以设置排队或者多实例等方法）

![](/media/202408/2024-08-07_131911_5407550.898215296342105.png)

#### 3.3 字段处理

如果有某个数据可能有被对端修改，有被对端读取，还可能是订阅式的读取，那么可以为这个数据专门设置一个特殊服务，该服务包含get data、set data和notifer data的操作，Client想要什么就可以用什么。在SOME/IP中称为Field，其实就是方法和事件的结合体，但是由于其处理的内容是同一字段，放在不同服务里不太合适，所以专门设置了这种Field的组合形式

![](/media/202408/2024-08-07_131937_2419820.242663112342128.png)