CANoe_CAPL脚本实现SOME/IP报文收发（一）_canoe someip

学习是个漫长且痛苦的过程，道路艰辛而曲折，希望我们都在时代的长河中做一颗闪闪发光的尘埃。只有持之以恒才能有所成就    ——Tom

目录

前言

初识SOME/IP

1. 分层定位（基于OSI模型）

2. 关键特性与分层功能

3. 协议栈封装流程

SOME/IP协议

一，服务说明

二， Method

三， Event

四， Field

前言

哈喽，好久不见，Tom又来了。。。

最近不少粉丝私信说公司有以太网SOME/IP需求，想问如何通过CANoe脚本实现SOME/IP报文的手法。

今天Tom出一期文章详细讲解一下如何SOME/IP实现。

初识SOME/IP

首先我们需要知道什么是SOME/IP，它是在以太网七层协议种属于哪一层？

SOME/IP的全称是“Scalable service-Oriented MiddlewarE over IP”，即“可扩展的面向服务的IP中间件”‌

SOME/IP是由AUTOSAR发布的，主要用于自动/嵌入式通信。它支持远程过程调用、事件通知和底层序列化/线格式等功能。SOME/IP位于OSI7层模型的第4层之上，当接收方有需求时才发送数据，从而降低总线的负载‌13。

1. 分层定位（基于OSI模型）

在OSI七层模型中，SOME/IP的定位如下：

• 应用层（Application Layer，第7层）：
  SOME/IP直接运行在TCP或UDP之上，定义了服务的接口、通信模式（如请求/响应、发布/订阅）和服务发现（SOME/IP-SD）等高层逻辑，属于典型的应用层协议。

• 传输层（Transport Layer，第4层）：
  依赖TCP或UDP协议实现端到端的数据传输（如可靠传输用TCP，低延迟用UDP）。

• 网络层（Network Layer，第3层）：
  基于IP协议（IPv4/IPv6）实现跨网络的寻址和路由。

• 数据链路层（Data Link Layer，第2层）：
  通过以太网（Ethernet）、CAN FD、FlexRay等物理媒介传输数据帧。SOME/IP本身不直接涉及这一层，但最终数据会封装到以太网帧中。

2. 关键特性与分层功能

• 服务化通信（应用层核心功能）：
  SOME/IP支持面向服务的架构（SOA），允许ECU（电子控制单元）动态发布、发现和使用服务（如传感器数据、控制指令）。

• 序列化与反序列化（表示层功能）：
  虽然OSI模型中序列化属于表示层（第6层），但在TCP/IP模型中通常被合并到应用层，SOME/IP直接处理数据的序列化。

• 服务发现（SOME/IP-SD）：
  通过组播（Multicast）实现服务的自动发现和注册，依赖UDP传输，属于应用层逻辑。

3. 协议栈封装流程

数据从SOME/IP到以太网的封装过程如下：

1. 应用层：SOME/SD-IP协议数据（服务请求/响应、服务发现报文）。

2. 传输层：添加TCP/UDP头部（端口号、校验和等）。

3. 网络层：添加IP头部（源/目的IP地址）。

4. 数据链路层：添加以太网头部（MAC地址）和CRC校验，形成以太网帧。

SOME/IP的关键特征包括：

• ‌序列化‌：数据在网络上的表示方式，确保不同系统间的数据传输一致性。
• ‌远程过程调用（RPC）‌：客户端ECU通过RPC请求服务器数据，RPC可以返回数据也可以不返回数据。
• ‌服务发现（SD）‌：管理服务的提供和停止，确保服务可被发现。
• ‌发布/订阅（Pub/Sub）‌：客户端可以订阅服务器内容，动态接收更新数据‌

如果不了解以太网七层协议的看上面的一些介绍可能有点懵。接下来我会用白话将SOME/IP描述成大家都能看懂。

SOME/IP协议

一，服务说明

服务是SOME/IP的最核心概念。在一个服务中，定义了Server和Client两个角色：Server提供服务，Client调用服务。对于同一个服务，只能存在一个Server，但可以同时存在多个Client调用服务。一个Service由0~多个Event/Method/Field组成。与CAN相比，面向服务的通讯方式能够大大降低总线的负载率

二， Method

调用或引用一个进程/函数/子程序，通常由Client发起，并由Server答复。Request是最常见的一种Method，由Client向Server请求数据；Response是Request的结果，由Server答复Client的Request。而Method Fire & Forget方式，只Client向Server发起，但Server对该请求不回复.

三， Event

一个单向的数据传输，只能是on change类型，用于Server主动向订阅（Subscribe）了相关服务的Client发布（Publish）信息。

四， Field

由以下三项内容构成：

• Notifier：通知，Server的Client订阅了服务后第一时间主动向其发送数据。
• Getter：获取，由Client向Server请求数据。
• Setter：设置，由Client修改Server的数据。

Method方式是通过远程过程调用RPC进行发送Request请求。此种方式不需要订阅，前提条件是SD参数要对齐。

method分为两种形式：  R/R    和   F/F

R/R:   Request/Response      一发一收（例如UDS协议，发送1002服务，需要回5002）

F/F:    Request        一发不收      此种方式仅远程调用不要求DUT回复（例如UDS中1082服务）

Event事件方式是通过Client端订阅了Server服务端的服务后，Server一旦触发事件的发生，那么会向订阅了服务的Client端发送事件。这种方式需要SD报文进行订阅流程。

例如：毫米波雷达提供了一种服务，ADAS系统作为Client端需要订阅雷达传回的一些信息，那么ADAS系统需要去订阅雷达的服务，订阅成功后，一旦雷达探测到前方有障碍物之类的东西，那么雷达就主动向ADAS系统传回事件。ADAS系统接收到有障碍物的信息后就会进行一系列的减速，刹车等操作。

最后一个Field方式

Field方式分为三种：

Notifier：此种方式需要订阅，订阅成功后，立马向Client端发送数据

Getter：此种方式与Method方式类似，是一发一收的操作，区别是，Getter方式用于获取server的一些配置，例如底盘系统的悬架的高低是多少？发送一次Getter请求，返回当前悬架的高低档位

Setter：此种方式与Method也类似，也是一发一收的操作，区别是，Setter方式用于设置Server的一些配置，例如我需要设置底盘的高低档位是第3档，那么发送一次Setter请求，返回设置成功的参数。

以上为SOME/IP协议层的一些东西，下一版将讲述一下SOME/IP在CANoe内需要怎么发送报文，以及怎么通过CAPL脚本发送报文，通过Trace窗口分析SOME/IP报文，敬请关注

别忘了一键三连~~~~~~~~