在当前国家电网即将全面推行用GSP替代MMS的背景下，作为这两套协议的开发者，我想从规范角度和软件开发角度分享一下对IEC61850到这两种协议映射的感受和观点，若有谬误之处欢迎大家批评指正及给出宝贵意见。
我认为在IEC61850的世界里该和MMS道一声永别了，为什么这么说呢？因为在IEC61850的世界里MMS本来就不该来，可是事实上MMS就是活生生的存在于IEC61850的世界里，这又是为什么呢？
我先说说为什么MMS不该来，首先IEC61850标准的各方面非常完善，过程层通信部分也根据电力的实际需求制定了GOOSE/SV两种通信协议，而在站控层的TCP层面却采用了既有的工业自动化制造报文协议MMS，这么多工作都做了，为什么独独这么小的工作却映射给了MMS呢？又长篇大论的描述了映射机制呢？这就要从标准制定各方的利益博弈按活期了。IEC61850标准是一个国际性标准，各主要经济体中有影响力的相关方都参与其中，当然也包括中国。而其中老美的SISCO是通信协议的一大利益相关方，正是SISCO全力在IEC推动MMS的映射，并获得了采纳。可见，一项标准的方方面面都会有各方博弈和互相妥协的痕迹，并不仅仅是客观公平那么单纯。
那么，大家会说，选择MMS也没什么问题吧？已经用了这么多年了。然而在我看来其实问题很多。
MMS的问题
MMS(Manufacture Message Specification)是制造报文规范，本身是很优秀的规范，这一点是不能否认的，但是用在IEC61850就很牵强，MMS其场景和性能要求和电力的也不适应，更有诸多弊端，下面逐条分析一下：
IEC61850已经有自己的模型，只需要通讯协议解决通讯层面的问题，而MMS不是单单的通讯协议，使用MMS需要先转换到MMS模型，这就使得我们要做一次IEC61850模型向MMS模型转化的工作，IEC61850的标准上根本没有解释为什么要映射到MMS，国内倒是有人写文章说两者高度相似，我想说这两者充其量有一点点相似，查阅一下映射表我们可以看到原本有血有肉的逻辑节点（Logical Nodes）数据（Data）报告控制块（RCB）定值组控制块（SGCB）日志控制块（LCB）控制（Control）等全部映射到了MMS的有名变量（Named Variable Objects），这看着就不合理，实际上也给通讯开发上带来很多不便，要知道在网络通讯上还要把有名变量映射回IEC61850的模型，最后代码写的很别扭看起来更别扭。
再来看看引用方面的差异，直接举例对比如下表：
|
IEC61850
|
MMS
|
|
LDName/MMXU.PhV.PhsaA.cVal.mag.f
|
DomainID：LDName
ItemID：MMXU$MX$PhV$PhsaA$cVal$mag$f
|
|
LDName/MMXU.BufRptCB01
|
DomainID：LDName
ItemID：MMXU$RP$BufRptCB01
|
引用方式还是存在明显差异，特别是有一个小小的细节，就是MMS的引用多了功能约束，可能从来没有人质疑功能约束，我在这里斗胆说一下功能约束在IEC61850里很多情况下并不是必须的，但是在MMS里就是必须的，因为没有这个很多时候无法做到将有名变量映射回IEC61850的模型，比如功能约束没有BR，MMS中的层面就不知道是缓存报告控制块，没有SE就不知道是可编辑定值组。也就是功能约束可能更多为了让MMS有条件在IEC61850的世界里活下来而创造的。
同样的，服务映射也存在问题，比如GetAllDataValues、GetDataValues、GetDataSetValues、GetBRCBValues、Select等十多个服务都映射到了MMS的read一个服务上，同样也有SetDataValues、GetBRCBValues、Operate等十多个服务映射到MMS的write一个服务上，这样做太简单粗暴了，抹杀了IE61850接口的丰富性和针对性，非常的不合理。IEC61850向MMS映射貌似简单了，但是反过来解析的时候将read和write映射回原本的服务就显得很别扭，代码变得啰嗦，处理过程也极不合理。
IEC61850的变量类型和MMS不一致，需要一一转换，有些转换的也非常牵强，比如IEC61850里的质量类型，MMS中是不存在的，最后用的是位串，问题是还有其他IEC61850的类型也会转换到MMS的位串进行发送的，反过来如何解析呢？因为质量类型是13个bit，所以13个bit的位串就是质量类型，这样的代码写出来很可笑，但是又是没办法的。
大家都知道掌握IEC61850核心思想是有一定难度的，到了通讯部分应该尽量做一些易用性考虑，而MMS的规范真的很复杂难懂，写起来也很麻烦，就算用了MMSLite用起来也是很难用，掌握IEC61850核心思想是有意义的，付出一些辛苦也是值得的，但是此时额外增加的MMS难度实在是没有必要，白白浪费精力。
综上所述IEC61850作为新生的拥有先进理念的规范，实在不应该再让MMS存在于其中，其实大部分国人已经看到MMS的问题，国网也早就有替换的打算，加上中美贸易战让我们更加清楚美帝的真实面目，而且IEC61850很多应用于骨干电网的核心控制保护的实现上，安全性非常重要，尤其很多企业使用美国的MMSlite这里面是否有无法预估的风险我们不得不为此担忧。我们国家是时候该有属于自己的规范了，IEC61850的编委里有各个主要国家的委员，其标准本身是国际广泛合作共同努力编出来，完全符合电力思想，所以IEC61850还是会继续沿用，而MMS在我国一定会全面替换。目前已经有了规范的初稿，并且国网将会全力推行，届时国内企业也会积极响应。
MMS替代协议
下面我们就来认识一下国网的替代规范，其名称为GSP（General Service Protocol通用服务协议），IEC61850采用GSP有以下优点：
所有引用可直接采用的IEC61850的引用，并且不需要对象模型的映射工作，大大减少对象模型映射工作量的同时也降低了模型映射中的出错风险；
所有ACSI的服务接口都有一一对应的GSP服务接口，请求和应答参数一致，每个服务有专门的服务编码，直接针对性的解析，不像MMS解析报文后还需向IEC61850模型映射，需要对服务进行识别和对变量进行识别的过程；
GSP的数据类型与IEC61850存在差异非常小，几乎可以做到一一对应，这样大幅度减少了类型变化的工作量和出错风险；
采用PER编码，对网络传输的报文进行了压缩，节约了网络流量，提高传输效率；
GSP优势举例
下面我们通过实例进行两者优缺点的对比，考虑使能报告控制块是很常用的操作，我们不妨就以此为例：
首先服务端在启动服务的时候就做了一次对象映射的过程，这个对于程序员来说要付出相当多的工作，系统启动并映射完成后，当有客户端发来了使能报告控制块的请求时，由于走的是MMS协议，我们看到的只是write请求，这样我们要在MMS层找到是向哪个有名变量进行写操作，正常情况下我们找到了这个有名变量，但是很遗憾我们并不知道这个针对的是报告控制块的使能，好吧我们需要再检查一下，于是就开始对比，将报告控制块的所有字段逐个对比，终于我们发现了和报告控制块的使能字段是映射的，所以这是一个使能报告控制块的操作，那么可以进行使能操作，但是别忘了在不知道之前我们可能已经做了Goose、SV、日志、定值组、数据等等的对比也可能是之后对比，谁先谁后不重要，但是一个都不能少，纵然CPU很快，但是也不能如此暴殄天物啊。
如果换做GSP呢？首选服务端启动后不需要对象的映射，收到客户端的使能报告控制块的请求时通过服务编码立即可以知道是写报告控制块的请求，编码的Seq部分立即告诉我送来的是使能报告控制块字段，直接解析出来做使能报告控制块的操作就可以了。
现在GSP替代后的优点已经非常的显而易见了，如果说缺点倒也不是没有，比如采用PER编码其开发的复杂度大幅度提高了，再就是没有抓包工具支持，出现通讯问题比较难于定位，前者为了节约网络流量提高传输效率可以欣然接受，后者我相信用不了多久就会有抓包工具的支持，让我们拭目以待吧。
最后我再说说GSP替代的最大优点那就是它是属于我们国家自主的协议，一是不用但心受到约束，二是可以提高网络安全性，三是我们可以无限发挥我们中国人自己的智慧。
目前GSP替代MMS的规范已经基本完善，主流自动化厂家也已经实现并经过几轮测试，国网计划2021年底进行全面推广，希望GSP替代MMS的规范早日问世，我们也团结起来支持自主协议，让IEC61850在我们国家向MMS正式的道一声永别。
