📚 课程目录第2章 SECS/GEM协议栈架构

2. SECS/GEM 协议栈架构：分层模型、消息格式与事务处理

SECS/GEM 协议栈并非单一协议，而是一套层次化的通信规范。理解其分层模型、消息封装格式以及事务处理机制，是进行协议栈移植与 GEM 功能集成的核心基础。本章将从这三个维度深入剖析协议栈的内部构造。

2.1 协议分层模型

SECS/GEM 协议栈遵循 OSI 七层模型的思想，但在实际工业应用中，通常将其简化为四个核心层次。每一层都承担着特定的职责，并为上层提供透明的服务。

    核心要点： 分层设计的目的是解耦。底层（HSMS/TCP）负责可靠传输，中间层（SECS-II）负责消息编码与解析，顶层（GEM）负责定义设备行为与数据模型。移植时，通常只需替换底层传输层，而保持 SECS-II 与 GEM 逻辑不变。

下表总结了各层的主要职责与对应的 SEMI 标准：

层次	SEMI 标准	核心职责	移植关注点
GEM	E30	定义设备能力、状态模型、报告、报警、远程控制等语义	需根据设备功能实现 GEM 接口回调
SECS-II	E5	消息编码/解码、数据项类型定义、Stream/Function 路由	通常作为静态库移植，需关注字节序与内存对齐
HSMS	E37	连接建立/断开、心跳维持、消息分帧与重组	需适配目标平台的 TCP/IP 协议栈
TCP/IP	—	提供可靠的、面向连接的字节流传输	由操作系统或硬件协议栈提供

2.2 消息格式：Message Header & Data Item

SECS/GEM 的消息格式分为两个层次：传输层消息头（HSMS Header） 和 应用层数据项（SECS-II Data Item）。理解这两者的结构是解析与构造消息的前提。

2.2.1 HSMS 消息头

HSMS 消息头固定为 10 字节，位于每一条 SECS-II 消息的最前端。它定义了消息的长度、类型、会话 ID 以及 Stream/Function 编码。

2.2.2 SECS-II 数据项 (Data Item)

SECS-II 消息体由一系列 数据项 (Data Item) 组成。每个数据项采用 TLV (Type-Length-Value) 格式编码，这是 SECS-II 协议的核心编码规则。

TLV 编码规则： 每个数据项由 1 字节的格式码 (Format Code)、1-3 字节的长度 (Length) 和可变长度的值 (Value) 组成。格式码的高 4 位表示数据类型（如 List、ASCII、Binary、U4、F8 等），低 4 位表示长度字节数。

常见的数据项格式码如下：

格式码 (Hex)	数据类型	描述	长度字节数
0x00	List	数据项列表，包含子项	1-3
0x10	Binary	二进制字节数组	1-3
0x20	Boolean	布尔值 (True/False)	1-3
0x40	ASCII	ASCII 字符串	1-3
0x60	I8 / I1 / I2 / I4	有符号整数 (长度由低4位决定)	1-3
0xA0	U8 / U1 / U2 / U4	无符号整数	1-3
0xE0	F8 / F4	浮点数	1-3

以下是一个典型的 SECS-II 消息编码示例（S1F1 请求设备 ID）：

// S1F1 消息的 HSMS 头 + SECS-II 体 (十六进制)
// HSMS Header (10 bytes)
00 00 00 0A    // Length = 10 bytes (消息体长度)
00 01          // Session ID = 1
00             // H.B.2 = 0
00             // S Type = 0 (数据消息)
01 01          // Stream = 1, Function = 1
00 00 00 01    // System Bytes = 1

// SECS-II Body (10 bytes)
// 数据项: 一个空的 List (S1F1 请求不需要参数)
00 00          // Format Code = 0x00 (List), Length = 0

2.3 事务处理机制

SECS/GEM 的事务处理机制基于 请求-响应 模式，并通过 系统字节 (System Bytes) 实现消息的关联与超时管理。这是确保通信可靠性的关键。

2.3.1 事务类型

根据 Stream 和 Function 的奇偶性，SECS-II 消息分为两类：

Primary Message (主消息): Function 为奇数。通常由主机或设备主动发起，用于请求操作或查询状态。
Secondary Message (副消息): Function 为偶数。是对 Primary Message 的响应，携带请求的结果或数据。

重要规则： 一个 Primary Message 必须对应一个 Secondary Message。如果接收方无法处理请求，必须回复一个 SxF0 (Function 0) 错误消息，而不是保持沉默。这是协议的基本健壮性要求。

2.3.2 事务生命周期

一个完整的事务处理流程如下：

发起： 发送方构造 Primary Message，分配一个唯一的 System Bytes，并启动 T3 超时定时器。
传输： 消息通过 HSMS 层发送到接收方。
处理： 接收方解析消息，执行对应操作，构造 Secondary Message，并将 System Bytes 原样复制到响应消息中。
响应： 发送方收到 Secondary Message，通过 System Bytes 匹配到挂起的事务，停止 T3 定时器，完成事务。
超时： 如果 T3 定时器超时仍未收到响应，发送方应重试或上报通信故障。

2.3.3 多事务并发与系统字节管理

在实际通信中，主机可能同时发起多个请求，而不必等待前一个事务完成。协议栈通过 系统字节 (System Bytes) 来区分并发事务。

唯一性： 每个未完成的事务必须拥有唯一的 System Bytes。通常使用递增计数器或基于时间戳的生成策略。
查找表： 协议栈内部维护一个事务查找表 (Transaction Lookup Table)，以 System Bytes 为 Key，存储事务状态、超时时间、回调函数等。
资源限制： 嵌入式系统中，事务表大小通常有限（如 16 或 32 个条目），超出限制时需拒绝新请求或复用最旧的事务。

    移植实践： 在嵌入式 RTOS 中实现事务管理时，建议使用 定时器任务 统一管理所有 T3 超时，而不是为每个事务创建独立的定时器。这样可以减少系统资源消耗，并避免定时器漂移问题。

下表总结了事务处理中的关键参数：

参数	默认值	说明
T3 (Reply Timeout)	45 秒	等待 Secondary Message 的最大时间
T5 (Connect Timeout)	10 秒	HSMS 连接建立超时
T6 (Control Timeout)	5 秒	等待 HSMS 控制消息响应的超时
T8 (Network Timeout)	5 秒	TCP 数据接收超时
Max Transactions	32	并发事务数上限（取决于内存）

通过本章的学习，你应该能够清晰地描述 SECS/GEM 协议栈的分层结构，能够手动解析 HSMS 消息头和 SECS-II 数据项，并理解基于 System Bytes 的事务处理机制。这些知识将直接应用于后续的协议栈移植与调试工作中。