2021-07-20

在当前国家电网即将全面推行用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,国内倒是有人写文章说两者高度相似,我想说这两者充其量有一点点相似。

再来看看引用方面的差异,直接举例对比如下表:

IEC61850MMS
LDName/MMXU.PhV.PhsaA.cVal.mag.fDomainID:LDName, ItemID:MMXU$MX$PhV$PhsaA$cVal$mag$f
LDName/MMXU.BufRptCB01DomainID:LDName, ItemID:MMXU$RP$BufRptCB01

引用方式还是存在明显差异,特别是MMS的引用多了功能约束,功能约束在IEC61850里很多情况下并不是必须的,但是在MMS里就是必须的。同样的,服务映射也存在问题,比如GetAllDataValues、GetDataValues等十多个服务都映射到了MMS的read一个服务上,这样做太简单粗暴了,抹杀了IEC61850接口的丰富性和针对性。

类型差异问题

IEC61850的变量类型和MMS不一致,需要一一转换,有些转换的也非常牵强。

易用性考虑

大家都知道掌握IEC61850核心思想是有一定难度的,到了通讯部分应该尽量做一些易用性考虑,而MMS的规范真的很复杂难懂,额外增加的MMS难度实在是没有必要。

综上所述IEC61850作为新生的拥有先进理念的规范,实在不应该再让MMS存在于其中。我们国家是时候该有属于自己的规范了。目前已经有了规范的初稿,并且国网将会全力推行。

MMS替代协议

下面我们就来认识一下国网的替代规范,其名称为GSP(General Service Protocol通用服务协议),IEC61850采用GSP有以下优点:

GSP优势举例

下面我们通过使能报告控制块这一常用操作进行对比:在MMS协议下,服务端需要完成对象映射,收到客户端请求后看到的只是write请求,需要逐个对比字段才能确定操作类型。而换做GSP,服务端启动后不需要对象的映射,收到请求时通过服务编码立即可以知道操作类型,直接解析处理即可。

GSP替代后的优点已经非常的显而易见了。最后GSP替代的最大优点是它属于我们国家自主的协议,一是不用担心受到约束,二是可以提高网络安全性,三是我们可以无限发挥我们中国人自己的智慧。

目前GSP替代MMS的规范已经基本完善,主流自动化厂家也已经实现并经过几轮测试,国网计划2021年底进行全面推广,让我们拭目以待。