4. T3定时器超时模拟：等待Reply超时、重传机制、Transaction ID管理

T3定时器（Reply Timeout Timer）是SECS/GEM通信中用于监控等待回复的关键机制。当HSMS主动发送一个需要回复的消息（如Primary Message）后，会启动T3定时器。若在T3超时前未收到对应的Reply Message，则视为通信异常。本章将深入模拟T3超时场景，并讲解重传机制与Transaction ID（事务ID）的生命周期管理。

4.1 T3定时器工作原理与超时判定

在SECS-II消息交换中，Primary Message（如S1F1、S2F17）携带一个唯一的Transaction ID（通常为WBit=1）。接收方必须在T3超时前回复Secondary Message（如S1F2、S2F18），且回复消息必须携带相同的Transaction ID。T3定时器的典型取值范围为45秒至120秒，具体值由通信双方协商确定。

4.2 重传机制设计

当T3超时发生后，设备端需要决定是否重传Primary消息。重传机制必须考虑以下因素：

• 重传次数上限：通常设置为3次（可配置），超过上限后不再重传，直接上报通信故障。
• 重传间隔策略：固定间隔（如T3值）或指数退避（如T3×2^n），避免网络拥塞。
• Transaction ID复用：重传时必须使用相同的Transaction ID，否则接收方无法关联到原始请求。
• 幂等性保证：接收方需能识别重传消息，避免重复执行（如重复的S2F17导致重复的配方下载）。

4.3 Transaction ID管理

Transaction ID（事务ID）是SECS/GEM协议中用于关联Primary与Secondary消息的唯一标识。在T3超时和重传场景中，Transaction ID的管理直接决定通信的正确性与资源泄漏风险。

4.3.1 Transaction ID生命周期

1. 分配：发送Primary消息时，从空闲池中获取一个唯一ID（通常为0~32767循环使用）。
2. 挂起：ID被标记为“使用中”，绑定T3定时器，等待Reply。
3. 完成：收到匹配的Secondary消息，释放ID回空闲池。
4. 超时清理：T3超时后，若不再重传，强制释放ID；若重传，ID保持挂起状态。
5. 异常释放：连接断开时，所有挂起的ID必须立即释放，防止泄漏。

4.3.2 代码示例：Transaction ID管理器核心逻辑

// Transaction ID管理器（简化版）
class TransactionManager {
private:
    static const int MAX_ID = 32767;
    std::bitset<MAX_ID + 1> id_bitmap_;  // 位图标记ID使用状态
    std::map<uint16_t, TimerHandle> timer_map_;  // ID -> T3定时器句柄
    std::mutex mtx_;

public:
    uint16_t Allocate() {
        std::lock_guard<std::mutex> lock(mtx_);
        for (uint16_t id = 0; id <= MAX_ID; ++id) {
            if (!id_bitmap_.test(id)) {
                id_bitmap_.set(id);
                return id;
            }
        }
        throw std::runtime_error("No available Transaction ID");
    }

    void Release(uint16_t id) {
        std::lock_guard<std::mutex> lock(mtx_);
        id_bitmap_.reset(id);
        auto it = timer_map_.find(id);
        if (it != timer_map_.end()) {
            CancelTimer(it->second);
            timer_map_.erase(it);
        }
    }

    void OnT3Timeout(uint16_t id) {
        // 超时回调：决定重传或释放
        if (retry_count_[id] < MAX_RETRY) {
            retry_count_[id]++;
            SendPrimaryWithSameID(id);  // 重传，ID不变
            StartT3Timer(id);           // 重新启动T3
        } else {
            Release(id);                // 超过重传上限，释放ID
            ReportCommunicationError(id);
        }
    }
};

4.4 异常场景模拟：T3超时+重传+ID泄漏

以下是一个典型的T3超时异常模拟场景，展示从超时发生到ID泄漏的完整链路：

• 步骤1：Host发送S1F1 W（WBit=1），分配Transaction ID=100，启动T3定时器。
• 步骤2：设备端因CPU繁忙未及时回复S1F2，T3超时（45秒）。
• 步骤3：Host触发重传，再次发送S1F1 W（ID=100），重启T3。
• 步骤4：设备端此时回复S1F2（ID=100），Host收到后释放ID=100。
• 步骤5（异常分支）：若设备端在T3超时后、重传前回复了S1F2，Host应能识别延迟回复并丢弃，但ID可能已被错误释放或重复使用。

4.5 容错机制设计总结

针对T3定时器超时场景，建议在设备端和Host端同时实施以下容错机制：