【汽车网络通讯协议】SOME/IP及SOME/IP-SD介绍

最新推荐文章于 2025-02-04 15:16:30 发布
最新推荐文章于 2025-02-04 15:16:30 发布
阅读量1.3k 收藏 22
点赞数 29
分类专栏： 汽车通信 文章标签： 汽车 tcp/ip 网络协议
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/Jessica_zhu1/article/details/143589819
版权

SOME/IP介绍

什么是SOME/IP？

SOME/IP （可扩展服务导向中间件协议，Scalable Service Oriented MiddlewarE over IP）

  • ”可扩展“-在不同硬件平台、不同操作系统或嵌入式固件已经不同应用软件的以后设备之间的可扩展性和互操作性
  • ”面向服务“-表明它是一种面向服务的基本协议。因此仅当客户端请求或服务器通知特定订阅者时，才在客户端-服务器配置中交换数据 ，这就确保了永远不会浪费带宽，并且仅在需要的时间和地点进行数据通信/交换。
  • ”中间件“-它也是一种中间件。即其位于应用层，有自己的通用协议层来处理更具体的操作及应用；
  • ”基于IP“-它也是一个基于以太网的协议。 它使用类似的硬件接口，确保高达 100Mbps 的带宽。 同时数据通过中间件（即应用层）通过网络电缆使用 TCP/IP 或 UDP 协议进行通信。 当客户端需要来自服务器的数据时，它可由客户端使用
    TCP 协议进行请求。 如果服务器必须将数据传送给所有活动的订阅者，则可通过 UDP 协议传输。 UDP
    协议上的数据通信可以是单播、多播或广播。

OSI七层协议模型

首先，我们需要了解在计算机领域的一种标准化网络通信协议框架。也就是OSI七层协议模型，是ISO国际标准化提出的一个试图使各种计算机在世界范围内互连为网络的标准框架。

在这里插入图片描述

  • （第7层）应用层
    位于OSI参考模型层次结构的最顶层，由网络应用实现。这些应用产生要在网络上传输的数据。应用层还为应用服务提供访问网络的窗口，并向用户显示接收到的信息。。该层协议有HTTP（超文本传输协议）、SMTP（电子邮件传输协议）、FTP（文件传输协议）、DNS（用于将域名转换为IP地址的分布式数据库系统，它允许用户通过输入易于记忆的域名来访问互联网上的资源，而无需记住复杂的IP地址）等。
  • （第6层）表示层
    也叫翻译层。表示层负责提取应用层的数据如文字、图像、音频等，并按照网络传输所需的格式进行转换、加密/解密、压缩。该层协议有JPEG、MPEG、GIF、HTML、ASCII、TLS/SSL（加密保护协议）等。
  • （第5层）会话层
    负责建立连接，管理连接，终止两个设备之间的会话。提供身份验证和安全性。该层协议有RPC(远程过程调用,用于分布式系统)、NetBIOS(网上基本输入输出系统,用于局域网通信)、PPTP(点对点隧道协议,用于虚拟专网VPN)等.
  • （第4层）传输层
    为应用层提供服务，并从网络层获取服务。传输层负责完整消息的端到端传递，将来自会话层的信息进行分段重组，并提供成功数据传输的确认，在发现错误时重传数据。该层协议有TCP(传输控制协议,有连接可靠)、UDP(用户数据报协议,无连接不可靠)等
  • （第3层）网络层
    网络层用于将数据从一台主机传输到位于不同网络中的另一台主机。它还负责数据包路由，即从可用的路由中选择传输数据包的最短路径。该层协议IP协议（网际互连协议）
  • （第2层）数据链路层
    负责节点到节点的消息传递。它的主要功能是确保数据在物理层上无误地从一个节点传输到另一个节点。数据链路层将从网络层接收到的数据包进一步划分为帧，并在帧中封装发送者和接收者的MAC地址。
  • （第1层）物理层
    负责设备之间的实际物理连接。它传输的信息单位是比特，负责从一个节点向另一个节点传输单个比特。

计算机网络-OSI七层模型【B站视频动画讲解】

