ErrorMessages

核心概念速览

目的：让设备向主机报告“为什么不能处理某条消息”或“何时发生了通信/消息故障”，以便主机能采取同步或恢复动作。
两类相关概念：Communication Fault（通信故障） 与 Message Fault（消息故障）。设备在检测到这些故障/错误时应发送错误消息。
设备必须能报告的典型错误原因：不认识的 Device ID、未识别的 Stream 类型、未识别的 Function、非法的消息/数据格式、数据过长、以及事务/会话计时器超时等。设备要把这些视为应用层错误，并不对该错误消息做进一步处理（即报错后不再尝试按该消息执行业务）。
Stream-9（System Errors）是专门用于错误回报的流：包括 S9,F1 (Unrecognized Device ID)、S9,F3 (Unrecognized Stream Type)、S9,F5 (Unrecognized Function Type)、S9,F7 (Illegal Data)、S9,F9 (Transaction Timer Timeout)、S9,F11 (Data Too Long)、S9,F13 (Conversation Timeout) 等；GEM 要求支持所有 Stream-9 的消息。

错误消息只做“说明性/报告性”用途：当检测到消息或通信故障时，设备应发送相应的 S9 消息并停止对该错误消息的任何后续应用处理（不要把它当成普通命令来执行）。这一点在文中有明确要求。
实现要点：在消息解析流程中把错误检测路径设计为“报错 → 丢弃/结束该事务”，避免在错误路径中触发设备动作或状态更改（以防误动作）。

实现要点：实现一张“消息校验表”（Message Validation Matrix），在收到每条主机消息后依次做：

事务计时器（transaction timer）：用于等待某条主-从交易的 reply；超时触发 S9,F9。
会话/对话计时器（conversation timer）：用于等待后续特定期望消息（sequence 中的后续步骤）；超时触发 S9,F13。
注意：计时器的存在与精确语义在不同底层协议（SECS-I / HSMS / SMS 等）中有差异；有些协议或实现可能没有严格的“事务计时器”概念（文中也提到协议依赖性，需对接具体协议规范确认）。

不把错误当作 Alarm（警报）：E30 明确把 message/communication faults 与 alarm 概念区分开，错误消息属于“通信/消息异常”的报告。不要把 S9 事件放到 Alarm 管理链路（ALID）中误处理。
与 Spooling 的关系：文中对 spooling 的讨论与消息类型有关（例如 Stream-1 消息不进入 spool）。是否将 S9 消息加入 spool 需要参照文档对 spooling 行为的总体定义与工厂策略（此点在 E30 中未在 4.9 明确要求是否 spooling）

在发送 S9 报文时，应在设备日志中保存：收到的原始消息摘要（安全剪裁）、触发的校验步骤、触发时间戳、相关计时器状态与队列长度。这样主机/集成方在收到 S9 后可以快速定位问题。
对于非法数据/数据过长类错误，设备可在 S9 报文外（或配合事件上报）提供一个可供主机请求的“错误详细信息”接口（例如通过 trace 或特定状态变量），但要注意不要泄露过多设备内部敏感信息。
在前面板/操作台显示中设置“未识别消息指示器”（示例中有提及）以便人工干预。

当设备返回 S9 某种错误时，主机通常应：记录、分析、必要时重发（如果是 transient 的 conversation timeout/transaction timeout），或通知运维/暂停该链路的自动动作。设备端应保证在发送 S9 后处于稳定且可重试的状态，不要因一次消息错误导致连接不可恢复。

设备端应把消息/通信异常明确识别并通过 Stream-9（S9,Fx）系列消息准确报告：报错即终止该消息的业务处理，同时提供足够的诊断信息以便主机或运维进行同步与恢复。

有任何问题或疑问，请发送邮件到--->admin@secs-ii.net