设备通信问题常常只在现场、特定固件或某个故障窗口出现。若日志只有“通信失败”，开发者只能反复猜测。可维护的通信模块应把原始证据、解析结果、请求关联和设备状态串成一条可回放链路。

1. 先明确要观察哪一层

Wireshark 看不到 USB 串口芯片另一侧的真实 RS-485 电气波形；示波器也不知道某个功能码的业务含义。工具必须匹配问题层次。

2. 原始数据日志要可重建

对每个收发块至少记录：

1
2

Timestamp, Direction, DeviceId, ConnectionGeneration,
ChunkSequence, ByteCount, RawBytes, TransportMetadata

随后记录解析事件：

1
2

FrameSequence, Command, TransactionId, ParseResult,
ChecksumResult, PayloadSummary, CorrelationId

“块序号”与“帧序号”必须分开，因为一块可能含多帧，一帧也可能跨多块。时间戳注明来源和精度：墙上时间方便跨系统关联，单调时钟适合计算持续时间，硬件时间戳适合分析总线时序。

3. 十六进制日志的边界

原始字节很有价值，也可能包含 Recipe、序列号、账户或工艺数据。生产日志应：

• 默认限制每条记录的最大字节数；
• 对已知敏感字段脱敏，而不是事后搜索字符串；
• 保留原始总长度与截断标志；
• 使用二进制归档保存完整证据，并实施访问控制和保留周期；
• 不在实时回调中同步格式化大型 hex 字符串。

为了可读性，显示层可输出 AA 01 00 02；存储层更适合保存原始 byte 或 Base64，避免文本解析歧义。

4. 网络抓包如何不误判

TCP 抓包中，一个应用帧可能跨多个 TCP segment，也可能多个帧位于同一 segment。分析时应让 Wireshark 重组 TCP 流，再按应用协议长度解析，不能把 packet 边界当 message 边界。

常用流程：

1
2
3
4
5

# Windows 上先列出捕获接口；接口编号因机器而异。
tshark -D

# 只示意捕获过滤器，先替换接口编号、设备地址和端口。
tshark -i 3 -f "host 192.0.2.10 and tcp port 5000" -w device-session.pcapng

Windows 上实时捕获常规网络接口需要安装并加载 Npcap（Wireshark 安装器可一并安装）；否则 tshark -D 可能仍显示部分 extcap 等接口，但无法正常捕获本机常规网卡流量。

192.0.2.0/24 是文档示例网段。真实环境应先确认捕获权限、接口位置和数据合规要求。TLS 会隐藏应用载荷；不要为了抓包在生产环境关闭证书验证或加密。

5. 记录格式要版本化

可回放记录不应只是程序日志。建议文件头包含：

1
2
3
4
5
6
7

FormatVersion
ProtocolName / ProtocolVersion
CaptureStartUtc
ClockFrequency / TimestampOrigin
DeviceIdentity / FirmwareVersion
TransportConfiguration
PayloadEncoding

每条记录使用相对单调时间、方向、连接世代和原始数据。格式版本不兼容时明确拒绝，避免新回放器悄悄误解旧数据。

6. 回放的三种时间模式

回放器默认不应连接真实设备或执行真实输出。把传输接口替换为内存端点，并通过显式开关才能进入硬件测试环境。

7. 模拟器不是返回固定成功

有效模拟器应复现协议和状态机，而不是每条命令都返回 OK。至少支持：

• 正常请求/响应与主动事件；
• 分片、粘包、乱序事件和迟到响应；
• CRC 错误、非法长度、未知命令；
• 设备 Busy、Faulted、NotReady；
• 执行后断线、重启和会话世代变化；
• 可控的虚拟时间。

模拟器越靠近传输层，越能测试真实解析器；越靠近业务能力层，越适合流程测试。两者用途不同，可以同时保留。设备行为模拟器与实机/HIL 测试梯度见《设备软件架构与控制模型（七）：实机、模拟器与 HIL》。

8. 契约测试

同一组协议向量应同时验证编码器、解码器和设备模拟器：

1
2
3
4

请求对象 → 编码 → 期望字节
原始字节 → 解码 → 期望对象
编码结果 → 解码 → 等价对象
错误字节 → 明确的拒绝原因

向量来源按可信度排序：标准规范示例、设备厂商确认样例、经人工标注的实机抓包、人工构造边界样例。不要把一次未知是否正确的现场抓包直接封为“黄金数据”。

9. 模糊测试与不变量

解析器适合做基于属性的测试。对任意 byte 输入，应满足：

• 不越界、不死循环、不无限分配；
• 每次返回要么需要更多数据，要么消费至少一个字节；
• 帧长永不超过契约上限；
• 错误输入不会产生未经验证的业务命令；
• 取消和关闭后没有后台任务泄漏。

模糊测试发现崩溃后，把最小化输入加入永久回归语料。

10. 现场问题闭环

一次完整问题包应包含：软件版本、设备身份与固件、配置快照、单调时间线、原始通信记录、解析日志、状态转换和复现步骤。修复后用同一记录回放，并增加一个能在旧版本失败、在新版本通过的自动化测试。

这比“多打一些日志再去现场”更重要：证据必须能驱动可重复验证。

11. 小结

协议诊断的关键是保持层次和可重建性：原始块、完整帧、请求关联和业务状态分别记录，再用版本化回放格式、真实状态模拟器和契约测试形成闭环。这样现场偶发故障才会变成可重复的软件输入。

参考资料

• Wireshark User’s Guide
• IETF：PCAP Next Generation (pcapng) Capture File Format
• Microsoft Learn：Unit testing C# with xUnit