OSI七层模型及对其简单理解举例

有了 IP 地址，为什么还要用 MAC 地址？

TCP/IP四层or五层模型

是TCP/IP在OSI基础上进一步划分的在这里插入图片描述

SOME/IP的分层结构

基于TCP/IP的五层协议，SOME/IP位于应用层。
在这里插入图片描述

SOME/IP的消息类型

SOME/IP通过网络提供面向服务的通信。它基于列出服务提供的功能的服务定义。服务可以由零个或多个Event（事件）、Method（方法）和Field（字段）的组合组成。

Event（事件）

提供数据，这些数据周期性地或在发生更改时从提供程序发送到订阅程序。
发送策略：

  • cyclic update 周期发送
    例，每过50ms发送一次信息。
  • update on change 有变化时发送
    例，当车门状态由开启变为关闭时，发送信息。
  • epsilon change 变化超过阈值时发送
    例，当预测值和当前值之间的差大于阈值时，才发送更新

在这里插入图片描述

Method（方法）

为订阅者提供了发出在提供者端执行的远程过程调用的可能性。

  • RR Method（Request/Response）
    请求/相应方法，即Clinet客户端发送请求给Server，Server受到请求后，再给Client恢复响应。属于同步调用
    在这里插入图片描述

  • F&F Method （Fire/Forget）
    发射后不管，翻译过来听起来很奇怪吧。实际上Fire/Forget这个词汇最早是描述一种导弹制导方式。即在发射后不需要进一步的外部干预，例如目标照明或有线制导，并且可以在发射器不在目标视线内的情况下击中目标。在这里表示Client客户端只对Server服务器发送请求，无需响应。
    在这里插入图片描述

Field（字段）

以下三个字段中的一个或多个的组合：

  • Notifier 通知 ：将有关更改的数据从提供者发送到订阅者
  • Getter 获取：订阅者可以调用它来显式地向提供者查询值
  • Setter 设置：当订阅者想要改变提供者端的值时，可以调用它。

Field/Notifier与Event的区别：

Field/Notifier的发送策略和Event一致，区别在于当第一订阅成功时， Field/Notifier的Server服务端会主动发送一个字段值，此时Client客户端可以立即获得Field的初始值，不用等待事件触发。

SOME/IP的传输协议

SOME/IP支持两种传输协议：用户数据报协议（UDP）和传输控制协议（TCP）

TCP

TCP添加了额外的功能来实现可靠的通信。TCP不仅处理比特错误，还处理分段、丢失、重复、重新排序和网络拥塞。

UDP

UDP是一种非常精简的传输协议，只支持最重要的功能（多路复用和使用校验和进行错误检测）

在车辆内部，许多应用需要非常短的超时时间才能快速做出反应。使用UDP可以更好地满足这些要求，因为应用程序本身可以处理不太可能发生的错误。例如，在使用循环数据的情况下，最好的方法通常是等待下一次数据传输，而不是尝试修复上一次数据传输。UDP的主要缺点是它不处理分段。因此，只能传输较小的数据块。

使用规则：

  • 仅当需要传输非常大的数据块（> 1400 Mbps）并且在错误情况下没有硬延迟要求时，才使用TCP
  • 如果需要非常严格的延迟要求（<100 ms）以防止错误，则使用UDP
  • 如果需要传输非常大的数据块（> 1400 KB），并且存在错误情况下的硬延迟要求，则将UDP与SOME/IP-TP一起使用

SOME/IP的报文格式

SOME/IP由Header（报文头）和 Payload构成，其中协议头部里的字段是：
在这里插入图片描述

  • Message ID (Service ID/Method ID) [32 Bits]
    消息ID（服务ID/方法ID）[32位]
    报文唯一的标识符在这里插入图片描述

  • Length [32 Bits]
    长度[32位]
    Length字段后包括数据的长度

  • Request ID (Client ID/Session ID) [32 Bits]
    请求ID（客户端ID/会话ID）[32位]
    在这里插入图片描述
    Client ID：区分请求同一服务Service的不同客户端
    Session ID：同一客户端请求同一服务Service的次数
    在这里插入图片描述

  • Protocol Version [8Bits]
    协议版本[8位]

  • Interface Version [8 Bits]
    接口版本[8位]

  • Message Type [8 Bits]
    消息类型[8位]

