当前位置：首页 > news >正文

SOME/IP--协议英文原文讲解11

news 来源：原创 2025/9/17 1:33:50

前言

SOME/IP协议越来越多的用于汽车电子行业中，关于协议详细完全的中文资料却没有，所以我将结合工作经验并对照英文原版协议做一系列的文章。基本分三大块：

1. SOME/IP协议讲解

2. SOME/IP-SD协议讲解

3. python/C++举例调试讲解

4.2.6 Error Handling

Error handling can be done in the application or the communication layer below. Therefore SOME/IP supports two different mechanisms:
• Return Codes in the Response Messages of methods
• Explicit Error Messages
SOME/IP 在两种情况发送错误消息
1. method 的响应消息
消息类型是0x80 , ReturnCode 设置错误码
2. 显式的直接发送错误码
消息类型是0x81， ReturnCode 设置错误码 payload中携带更多的错误信息
可以任选其一
或者两种都用

Which one of both is used, depends on the configuration.
[PRS_SOMEIP_00901]
Upstream requirements: RS_SOMEIP_00008
Return Codes in the RESPONSE Messages (Message Type 0x80) of methods shall
be used to transport application errors and the response data of a method from the
provider to the caller of a method. Message Type RESPONSE 0x80 shall be used
in cases where no additional/extended error information (apart from the error code
encoded in the Return Code field) needs to be propagated to the caller.
Note:
Please be aware that return codes of the Request and Response methods are not
treated as errors from the point of view of SOME/IP. This means that the message type
is still 0x80 if a request/response method exits with a return code not equal to 0x00
(message type is still 0x80 if ApplicationError of AUTOSAR ClientServerOperation is
different from E_OK).
method response的消息类型是0x80(非错误消息）
站在SOMEIP的角度 returnCode 中的错误码不是真正的错误消息，只是应用程序处理的非OK的结果。

[PRS_SOMEIP_00902]
Upstream requirements: RS_SOMEIP_00008
Explicit Error Messages shall be used to transport application errors and the response
data or generic SOME/IP errors from the provider to the caller of a method.
[PRS_SOMEIP_00903] 0x81消息类型的使用作用
Upstream requirements: RS_SOMEIP_00008
If more detailed error information (apart from an error code encoded in the Return
Code field) needs to be propagated to the caller, an ERROR message (Message type
0x81) shall be used. The payload of the Error Message shall be filled with serialized
error specific data, e.g. an exception string, or other error information. This additional
error information shall be modeled in the interface description, or defined by the standard.
This can be used to handle all different application errors that might occur in the server.
In addition, problems with the communication medium or intermediate components
(e.g. switches) may occur, which have to be handled e.g. by means of reliable transport.
All messages have a return code field in their header. (See chapter 4.1.2)
这段内容（[PRS_SOMEIP_00903]）描述了 **SOME/IP 协议** 中 **0x81 消息类型（ERROR 消息）** 的使用场景和作用。以下是详细解释：

---

### 核心作用
1. **传播详细的错误信息**：
- 当需要向调用方传递比 **Return Code** 字段更详细的错误信息时，应使用 **ERROR 消息（消息类型 0x81）**。
- ERROR 消息的有效载荷（payload）可以包含序列化的错误特定数据，例如异常字符串或其他错误信息。

2. **错误信息的标准化**：
- 额外的错误信息应在接口描述中建模，或由标准定义。
- 这确保了错误信息的格式和内容在不同实现之间保持一致。

3. **应用错误的处理**：
- ERROR 消息可用于处理服务器中可能发生的所有不同类型的应用错误。

4. **通信问题的处理**：
- 除了应用错误外，通信介质或中间组件（如交换机）的问题也可能发生。
- 这些问题可以通过可靠的传输机制（如 TCP）来处理。

---

### 关键点
1. **ERROR 消息的结构**：
- ERROR 消息的消息类型为 **0x81**。
- 消息头中包含 **Return Code** 字段，用于指示错误的基本类型。
- 消息的有效载荷可以包含详细的错误信息，例如异常字符串或其他数据。

2. **Return Code 字段**：
- 所有 SOME/IP 消息的头部都包含一个 Return Code 字段，用于指示操作的结果（成功或失败）。
- 如果 Return Code 字段不足以描述错误，则需要使用 ERROR 消息传递更多信息。

3. **错误信息的序列化**：
- 错误信息需要以序列化的形式填充到 ERROR 消息的有效载荷中。
- 序列化格式应在接口描述或标准中定义。

4. **接口描述的作用**：
- 接口描述文件应定义可能的错误类型及其对应的错误信息格式。
- 这确保了客户端和服务器对错误信息的解析和处理是一致的。

---

### 使用场景
1. **服务器内部错误**：
- 例如，服务器在处理请求时发生异常，需要将详细的错误信息（如异常堆栈）传递给客户端。

2. **通信问题**：
- 例如，网络中断或交换机故障导致消息无法传递，需要通知客户端。

3. **自定义错误信息**：
- 例如，服务器可以返回自定义的错误描述，帮助客户端更好地理解问题。

---

### 示例
假设一个 SOME/IP 服务器在处理请求时发生了一个应用错误，错误代码为 `0x80`（表示通用错误），同时需要传递详细的错误信息。

#### ERROR 消息的结构：
- **消息类型**：0x81（ERROR 消息）
- **Return Code**：0x80（通用错误）
- **有效载荷**：序列化的错误信息，例如：
```json
{
"errorCode": 1001,
"errorMessage": "Invalid input parameter",
"details": "Parameter 'value' must be between 0 and 100"
}
```

#### 客户端处理：
- 客户端接收到 ERROR 消息后，解析 Return Code 和有效载荷，显示详细的错误信息给用户或记录日志。

---

### 总结
[PRS_SOMEIP_00903] 规定了 SOME/IP 中 **ERROR 消息（0x81）** 的使用场景和作用：
1. 用于传递比 Return Code 更详细的错误信息。
2. 错误信息应以序列化的形式填充到有效载荷中，并在接口描述或标准中定义。
3. 适用于处理服务器内部错误、通信问题以及自定义错误信息。

[PRS_SOMEIP_00904]
Upstream requirements: RS_SOMEIP_00008
Only responses (Response Messages (message type 0x80) and Error Messages
(message type 0x81) shall use the return code field to carry a return code to the request
(Message Type 0x00) they answer.
Message Type 0x00 的响应消息类型只有0x80 和 0x81 ,并且只有这两种类型消息使用returnCode携带错误吗
[PRS_SOMEIP_00905]
Upstream requirements: RS_SOMEIP_00008
All other messages than 0x80 and 0x81 shall set this field to 0x00.
For message type see Chapter 4.1.2.7.
除了0x80 0x81的消息类型 returnCode的值要设置为 0x00

ReturnCode的编程类型应该为 uint8_t类型。

错误码的生成和处理没有指定，客户可根据自己的情况编程处理。

[PRS_SOMEIP_00539]
Upstream requirements: RS_SOMEIP_00008
A SOME/IP error message (i.e. return code 0x01 - 0x1f) shall not be answered with
an error message.

当一个 SOME/IP 错误消息被接收时，不应再以错误消息进行响应。
换句话说，错误消息不应触发进一步的错误消息
该规则的目的是避免错误消息的无限循环

4.2.6.2 Error Message
For more flexible error handling, SOME/IP allows a different message layout specific
for Error Messages instead of using the message layout of Response Messages.
The recommended layout for the exception message is the following:
• Union of specific exceptions. At least a generic exception without fields needs to
exist.
• Dynamic Length String for exception description.
Rationale: The union gives the flexibility to add new exceptions in the future in a typesafe manner. The string is used to transport human readable exception descriptions to
ease testing and debugging.
这段内容描述了 **SOME/IP 协议** 中 **错误消息（Error Message）** 的灵活布局设计，特别是为了支持更灵活的错误处理。以下是详细解释：

---

### 核心设计
1. **错误消息的布局**：
- SOME/IP 允许错误消息使用不同于响应消息（Response Message）的布局。
- 这种设计使得错误消息可以包含更丰富的错误信息，而不仅仅是 Return Code。

2. **推荐的错误消息布局**：
- **特定异常的联合体（Union of specific exceptions）**：
- 至少需要包含一个没有字段的通用异常（generic exception）。
- 联合体（Union）的设计允许在未来以类型安全的方式添加新的异常类型。
- **动态长度字符串（Dynamic Length String）**：
- 用于传输人类可读的异常描述，便于测试和调试。

---

### 关键点
1. **联合体（Union）的作用**：
- 联合体是一种数据结构，可以存储多种不同类型的值，但同一时间只能使用其中一种类型。
- 在错误消息中使用联合体，可以为不同的异常类型定义不同的字段，同时保持类型安全。
- 例如：
```c
union Exception {
GenericException generic;
InvalidParameterException invalidParam;
TimeoutException timeout;
// 其他异常类型
};
```

2. **通用异常（Generic Exception）**：
- 至少需要定义一个没有字段的通用异常，作为默认的异常类型。
- 例如：
```c
struct GenericException {
// 无字段
};
```

3. **动态长度字符串**：
- 用于传输人类可读的异常描述，例如错误消息或堆栈跟踪。
- 这种设计便于开发人员测试和调试系统。

4. **灵活性和可扩展性**：
- 联合体和动态长度字符串的设计使得错误消息可以灵活地适应未来的需求。
- 例如，可以轻松添加新的异常类型，而无需修改现有的消息布局。

---

### 示例布局
以下是一个错误消息的示例布局：
```c
struct ErrorMessage {
uint8_t returnCode; // Return Code (0x01 - 0x1F)
union Exception {
GenericException generic;
InvalidParameterException invalidParam;
TimeoutException timeout;
// 其他异常类型
} exception;
string description; // 动态长度字符串
};

struct GenericException {
// 无字段
};

struct InvalidParameterException {
string paramName; // 无效参数的名称
string expectedValue; // 期望的值
};

struct TimeoutException {
uint32_t timeoutDuration; // 超时时间（毫秒）
};
```

---

### 使用场景
1. **服务器返回错误消息**：
- 例如，客户端发送请求时提供了无效参数，服务器返回错误消息：
- Return Code: `0x03`（无效参数）
- Exception: `InvalidParameterException`
- Description: `"Parameter 'value' must be between 0 and 100"`

2. **客户端处理错误消息**：
- 客户端接收到错误消息后，解析 Return Code、异常类型和描述，记录日志或显示给用户。

---

### 总结
SOME/IP 协议中的错误消息设计具有以下特点：
1. **灵活的布局**：使用联合体和动态长度字符串，支持多种异常类型和人类可读的描述。
2. **可扩展性**：通过联合体设计，可以轻松添加新的异常类型。
3. **便于测试和调试**：动态长度字符串提供了详细的错误信息，便于开发人员分析和解决问题。

这种设计使得 SOME/IP 协议能够更灵活地处理各种错误场景，并提供详细的错误信息，帮助开发人员快速定位和解决问题。

[PRS_SOMEIP_00188]
Upstream requirements: RS_SOMEIP_00008
The receiver of a SOME/IP message shall not return an error message for events/notifications.
事件和通知类消息不能回复错误码
[PRS_SOMEIP_00189]
Upstream requirements: RS_SOMEIP_00008
The receiver of a SOME/IP message shall not return an error message for fire&forget
methods.
F&F消息不能返回错误码
[PRS_SOMEIP_00537]
Upstream requirements: RS_SOMEIP_00008
The receiver of a SOME/IP message shall not return an error message for events/notifications and fire&forget methods if the Message Type is set incorrectly to Request or
Response.
通过消息ID辨识出来消息是事件、通知、F&F 时，但是MessageType是错误的，这用情况也不用回复错误码
[PRS_SOMEIP_00190]
Upstream requirements: RS_SOMEIP_00008
For Request/Response methods the error message shall copy over the fields of the
SOME/IP header (i.e. Message ID, Request ID, and Interface Version) but not the
payload. In addition Message Type and Return Code have to be set to the appropriate
values.
错误回复消息的 header要和请求保持一致拷贝过来，不过其中的MessageType和ReturnCode要设置为自己需要的。

4.2.6.3 Error Processing Overview
[PRS_SOMEIP_00576]
Upstream requirements: RS_SOMEIP_00008, RS_SOMEIP_00014
Error handling shall be based on the message type received (e.g. only methods
can be answered with a return code) and shall be checked in a defined order of
[PRS_SOMEIP_00195].
这条上面讲了
[PRS_SOMEIP_00910]
Upstream requirements: RS_SOMEIP_00008, RS_SOMEIP_00014
UDP报文的检查
For SOME/IP messages received over UDP, the following shall be checked:
• The UDP datagram size shall be at least 16 Bytes (minimum size of a SOME/IP
message) 最少16个字节
• The value of the length field shall be less than or equal to the remaining bytes in
the UDP datagram payload 长度域描述的字节数要少于或等于后面的字节数
If one check fails, a malformed error shall be issued.
[PRS_SOMEIP_00195]
Upstream requirements: RS_SOMEIP_00008, RS_SOMEIP_00014
SOME/IP messages shall be checked by error processing. This does not include the
application based error handling but just covers the error handling in messaging and
RPC.
An overview of the error processing is shown in Figure 4.12.

下图中表示了常见RPC错误码的检查场景。

[PRS_SOMEIP_00614]
Upstream requirements: RS_SOMEIP_00008, RS_SOMEIP_00014
When one of the errors specified in [PRS_SOMEIP_00195] occurs while receiving
SOME/IP messages over TCP, the receiver shall check the TCP connection and shall
restart the TCP connection if needed.
当发生上面流程图中的错误时，如果是TCP报文，则需要检查TCP连接是否正常，因为有可能TCP连接异常会导致那些错误。
Rational:
用下面方法检查TCP连接
Checking the TCP connection might include the following:
• Checking whether data is received for e.g. other Eventgroups.
如果收到同一个TCP连接上的其他正常数据包说明连接正常
• Sending out a Magic Cookie message and waiting for the TCP ACK.
发送魔术Cookie包等待TCP回复。
• Reestablishing the TCP connection
重置TCP连接

4.2.6.4 Communication Errors and Handling of Communication Errors
When considering the transport of RPC messages different reliability semantics exist:
• Maybe — the message might reach the communication partner
• At least once — the message reaches the communication partner at least once
• Exactly once — the message reaches the communication partner exactly once
When using the above terms, in regard to Request/Response the term applies to both
messages (i.e. request and response or error).
While different implementations may implement different approaches, SOME/IP currently achieves "maybe" reliability when using the UDP binding and "exactly once" reliability when using the TCP binding. Further error handling is left to the application.
For "maybe" reliability, only a single timeout is needed, when using request/response
communication in combination of UDP as transport protocol. Figure 4.13 shows the
state machines for "maybe" reliability. The client’s SOME/IP implementation has to
wait for the response for a specified timeout. If the timeout occurs SOME/IP shall
signal E_TIMEOUT to the client application.
这段内容（4.2.6.4）讨论了 **SOME/IP 协议** 中 **RPC 消息传输的可靠性语义** 以及 **通信错误的处理**。以下是详细解释：

---

### 核心内容
1. **可靠性语义**：
- 在传输 RPC 消息时，存在以下三种可靠性语义：
- **Maybe（可能到达）**：消息可能会到达通信对方。
- **At least once（至少一次）**：消息至少会到达通信对方一次。
- **Exactly once（恰好一次）**：消息恰好会到达通信对方一次。
- 对于 Request/Response 通信，这些语义适用于请求和响应（或错误）消息。

2. **SOME/IP 的可靠性实现**：
- 使用 **UDP 绑定** 时，SOME/IP 实现的是 **"maybe" 可靠性**。
- 使用 **TCP 绑定** 时，SOME/IP 实现的是 **"exactly once" 可靠性**。
- 进一步的错误处理由应用程序负责。

3. **"Maybe" 可靠性的超时处理**：
- 当使用 UDP 作为传输协议时，只需要一个超时机制来处理请求/响应通信。
- 如果超时发生，SOME/IP 实现应向客户端应用程序发送 `E_TIMEOUT` 错误。

---

### 关键点
1. **UDP 绑定的可靠性**：
- UDP 是无连接的协议，不保证消息的可靠传输。
- 因此，使用 UDP 绑定时，SOME/IP 只能实现 **"maybe" 可靠性**。
- 消息可能会丢失、重复或乱序到达。

2. **TCP 绑定的可靠性**：
- TCP 是面向连接的协议，提供可靠的消息传输。
- 因此，使用 TCP 绑定时，SOME/IP 可以实现 **"exactly once" 可靠性**。
- 消息不会丢失、重复或乱序到达。

3. **超时机制**：
- 在使用 UDP 绑定时，客户端需要设置一个超时时间，等待服务器的响应。
- 如果超时发生，客户端应通知应用程序，并返回 `E_TIMEOUT` 错误。

4. **状态机**：
- 图 4.13 展示了 **"maybe" 可靠性** 的状态机。
- 客户端的状态机包括以下状态：
- 等待请求发送。
- 等待响应。
- 超时处理。

---

### 实现建议
1. **UDP 绑定的实现**：
- 客户端发送请求后，启动一个超时计时器。
- 如果在超时时间内未收到响应，则触发 `E_TIMEOUT` 错误。
- 客户端可以选择重试请求或通知上层应用。

2. **TCP 绑定的实现**：
- 由于 TCP 提供可靠的传输，客户端不需要实现超时机制。
- 如果连接中断，TCP 会通知应用程序，SOME/IP 实现可以处理连接错误。

3. **错误处理**：
- 应用程序需要根据不同的可靠性语义实现适当的错误处理逻辑。
- 例如，在使用 UDP 绑定时，应用程序可能需要实现重试机制。

---

### 示例场景
#### 场景 1：UDP 绑定（"maybe" 可靠性）
- 客户端发送请求：`getData()`。
- 启动超时计时器（例如 1 秒）。
- 如果在 1 秒内未收到响应，客户端触发 `E_TIMEOUT` 错误。
- 客户端可以选择重试请求或通知上层应用。

#### 场景 2：TCP 绑定（"exactly once" 可靠性）
- 客户端发送请求：`calculate(5, 10)`。
- 服务器处理请求并返回响应：`result = 15`。
- 客户端接收到响应，确保消息不会丢失或重复。

---

### 总结
SOME/IP 协议支持不同的可靠性语义，具体取决于使用的传输协议：
1. **UDP 绑定**：实现 **"maybe" 可靠性**，需要超时机制处理请求/响应通信。
2. **TCP 绑定**：实现 **"exactly once" 可靠性**，提供可靠的消息传输。
3. **错误处理**：应用程序需要根据可靠性语义实现适当的错误处理逻辑。

根据文件内容，图 4.13 展示了 **SOME/IP 协议** 中 **"maybe" 可靠性** 的状态机。以下是详细解释：

---

### 状态机描述
#### 客户端状态机
1. **初始状态**：
- 客户端准备发送请求。

2. **发送请求（sendReq）**：
- 客户端发送请求消息，进入 **waitingForResponse** 状态。

3. **等待响应（waitingForResponse）**：
- 客户端等待服务器的响应。
- 如果接收到响应（rspReceived），则处理响应并结束。
- 如果超时（rspTimeout），则触发 **Error: NoResponse** 错误。

4. **错误处理（Error: NoResponse）**：
- 客户端通知应用程序请求超时，返回 `E_TIMEOUT` 错误。

#### 服务器状态机
1. **接收请求（reqReceived）**：
- 服务器接收到客户端的请求，进入 **processing** 状态。

2. **处理请求（processing）**：
- 服务器处理请求并生成响应。

3. **发送响应（sendRsp）**：
- 服务器发送响应消息，结束处理。

---

### 关键点
1. **"maybe" 可靠性**：
- 使用 UDP 绑定时，SOME/IP 实现的是 **"maybe" 可靠性**。
- 消息可能会丢失、重复或乱序到达。

2. **超时机制**：
- 客户端在发送请求后启动超时计时器。
- 如果超时发生，客户端触发 `E_TIMEOUT` 错误。

3. **状态转换**：
- 客户端的状态转换包括发送请求、等待响应和处理超时。
- 服务器的状态转换包括接收请求、处理请求和发送响应。

---

### 总结
图 4.13 展示了 SOME/IP 协议中 **"maybe" 可靠性** 的状态机，适用于使用 UDP 绑定的场景。客户端需要处理请求发送、响应接收和超时错误，而服务器需要处理请求接收、处理和响应发送。

对于 **"exactly once" 可靠性**，可以使用 TCP 绑定，因为 TCP 提供了可靠的消息传输。

0voice · GitHub

前言

4.2.6 Error Handling

相关文章：