3. T6定时器定义与作用：T6定时器在事务处理阶段的功能与标准超时值
T6定时器是SECS/GEM协议中用于控制单个事务（Transaction）完成时间的核心定时器。它从主设备（Host）或设备（Equipment）发送一个需要回复的消息（如Primary Message）开始计时，直到收到对应的Reply Message或Secondary Message为止。如果T6超时，意味着该事务未能正常完成，协议栈必须执行异常恢复流程。
关键概念： T6定时器覆盖的是“请求-响应”配对过程，与T5（连接建立）和T3（Reply Timeout）不同，T6专注于事务层级的完整性，是保障会话原子性的第一道防线。
3.1 T6定时器在事务处理中的位置
在SECS/GEM通信模型中，一个完整的事务通常包含以下阶段：
- 主消息发送（Primary Message）： 发起方发送一个需要响应的消息（如S1F1、S2F17）。
- 等待响应（Wait for Reply）： 发起方启动T6定时器，等待接收方回复。
- 响应接收（Reply Received）： 接收方返回对应的Secondary Message（如S1F2、S2F18），T6定时器停止。
- 事务完成（Transaction Complete）： 双方确认消息交换结束。
如果步骤2中T6超时，发起方将认为该事务失败，并可能触发重试、断开连接或上报异常。
3.2 T6定时器的标准超时值
根据SEMI E5（SECS-II）和E37（HSMS）标准，T6定时器的推荐超时值如下表所示。实际部署时可根据网络延迟和设备处理能力进行调整。
| 参数 | 标准值 | 范围 | 说明 |
|---|---|---|---|
| T6 默认值 | 45 秒 | 10 ~ 120 秒 | 适用于大多数半导体设备事务处理 |
| T6 最小值 | 10 秒 | — | 用于高速、低延迟的本地通信场景 |
| T6 最大值 | 120 秒 | — | 用于复杂事务（如大批量数据上传） |
| T6 与 T3 关系 | T6 > T3 | — | T6必须大于T3，避免T3超时后T6仍运行 |
配置建议： 在首次部署时，建议将T6设置为45秒，并通过实际生产流量监控超时事件。如果频繁出现T6超时，应优先排查设备响应速度或网络延迟，而非简单增大超时值。
3.3 T6定时器与T3定时器的区别
T6和T3是SECS/GEM协议中最容易混淆的两个定时器。下表从多个维度进行对比：
| 对比维度 | T3 定时器 | T6 定时器 |
|---|---|---|
| 作用层级 | 消息层（Message Level） | 事务层（Transaction Level） |
| 计时起点 | 消息发送完成 | 主消息发送完成 |
| 计时终点 | 收到任何回复消息 | 收到正确的Secondary Message |
| 超时后果 | 重发消息或断开连接 | 事务失败，触发异常处理 |
| 标准值 | 45 秒 | 45 秒 |
| 配置关系 | 独立配置 | 必须大于T3 |
常见误区： 有些工程师将T6和T3设置为相同值，这会导致T3超时后立即触发T6超时，造成双重异常处理。正确的做法是T6至少比T3大5~10秒，给T3重试留出缓冲时间。
3.4 T6定时器超时处理流程
当T6定时器超时时，协议栈应执行以下标准处理步骤：
- 停止等待状态： 立即停止对该事务的等待，释放事务ID（Transaction ID）。
- 记录异常日志： 记录超时的事务类型、消息ID、时间戳等信息。
- 通知上层应用： 通过回调或事件机制通知应用层事务失败。
- 可选重试： 根据应用策略决定是否重新发送主消息（需使用新的事务ID）。
- 连接检查： 如果连续多次T6超时，应检查TCP连接状态或执行连接重建。
3.5 T6定时器配置实战要点
- 与T3协同配置： 确保T6 > T3 + 网络往返时间（RTT），避免T3重试期间T6超时。
- 考虑事务复杂度： 简单查询（如S1F1/S1F2）可使用较短T6（15~30秒），大批量数据上传（如S6F11/S6F12）需较长T6（60~120秒）。
- 监控超时频率： 如果T6超时率超过1%，应分析根本原因，而非单纯增大超时值。
- 日志记录策略： 记录每次T6超时的事务上下文，包括消息ID、数据长度、设备状态，便于事后分析。
最佳实践： 在设备端和主机端分别配置独立的T6定时器，并保持两端值一致。如果两端T6值不一致，可能导致一端认为事务超时而另一端仍在等待，造成状态不同步。