1. 从一次抓包说起SV 采样值链路到底通没通如果你在变电站数字化改造现场做过调试大概率遇到过这种场景合并单元上电正常保护装置也没有告警但后台就是收不到采样值或者收到的数据通道映射对不上。这时候光看装置面板没用得把网口镜像出来抓包看 IEC61850 的 SV 报文到底有没有发、ASDU 里的字段对不对。SV全称 Sampled Value 采样测量值也叫 SMV是 IEC61850 体系里专门用来实时传输数字采样信息的通信服务。它跑在过程层负责把电子式电流电压互感器ECT/EVT经合并单元数字化后的瞬时采样值送到间隔层的继电保护、测控装置。和 GOOSE 一样SV 直接映射到数据链路层不走 TCP/IP以太网类型值是 0x88BAAPPID 建议范围 0x40000x7FFF。这篇文章面向正在做变电站数字化调试、需要对照抓包确认采样值链路的读者。我会从 SV 和 GOOSE 的定位差异切入重点拆 SMV 帧结构和 ASDU 数据单元每个字段的含义然后给出一套可复制的报文解析配置骨架最后逐字段告诉你怎么验证。适合已经了解 IEC61850 基本概念、但被 SV 报文细节卡住的工程人员。2. SV 与 GOOSE 的定位差异别把两者混为一谈很多人第一次接触 IEC61850 会以为 SV 和 GOOSE 差不多都是二层组播报文抓包工具里都能看到。实际上两者在体系里的位置、传输内容、重要性都不一样搞混了排查方向就会跑偏。2.1 传输内容与重要性SV 发送的是原始采样数据就是电流电压的瞬时值数据量大、频率高典型采样率是每周波 80 点或 256 点。GOOSE 发送的是快速报文和跳闸报文比如保护动作信号、开关位置事件驱动、重要性更高。简单说SV 是持续不断的数据流GOOSE 是关键时刻的命令。2.2 服务映射范围这是最容易踩坑的地方。GOOSE 和 GSSE 的管理都通过同样的二层网络实现但 SV 的报文走二层网络而 SV 的其他服务比如读写控制块是映射到了 MMS 协议。也就是说SV 是数据面走二层、控制面走 MMS的混合模式。作用范围上站控层/间隔层跑 MMS 和 GOOSE过程层跑 SV 和 GOOSE。2.3 以太网类型与地址分配对照下面这张表抓包时一眼就能区分报文类型类型以太网类型值APPID 范围目的 MAC 建议范围GOOSE0x88B80x0000 起01-0C-CD-01-00-00 ~ 01-0C-CD-01-01-FFGSE 管理0x88B90x0000 起01-0C-CD-02-00-00 ~ 01-0C-CD-02-01-FFSMV0x88BA0x4000~0x7FFF01-0C-CD-04-00-00 ~ 01-0C-CD-04-01-FF注意SV 的 APPID 建议从 0x4000 开始是为了把模拟量采样值和时间紧迫的保护相关 GOOSE 信息与低优先级的总线负载区分开。配置时别随手填个 0x0001会和 GOOSE 撞车。3. SMV 帧结构与 ASDU 字段逐层拆解理解了定位差异接下来进入正题。SV 报文从以太网帧头到 ASDU 数据单元每一层都有讲究。我按抓包工具里从上到下的顺序拆。3.1 以太网帧头部分SV 基于 ISO/IEC 8802-3 框架帧结构和 GOOSE 类似但部分字段有区别。前导码 7 字节、帧起始 1 字节是物理层的东西抓包工具一般不显示。从 MAC 报头开始目的地址 6 字节前四字节固定为 01-0C-CD-04后两字节按配置。源地址 6 字节就是发送方网口 MAC。优先级标记 TPID 2 字节固定 0x8100TCI 里包含 User priority、CFI 和 VID。User priority 的值要在配置时设置好用来区分优先级。以太网类型 2 字节固定 0x88BA这是识别 SV 报文的关键。再往下是 APPID 2 字节保留值范围 0x40000x7FFF。Length 2 字节包括从 APPID 开始的以太网型 PDU 的 8 位位组数目值为 8mm1480。然后是 2 字节保留 1、2 字节保留 2接着就是 APDU最后是必要的填充字节和帧校验序列。3.2 APDU 与 ASDU 的整体结构从以太网类型往下就是 SV 的 APDU基本格式是标记 长度 ASDU 的数目 n ASDU1 ASDU2 … ASDUn。其中 ASDU 的个数小于等于 12。每个 ASDU 结构包含 svID、datset、smpCnt、confRev、refrTm、smpSynch、smpRate 和 Sequence of Data。这里有个关键点标准定义里 datset、refrTm、smpRate 是可选字段实际抓包中经常没有。Sequence of Data 默认为字节串工程应用阶段采样值数据集会用 XML 描述。3.3 ASDU 各字段含义对照下面这张表是我对照 Wireshark 解析结果整理的注意 Wireshark 的定义和官方 ASN.1 描述有冲突时以 Wireshark 为准因为它能实际解析 pcap 包字段标记说明ASDU T_L60H标记 60H长度占用 1~3 字节由 ASN.1 格式决定noASDU80HASDU 个数12官方标准写 1~65535security81H可选现有 pcap 包无该字段svID80H字符串系统内唯一标志datset81H可选MSVCB 或 USVCB 的数据集需提前用 XML 描述smpCnt82H采样计数器每个新采样值加 1收到同步信号后置零confRev83H配置版本号配置被修改次数refrTm84HUtc 时间SV 缓冲区更新时间smpSynch85H同步标志采样值是否与时钟信号同步smpRate86H采样速率现有 pcap 包中无该字段seqData87H数据由 dataset 定义默认为字节串提示smpCnt 是排查采样链路最常用的字段。如果 smpCnt 不连续跳变说明合并单元采样或发送环节有问题如果 smpCnt 一直不归零说明同步信号没进来。3.4 9-1 与 9-2 的报文结构差异从发展历史看SMV 先后经历 IEC60044-8、IEC61850-9-1、IEC61850-9-2目前主要用 9-2 和 60044-8。IEC60044-8 是点对点光纤串行接口采用 FT3 格式不依赖外部同步时钟但物理接口专用、接线复杂。9-1/9-2 用标准以太网接口可以组网传输、利于数据共享但依赖外部时钟。9-1 的 SV 报文结构非常简单只有字节串具体信息含义定义在 IEC60044-8 中。9-2 的 APDU 报文结构就是上面拆解的这套工程应用阶段采样值数据集用 XML 描述。抓包时如果看到纯字节串没有 ASDU 标记那大概率是 9-1 或 FT3 格式。4. 可复制的报文解析配置骨架理论讲完上实操。下面给出一套用 Python Scapy 解析 SV 报文的配置骨架你可以直接复制到本地跑。前提是已经用 Wireshark 或 tcpdump 抓到了 SV 的 pcap 包。4.1 环境准备与依赖安装pip install scapyScapy 自带对 IEC61850 的部分支持但 SV 的 ASDU 解析需要自己补。先确认版本python -c import scapy; print(scapy.__version__)4.2 解析脚本骨架from scapy.all import rdpcap, Ether from scapy.layers.l2 import Dot1Q # SV 以太网类型 SV_ETHERTYPE 0x88BA def parse_sv_frame(pkt): if Ether not in pkt: return None eth pkt[Ether] if eth.type ! SV_ETHERTYPE: return None # 处理 VLAN 标签 offset 14 if Dot1Q in pkt: offset 4 raw bytes(pkt) appid int.from_bytes(raw[offset:offset2], big) length int.from_bytes(raw[offset2:offset4], big) apdu raw[offset8:offset8length-8] return { src: eth.src, dst: eth.dst, appid: hex(appid), length: length, apdu_hex: apdu.hex() } def parse_asdu(apdu): # 简化版 ASDU 解析按标记逐字段读取 result {} i 0 while i len(apdu): tag apdu[i] i 1 if tag 0x60: # ASDU T_L length apdu[i] i 1 result[asdu_len] length elif tag 0x80: # svID 或 noASDU length apdu[i] i 1 val apdu[i:ilength] if length 2: result[noASDU] int.from_bytes(val, big) else: result[svID] val.decode(ascii, errorsignore) i length elif tag 0x82: # smpCnt length apdu[i] i 1 result[smpCnt] int.from_bytes(apdu[i:ilength], big) i length elif tag 0x83: # confRev length apdu[i] i 1 result[confRev] int.from_bytes(apdu[i:ilength], big) i length elif tag 0x85: # smpSynch length apdu[i] i 1 result[smpSynch] apdu[i] i length elif tag 0x87: # seqData length apdu[i] i 1 result[seqData] apdu[i:ilength].hex() i length else: # 未知标记跳过 if i len(apdu): length apdu[i] i 1 length return result if __name__ __main__: pkts rdpcap(sv_capture.pcap) for pkt in pkts: info parse_sv_frame(pkt) if info: print(APPID:, info[appid], SRC:, info[src]) asdu parse_asdu(bytes.fromhex(info[apdu_hex])) print( ASDU:, asdu)4.3 配置参数说明脚本里几个关键参数需要按现场调整。SV_ETHERTYPE 固定 0x88BA 不用改。offset 初始 14 是标准以太网头长度如果抓包带 VLAN 标签要加 4。apdu 的起始位置是 offset8因为 APPID 2 字节 Length 2 字节 保留 1 2 字节 保留 2 2 字节共 8 字节。注意不同厂家合并单元的 ASDU 字段顺序可能有细微差异如果解析结果对不上先用 Wireshark 打开同一个 pcap 包对照它的解析树逐字段核对再调整脚本里的标记判断。5. 逐字段验证对照抓包确认采样值链路脚本跑通只是第一步真正要确认链路正常得逐字段验证。下面是我在实际项目里用的验证动作按顺序做一遍基本能定位大部分问题。5.1 验证 APPID 与目的 MAC先看 APPID 是否在 0x40000x7FFF 范围内目的 MAC 前四字节是否为 01-0C-CD-04。如果 APPID 是 0x0000 开头说明配置时没按规范设置可能和 GOOSE 冲突。如果目的 MAC 不是 01-0C-CD-04 开头说明组播地址配错了交换机可能没转发到保护装置。5.2 验证 noASDU 与 svIDnoASDU 应该小于等于 12。如果大于 12说明合并单元配置异常。svID 是系统内唯一标志对照 SCD 文件里的配置确认和设计一致。如果 svID 为空或乱码说明合并单元下装配置有问题。5.3 验证 smpCnt 连续性这是最关键的一步。把抓包按时间排序看 smpCnt 是否连续递增。正常情况下每个采样点加 1到 65535 后回绕到 0。如果出现跳变比如从 100 直接跳到 200说明中间丢了 100 个采样点可能是网络拥塞或合并单元发送异常。如果 smpCnt 一直不变说明合并单元没在更新采样值。5.4 验证 smpSynch 与 confRevsmpSynch 值为 0 表示不同步1 表示本地同步2 表示全局同步。保护装置对同步有要求如果 smpSynch 一直是 0保护可能闭锁。confRev 是配置版本号对照 SCD 文件确认如果和设计不一致说明合并单元下装的配置版本不对。5.5 验证 seqData 长度与通道映射seqData 是字节串长度由 dataset 定义。一个采样值通常占 8 字节4 字节电流 4 字节电压或按厂家定义。用 seqData 长度除以 8得到通道数对照 SCD 文件里的数据集定义确认通道映射正确。如果长度对不上说明数据集配置有误。6. 本篇常见错排查实际调试中下面这几个错误出现频率最高我按排查顺序列出来。6.1 抓不到 SV 报文先确认镜像口配置对不对SV 是组播报文交换机需要配置组播转发或镜像。再确认网口速率SV 采样率高时流量大百兆口可能丢包。最后确认合并单元是否真的在发用装置面板或配置工具看发送计数。6.2 解析出来 ASDU 字段错位大概率是 VLAN 标签没处理或者 APDU 起始位置算错了。先用 Wireshark 打开同一个包看它的解析树里 APDU 从第几字节开始对照调整脚本。另外注意 ASDU 可能有多个脚本要循环解析。6.3 smpCnt 不连续先看网络是否有丢包用交换机端口统计确认。再看合并单元采样是否正常用配置工具看采样计数。如果网络和采样都正常可能是抓包工具本身丢包换 tcpdump 命令行抓包对比。6.4 smpSynch 一直为 0检查外部时钟源是否接入合并单元的同步信号是否正常。如果是本地同步模式确认合并单元是否收到 GPS 或北斗对时。同步没建立前保护装置通常会闭锁 SV 相关功能。6.5 confRev 与 SCD 不一致说明合并单元下装的配置版本和当前 SCD 不匹配。重新下装配置或者核对 SCD 文件里的 confRev 值。这个字段是排查配置类问题的关键别忽略。7. 接入与验证用 TaoToken 跑通模型侧解析上面这套解析脚本和验证动作适合在本地环境跑。如果你想把 SV 报文解析和模型侧的分析结合起来比如让模型帮你解读 ASDU 字段、生成排查建议可以用 TaoToken 的 API 接入。先到 API Keys 页面创建密钥https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite然后参考接入文档配置https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite配置好后可以把解析出来的 ASDU 字段作为输入让模型帮你判断采样值链路是否正常。比如把 smpCnt、smpSynch、confRev 的值贴进去问它这些字段组合是否说明采样链路正常模型会给出排查方向。如果你想先验证模型对 IEC61850 术语的理解可以直接在模型对话页面测试https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite对于需要长期做变电站数字化调试、频繁解析 SV/GOOSE 报文的场景可以考虑 Coding Plan把解析脚本和排查流程固化下来https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite控制台入口在这里可以管理你的调用记录和用量https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite如果你用的是 Claude Code 做开发Anthropic 兼容接入方式可以参考https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite最后提醒一句SV 报文解析的核心是逐字段对照抓包验证脚本只是工具真正判断链路是否正常还得靠 smpCnt 连续性、smpSynch 同步状态和 confRev 版本一致性这三个硬指标。把这三个字段盯住大部分采样值链路问题都能定位。
1. 从一次抓包说起SV 采样值链路到底通没通如果你在变电站数字化改造现场做过调试大概率遇到过这种场景合并单元上电正常保护装置也没有告警但后台就是收不到采样值或者收到的数据通道映射对不上。这时候光看装置面板没用得把网口镜像出来抓包看 IEC61850 的 SV 报文到底有没有发、ASDU 里的字段对不对。SV全称 Sampled Value 采样测量值也叫 SMV是 IEC61850 体系里专门用来实时传输数字采样信息的通信服务。它跑在过程层负责把电子式电流电压互感器ECT/EVT经合并单元数字化后的瞬时采样值送到间隔层的继电保护、测控装置。和 GOOSE 一样SV 直接映射到数据链路层不走 TCP/IP以太网类型值是 0x88BAAPPID 建议范围 0x40000x7FFF。这篇文章面向正在做变电站数字化调试、需要对照抓包确认采样值链路的读者。我会从 SV 和 GOOSE 的定位差异切入重点拆 SMV 帧结构和 ASDU 数据单元每个字段的含义然后给出一套可复制的报文解析配置骨架最后逐字段告诉你怎么验证。适合已经了解 IEC61850 基本概念、但被 SV 报文细节卡住的工程人员。2. SV 与 GOOSE 的定位差异别把两者混为一谈很多人第一次接触 IEC61850 会以为 SV 和 GOOSE 差不多都是二层组播报文抓包工具里都能看到。实际上两者在体系里的位置、传输内容、重要性都不一样搞混了排查方向就会跑偏。2.1 传输内容与重要性SV 发送的是原始采样数据就是电流电压的瞬时值数据量大、频率高典型采样率是每周波 80 点或 256 点。GOOSE 发送的是快速报文和跳闸报文比如保护动作信号、开关位置事件驱动、重要性更高。简单说SV 是持续不断的数据流GOOSE 是关键时刻的命令。2.2 服务映射范围这是最容易踩坑的地方。GOOSE 和 GSSE 的管理都通过同样的二层网络实现但 SV 的报文走二层网络而 SV 的其他服务比如读写控制块是映射到了 MMS 协议。也就是说SV 是数据面走二层、控制面走 MMS的混合模式。作用范围上站控层/间隔层跑 MMS 和 GOOSE过程层跑 SV 和 GOOSE。2.3 以太网类型与地址分配对照下面这张表抓包时一眼就能区分报文类型类型以太网类型值APPID 范围目的 MAC 建议范围GOOSE0x88B80x0000 起01-0C-CD-01-00-00 ~ 01-0C-CD-01-01-FFGSE 管理0x88B90x0000 起01-0C-CD-02-00-00 ~ 01-0C-CD-02-01-FFSMV0x88BA0x4000~0x7FFF01-0C-CD-04-00-00 ~ 01-0C-CD-04-01-FF注意SV 的 APPID 建议从 0x4000 开始是为了把模拟量采样值和时间紧迫的保护相关 GOOSE 信息与低优先级的总线负载区分开。配置时别随手填个 0x0001会和 GOOSE 撞车。3. SMV 帧结构与 ASDU 字段逐层拆解理解了定位差异接下来进入正题。SV 报文从以太网帧头到 ASDU 数据单元每一层都有讲究。我按抓包工具里从上到下的顺序拆。3.1 以太网帧头部分SV 基于 ISO/IEC 8802-3 框架帧结构和 GOOSE 类似但部分字段有区别。前导码 7 字节、帧起始 1 字节是物理层的东西抓包工具一般不显示。从 MAC 报头开始目的地址 6 字节前四字节固定为 01-0C-CD-04后两字节按配置。源地址 6 字节就是发送方网口 MAC。优先级标记 TPID 2 字节固定 0x8100TCI 里包含 User priority、CFI 和 VID。User priority 的值要在配置时设置好用来区分优先级。以太网类型 2 字节固定 0x88BA这是识别 SV 报文的关键。再往下是 APPID 2 字节保留值范围 0x40000x7FFF。Length 2 字节包括从 APPID 开始的以太网型 PDU 的 8 位位组数目值为 8mm1480。然后是 2 字节保留 1、2 字节保留 2接着就是 APDU最后是必要的填充字节和帧校验序列。3.2 APDU 与 ASDU 的整体结构从以太网类型往下就是 SV 的 APDU基本格式是标记 长度 ASDU 的数目 n ASDU1 ASDU2 … ASDUn。其中 ASDU 的个数小于等于 12。每个 ASDU 结构包含 svID、datset、smpCnt、confRev、refrTm、smpSynch、smpRate 和 Sequence of Data。这里有个关键点标准定义里 datset、refrTm、smpRate 是可选字段实际抓包中经常没有。Sequence of Data 默认为字节串工程应用阶段采样值数据集会用 XML 描述。3.3 ASDU 各字段含义对照下面这张表是我对照 Wireshark 解析结果整理的注意 Wireshark 的定义和官方 ASN.1 描述有冲突时以 Wireshark 为准因为它能实际解析 pcap 包字段标记说明ASDU T_L60H标记 60H长度占用 1~3 字节由 ASN.1 格式决定noASDU80HASDU 个数12官方标准写 1~65535security81H可选现有 pcap 包无该字段svID80H字符串系统内唯一标志datset81H可选MSVCB 或 USVCB 的数据集需提前用 XML 描述smpCnt82H采样计数器每个新采样值加 1收到同步信号后置零confRev83H配置版本号配置被修改次数refrTm84HUtc 时间SV 缓冲区更新时间smpSynch85H同步标志采样值是否与时钟信号同步smpRate86H采样速率现有 pcap 包中无该字段seqData87H数据由 dataset 定义默认为字节串提示smpCnt 是排查采样链路最常用的字段。如果 smpCnt 不连续跳变说明合并单元采样或发送环节有问题如果 smpCnt 一直不归零说明同步信号没进来。3.4 9-1 与 9-2 的报文结构差异从发展历史看SMV 先后经历 IEC60044-8、IEC61850-9-1、IEC61850-9-2目前主要用 9-2 和 60044-8。IEC60044-8 是点对点光纤串行接口采用 FT3 格式不依赖外部同步时钟但物理接口专用、接线复杂。9-1/9-2 用标准以太网接口可以组网传输、利于数据共享但依赖外部时钟。9-1 的 SV 报文结构非常简单只有字节串具体信息含义定义在 IEC60044-8 中。9-2 的 APDU 报文结构就是上面拆解的这套工程应用阶段采样值数据集用 XML 描述。抓包时如果看到纯字节串没有 ASDU 标记那大概率是 9-1 或 FT3 格式。4. 可复制的报文解析配置骨架理论讲完上实操。下面给出一套用 Python Scapy 解析 SV 报文的配置骨架你可以直接复制到本地跑。前提是已经用 Wireshark 或 tcpdump 抓到了 SV 的 pcap 包。4.1 环境准备与依赖安装pip install scapyScapy 自带对 IEC61850 的部分支持但 SV 的 ASDU 解析需要自己补。先确认版本python -c import scapy; print(scapy.__version__)4.2 解析脚本骨架from scapy.all import rdpcap, Ether from scapy.layers.l2 import Dot1Q # SV 以太网类型 SV_ETHERTYPE 0x88BA def parse_sv_frame(pkt): if Ether not in pkt: return None eth pkt[Ether] if eth.type ! SV_ETHERTYPE: return None # 处理 VLAN 标签 offset 14 if Dot1Q in pkt: offset 4 raw bytes(pkt) appid int.from_bytes(raw[offset:offset2], big) length int.from_bytes(raw[offset2:offset4], big) apdu raw[offset8:offset8length-8] return { src: eth.src, dst: eth.dst, appid: hex(appid), length: length, apdu_hex: apdu.hex() } def parse_asdu(apdu): # 简化版 ASDU 解析按标记逐字段读取 result {} i 0 while i len(apdu): tag apdu[i] i 1 if tag 0x60: # ASDU T_L length apdu[i] i 1 result[asdu_len] length elif tag 0x80: # svID 或 noASDU length apdu[i] i 1 val apdu[i:ilength] if length 2: result[noASDU] int.from_bytes(val, big) else: result[svID] val.decode(ascii, errorsignore) i length elif tag 0x82: # smpCnt length apdu[i] i 1 result[smpCnt] int.from_bytes(apdu[i:ilength], big) i length elif tag 0x83: # confRev length apdu[i] i 1 result[confRev] int.from_bytes(apdu[i:ilength], big) i length elif tag 0x85: # smpSynch length apdu[i] i 1 result[smpSynch] apdu[i] i length elif tag 0x87: # seqData length apdu[i] i 1 result[seqData] apdu[i:ilength].hex() i length else: # 未知标记跳过 if i len(apdu): length apdu[i] i 1 length return result if __name__ __main__: pkts rdpcap(sv_capture.pcap) for pkt in pkts: info parse_sv_frame(pkt) if info: print(APPID:, info[appid], SRC:, info[src]) asdu parse_asdu(bytes.fromhex(info[apdu_hex])) print( ASDU:, asdu)4.3 配置参数说明脚本里几个关键参数需要按现场调整。SV_ETHERTYPE 固定 0x88BA 不用改。offset 初始 14 是标准以太网头长度如果抓包带 VLAN 标签要加 4。apdu 的起始位置是 offset8因为 APPID 2 字节 Length 2 字节 保留 1 2 字节 保留 2 2 字节共 8 字节。注意不同厂家合并单元的 ASDU 字段顺序可能有细微差异如果解析结果对不上先用 Wireshark 打开同一个 pcap 包对照它的解析树逐字段核对再调整脚本里的标记判断。5. 逐字段验证对照抓包确认采样值链路脚本跑通只是第一步真正要确认链路正常得逐字段验证。下面是我在实际项目里用的验证动作按顺序做一遍基本能定位大部分问题。5.1 验证 APPID 与目的 MAC先看 APPID 是否在 0x40000x7FFF 范围内目的 MAC 前四字节是否为 01-0C-CD-04。如果 APPID 是 0x0000 开头说明配置时没按规范设置可能和 GOOSE 冲突。如果目的 MAC 不是 01-0C-CD-04 开头说明组播地址配错了交换机可能没转发到保护装置。5.2 验证 noASDU 与 svIDnoASDU 应该小于等于 12。如果大于 12说明合并单元配置异常。svID 是系统内唯一标志对照 SCD 文件里的配置确认和设计一致。如果 svID 为空或乱码说明合并单元下装配置有问题。5.3 验证 smpCnt 连续性这是最关键的一步。把抓包按时间排序看 smpCnt 是否连续递增。正常情况下每个采样点加 1到 65535 后回绕到 0。如果出现跳变比如从 100 直接跳到 200说明中间丢了 100 个采样点可能是网络拥塞或合并单元发送异常。如果 smpCnt 一直不变说明合并单元没在更新采样值。5.4 验证 smpSynch 与 confRevsmpSynch 值为 0 表示不同步1 表示本地同步2 表示全局同步。保护装置对同步有要求如果 smpSynch 一直是 0保护可能闭锁。confRev 是配置版本号对照 SCD 文件确认如果和设计不一致说明合并单元下装的配置版本不对。5.5 验证 seqData 长度与通道映射seqData 是字节串长度由 dataset 定义。一个采样值通常占 8 字节4 字节电流 4 字节电压或按厂家定义。用 seqData 长度除以 8得到通道数对照 SCD 文件里的数据集定义确认通道映射正确。如果长度对不上说明数据集配置有误。6. 本篇常见错排查实际调试中下面这几个错误出现频率最高我按排查顺序列出来。6.1 抓不到 SV 报文先确认镜像口配置对不对SV 是组播报文交换机需要配置组播转发或镜像。再确认网口速率SV 采样率高时流量大百兆口可能丢包。最后确认合并单元是否真的在发用装置面板或配置工具看发送计数。6.2 解析出来 ASDU 字段错位大概率是 VLAN 标签没处理或者 APDU 起始位置算错了。先用 Wireshark 打开同一个包看它的解析树里 APDU 从第几字节开始对照调整脚本。另外注意 ASDU 可能有多个脚本要循环解析。6.3 smpCnt 不连续先看网络是否有丢包用交换机端口统计确认。再看合并单元采样是否正常用配置工具看采样计数。如果网络和采样都正常可能是抓包工具本身丢包换 tcpdump 命令行抓包对比。6.4 smpSynch 一直为 0检查外部时钟源是否接入合并单元的同步信号是否正常。如果是本地同步模式确认合并单元是否收到 GPS 或北斗对时。同步没建立前保护装置通常会闭锁 SV 相关功能。6.5 confRev 与 SCD 不一致说明合并单元下装的配置版本和当前 SCD 不匹配。重新下装配置或者核对 SCD 文件里的 confRev 值。这个字段是排查配置类问题的关键别忽略。7. 接入与验证用 TaoToken 跑通模型侧解析上面这套解析脚本和验证动作适合在本地环境跑。如果你想把 SV 报文解析和模型侧的分析结合起来比如让模型帮你解读 ASDU 字段、生成排查建议可以用 TaoToken 的 API 接入。先到 API Keys 页面创建密钥https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite然后参考接入文档配置https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite配置好后可以把解析出来的 ASDU 字段作为输入让模型帮你判断采样值链路是否正常。比如把 smpCnt、smpSynch、confRev 的值贴进去问它这些字段组合是否说明采样链路正常模型会给出排查方向。如果你想先验证模型对 IEC61850 术语的理解可以直接在模型对话页面测试https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite对于需要长期做变电站数字化调试、频繁解析 SV/GOOSE 报文的场景可以考虑 Coding Plan把解析脚本和排查流程固化下来https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite控制台入口在这里可以管理你的调用记录和用量https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite如果你用的是 Claude Code 做开发Anthropic 兼容接入方式可以参考https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite最后提醒一句SV 报文解析的核心是逐字段对照抓包验证脚本只是工具真正判断链路是否正常还得靠 smpCnt 连续性、smpSynch 同步状态和 confRev 版本一致性这三个硬指标。把这三个字段盯住大部分采样值链路问题都能定位。