值字段描述
0x00REQUEST期望有响应的请求
0x01REQUEST_NO_RETURN不期望有响应的请求
0x02NOTIFICATION不期望有响应的通知/事件回调请求
0x80RESPONSE响应信息
0x81ERROR错误响应
0x20TP_REQUEST期望有响应的TP请求
0x21TP_REQUEST_NO_RETURN不期望有响应的TP请求
0x21TP_NOTIFICATION通知/事件回调的TP请求
0xa0TP_RESPONSETP响应信息
0xa1TP_ERROR包含错误的TP响应
  • Return Code [8 Bits]
    返回代码[8位]
值字段描述
0x00E_OK未出现错误
0x01E_NOT_OK出现未知错误
0x02E_UNKNOWN_SERVICE请求的服务ID未知
0x03RESPE_UNKNOWN_METHODNSE请求的方法ID未知，服务ID已知
0x04E_NOT_READY服务ID和方法ID是已知的，应用程序未运行
0x05E_NOT_REACHABLE无法访问运行服务的系统（仅限内部错误代码）
0x06E_TIMEOUT发生超时（仅限内部错误代码）
0x07E_WRONG_PROTOCOL_VERSIONSOME/IP协议版本不匹配
0x08E_WRONG_INTERFACE_VERSION服务接口版本不匹配
0x09E_MALFORMED_MESSAGE反序列化错误
0x0aE_WRONG_MESSAGE_TYPE报文类型错误（例如，对于定义为REQUEST的方法，为REQUEST_NO_RETURN）
0x0bE_E2E_REPEATEDE2E重复计算错误
0x0cE_E2E_WRONG_SEQUENCEE2E序列化错误
0x0dE_E2E没有进一步指明E2E错误
0x0eE_E2E_NOT_AVAILABLEE2E不可用
0x0fE_E2E_NO_NEW_DATA没有E2E计算的新数据
0x10 -0x1fE_E2E_NO_NEW_DATA包含错误的TP响应
0xa1RESERVED保留用于一般的SOME/IP错误
0x20 -0x5ERESERVED保留服务和方法的特殊错误

带E2E通信保护的SOME/IP报文格式：
在这里插入图片描述
在返回代码之后增加了E2E报文头

序列化与反序列化

序列化是将数据结构等转换为可保持或传输的字节流格式的过程。
反序列化就是序列化的逆过程，它从存储或传输介质中读取数据，并重建对象的原始状态。

序列化的目的是为了保持传输数据的完整性和可传递性。通过网络发送到另一个接收端。

接口规范定义了PDU中所有参数的确切位置，并考虑了内存对齐。序列化过程不应尝试自动对齐参数，而应按照接口规范中指定的对齐方式进行对齐。

如下图 以含有5个成员的结构体为例子，其中红色部分为变长数组后的剩余字段的填充部分。而固定长度的数据元素后不能有填充。
在这里插入图片描述
在这里插入图片描述

基本数据类型的序列化

类型描述长度[bit]
boolean布尔值8
uint8无符号8位整数8
uint16无符号16位整数16
uint32无符号32位整数32
uint64无符号64位整数64
sint8有符号8位整数8
sint16有符号16位整数16
sint32有符号32位整数32
sint64有符号64位整数64
float32单精度浮点数32
float64双精度浮点数64

以uint32类型的数据0x12345678为例：

  • 大端字节序
    就是从高位->低位读 类比 人类读数法（如一千两百三十）
    32位数划分为4个字节
    低地址存高位数，高地址存低位数

    byte0byte1byte2byte3
    0x120x340x560x78

  • 小端字节序
    机器读数法 从低位->高位读
    低地址存低位数，高地址存高位数

    byte0byte1byte2byte3
    0x780x560x340x12

结构体的序列化

