第二讲：协议栈分层模型——OSI七层与IEC61850的映射
各位同学，今天我们聊聊协议栈的分层模型。说实话，很多初学者一看到OSI七层模型就头大，觉得太抽象。我当年刚接触IEC61850时也一样，心想：搞个通信协议而已，干嘛要搞这么复杂？
但后来在项目中吃过亏，才明白——分层不是没事找事，而是为了让我们能灵活替换底层技术，上层业务代码不用动一行。
2.1 OSI七层模型回顾
先简单过一下OSI七层，从上到下分别是：
- 应用层：用户与网络的接口，比如你发的IEC61850读写请求
- 表示层：数据格式转换、加密压缩
- 会话层：建立、管理、终止会话
- 传输层：端到端可靠传输（TCP/UDP）
- 网络层：路由寻址（IP）
- 数据链路层：帧封装、MAC地址（以太网）
- 物理层：比特流传输（网线、光纤）
嗯，这里要注意：IEC61850并没有完全照搬七层，而是做了精简和映射。说白了，它只用了其中几层，其他层要么合并，要么直接跳过。
2.2 IEC61850的映射关系
我个人习惯把IEC61850的协议栈画成一张图，这样一看就明白。下面是我用SVG画的分层映射图：
从这张图可以清楚看到：MMS跑在TCP/IP之上，走的是传统客户端/服务器模式。而GOOSE和SV则直接映射到数据链路层，跳过了TCP/IP的协议栈开销。为什么？因为GOOSE和SV要求实时性，毫秒级甚至微秒级延迟，TCP那套三次握手、重传机制根本玩不转。
2.3 核心分层详解
2.3.1 MMS——制造报文规范
MMS是IEC61850的"大管家"。所有读/写数据、控制命令、文件传输，都通过MMS完成。它工作在应用层，使用TCP连接，可靠但相对慢。
我在项目中遇到过一个问题：某次调试时，MMS连接总是超时。查了半天，发现是TCP窗口大小没调好，导致大文件传输卡死。后来把TCP接收缓冲从8K调到64K，问题解决。嗯，这种坑不踩一次真不知道。
MMS的核心特点：
- 面向连接（TCP 102端口）
- 请求-响应模式
- 适合配置、监控、日志等非实时业务
- 数据量大，但延迟容忍度高（几十毫秒级）
2.3.2 GOOSE——通用面向对象变电站事件
GOOSE是IEC61850里最"酷"的协议之一。它不建立连接，直接往以太网里发组播报文。一个装置跳闸了，GOOSE报文在1-3毫秒内就能通知到所有相关设备。
你想想看，传统变电站里，跳闸信号要走硬接线，一根电缆对应一个信号。有了GOOSE，一根网线就能传几百个信号。省了多少电缆和施工成本！
避坑指南：我曾经在调试GOOSE时，发现报文偶尔丢失。后来用Wireshark抓包一看，原来是交换机的IGMP Snooping没配好，组播报文被过滤了。记住：GOOSE依赖组播，交换机的组播配置必须正确。
2.3.3 SV——采样值
SV和GOOSE很像，也是组播模式，直接跑在以太网上。区别在于：SV传的是模拟量采样数据，比如电压、电流的瞬时值。一个SV报文里可能包含80个采样点，每秒钟发送4000帧甚至更高。
为什么会这么高频？因为保护装置需要精确的波形数据来做故障判断。采样率低了，波形失真，保护就可能误动或拒动。
注意：SV对网络带宽要求极高。一个9-2LE的SV流，每秒钟产生约10Mbps的数据。如果变电站有几十个间隔，网络必须精心设计，否则分分钟丢包。
2.4 三种协议对比
为了方便记忆，我整理了一个对比表：
| 特性 | MMS | GOOSE | SV |
|---|---|---|---|
| 通信模式 | 客户端/服务器 | 发布/订阅 | 发布/订阅 |
| 传输层 | TCP | 直接以太网 | 直接以太网 |
| 实时性 | 几十毫秒 | 1-3毫秒 | 微秒级 |
| 典型应用 | 读/写数据、控制 | 跳闸、合闸信号 | 电压电流采样 |
| 数据量 | 大 | 小 | 大（高频） |
| 可靠性机制 | TCP重传 | 重复发送 | 连续发送 |
2.5 我的经验总结
做IEC61850开发这些年，我最大的体会是：理解分层模型，是看懂协议栈的第一步。很多新手一上来就扎进代码里，结果被ASN.1编码、ACSI服务搞得晕头转向。其实你只要记住：
- MMS是"打电话"——建立连接，一问一答
- GOOSE是"喊广播"——不管谁在听，我直接喊
- SV是"直播流"——持续不断地往外推数据
这三种模式，覆盖了变电站里所有的通信需求。剩下的，无非是数据怎么打包、怎么解析的细节问题。那些细节，我们后面几章慢慢聊。
一句话记住本章：IEC61850协议栈把OSI七层压缩成三层核心——MMS（应用层）、GOOSE（链路层）、SV（链路层），分别对应不同的实时性要求。
公众号:蓝海资料掘金营，微信deep3321