企业官网建设流程全解析

1. 从一次抓包说起：SV 采样值链路到底通没通

如果你在变电站数字化改造现场做过调试，大概率遇到过这种场景：合并单元上电正常，保护装置也没有告警，但后台就是收不到采样值，或者收到的数据通道映射对不上。这时候光看装置面板没用，得把网口镜像出来抓包，看 IEC61850 的 SV 报文到底有没有发、ASDU 里的字段对不对。

SV，全称 Sampled Value 采样测量值，也叫 SMV，是 IEC61850 体系里专门用来实时传输数字采样信息的通信服务。它跑在过程层，负责把电子式电流电压互感器（ECT/EVT）经合并单元数字化后的瞬时采样值，送到间隔层的继电保护、测控装置。和 GOOSE 一样，SV 直接映射到数据链路层，不走 TCP/IP，以太网类型值是 0x88BA，APPID 建议范围 0x4000～0x7FFF。

这篇文章面向正在做变电站数字化调试、需要对照抓包确认采样值链路的读者。我会从 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 以太网类型与地址分配

对照下面这张表，抓包时一眼就能区分报文类型：

注意：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 字节固定 0x8100，TCI 里包含 User priority、CFI 和 VID。User priority 的值要在配置时设置好，用来区分优先级。以太网类型 2 字节固定 0x88BA，这是识别 SV 报文的关键。

再往下是 APPID 2 字节，保留值范围 0x4000～0x7FFF。Length 2 字节，包括从 APPID 开始的以太网型 PDU 的 8 位位组数目，值为 8+m（m<1480）。然后是 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 包：

提示：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 scapy

Scapy 自带对 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:offset+2], 'big') length = int.from_bytes(raw[offset+2:offset+4], 'big') apdu = raw[offset+8:offset+8+length-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:i+length] if length <= 2: result['noASDU'] = int.from_bytes(val, 'big') else: result['svID'] = val.decode('ascii', errors='ignore') i += length elif tag == 0x82: # smpCnt length = apdu[i] i += 1 result['smpCnt'] = int.from_bytes(apdu[i:i+length], 'big') i += length elif tag == 0x83: # confRev length = apdu[i] i += 1 result['confRev'] = int.from_bytes(apdu[i:i+length], '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:i+length].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 的起始位置是 offset+8，因为 APPID 2 字节 + Length 2 字节 + 保留 1 2 字节 + 保留 2 2 字节，共 8 字节。

注意：不同厂家合并单元的 ASDU 字段顺序可能有细微差异，如果解析结果对不上，先用 Wireshark 打开同一个 pcap 包，对照它的解析树逐字段核对，再调整脚本里的标记判断。

5. 逐字段验证：对照抓包确认采样值链路

脚本跑通只是第一步，真正要确认链路正常，得逐字段验证。下面是我在实际项目里用的验证动作，按顺序做一遍，基本能定位大部分问题。

5.1 验证 APPID 与目的 MAC

先看 APPID 是否在 0x4000～0x7FFF 范围内，目的 MAC 前四字节是否为 01-0C-CD-04。如果 APPID 是 0x0000 开头，说明配置时没按规范设置，可能和 GOOSE 冲突。如果目的 MAC 不是 01-0C-CD-04 开头，说明组播地址配错了，交换机可能没转发到保护装置。

5.2 验证 noASDU 与 svID

noASDU 应该小于等于 12。如果大于 12，说明合并单元配置异常。svID 是系统内唯一标志，对照 SCD 文件里的配置，确认和设计一致。如果 svID 为空或乱码，说明合并单元下装配置有问题。

5.3 验证 smpCnt 连续性

这是最关键的一步。把抓包按时间排序，看 smpCnt 是否连续递增。正常情况下每个采样点加 1，到 65535 后回绕到 0。如果出现跳变，比如从 100 直接跳到 200，说明中间丢了 100 个采样点，可能是网络拥塞或合并单元发送异常。如果 smpCnt 一直不变，说明合并单元没在更新采样值。

5.4 验证 smpSynch 与 confRev

smpSynch 值为 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_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite

然后参考接入文档配置：https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite

配置好后，可以把解析出来的 ASDU 字段作为输入，让模型帮你判断采样值链路是否正常。比如把 smpCnt、smpSynch、confRev 的值贴进去，问它"这些字段组合是否说明采样链路正常"，模型会给出排查方向。

如果你想先验证模型对 IEC61850 术语的理解，可以直接在模型对话页面测试：https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite

对于需要长期做变电站数字化调试、频繁解析 SV/GOOSE 报文的场景，可以考虑 Coding Plan，把解析脚本和排查流程固化下来：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite

控制台入口在这里，可以管理你的调用记录和用量：https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite

如果你用的是 Claude Code 做开发，Anthropic 兼容接入方式可以参考：https://taotoken.net/claude-code-anthropic?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite

最后提醒一句：SV 报文解析的核心是逐字段对照抓包验证，脚本只是工具，真正判断链路是否正常，还得靠 smpCnt 连续性、smpSynch 同步状态和 confRev 版本一致性这三个硬指标。把这三个字段盯住，大部分采样值链路问题都能定位。