结构体成员按顺序序列化
在这里插入图片描述
也可增加8、16、32bit的Length Field长度字段表示结构体中数据元素的字节长度，此时结构体内所嵌套的结构体也需增加Length Field字段
在这里插入图片描述

字符串序列化

定长和变长字符串 都是以"\0"字符（0x00）结尾。
支持不同的Unicode编码UTF-8/UTF-16BE/UTF-16LE

定长字符串

序列化格式：BOM+数据+结束符

  • UTF-8
    以 前三个字节作为BOM（字节顺序标记），一个字节长度结尾（0x00）

     EFBBBF(UTF-8的BOM) E8BDA6(车) E8BDBD(载)  45(E) 54(T)  48(H） 0x00(结尾)

  • UTF-16BE（大端序） / UTF-16LE（小端序）
    以 前两个字节作为BOM，两个字节长度结尾（0x00 0x00）

     FEFF(UTF-16BE的BOM) 5E8F(序) 5217(列) 5316(化) 0041(A) 0042(B) 0043(C) 0x00 0x00(结尾)

图中红色部分为定长字符串 剩余未占用,用Padding填充。
在这里插入图片描述

变长字符串

在定长字符串的基础上，变长字符串在BOM前增加了Length Field长度字段，用来表示动态字符串的字节长度。

序列化格式：
Length Field（从BOM到\0的长度和）+BOM+数据+结束符
如下图所示表达了两个字符串的序列化数据：
第一个 字符串:

000A(表示实际字符串所占用字节长度10bytes) EFBBBF(utf-8的BOM)E6B5AA(浪) E8B4B9(费) 0x00(结尾)

第二个 字符串:

000A(表示实际字符串所占用字节长度10bytes) EFBBBF(utf-8的BOM) 62(b) 61(a) 64(d) 67(g)75(u)79(y) 0x00(结尾)

在这里插入图片描述

字符编码BOM
UTF-8EF BB BF
UTF-16BEFE FF
UTF-16LEFF FE
UTF-32BE00 00 FE FF
UTF-32LEFF FE 00 00

为什么 utf8没有字节序，utf16、utf32有字节序

数组序列化

定长数组序列化
一维定长数组

LengthField（长度字段，可选）+每个数组元素按顺序序列化…
在这里插入图片描述

多维定长数组

LengthField（所有数据的总长度，可选）+按照第一维度的顺序对第二维度数组进行序列化…

eg. uint8 arr[2][4] //未配置长度字段

arr[0][0]  arr[0][1] arr[0][2] arr[0][3] //每个元素占一个字节长度
arr[1][0]  arr[1][1] arr[1][2] arr[1][3]

在这里插入图片描述

变长数组序列化
一维变长数组

LengthField(长度字段,必须配置)+每个数组元素按顺序序列化…
在这里插入图片描述

多维变长数组

LengthField（长度字段，必须配置）+按照第一维度的顺序对第二维度数组进行序列化…

eg. uint8 arr[2][4] //配置32位的长度字段(占四个字节长度)

length_field_all = 0x00000010(总长度为16字节) 
length_field1 = 0x00000004(第二维第一个元素长度4个字节)
arr[0][0]  arr[0][1] arr[0][2] arr[0][3] //每个元素占一个字节长度
length_field2 = 0x00000004(第二维第二个元素长度4个字节)
arr[1][0]  arr[1][1] arr[1][2] arr[1][3]

在这里插入图片描述

SOME/IP-SD (服务发现/订阅)

SOME/IP-SD报文格式

SOME/IP-SD是基于SOME/IP的报文,主要用于 服务的发现寻址并检测服务实例是否正在运行 以及 发布/订阅 ，通过UDP进行传输，在SOME/IP报头的基础下增加了部分内容，报文格式如下：
在这里插入图片描述

#固定值
Service ID: 0xFFFF
Method ID: 0x8100
Length: 32 bit
Client ID: 0x0000
Session ID: 0x0001~0xFFFF (记录会话次数，每次根据用例的发送次数递增)
Protocol Version: 0x01
Interface Version: 0x01
Message Tyoe: 0x02 (通知)
Return Code: 0x00 (E_OK)

在SOME/IP报头的基础下增加了部分内容：

  • Flags [8 bit] 标识字段
    最高位reboot flag表示重启状态，若为1表示正在重启中，0表示未重启或Session ID完成1～0xFFFF的循环之后此时置0。
//检测重启逻辑
if old.reboot == 0 and new.reboot ==1 then 检测到重启
if old.reboot == 1 and new.reboot ==1 and old.session_id > new.session_id 检测到重启

第二高位unicast flag表示单播标志，若为1表示支持单播，0表示不支持单播
其余为固定为0
eg：1100 0000 （表示正在重启中且支持单播）

  • Reserved [24 bit] 保留字段
    预留字段，所有位固定为0

  • Length of Entries Array[32 bit] 入口数组的长度

  • Entries Array 入口数组
    有两类 Service Entry和Eventgroup Entry

    1.Service Entry
    针对服务寻址类型报文
    在这里插入图片描述

名称位 bit描述
Type Field8用来区分服务寻址的不同场景。
0x00 表示 FindService（发现服务）
0x01 表示 OfferService / StopOfferService（提供/停止提供服务）
Index 1st options8表示第一个option的索引值
Index 2st options8表示第二个option的索引值
#of opt14表示第一个option的条目数
#of opt24表示第二个option的条目数
Service ID16标识服务ID。如果是Server端 则通过SdServerServerID配置；如果是Client端 则通过SdClientServerID配置
Instance ID16实例ID，区分同一服务的不同实例。如果指的是服务的所有服务实例，则将其设置为0xFFFF
Major Version8主要版本
TTL24Entry的生命周期，单位s（秒)
当TTL>0&&Type_Field == 0时，为FindService
当TTL>0&&Type_Field ==1时，为OfferService
当TTL == 0&&Type_Field ==1时，为StopOfferService
Minor Version32次要版本

  2.Eventgroup Entry
  针对事件订阅类报文   在这里插入图片描述

