深入浅出理解SOMEIP.docVIP

深入浅出理解SOMEIP SOME/IP，全称为Scalable service-Oriented MiddlewarE over IP，是用于控制消息的汽车中间件解决方案，是一种面向服务的可伸缩的协议。SOME/IP于2011年由BMW设计，2014年纳入AUTOSAR规范。 SOME/IP的报文格式如下图所示，由消息头部(Header)和消息体(Payload)组成，Header主要包括以下字段： Message ID，用于唯一标识消息，当消息为Method类型时，由Service ID和Method ID组成，当消息为Event类型时，由Service ID和Event ID组成，如下图所示： Length，消息长度(从Request ID开始到Payload结束)； Request ID，服务提供者和调用者可用于区分相同消息的不同调用，由Client ID和Session ID组成，如下图所示： 通常我们称服务提供者为Service，服务调用者为Client，Service ID和Client ID用于区分，一般会在一个SOA架构中统一地配置这些ID的数值。 这里插播一点个人理解，在SOA中，每个服务就好像我们每一个人在社会中扮演的角色，在对别人提供着服务的同时，同时也享受着别人提供出来的服务，人与人之间，既是彼此独立的，又是需要互相通讯的。服务提供者将功能具象为一组接口，这样使用者就能知道如何调用服务，完成某件事情，得到某个结果。 Protocol Version，协议头版本号，目前该值必须为1； Interface Version，接口版本号，一般由服务提供者定义； Message Type，用于标识消息的类型，如下图所示： 消息类型和通信机制之间的映射关系，如下图所示(灵魂画手，将就看吧)，不难发现，Field结合了Method和Event，这也就理解了Message ID中为什么只有Method ID和Event ID，没有Field ID。Field可以用于实现这样一种通信场景：客户端希望能够获取/设置/监听服务端的某一个状态值，图中SOME/IP-SD。 Return Code，用于标识请求是否成功处理，不同的消息类型，它们在传输时所携带的Return Code也不同： 具体返回值和错误码定义如下： Payload，也叫有效载荷，是消息内容，通常它的长度是可变的。SOME/IP协议在OSI七层网络结构中位于应用层，它建立在TCP或者UDP传输层协议之上。当通过UDP传输时，由于UDP的限制，Payload的长度应该限制在1400字节以内，超了则要分组(SOME/IP-TP)，而当通过TCP传输时，可以传输更多的字节，理论上只要不超过Length字段的大小即可。 对于AUTOSAR系统，Payload要遵循AUTOSAR规范进行序列化，对于非AUTOSAR系统，可以遵循AUTOSAR规范进行序列化，也可以采用其他序列化方式如常用的Google Protocol Buffer、JSON等。 以上介绍了SOME/IP协议，可以发现，SOME/IP其实并不等同于SOA，只能说要实现SOA，SOME/IP是一个很不错的协议选择。SOME/IP还有一个控制协议SOME/IP-SD， SOME/IP-SD也是基于SOME/IP的报文，用来实现服务发现和事件订阅机制。SOME/IP-SD消息通过UDP进行传输，报文格式如下图所示： Flags=重新启动标志+单播标志+显示初始数据控制标志，如下图所示： 服务重新启动后，所有消息的Reboot Flag须置为1，直到Session ID重新从1开始计数，之后的Reboot Flag须置为0。 Entries Array，Entry可以理解为“入口”，包含了服务实例以及需要订阅的事件组的信息，分为Service和Eventgroup两种类型，一个SD报文可能包含多个Entry，每个Entry大小都是16个字节，一个Entry可能包含0-2个Option。下图为一个完整的SD报文示例： Service Entry 用于服务发现： Type：当网络中未收到相关服务的OfferService或者暂时未收到，而Client又需要访问该服务，那Client可以发出FindService去主动寻找服务，如果Service已经就绪的话，会回复OfferService报文；服务就绪后，主动发出OfferService，用以告知组播内其他节点，该服务已经启动，可以创建连接；当服务不可用时，会主动发送StopOfferService报文，用以告知组播内其他节点，该服务目前不可用，停止发送请求，并取消订阅。 Type值 名称 0x00 FindService 0x01 OfferService St