先划清区的边界
工控系统是链条式结构：传感器到控制器、控制器到网络、网络到上位采集、上位到业务应用。故障时各方看到的现象往往只是链条中的一段，容易互相推责。隔离判定的目的不是分清责任，而是尽快把问题缩小到一个确定的区段——用“这一段是好的、那一段是坏的”这种二值判断，替代无休止的现象争论。
基本信息
| 链条环节 | 现场信号、控制层、网络层、上位采集、业务应用 |
|---|---|
| 判定方法 | 分段替换、旁路注入、双点比对、独立工具直连 |
| 关键证据 | 每一段边界处的实际输入与输出数据，而非各方描述 |
| 沟通要求 | 把事实与推断分开记录，避免把推测当结论 |
典型使用场景
- 上位系统没有数据，需要判断是控制器、网关还是采集服务问题
- 两个系统数据不一致，需要确定以哪一段为基准
- 现场动作与上位显示不符，需要判断信号在哪一段失真
- 多方厂家互相推责时，用分段证据推动问题收敛
- 新增环节后出现异常，需要确认是新增段引起还是原有段劣化
分段判定手段
| 手段 | 做法 | 能得到什么 |
|---|---|---|
| 分段替换 | 用已知正常的部件替换可疑段 | 替换后恢复正常即可定位该段 |
| 旁路注入 | 在段边界注入已知正确信号 | 下游正常则说明故障在上游或本段 |
| 双点比对 | 在上下游两端同时读同一物理量 | 数值差异说明中间段存在问题 |
| 独立工具直连 | 用测试工具绕过中间环节直连设备 | 绕过后正常说明问题在中间环节 |
边界同时取证
边界同时取证
# 在每个边界同时留证据，而不是只在一端观察
# 1) 控制器侧：在线读取变量实际值并记录设备时间戳
# 2) 网络侧：抓包确认报文是否真的到达下游
tcpdump -i eth0 -nn host 192.168.1.10 -w boundary.pcap
# 3) 上位侧：记录采集服务的连接与超时日志时间点
# 4) 三处时间对齐后，即可判断报文在哪一段停止或变形判定应按“段”而不是按“设备”来做。一段里可能有多台设备与多条链路，先确认整段是否正常，再往段内细分，比一上来逐台怀疑效率高得多。
时间戳对齐是分段判定的前提。控制器、网络设备与上位主机时间不同源时日志顺序会失真，得出的因果关系很可能是错的，应先做时间同步再比对。
把事实与推断分开写进记录。“控制器应该没问题”是推断，“控制器端口无报文输出”是事实，只有后者能作为判定依据，也才能让其他方接受。