SOMEIP报文格式部分字段概述（二）

最新推荐文章于 2025-06-16 14:49:51 发布

yhjc_sdn

最新推荐文章于 2025-06-16 14:49:51 发布

阅读量6.8k

点赞数 5

CC 4.0 BY-SA版权

本文链接：https://blog.youkuaiyun.com/yhjc_sdn/article/details/106033737

本文详细介绍了SOMEIP协议中Message ID的作用，它作为RPC调用的标识；Request ID如何区分相同Method的多个call，以及在AUTOSAR架构下的结构化要求；同时解析了Version字段和Message Type字段的不同含义，包括Request、Response、Error和Notification等消息类型。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

书非借而不能读也！
为了提高效率，现在参考了某网友的（忘记来源了）相关文章。

【SOMEIP报文格式部分字段概述】
头部字段
【Message ID】
Message ID是一个32位标识符，用于将RPC调用分派给应用程序的method并识别event 。 Message ID必须能唯一标识service的method或event。
Message ID的分配取决于用户; 然而，对于整个系统（即车辆），消息ID必须是唯一的。消息ID可以与CAN ID进行比较，并且应该使用类似的过程进行处理。

 为了构造不同的method， event和field ，它们被聚集到service中。 service具有一组method ， event和field以及services ID，该ID仅用于此service。
Service-ID应该是16位长度无符号整数（uint16）。  Service-ID=0xFFFE用来编码非SOME / IP服务。同一车辆内的不同服务应具有不同的Service-ID。
Method和event应在service内部使用16位Method ID来识别，对Event和notification来说，称为Event ID。

【Request ID】
Request ID允许客户端区分相同的Method的多个call 。 Request ID对于客户端和服务器的一个组合来说，需要时唯一的。在生成响应消息时，服务器必须将请求中的Request ID复制到response消息中。这允许客户将响应映射到发出的请求，即使有多个请求未完成。
只要响应已经接收到或者不再期望这个响应（超时），就可以重新使用Request ID。在汽车使用案例中，只有很少数量的未完成的请求在被继续等待。小型系统里在没有并行请求的可能性的情况下， Request ID可能总是设置为相同的值。
在AUTOSAR 架构下, Request ID需要