我是靠谱客的博主 执着猫咪,最近开发中收集的这篇文章主要介绍SOME/IP协议详解「2.0·服务化通信概述」SOME/IP协议详解「2.0·服务化通信概述」,觉得挺不错的,现在分享给大家,希望可以做个参考。

概述

SOME/IP协议详解「2.0·服务化通信概述」

点击返回雪云飞星的SOME/IP协议详解「总目录」


  • SOME/IP协议详解「2.0·服务化通信概述」
    • 1 SOME/IP服务的组成
    • 2 Method|Event|Field
      • 2.1 Method
      • 2.2 Event
      • 2.3 Field
      • 3 小结


1 SOME/IP服务的组成

someip提供基于网络的面向服务的通信机制,而每个服务一般都是由相近或相关的一些功能组成。在someip中规定服务中可以包含三种接口,这三种接口对应了我们在SOME/IP协议详解「1.1·面向服务与面向信号」中讲解的事件发送、方法调用和字段处理。在someip中称为Methond、Event和Field,这里按下不表,下一段详细讲解
在这里插入图片描述
我们继续说明什么是服务,我们举个车载空调的例子。空调是大家生活中常见的物品,提供我们加热、制冷等功能。由于现代的空调功能越来越多,我们不做详细举例,这里仅仅说明最基本的几个功能:

  1. 能打开或关闭空调
  2. 能调高或调低空调的风量
  3. 能告知当前的环境温度
  4. 能告知当前的目标温度
  5. 能设置当前的目标温度
  6. 可以通过多种方式(例如语音、按键、触摸屏等方法)设置当前的目标温度

在这里插入图片描述

那么对于有上述需求的一个空调程序,我们将其形成一个服务。通过someip给出的三种接口,就可以将上面的6种功能设计成上图中的接口形式:

  • 两个可被调用的method,客户端可以调用其接口以打开/关闭空调 或 用来增加/减少风量。对应了上述功能点的1和2
  • 一个Event,可以不断通知客户端当前的环境温度是多少。对应上述功能点的3
  • 一个Field,由于我们希望目标温度其实既可以设置,由可以读取,所以我们将其设置为字段形式。对应上述功能点的4和5

需要说明的是:

  1. 服务端对客户端是可以一对多的(反过来不行),那么一个服务是天生可以被多种客户端调用(所以支持语音、按键、触摸屏等多种方式)。对应上述功能点的6
  2. 可以通过Method和Event的组合实现一个Field,不过从概念上来讲,Field的使用更加便于应用工程师理解和使用
  3. Method、Event和Field在CP架构中没有对应的概念,是通过RTE的SR、CS和Trigger接口组合模拟出来的;对网络设计还是展现成Method、Event和Field
  4. Field里面的设置、读取和通知机制的官方叫法为:setter、getter和notifier
  5. Event和Field里的notifier都可以做变更通知,但是其中还是有区别的:Event里的通知是完全由自身控制,按自己的需求通知对方,订阅近起到了使能作用;而Field里面的通知是只要对端订阅成功,会立即发送通知,后再根据自身情况通知

2 Method|Event|Field

其实Method|Event|Field这些都是上层的概念。上层不考虑下层通信,认为下层通信都被完美封装起来,所以上层的使用就像是在一个芯片中调用其他接口一样。真正对应到下层代码具体实现上,就是三种机制的支撑:

  1. 请求/响应
  2. 请求/不响应
  3. 主动发送

由1和2组成了Method概念|3组成Event概念|1、2和3组成Field概念
在这里插入图片描述
我们尝试用代码来理解一下这几个概念,虽然不能100%的准确描述,但是帮忙大家理解是一个很好的手段
在这里插入图片描述

我们将一个服务看成一个类的定义:
class AirConditionerService
服务的定义可以实例化,且可以被多实例化;此处我们实例化出一个来,且不考虑通信过程,就认为其是全局的:
AirConditionerService AirConditionerInstance

2.1 Method

Method就是一个被调用的函数,里面可以执行各种算法,对于类来讲,就很好理解了,就正好对应类的方法。例如图中的:

void OpenOrCloseMachine(boolean state)
{
    //控制打开或者关闭空调
}
void UpOrDownWind(boolean state)
{
    //控制增加或者减少风量
}

注意这里的调用者是另一个ECU(ECU2),而仅通过someip将接口里的数据传输过来,ECU0收到数据后,执行响应的功能。比如此处对端想要调用OpenOrCloseMachine方法,就得对state赋值为on,然后将其传给ECU0,ECU0收到后调用OpenOrCloseMachine函数,并将state作为入参传入。OpenOrCloseMachine这个函数收到判断是否state==on,然后执行打开空调的操作,运行压缩机等等
上面的OpenOrCloseMachine只有一个boolean类型的入参,所以不具备数据返回功能,即ECU2远程调用OpenOrCloseMachine函数后就直接结束了,拿不到更多的信息,也不知道空调是否被真正打开。这种只有传入没有返回的Method被称为FF Method(Fire&Forget Method),如果想要返回状态,就要用到RR Method(Request/Response Method)。而RR的方法的函数会长成下面的样子:

void OpenOrCloseMachine(boolean requestState, booelan* responseState)
{
    //控制打开或者关闭空调
    if (空调被打开) {
    	*responseState = on;
	}
}

这样一来,通过responseState就可以返回空调是否真的被打开了,当然也可以顺便返回一些其他数据,比如空调当前的功率、风量等等信息。有时候,如果数据类型和含义是一致的情况下,也可以做成inout的形式,即一个入参可以即传入,又返回,比如:

void OpenOrCloseMachine(boolean* inoutState)
{
    //控制打开或者关闭空调
    if (空调被打开) {
    	*responseState = on;
	}
}

那么客户端可以通过inoutState传入请求的状体啊,服务端也可以通过这个参数返回当前状态,这种方式也属于RR方法

2.2 Event

事件和Method刚好相反,是由服务端主动发送数据给客户端;而不是像Method那样,请求一次响应一次。Event什么时候发送数据都是因为服务端自己满足了某种条件

void SendCurrentTemperature(int outputTemperature)
{
    //发送当前环境温度
}

还是说空调的事,空调服务可以通过Event发送当前的环境温度给对端(比如给显示屏)。可以是周期的发送,也可以是某个事件(比如这个温度改变了才发送,或者其他什么事件都可以,由应用开发者决定就好)。由于环境温度还是基本上都是实时在变化的,所以上述图中的就是基于一个周期Task去循环发送温度;谁用谁调这个接口就可以,入参就是当前的环境温度
其实事件本身并不是用来传数据的(那是Field干的,上述传输环境温度只是帮助大家理解,并不是一个很好的实践),它本质上还是一个事件,比如空调出现了什么故障,或者切换到某种模式了都是一个事件;是用来通知对方的一种机制,甚至都可以没有参数,比如下面的:

void MachineTurnOff()
{
    //空调关机,并通知对方
}

可以和FF Method组成一个异步的关机流程:
比如ECU2调用OpenOrCloseMachine(off)去要求ECU0里的空调关机。但是关机不是立马关掉的,所以过了一分钟后,ECU0成功关闭了空调,然后通过MachineTurnOff()接口再告诉ECU2(或者别的也行)成功关机了

2.3 Field

Field与前面两种最大的不同就是Field的核心是操控一个具体的数据,这个数据一般来说是一个具有具体意义的变量;而Method和Event最主要的作用是用来执行某些动作,虽然也具有对变量的操控能力,但是在设计的时候,最好将变量操作设计为Field,更加合理

int targetTemperature;

void SetTargetTemperature(intout* inputTemperature)
{
    //设置期望的温度值,然后压缩机开始工作
    if (inputTemperature != oldTemperature) {
        notiferTargetTemperature(inputTemperature);
    }
}

void GetTargetTemperature(int* outputTemperature)
{
    //读取当前期望的温度值
}

void NotiferTargetTemperature(int Temperature)
{
    //通知当前期望的温度值
}

变量的操作也就是读和写两种,分别对应getter和setter。还有一种就是notifier,也是读的一种,与event类似,不需要客户端主动读;服务端在发生了某些变动的时候,可以主动发送这个数据,或者甚至也可以周期发送。就比如博主在代码里写的一样,由于SetTargetTemperature可以被多个ECU调用(ECU1,2,3都可以),那么可以设计成当有ECU来设置这个数据的时候,就可以通知单个或者所有ECU当前的目标温度,以达到同步更新的效果(防止ECU1更新了数据,ECU2和3都还不知道)
还有需要注意的一点是:

  1. Field必须至少包含一个getter、setter和notifier,如果缺少任意一个,就不能称为Field
  2. setter设置了数据之后,会立即返回一个新值回来;但为了方便大家理解,图中没有展现出来

3 小结

  1. Method|Event|Field是上层设计的三个概念,能完全覆盖所有的应用场景
  2. Method和Event主要针对动作,Method是请求进行某个动作,Evnet是发生了某个动作,通知对方;Field才是主要用来对某个数据的读写

点击返回雪云飞星的SOME/IP协议详解「总目录」

最后

以上就是执着猫咪为你收集整理的SOME/IP协议详解「2.0·服务化通信概述」SOME/IP协议详解「2.0·服务化通信概述」的全部内容,希望文章能够帮你解决SOME/IP协议详解「2.0·服务化通信概述」SOME/IP协议详解「2.0·服务化通信概述」所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(38)

评论列表共有 0 条评论

立即
投稿
返回
顶部