前言
SOME/IP协议越来越多的用于汽车电子行业中，关于协议详细完全的中文资料却没有，所以我将结合工作经验并对照英文原版协议做一系列的文章。基本分三大块：
1. SOME/IP协议讲解
2. SOME/IP-SD协议讲解
3. python/C++举例调试讲解
5.1.4.5 SOME/IP-SD Mechanisms and Errors
In this section SOME/IP-SD in cases of errors (e.g. lost or corrupted packets) is discussed. This is also be understood as rationale for the mechanisms used and the
configuration possible.
Soft State Protocol: SOME/IP-SD was designed as soft state protocol, that means that
entries come with a lifetime and need to be refreshed to stay valid (setting the TTL to
the maximum value shall turn this off).
Initial Wait Phase:
The Initial Wait Phase was introduced for two reasons: deskewing events of starting
ECUs to avoid traffic bursts and allowing ECUs to collect multiple entries in SD messages.
Repetition Phase:
The Repetition Phase was introduced to allow for fast synchronization of clients and
servers. If the clients startup later, it will find the server very fast. And if the server
starts up later, the client can be found very fast. The Repetition Phase increases the
time between two messages exponentially to avoid that overload situations keep the
system from synchronization.
Main Phase:
In the Main Phase the SD tries to stabilize the state and thus decreases the rate of
packets by sending no Find Services anymore and only offers in the cyclic interval
(e.g. every 1s).
Request-Response-Delay:
SOME/IP-SD shall be configured to delay the answer to entries in multicast messages
by the Request-Response-Delay. This is useful in large systems with many ECUs.
When sending a SD message with many entries in it, a lot of answers from different
ECUs arrive at the same time and put large stress on the ECU receiving all these
answers.
以下是关于 **SOME/IP-SD 机制与错误处理** 的清晰梳理，结合您提供的技术文档内容进行结构化解析：
---
### **1. Soft State Protocol（软状态协议）**
- **核心机制**：
- 所有服务条目（Service Entries）均附带 **生存时间（TTL）**，需定期刷新以维持有效性。
- **例外**：若将 TTL 设为最大值，可禁用刷新机制（条目永久有效）。
- **设计目的**：
- 避免因节点异常退出导致无效条目残留，通过 TTL 自动清理无效状态。
---
### **2. Initial Wait Phase（初始等待阶段）**
- **触发条件**：ECU 启动时首次发送服务发现消息前的延迟阶段。
- **作用**：
1. **防流量突增**：分散同时启动的 ECU 的广播消息，避免网络拥塞。
2. **消息聚合**：允许 ECU 收集多个服务条目后合并发送，减少报文数量。
- **典型配置**：延迟时间随机化（如 0~500ms），避免同步化。
---
### **3. Repetition Phase（重复阶段）**
- **核心行为**：
- 服务提供者（Server）以**指数退避**方式重复广播服务可用性（Offer Service）。
- 初始间隔短（如 100ms），后续间隔逐步增大（如 200ms → 400ms → ...）。
- **设计目的**：
- **快速同步**：确保晚启动的 Client/Server 能快速发现对方。
- **防过载**：通过退避算法避免持续高频率广播导致网络压力。
---
### **4. Main Phase（主阶段）**
- **稳定状态行为**：
- 停止发送 **Find Service** 请求（仅由 Client 在初始阶段发送）。
- 仅以固定周期（如 1s）广播 **Offer Service** 维持状态。
- **优化目标**：降低网络负载，维持服务发现的稳定性。
---
### **5. Request-Response-Delay（请求-响应延迟）**
- **应用场景**：多 ECU 大型系统中，响应多播请求时的延迟应答机制。
- **工作原理**：
- 收到多播请求（如 Find Service）后，ECU 不立即响应，而是延迟随机时间（如 0~50ms）再回复。
- **优势**：避免大量 ECU 同时响应导致的**响应风暴**（减轻接收端负载）。
---
### **6. 错误处理机制**
- **丢包/包损坏**：
- 依赖周期性广播（Repetition/Main Phase）自然恢复，无需显式重传。
- Client 未收到响应时会重新发送 Find Service。
- **ECU 异常下线**：
- 因 TTL 机制，未刷新的服务条目会自动失效。
---
### **配置参数示例**
| 参数 | 典型值 | 作用 |
|-----------------------|-------------|-----------------------------|
| TTL（Offer Service） | 3s~10s | 控制服务条目有效期 |
| Initial Wait Delay | 0~500ms | 初始阶段随机延迟 |
| Repetition Base Delay | 100ms | 重复阶段的初始间隔 |
| Main Phase Interval | 1s | 主阶段的广播周期 |
| Request-Response-Delay| 0~50ms | 多播响应的随机延迟 |
---
5.1.4.6 Error Handling
-- 编程指导 建议
[PRS_SOMEIPSD_00125]
Upstream requirements: RS_SOMEIPSD_00019
Check that at least enough bytes for an empty SOME/IP-SD message are present,
i.e the message is at least 12 Bytes long. If the check fails, the message shall be
iscarded without further actions.
[PRS_SOMEIPSD_00126]
Upstream requirements: RS_SOMEIPSD_00019
If the Service ID of a received entry is not known and not a Subscribe Eventgroup
entry, the entry shall be ignored. Otherwise a Negative Acknowledgement shall be
returned according to [PRS_SOMEIPSD_00393].
[PRS_SOMEIPSD_00127]
Upstream requirements: RS_SOMEIPSD_00019
If the Instance ID of a received entry is not known and not a Subscribe Eventgroup
entry, the entry shall be ignored. Otherwise a Negative Acknowledgement shall be
returned according to [PRS_SOMEIPSD_00393].
[PRS_SOMEIPSD_00128]
Upstream requirements: RS_SOMEIPSD_00019
If the Major Version of a received entry is not known and not a Subscribe Eventgroup
entry, the entry shall be ignored. Otherwise a Negative Acknowledgement shall be
returned according to [PRS_SOMEIPSD_00393].
[PRS_SOMEIPSD_00129]
Upstream requirements: RS_SOMEIPSD_00019
If the Eventgroup ID of a received entry is not known and not a Subscribe Eventgroup
entry, the entry shall be ignored. Otherwise a Negative Acknowledgement shall be
returned according to [PRS_SOMEIPSD_00393]. This is only applicable to eventgroup
entries.
[PRS_SOMEIPSD_00803]
Upstream requirements: RS_SOMEIPSD_00019
If the length of the Entries Array has an invalid size (i.e. the entries array would exceed
the message size), the message shall be discarded without further actions.
以下是针对 **SOME/IP-SD 报文处理要求** 的逐条技术解析与实现逻辑总结：
---
### **报文基础验证规则**
#### **[PRS_SOMEIPSD_00125] - 最小长度校验**
- **要求**：
- 所有 SOME/IP-SD 报文必须 ≥12 字节（空消息的最小长度）。
- **处理逻辑**：
```c
if (message.length < 12) {
discard_message(); // 直接丢弃，无后续动作
}
```
- **技术背景**：
- 12 字节 = SOME/IP头部(8) + SD头部(4)（含长度、标志位等）。
---
### **服务条目有效性验证**
#### **[PRS_SOMEIPSD_00126] - Service ID 校验**
- **合法条件**：
- Service ID 已知 **或** 条目类型为 `Subscribe Eventgroup`。
- **异常处理**：
```c
if (entry.service_id != known_id && entry.type != SUBSCRIBE_EVENTGROUP) {
if (requires_ack(entry)) {
send_nack(PRS_SOMEIPSD_00393); // 返回NACK
} else {
ignore_entry(); // 静默忽略
}
}
```
#### **[PRS_SOMEIPSD_00127] - Instance ID 校验**
- **逻辑同 Service ID**，仅校验字段替换为 `Instance ID`。
#### **[PRS_SOMEIPSD_00128] - Major Version 校验**
- **逻辑同 Service ID**，仅校验字段替换为 `Major Version`。
#### **[PRS_SOMEIPSD_00129] - Eventgroup ID 校验**
- **特殊限制**：
- 仅适用于 `Eventgroup` 相关条目（如 Subscribe/Stop Subscribe）。
- 若 Eventgroup ID 未知且非订阅类条目，静默忽略；否则返回 NACK。
---
### **数组长度安全校验**
#### **[PRS_SOMEIPSD_00803] - Entries Array 越界检查**
- **要求**：
- Entries Array 的声明长度不得导致数组超出报文实际大小。
- **处理逻辑**：
```c
if (entries_array_length > (message.length - current_offset)) {
discard_message(); // 直接丢弃，防内存越界
}
```
- **安全意义**：
- 防止恶意或错误报文引发缓冲区溢出。
---
### **关键设计原则总结**
1. **静默丢弃优先**：
- 基础格式错误（如长度不足、数组越界）直接丢弃，避免无效处理开销。
2. **订阅特殊性**：
- `Subscribe Eventgroup` 条目享有宽松校验（允许未知 Service/Instance ID），支持动态事件订阅。
3. **负反馈机制**：
- 对需应答的无效条目返回标准化 NACK（引用 [PRS_SOMEIPSD_00393]），确保调试可追溯。
4. **防御性编程**：
- 所有校验均前置，防止无效数据进入核心逻辑。
---
### **实现建议**
```python
def validate_sd_message(message):
# 基础校验
if message.length < 12:
return Discard()
# Entries数组越界检查
if message.entries_array_length > (message.length - message.entries_offset):
return Discard()
# 逐条目校验
for entry in message.entries:
if not is_subscribe_eventgroup(entry):
if not validate_service_id(entry.service_id):
return Nack() if requires_ack(entry) else Ignore()
# 其他字段校验同理...
return Process() # 全部校验通过
```
[PRS_SOMEIPSD_00130]
Upstream requirements: RS_SOMEIPSD_00019
Check the referenced Options of each received entry:
• The referenced options exist.
• The entry references all required options (e.g. a provided eventgroup that uses
unicast requires a unicast endpoint option in a received Subscribe Eventgroup
entry).
• The entry only references supported options (e.g. a required eventgroup that
oes not support multicast data reception does not support multicast endpoint
options in a Subscribe Eventgroup ACK entry).
• There are no conflicts between the options referenced by an entry (i.e. two options of same type with contradicting content).
• The Type of the referenced Option is known or the discardable flag is set to 1.
• The Type of the referenced Option is allowed for the entry
[PRS_SOMEIPSD_00583] or discardable flag is set to 1.
• The Length of the referenced Option is consistent to the Type of the Option.
• An Endpoint Option has a valid L4-Protocol field.
• The Option is valid (e.g. a multicast endpoint option shall use a multicast IP
address).
Note:
If an entry references an option that is known by the Service Discovery implementation but not required by the service (e.g. an Offer references a TCP and UDP option
and the client uses only UDP, or a Subscribe Eventgroup entry references a UDP endpoint option but the server uses only multicast event transmission), the entry shall be
processed.
### **SOME/IP-SD 条目选项（Options）验证规则解析**
针对 **[PRS_SOMEIPSD_00130]** 的要求，以下是详细的校验逻辑与技术实现指导：
---
#### **1. 选项基础验证**
**校验项**：
- **选项存在性**：条目引用的所有选项必须存在于报文中。
- **长度一致性**：选项的 `Length` 字段必须与其 `Type` 定义的格式匹配。
- **协议有效性**：Endpoint 选项的 `L4-Protocol` 字段必须合法（如 TCP/UDP/SOMEIP）。
---
#### **2. 选项与条目的兼容性验证**
**校验项**：
- **必选选项**：条目必须引用其类型要求的选项（如 `Subscribe Eventgroup` 使用单播时需引用单播 Endpoint 选项）。
- **禁止选项**：条目不得引用其类型不支持的选项（如不支持多播的服务禁止引用多播 Endpoint 选项）。
- **选项冲突**：同一条目引用的多个选项内容不能矛盾（如两个 IP Endpoint 选项指向不同端口）。
**示例场景**：
- ✅ **合法**：`Offer Service` 条目同时引用 TCP 和 UDP Endpoint 选项（客户端可任选）。
- ❌ **非法**：`Subscribe Eventgroup` 条目引用多播 Endpoint，但服务端仅支持单播。
---
#### **3. 未知选项处理**
**规则**：
- 若选项的 `Type` 未知，但其 `discardable` 标志为 `1`，则忽略该选项继续处理条目。
- 若 `Type` 未知且 `discardable=0`，则根据条目类型返回 NACK 或忽略。
---
#### **4. 选项内容有效性验证**
**校验项**：
- **多播地址合法性**：若为多播 Endpoint 选项，IP 地址必须属于多播范围（如 224.0.0.0/4）。
- **IP/端口有效性**：Endpoint 选项的 IP 和端口必须符合协议规范。
---
### **处理流程总结**
1. **逐选项检查**：存在性、长度、协议、内容有效性。
2. **条目级校验**：必选/禁止选项、选项冲突、未知选项容忍。
3. **决策逻辑**：
- 任何关键校验失败 → 返回 NACK 或忽略条目（根据条目类型）。
- 非关键选项错误（如 `discardable=1`）→ 静默忽略。
---
### **设计注意事项**
- **性能优化**：预处理报文时建立选项索引，加速引用检查。
- **安全边界**：严格校验选项长度和指针偏移，防止缓冲区溢出。
- **日志记录**：为 NACK 响应附加详细错误原因，便于调试。
[PRS_SOMEIPSD_00131]
Upstream requirements: RS_SOMEIPSD_00019
Check if the TCP connection is already present (only applicable, if TCP is configured
for Eventgroup and Subscribe Eventgroup entry was received)
[PRS_SOMEIPSD_00852]
Upstream requirements: RS_SOMEIPSD_00019
Check if a security association is already established.
[PRS_SOMEIPSD_00132]
Upstream requirements: RS_SOMEIPSD_00019
Check if enough resources are left (e.g. Socket Connections)
[PRS_SOMEIPSD_00232]
Upstream requirements: RS_SOMEIPSD_00019
If the checks in [PRS_SOMEIPSD_00130] fail for a received Find entry, the entry shall
be ignored, except when Endpoint or Multicast Options are referenced, in which case
only the Options shall be ignored according to [PRS_SOMEIPSD_00529].
[PRS_SOMEIPSD_00233]
Upstream requirements: RS_SOMEIPSD_00019
If the checks in [PRS_SOMEIPSD_00130] fail for a received Offer entry, the entry
shall be ignored.
[PRS_SOMEIPSD_00234]
Upstream requirements: RS_SOMEIPSD_00019
If the checks in [PRS_SOMEIPSD_00130], [PRS_SOMEIPSD_00131],
[PRS_SOMEIPSD_00832], [PRS_SOMEIPSD_00852] or [PRS_SOMEIPSD_00132]
fail for a received Subscribe Eventgroup entry, a Subscribe Eventgroup NACK entry
shall be sent.
### **SOME/IP-SD 连接与资源验证规则解析**
针对 **[PRS_SOMEIPSD_00131]、[PRS_SOMEIPSD_00852]、[PRS_SOMEIPSD_00132]** 及其关联条目的处理要求，以下是分层次的逻辑梳理和实现指导：
---
#### **1. 关键校验项分类**
| 校验规则 | 适用场景 | 失败处理方式 |
|-------------------------|----------------------------------|----------------------------------|
| **TCP连接存在性** | 仅当TCP配置的Eventgroup订阅时 | 返回Subscribe Eventgroup NACK |
| **安全关联建立** | 需安全传输的订阅请求 | 返回Subscribe Eventgroup NACK |
| **资源可用性** | 所有需分配资源的操作（如Socket） | 返回Subscribe Eventgroup NACK |
| **Find Entry选项校验** | Find Service条目中的选项错误 | 忽略条目（Endpoint/Multicast选项仅忽略选项本身） |
| **Offer Entry选项校验** | Offer Service条目中的选项错误 | 完全忽略整个条目 |
---
#### **2. 详细校验逻辑与实现**
##### **2.1 TCP连接验证 ([PRS_SOMEIPSD_00131])**
```c
if (entry.type == SUBSCRIBE_EVENTGROUP && uses_tcp(entry)) {
if (!tcp_connection_exists(entry.service_id, entry.instance_id)) {
send_nack(REASON_NO_TCP_CONNECTION); // 返回NACK
return;
}
}
```
**触发条件**：
- 仅当Eventgroup配置为TCP传输且收到`Subscribe Eventgroup`条目时校验。
---
##### **2.2 安全关联验证 ([PRS_SOMEIPSD_00852])**
```c
if (requires_security(entry)) {
if (!security_association_established(entry.service_id)) {
send_nack(REASON_SECURITY_ASSOCIATION_MISSING);
return;
}
}
```
**注意**：
- 安全需求通常由服务元数据（如AUTOSAR Secure Communication配置）定义。
---
##### **2.3 资源可用性验证 ([PRS_SOMEIPSD_00132])**
```c
if (entry.type == SUBSCRIBE_EVENTGROUP) {
if (!has_free_socket_connections()) {
send_nack(REASON_INSUFFICIENT_RESOURCES);
return;
}
// 其他资源检查（内存、队列等）
}
```
---
##### **2.4 Find/Offer Entry选项校验失败处理**
- **Find Entry处理 ([PRS_SOMEIPSD_00232])**
```c
if (entry.type == FIND_SERVICE) {
if (check_options_failed(entry)) {
if (has_endpoint_or_multicast_options(entry)) {
ignore_options_only(); // 仅忽略无效选项，继续处理条目
} else {
ignore_entry(); // 完全忽略条目
}
}
}
```
- **Offer Entry处理 ([PRS_SOMEIPSD_00233])**
```c
if (entry.type == OFFER_SERVICE && check_options_failed(entry)) {
ignore_entry(); // 无条件忽略整个条目
}
```
---
##### **2.5 Subscribe Eventgroup综合校验 ([PRS_SOMEIPSD_00234])**
```c
if (entry.type == SUBSCRIBE_EVENTGROUP) {
bool options_ok = check_options(entry); // PRS_SOMEIPSD_00130
bool tcp_ok = !needs_tcp(entry) || tcp_exists();// PRS_SOMEIPSD_00131
bool security_ok = !needs_security(entry) || security_exists(); // PRS_SOMEIPSD_00852
bool resources_ok = check_resources(); // PRS_SOMEIPSD_00132
if (!(options_ok && tcp_ok && security_ok && resources_ok)) {
send_nack(get_failure_reason()); // 返回具体错误原因的NACK
}
}
```
---
#### **3. 错误原因映射表**
| 校验失败类型 | NACK Reason Code |
|---------------------------|--------------------------------|
| TCP连接不存在 | `0x80` (TCP_CONNECTION_MISSING)|
| 安全关联未建立 | `0x81` (SECURITY_REQUIRED) |
| 资源不足 | `0x82` (RESOURCE_EXHAUSTED) |
| 选项校验失败 | `0x83` (INVALID_OPTIONS) |
---
#### **4. 设计注意事项**
1. **状态缓存优化**：
- 维护TCP连接和安全关联的缓存表，避免每次订阅时重复查询。
2. **资源预留机制**：
- 在发送`Subscribe Eventgroup ACK`前预先分配资源，防止竞态条件。
3. **错误恢复**：
- 客户端收到NACK后应根据原因码延迟重试（如资源不足时等待后重试）。
4. **多播兼容性**：
- 多播订阅无需TCP连接校验，但需验证多播地址合法性（参考[PRS_SOMEIPSD_00130]）。
---
### **典型处理流程图**
```mermaid
graph TD
A[收到Subscribe Eventgroup] --> B{选项校验通过?}
B --否--> C[发送NACK(INVALID_OPTIONS)]
B --是--> D{TCP必需且存在?}
D --否--> E[发送NACK(TCP_MISSING)]
D --是--> F{安全关联已建立?}
F --否--> G[发送NACK(SECURITY_REQUIRED)]
F --是--> H{资源充足?}
H --否--> I[发送NACK(RESOURCE_EXHAUSTED)]
H --是--> J[发送ACK并分配资源]
```
[PRS_SOMEIPSD_00235]
Upstream requirements: RS_SOMEIPSD_00019
If the checks in [PRS_SOMEIPSD_00130] or [PRS_SOMEIPSD_00132] fail for a received Subscribe Eventgroup ACK entry, the entry shall be processed, but the subscription shall not be considered as successful.
[PRS_SOMEIPSD_00231]
Upstream requirements: RS_SOMEIPSD_00019
Options that are referenced by an entry shall be ignored if:
• The Option Type is not known (i.e. not yet specified, or not supported by the
receiver) and the discardable flag is set to 1.
• The option is redundant (i.e. another option of the same type and same content
is referenced by this entry).
• The option is not required (e.g. a provided eventgroup that uses only multicast
oes not require a unicast endpoint option in a received Subscribe Eventgroup
entry, though it is still allowed).
[PRS_SOMEIPSD_00844]
Upstream requirements: RS_SOMEIPSD_00019
If the two Configuration Options have conflicting items (same name), all items shall
be handled. There shall be no attempt been made to merge duplicate items.
[PRS_SOMEIPSD_00832]
Upstream requirements: RS_SOMEIPSD_00019
Check for a provided service instance which requires a secure connection if on reception of a subscribe the security association for the corresponding connection is already
established.
### **SOME/IP-SD 订阅响应与选项处理规则解析**
针对订阅确认（Subscribe Eventgroup ACK）和安全连接的进阶处理要求，以下是结构化技术分析：
---
#### **1. Subscribe Eventgroup ACK 的容错处理 ([PRS_SOMEIPSD_00235])**
- **核心规则**：
- 即使选项校验（[PRS_SOMEIPSD_00130]）或资源检查（[PRS_SOMEIPSD_00132]）失败，**仍处理ACK条目**，但标记订阅为**未成功**。
- **设计意图**：
- 允许接收方记录错误状态，同时避免中断通信流程。
- **实现逻辑**：
```c
if (entry.type == SUBSCRIBE_EVENTGROUP_ACK) {
bool options_valid = check_options(entry); // PRS_SOMEIPSD_00130
bool resources_ok = check_resources(); // PRS_SOMEIPSD_00132
process_entry(entry); // 始终处理条目
if (!options_valid || !resources_ok) {
set_subscription_status(FAILED); // 仅标记失败
}
}
```
---
#### **2. 选项忽略条件 ([PRS_SOMEIPSD_00231])**
以下情况需忽略条目中的选项（不影响条目处理）：
| **忽略条件** | **示例场景** | **处理动作** |
|----------------------------|------------------------------------------|--------------------------|
| **未知类型且discardable=1** | 接收方不支持的新选项类型 | 静默跳过该选项 |
| **冗余选项** | 同一条目引用两个相同的TCP Endpoint选项 | 仅保留第一个，忽略重复项 |
| **非必要选项** | 多播服务引用单播Endpoint（非强制要求） | 忽略单播选项 |
**代码实现**：
```c
foreach (option in entry.options) {
if (option.discardable && !is_known_type(option.type)) {
continue; // 条件1：未知可丢弃选项
}
if (is_redundant(option, entry)) {
continue; // 条件2：冗余选项
}
if (!is_required(option, entry)) {
continue; // 条件3：非必要选项
}
process_option(option); // 处理有效选项
}
```
---
#### **3. 配置选项冲突处理 ([PRS_SOMEIPSD_00844])**
- **规则**：
- 若两个配置选项（Configuration Options）存在**同名参数冲突**，必须**全部处理**，禁止自动合并。
- **典型场景**：
- 服务端同时发送两个`Load Balancing`选项，包含不同的权重值。
- **实现要求**：
```c
if (has_conflicting_options(entry)) {
// 按接收顺序处理所有冲突选项（不覆盖）
foreach (option in get_conflicting_options(entry)) {
apply_option(option); // 可能产生叠加效果
}
}
```
---
#### **4. 安全连接强制验证 ([PRS_SOMEIPSD_00832])**
- **触发条件**：
- 服务实例配置为**需安全连接**（如AUTOSAR SecOC标识）。
- **验证逻辑**：
```c
if (entry.type == SUBSCRIBE_EVENTGROUP && requires_secure_connection(entry)) {
if (!check_security_association(entry.service_id)) {
send_nack(SECURITY_ASSOCIATION_MISSING); // 返回NACK
return;
}
}
```
- **关联标准**：
- 安全关联建立需符合AUTOSAR SecOC或TLS握手流程。
---
### **关键设计原则总结**
1. **失败隔离性**
- ACK条目的处理与订阅状态解耦，确保部分错误不影响基础通信。
2. **选项灵活性**
- 通过`discardable`标志和必要性检查，平衡严格校验与兼容性。
3. **冲突显式处理**
- 配置选项冲突需显式处理，避免隐式合并导致未定义行为。
4. **安全前置校验**
- 在订阅阶段强制验证安全关联，而非延迟到数据传输时。
---
### **典型错误处理流程**
```mermaid
graph TD
A[收到Subscribe Eventgroup ACK] --> B{选项校验通过?}
B --是--> C[标记订阅成功]
B --否--> D[记录错误原因,标记订阅失败]
A --> E{存在安全要求?}
E --是--> F{安全关联已建立?}
F --否--> G[发送NACK(SECURITY_REQUIRED)]
F --是--> H[继续处理]
```