名称位 bit描述
Type Field8用来区分服务订阅的不同场景。
0x06 表示 SubscribeEventgroup / StopSubscribeEventgroup（订阅/停止订阅事件组）
0x07 表示 SubscribeAckEventgroup / SubscribeEventgroupNack（订阅事件组成功/失败响应）
Index 1st options8表示第一个option的索引值
Index 2st options8表示第二个option的索引值
#of opt14表示第一个option的条目数
#of opt24表示第二个option的条目数
Service ID16标识服务ID。如果是Server端 则通过SdServerServerID配置；如果是Client端 则通过SdClientServerID配置
Instance ID16实例ID，区分同一服务的不同实例。对于任何实例，服务实例ID不得设置为0xFFFF。
Major Version8主要版本
TTL24Entry的生命周期，单位s（秒)
当TTL > 0 && Type_Field == 6时，为SubscribeEventgroup
当TTL > 0 && Type_Field ==7时，为SubscribeAckEventgroup
当TTL == 0 && Type_Field ==6时，为StopSubscribeEventgroup
当TTL == 0 && Type_Field ==7时，为SubscribeEventgroupNack
Reserved12保留位
Counter4对不同客户端订阅同一事件组的计数
Eventgroup ID16事件组ID，表示需要订阅的事件组标识符

  • Length of Options Array[32 bit] 选项数组的长度

  • Options Array 选项数组
    Option是Entry的附加信息（例如IP地址、传输协议、端口号）
    主要包含以下几种类型：
    1.Endpoint Option 端点选项
    由SOME/IP-SD实例用于向相关端点发送信号。端点包括本地IP地址、传输层协议（例如UDP或TCP）和发送方的端口号。这些端口也用于事件和通知事件。
    IPv4端点选项
    在这里插入图片描述
      -Length [16bit] 长度字段
      设置为0x0009
     - Type [8bit] 类型
      设置为0x04
     - Disc. Flag [1bit] 可丢弃标志
      设置为0
     - Reserved [7bit] 保留位
      设置为0x00
     - IPv4-Address [32bit] IPv4地址
      应将单播IP地址作为4bytes传输
     - Reserved [8bit] 保留位
      设置为0x00
     - Transport Protocol (L4-Proto)[8bit] L4传输层协议
      0x06为TCP，0x11为UDP
     - Port Number [16bit] 端口号
      第4层协议的端口

    IPv6端点选项
    在这里插入图片描述
     - Length [16bit] 长度字段
      设置为0x0015
     - Type [8bit] 类型
      设置为0x06
     - Disc. Flag [1bit] 可丢弃标志
      设置为0
     - Reserved [7bit] 保留位
      设置为0x00
     - IPv6-Address [128bit] IPv6地址
      应将单播IP地址作为16bytes传输
     - Reserved [8bit] 保留位
      设置为0x00
     - Transport Protocol (L4-Proto)[8bit] L4传输层协议
      0x06为TCP，0x11为UDP
     - Port Number [16bit] 端口号
      应设置为传输层端口（例如30490）。

    2.Multicast Option 多播选项
    由服务器服务（服务器服务多播端点）或客户端服务（客户端服务多播端点）传输：
    是由服务器/客户端服务发送,服务器/客户端指示IPv4多播地址、传输层协议（ISO/OSI第4层）和端口号，在Server端中多播事件和多播通知事件被发送到这些地址,在Client端接收多播事件和多播通知事件。
    IPv4多播选项
    在这里插入图片描述
     - Length [16bit] 长度字段
      设置为0x0009
     - Type [8bit] 类型
      设置为0x14
     - Disc. Flag [1bit] 可丢弃标志
      设置为0
     - Reserved [7bit] 保留位
      设置为0x00
     - IPv4-Address [32bit] IPv4地址
      应将单播IP地址作为4bytes传输
     - Reserved [8bit] 保留位
      设置为0x00
     - Transport Protocol (L4-Proto)[8bit] L4传输层协议
      0x11为UDP
     - Port Number [16bit] 端口号
      第4层协议的端口
    IPv6多播选项
    在这里插入图片描述  - Length [16bit] 长度字段
      设置为0x0015
     - Type [8bit] 类型
      设置为0x16
     - Disc. Flag [1bit] 可丢弃标志
      设置为0
     - Reserved [7bit] 保留位
      设置为0x00
     - IPv6-Address [128bit] IPv6地址
      应将单播IP地址作为16bytes传输
     - Reserved [8bit] 保留位
      设置为0x00
     - Transport Protocol (L4-Proto)[8bit] L4传输层协议
      0x11为UDP
     - Port Number [16bit] 端口号
      应设置为传输层端口。

    3.Configuration Option 配置选项
    用于传输任意配置字符串。如服务名称或其配置。在这里插入图片描述
     - Length [16bit] 长度字段
      配置Option占用的总字节数不包括（Length和Type的长度）
     - Type [8bit] 类型
      设置为0x01
     - Disc. Flag [1bit] 可丢弃标志
      若设置为丢弃Option，应为1
     - Reserved [7bit] 保留位
      设置为0x00
     - Configuration String [dyn length] 配置字符串
      所携带的配置字符串信息

    4.Load Balancing Option 负载均衡选项
    用于区分服务的不同实例的优先级，以便客户端根据这些设置选择服务实例。
    在这里插入图片描述 - Length [16bit] 长度字段
      设置为0x0005
     - Type [8bit] 类型
      设置为0x02
     - Disc. Flag [1bit] 可丢弃标志
      若设置为丢弃Option，应为1
     - Reserved [7bit] 保留位
      设置为0x00
     - Priority [16bit] 优先级
      携带此实例的优先级。值越低，优先级越高。
     - Weight [16bit] 权重
      携带此实例的权重。值越大，被选中概率越高。

