|
SOME/IP的特点
为了满足汽车内的应用，SOME/IP进行了特殊的设计，特点如下：
? 面向服务的通信
? 轻量化
? 兼容AUTOSAR（唯一兼容AUTOSAR的中间件）
? 适配不同规模的计算平台
报头格式
图1：SOME/IP 报头格式 （图片引用自《AUTOSAR SOME/IP Protocol Specification》）
Message ID
Message ID的前两个字节是服务（Service）的唯一识别号，定义为Service ID。每个服务都被分配了一个唯一的Service ID。服务包含了一系列的方法（Method），事件（Event）和字段（Field）。
他们都有一个唯一的Method ID，也就是Message ID的后两个字节，其中0 - 32767为方法（包括Method，Field.Getter以及Field.Setter），32768 – 65535为事件（包括Event和Field.Notify）。比如，多媒体系统中的“音乐播放器”可以作为一个服务“，切换到下一曲目”可以作为一个方法。
Length
包括Request ID，Protocol Version，Interface Version，Message Type，Return Code，Payload在内的长度，占用4个字节。
Request ID
Request ID的前两个字节称为Client ID，可以用来识别一个具体的客户端。在整车范围内，Client ID必须是唯一的。比如用户想要通过多功能方向盘模块（客户端）向多媒体系统（服务端）发送请求来切换到下一首音乐，而后排娱乐影音控制面板也可以做出相同的请求，那么这两个请求就可以通过Client ID去区分。
后两个字节称为Session ID，可以用来识别来自同一客户端的多次请求。比如多功能方向盘模块（客户端）向多媒体系统（服务端）连续发送了多次请求，服务端可以通过这个字段来区分不同的请求。而服务端也会把Request ID复制到响应消息的相同字段中，这样客户端也能通过Request ID来判断收到的响应是针对哪个请求的。
Protocol Version
SOME/IP的版本号，目前为1。
Interface Version
用来识别服务接口的主版本号，由用户定义。比如当服务增加了新的功能，或者发生变更，用户可以定义新的版本号，而客户端或服务端可以通过这个版本号来自动判断兼容性。
Message Type
用来识别不同的消息类型，目前存在五种类型，分别是：
? REQUEST(0x00)
? REQUEST_NO_RETURN(0x01)
? NOTIFICATION(0x02)
? REPONSE(0x80)
? ERROR(0x81)
Return Code
用来指示请求是否被成功的处理了。
Payload
包含用户自定义的数据。
传输层协议
SOME/IP 使用的传输层协议可以是TCP、UDP或SOME/IP TP。
? 如果传输的数据长度超过了1400字节，并且没有严苛的时间延迟要求，使用TCP传输
? 如果有时间延迟的要求（小于100毫秒），使用UDP传输
? 如果传输的数据长度超过1400字节，同时要求较小的延迟，可以使用SOME/IP TP
具体使用哪一种传输层协议跟具体的应用场景有关，如果以上提到的传输层协议均不能满足需求，用户还可以选择其他协议，比如1722等。
远程过程调用（RPC）
SOME/IP客户端和服务端之间的通信支持以下几种机制：
有响应的方法（Method with response）
客户端发送请求消息（Request）调用某一方法，服务端通过响应消息（Response）将结果返回给客户端。
图2：有响应的方法
#无响应的方法（Method fire & forget）
客户端发送请求消息（Request）调用某一方法，服务端不回复响应。
图3：无响应的方法
事件（Event）
客户端首先订阅（Subscribe）某一事件组（Event Group），当事件组中的包含的事件发生之后，服务端将通过Notification消息（Notify）通知客户端。Notification 消息不需要接收方进行回复，这一点有点像Fire & Forget消息。
图4：事件
字段（Field）
字段（Field）是客户端可以远程访问的服务端中的变量。
客户端可以通过远程调用Getter方法获取Field的值，也可以通过远程调用Setter方法设置Field的值。另外和Event相似，当客户端订阅了某个事件组，若事件组中包含的Field发生变化，服务端会主动的通过Notification消息通知客户端；当然，用户也可以选择周期发送Notification消息，这就和传统的周期性CAN报文很像了。
Field和Event的区别是：Field是一个持续存在的变量，比如多媒体音量，内灯亮度，车速，环境温度等；而Event指的是一个事件，事件没有发生就不存在，比如发生碰撞，出现故障等。
图5：字段
SOME/IP-SD
SOME/IP-SD（Service Discovery，服务发现）是SOME/IP中的服务发现机制，客户端可以通过SOME/IP-SD来查找服务的位置，判断服务的可用性，或者订阅事件组等等，基于SD可以实现车内节点的“即插即用（Plug & Play）”。
SD在传统IT行业并不是一个新鲜事物，但是当这个机制被引入汽车电子领域时却引起了很多争议——因为车内环境是相对比较固定的，和互联网完全不同，我们完全可以将所有配置都固化以提高速度。但是需求和技术是不断动态交替发展的，我们不能以静态的眼光去评价一项技术存在的价值。所以究竟SD何去何从，现在还很难下结论，只能交给时间来验证。
SOME/IP协议一致性测试
OPEN联盟发布的TC8是目前行业内关于车载以太网的标准测试规范之一，在2.0版本中加入了对SOME/IP协议的测试。
这里需要解释的是，SOME/IP本身只是中间件，它仅提供了若干接口，运行在其上的应用可以使用这些接口来完成通信。所以为了验证中间件的一致性，我们必须依赖应用来触发中间件产生特定的行为。这个应用可以是DUT自带的应用功能，或者是专门为了测试而开发的应用（也就是Test Stub）。按照应用类型的不同，在TC8中SOME/IP的测试分成以下两个部分：
SOME/IP Server
这部分测试依赖DUT自身的SOME/IP应用功能，我们会在其中抽取一些典型的服务、方法，用来验证一些比较基础的内容，比如报文格式，基本的RPC和SD机制等。
在测试中，我们通过测试系统来仿真客户端发送请求，并接收DUT的响应。除此之外，在触发应用产生特定行为时，部分测试可能需要某些特殊手段。比如在触发DUT发送Event报文时，可能需要仿真I/O输入，或者开发一个测试用的软件接口。
下面我们通过一条典型测试用例，比如SOMEIPSRV_FORMAT_01，来具体说明测试过程（测试规范原文可参考TC8）：
启动DUT的服务
Tester监听DUT的发送端口
DUT发送Offer Service报文
确认DUT发送的Offer Service报文的Client ID字段为0x0000
停止DUT运行的服务
在这条测试用例中索引的需求为如图6所示，即在SD报文中不使用Client ID，必须将这个字段配置为0x0000。此条测试用例检验DUT发送的SD Offer Service报文中的Client ID字段是否和AUTOSAR规范中定义的是否一致。
————————————————
版权声明：本文为CSDN博主「上海北汇信息科技有限公司」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_51954443/article/details/111915040
|