3. MMS协议详解：制造报文规范
MMS协议，全称是制造报文规范。说实话，我刚接触变电站通信时，觉得这名字挺唬人的。后来做项目多了才发现，它其实就是一套让智能电子设备（IED）之间能「好好说话」的规则。
为什么变电站要用MMS？我个人的理解是：变电站里的设备五花八门，有保护装置、测控装置、智能终端……每个厂家都有自己的通信方式。MMS就像个翻译官，让这些设备能互相理解。嗯，这里要注意，MMS可不是什么新协议，它在工业自动化领域已经用了三十多年了。
3.1 MMS的原理
MMS的核心思想其实很简单——虚拟制造设备（VMD）。你想想看，每个IED内部都有各种功能，比如遥测、遥信、遥控。MMS把这些功能抽象成标准化的对象，然后通过读写这些对象来实现通信。
我举个例子。你在变电站里看到一个保护装置，它内部有测量值、定值、状态量。MMS就把这些抽象成：
- 命名变量：比如电流值、电压值
- 命名变量列表：一组相关的变量，比如三相电流
- 日志：事件记录、故障录波
- 文件：配置文件、录波文件
说白了，MMS就是定义了一套「对象模型」和「服务」。客户端（比如后台监控系统）通过调用服务来操作这些对象。服务包括读、写、报告、订阅等等。
核心要点：MMS是C/S架构，客户端发起请求，服务器响应。但变电站里很多设备既是客户端又是服务器，比如保护装置既要响应后台的查询，也要主动上送告警。
我在项目中遇到过一个问题：两个不同厂家的保护装置，都声称支持MMS，但就是通不上。后来发现，一个用的是MMS的「读」服务，另一个用的是「读后响应」服务。虽然功能一样，但服务名称不同。这就是MMS的灵活性带来的坑。
3.2 MMS在变电站中的应用
在IEC 61850标准里，MMS被用来承载大部分通信。具体来说：
| 应用场景 | MMS服务 | 说明 |
|---|---|---|
| 遥测上送 | 读/报告 | 电流、电压、功率等模拟量 |
| 遥信上送 | 报告 | 开关位置、告警信号等状态量 |
| 遥控操作 | 写 | 分合闸命令、档位调节 |
| 定值读写 | 读/写 | 保护定值、参数设置 |
| 文件传输 | 文件服务 | 故障录波、事件记录 |
| 日志查询 | 日志服务 | SOE、操作记录 |
我建议你重点关注「报告」服务。为什么？因为变电站里大部分数据都是通过报告上送的。报告有两种模式：
- 缓存报告：数据变化时先存起来，等客户端来取。适合不要求实时性的数据。
- 非缓存报告：数据变化立即发送。适合保护动作、开关变位等实时性要求高的数据。
记得有一次，一个变电站的遥信老是延迟。我排查了半天，发现是报告配置错了——把非缓存报告配成了缓存报告。改过来后，延迟从秒级降到了毫秒级。嗯，配置细节真的很重要。
3.3 MMS报文结构与编码
MMS报文长什么样？我直接给你看个实际抓包的例子。这是从变电站现场抓的一个MMS读请求报文：
MMS: invokeID: 12345
MMS: confirmedRequestPDU
MMS: read
MMS: variableAccessSpecification
MMS: listOfVariable
MMS: [0] objectName
MMS: domainSpecific
MMS: domainName: "PROT1"
MMS: itemName: "GGIO1.AnIn1.mag.f"
这个报文在说：客户端请求读取PROT1设备里GGIO1逻辑节点的AnIn1数据对象的mag属性（幅值），f表示浮点数。
MMS的编码用的是ASN.1的BER编码。说白了，就是TLV格式——Tag（标签）、Length（长度）、Value（值）。每个数据都打上标签，告诉接收方这是什么类型的数据。
小技巧：抓包分析MMS报文时，重点关注invokeID。这个ID是请求和响应的配对标识。如果发现响应超时，先看看invokeID对不对得上。
我曾经调试过一个MMS通信问题，客户端一直报超时。抓包一看，客户端发的invokeID是1，服务器回的也是1，但客户端期望的是2。原来是客户端的ID生成逻辑有bug，每次请求后没递增。这种问题，不看报文根本发现不了。
MMS报文结构分三层：
- MMS PDU：协议数据单元，包含服务类型（读、写、报告等）
- 调用参数：具体服务的参数，比如读哪个变量
- 数据内容：实际的数据值
下面这张图展示了MMS报文在TCP/IP协议栈中的位置：
实际项目中，MMS报文大小一般在几百字节到几KB。遥测数据小一些，文件传输可能到MB级别。我建议你在配置网络时，把MTU设成1500字节以上，避免MMS报文被分片。
注意：MMS报文如果太大，会被TCP分片。分片后如果某个分片丢了，整个报文都得重传。所以对于大文件传输，建议用MMS的文件服务，而不是用变量读写。
最后说个经验。调试MMS通信时，我习惯先用Wireshark抓包，过滤条件设成mms。然后看三个东西：
- invokeID是否连续
- 响应时间是否在合理范围内（一般<100ms）
- 有没有重传包
这三个指标基本能判断MMS通信是否健康。如果发现重传多，先检查网络，再检查设备负载。我曾经遇到一个情况，设备CPU负载到90%了，MMS响应时间从20ms飙到500ms。后来发现是设备在同时处理多个MMS连接，线程池不够用了。
嗯，MMS协议就讲这么多。记住它的核心：对象模型+服务调用。理解了这两点，MMS就不难了。
公众号:蓝海资料掘金营，微信deep3321