以下为不同类型的Entry允许携带的Option类型及个数关系表：

例如，FindService 可以最多可以携带一条Configuration Option，一条Load Balancing Option。

EndpointMulticastConfigurationLoad Balancing
FindService000-10-1
OfferService1-200-10-1
StopOffer Service1-200-10-1
Subscribe Eventgroup0-20-10-10-1
StopSubscribe Eventgroup0-20-10-10-1
Subscribe EventgroupAck00-10-10-1
Subscribe EventgroupNack000-10-1
SOMEIP协议--第二节[SOME/SD](SD概述与SD行为)
qq_41816308的博客
07-22 7481
服务发现（简称SD)，主要有两个作用:1、实现服务发布和订阅行为2、管理某个服务实例(包括服务端和客户端）是否需要运行或者是否能够发送报文可以分为2个大状态: Down状态和Ready;而Ready又由3个子状态构成。所以也可以分为4个小状态: Down Phase，（服务下线阶段)，Initial Wait Phase(初始等待阶段)，Repettion Phase(重复阶段)和Main Phase(主阶段)。Ready状态里的所有子状态内都会含有一个计时器，大多数情况会定时进入下一个阶段。
详解SOME/IP-SD协议文档-翻译版
jasonj333
01-26 5813
1 介绍和概述 这份协议规范规定了协议SOME/IP Service Discovery (SOME/IP-SD)的格式、消息序列和语义 服务发现协议的主要任务是在车载通信中传达功能实体（也就是服务）的可用性，以及控制事件消息的发送行为。这允许只发送事件消息给那些需要它们的接收者（发布/订阅），此处描述的解决方案也称为SOME/IP-SD（基于IP的可扩展的面向服务的中间件-服务发现） 可以看出，SOME/IP-SD有两个功能： 应用程序之间传达自己的服务或获取对方的服务是否可用 向其他应用程序订阅服务
SOME/IP SD 协议介绍(二) SOME/IP-SD消息格式
Xuesengxinyi的博客
01-30 2128
服务发现消息应通过UDP进行支持。准备将服务发现消息传输到TCP中以供将来使用情况。服务发现消息应以SOME/IP头开始，如图1所示：• 服务发现消息应使用0xFFFF的Service-ID（16位）。• 服务发现消息应使用0x8100的Method-ID（16位）。• 服务发现消息应使用SOME/IP指定的uint32长度字段。这意味着长度以字节为单位，并从长度字段后的第一个字节开始，直到SOME/IP-SD消息的最后一个字节结束。
通信易懂唠唠SOME/IP——SOME/IP-SD报文格式
sinat_41928334的博客
02-04 1741
• Locate service instances.确定服务的位置• Detect if service instances are running.检测服务实例是否在运行• Implement the Publish/Subscribe handling.实现发布和订阅的处理服务发现的主要作用，是确认服务的可用性且控制发送event消息的行为。
SOMEIP SD介绍
酒无忧的博客
06-08 2832
SD（Service Discovery）属于SOME/IP协议中非常核心的内容，主要提供检测和提供可用服务的功能。SD的优点如下：SD通信主要涉及到3类报文：Find Service、Offer Service和Subscribe报文。服务端和客户端的通信行为包含以下几个阶段：在这个阶段，Service是不可用的，即服务端无法提供服务。当服务准备完毕(Available)后，进入此阶段；如果此阶段收到Find Service报文，服务端忽略此消息，不做任何处理；如果服务不可用了，将返回进入Down Pha
车载以太网之SomeIP-SD协议
weixin_40172368的博客
01-26 7783
车载以太网SomeIP SD
SOME/IP-SD-status
sigent的博客
03-04 667
Timings and repetitions for Server Service and Event Handlers status When the Down Phase is entered (coming from states other than init), the API SoAd_CloseSoCon() shall be called for all Socket Con...
SOME/IP05- SOME/IP-SD 服务发现的需求和概述
02-21 2059
文章目录1 SOME/IP-SD所处协议栈中的位置2 SOME/IP-SD 用到的缩略语 传送门 ==>> AutoSAR实战系列300讲「糖果Autosar」总目录 1 SOME/IP-SD所处协议栈中的位置 如下图所示，SOME/IP-SD 依赖于 SOME/IP。SOME/IP 本身支持 TCP 和 UDP 通信，但 SOME/IP SD 限制只能通过 UDP 使用 SOME/IP 2 SOME/IP-SD 用到的缩略语 缩写/首字母缩略词： 描述： Method 方法、
通信易懂唠唠SOME/IP——SOME/IP 协议规范
最新发布
sinat_41928334的博客
02-04 1011
主要介绍SOME/IP协议中远程过程调用RPC,事件通知Event。
SOME/IP08- SOME/IP-SD 服务发现通信行的时序图和状态图
03-27 1388
文章目录1 SOME/IP Service发现的通信行为1.1 SOME/IP Service State Machine Server1.2 SOME/IP Service State Machine Client 传送门 ==>> AutoSAR实战系列300讲「糖果Autosar」总目录 1 SOME/IP Service发现的通信行为 客户端和服务器的SOME/IP SD的通信行为分为Down和Available，其中，在Available状态下，根据不同的通信行为表现，分为Initi
someip-sd报文
01-26
someip-sd报文
SOMEIP-SD协议翻译和解读_R20-11.pdf
08-17
SOME/IP-SD协议的翻译
车载通信架构 —— SOME/IP-SD 协议介绍
Soly_kun的博客
09-24 992
### 本文主要 ### -> 1、SOME/IP-SD 基本概述 ### -> 2、主要功能 ### -> 3、通信行为
SOME/IP-SD-Service
sigent的博客
03-03 955
Interaction of the AUTOSAR Service Discovery module The AUTOSAR Service Discovery module offers functionality to detect and offer available services – i.e. functional entities – within the vehicle ne...
SOME/IP-SD-Diagram
sigent的博客
03-06 1293
Publish/Subscribe with link loss at client (figure ignoring timings) Publish/Subscribe Registration/Deregistration behavior (figure ignoring timings) Publish/Subscribe with link loss at Server (figu...
SOMEIP协议--第三节[SOMEIP/SD]（SD格式）
qq_41816308的博客
07-22 866
Entry和Option是SD报文中最重要的内容，是服务发现功能的承载。7.Minor Version是指当前服务的小版本号，可以配置，用于给用户区分当前服务的版本用的。注意：stop offer，stop subscribe，Subscribe Nack 这三条的TTL一定设为0，唯一和offer，subscribe，Subscribe的区别。Option用来辅助Entry实现其功能，是Entry携带的附加信息，作用上一般是用来告诉对端自己业务的ip和port信息，方便对端通过ip和port发送报文。
SOME/IP SD 协议介绍(一）
Xuesengxinyi的博客
01-29 1451
SOME/IP RPC的术语和定义同样适用于SOME/IP-SD。请参见[第7页上的SIP_RPC_14]。意味着一个ECU实现了一个服务实例，并通过SOME/IP-SD告知其他ECU可以使用它。意味着向实现所需服务实例的ECU发送SOME/IP-SD消息，表示其他ECU需要此服务实例。即使服务实例尚未运行，也可以发送此消息。意味着向承载该服务实例的ECU发送一条SOME/IP-SD消息，表示不再需要该服务实例。本地ECU提供的服务实例的配置和所需数据应称为。
车载以太网之SOME/IP-SD专题篇
wto9109的博客
03-21 2596
前言 首先，请问大家几个小小问题，你清楚： 你知道什么是SOME/IP SD吗？ SOME/IP-SD报文是如何发送与接收的呢？ SOME/IP-SD 存在哪几种Entry Type呢？ SOME/IP-SD内部状态机转换又是如何？ 今天，我们就来一起探索并回答这些问题。为了便于大家理解，以下是本文的主题大纲： 正文 通过之前的文章<SOME/IP>我们了解到了SOME/IP协议的基本组成与SOME/IP的具体工作过程，同时也提到了SOME/IP-SD在SOME/IP协议中所扮演的重要角
SOME/IP-SD协议详解：智能座舱间的通信服务发现与安全策略
SOME/IP-SD协议翻译和解读文档详细介绍了AUTOSAR Platform for Remote Services (PRS) 的一个关键组件——SOME/IP Service Discovery Protocol (SD)，它是面向服务的中间件(SOA)的一部分，特别针对车载以太网环境...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值