IEC61850国产替代协议CMS的优势详解

IEC61850国产替代协议CMS的优势详解

概述

CMS是通信报文规范 communication message specification 的简写，早期也有GSP的叫法。
它一个应用层的协议标准，将 DL/T 860 抽象通信服务接口直接映射到 TCP/IP 传输协议集，实现智能电子设备之间双向报文通信。

2024年初千呼万唤的CMS正式版终于发布了，全名《变电站二次系统通信报文规范》累计90页，主要目的是全面替代MMS，对应的一致性测试规范是《智能变电站自动化设备检测规范 第 12 部分：二次系统通信报文一致性》

IEC61850标准的8-1的标准页数是198页，而且仅仅是模型的映射部分，并不包含通讯编码规范，通讯规范需要查阅MMS的相关规范，关于通讯编码部分，英语原版少说500页，而MMS的服务定义，少说也有300页。而这些在CMS规范中，总计只需要90页。

我们还有个说法叫MMS国产替代协议，首先突出了这个协议是国产，是由国家电网有限公司牵头发布，其次就是替代，彻底抛弃MMS协议规范。

先抛出疑问
要知道IEC61850在我们国内已经流行十多年了，运行的智能设备数不胜数，支持IEC61850智能设备的成熟企业也数不胜数，为何此时还要替换其中的MMS协议呢？此举不是劳民伤财吗？其实这里面还是有非常充分的理由的，这里我也不多说了，我先描绘一下CMS和MMS的详细差异，大家就一目了然了。

CMS与MMS的差异

模型差异

MMS需要建立模型，模型差异如下

IEC61850	MMS
服务器(Server)	虚拟制造设备(VMD)
逻辑设备(LD)	域(Domain)
逻辑节点(LN)	有名变量(Named Variable)
数据(Data)	有名变量(Named Variable)
数据属性(DA)	有名变量(Named Variable)
数据集(Data Set)	有名变量列表(Named Variable List)
控制块(Control Block)	有名变量(Named Variable)
日志(log)	日志(Journal)
文件(File)	文件(File)

而CMS完全采用了IEC61850的模型，无需映射。

引用差异

模型	IEC61850	MMS
数据	LDName/MMXU.PhV.PhsaA.cVal.mag	LDName/MMXU$MX$PhV$PhsaA$cVal$mag
控制块	LDName/MMXU.BufRptCB01	LDName/MMXU$RP$BufRptCB01

CMS采用IEC61850引用

服务映射的差异

首先我们看看IEC61850和MMS版本服务服务的映射关系

IEC61850	MMS
Associate	Initiate
Abort	Abort
Release	Conelude
GetServerDirectory	GetNameList
GetLogicDeviceDirectory	GetNameList
GetLogicNodeDirectory	GetNameList
GetAllDataValues	Read
GetAllCBValues	Read
GetDataValues	Read
SetDataValues	Read
GetDataDirectory	GetVariableAccessAttribute
GetDataDefinition	GetVariableAccessAttribute
CreateDataSet	DefineNamedVariableList
DeleteDataSet	DeleteNamedVariableList
GetDataSetDirectory	GetNamedVariableListAttribute
GetDataSetValues	Read
SetDataSetValues	Write
Select	Read
SelectWithValue	Write
Cancel	Write
Operate	Write
CommandTermination	InformationReport
TimeActivatedOperate	Write
TimeActivatedOperateTermination	Write
SelectActiveSG	Write
SelectEditSG	Write
SetEditSGValue	Write
ConfirmEditSGValues	Write
GetEditSGValue	Read
GetSGCBValues	Read
Report	InformationReport
GetBRCBValues	Read
SetBRCBValues	Write
GetURCBValues	Read
SetURCBValues	Write
GetLCBValues	Read
SetLCBValues	Write
QueryLogByTime	ReadJournal
QueryLogAfter	ReadJournal
GetLogStatusValues	Read
GetGoCBValues	Read
SetGoCBValues	Write
GetMSVCBValues	Read
SetMSVCBValues	Write
GetFile	FileOpen/FileRead/FileClose
SetFile	ObtainFile/FileOpen/FileRead/FileClose
DeleteFile	FileDelete
GetFileAttributeValues	FileDirectory
GetFileDirectory	FileDirectory

可以看到还是存在相当多的差异的，而上述接口在CMS版本与IEC61850接口完全一致，除此以外CMS标准中还增加了如下接口

名称	描述
GetRpcInterfaceDirectory	读远程过程调用接口目录服务
GetRpcMethodDIrectory	读远程过程调用方法目录服务
GetRpcInterfaceDefinition	读远程过程调用接口定义服务
GetRpcMethodDefinition	读远程过程调用方法定义服务
RpcCall	远程过程调用服务，可以远程调用服务端提供的任意功能接口，为服务的扩展提供了无限的空间
Test	测试
AssociateNegotiate	关联协商
GetAllDataDefinition	读所有数据定义

数据类型的差异

SCL类型是指在模型文件中的类型，例如CID模型文件；
IE61850类型是运行中内部模型中的类型；
CMS类型是用于CMS协议网络通讯的类型；

差异带来的问题

模型差异带来的问题

1、模型映射本身就是问题
IEC61850已经有非常完善的模型，还要映射为MMS模型这本身就是最大的问题，就好像我已经建了一栋IEC61850办公大楼，大楼有名称有地址，然后有不同的楼层及房间，每个房间也有不同的功能比如有办公室、会议室、打印室、广播室、卫生间等等，但是对外我还要盖一栋房子，叫MMS办公大楼，MMS大楼的房间与IEC61850办公大楼的一一对应，对外大家只能看到这个MMS办公大楼，看不到IEC61850办公大楼，所有对IEC61850办公大楼的使用都要通过MMS办公大楼才能实现，这显然是大大的不合理。
2、映射的并不科学
好的映射最好是一对一，然而通过差异可见IEC61850的逻辑节点、数据、数据属性、控制块全部映射为MMS的有名变量，也就是说在IEC61850办公大楼里面的办公室、会议室、打印室、广播室、卫生间等等在MMS办公大楼里面都叫房间。形成了多对一，这在使用上必然出现问题，需要其他手段来弥补，这也是非常不合理的地方。

引用差异带来的问题

1、引用不同这就是不方便的
就好像中国人给中国人写信，直接写地址就好了，但是一定要先寄给美国人，写美国人地址，然后美国人填写中国人的地址转寄给中国人，这其中的问题不言而喻；
2、因为模型问题不得不加入功能约束
要知道对数据的功能约束确实有他的作用，但是对数据的引用不需要功能约束，但是MMS就必须要，甚至因为MMS增加了一些功能约束，比如控制块的功能约束“BR”“RP”“LG”还有控制数据的功能约束“CO”。大家可以先品一品这其中的问题。后面会对这个问题进行分析；

服务差异带来的问题

1、服务映射不是一对一
即使不是100%一对一也得达到个80%以上吧，然而仔细观察下来如GetAllDataValues、GetDataValues、GetDataSetValues、GetBRCBValues、Select等十多个服务都映射到了MMS的read一个服务上，同样也有SetDataValues、GetBRCBValues、Operate等十多个服务映射到MMS的write一个服务上，一对一恐怕连50%都达不到；
2、增加不必要的辅助信息
MMS中同样的InformationReport中必须包含特殊的字符来区分是报告还是命令终止，还有MMS中的Write、Read中必须增加功能约束，增加模型等手段来区分对应到具体的服务功能。

数据类型差异带来的问题

1、数据映射不是一对一

我认为类型更加需要一对一了，不然真的很麻烦，可惜出现了很多一对多和多对一现象，比如int8、int16、int32、int64，在MMS里面统一是integer，收到一个mms报文，告诉我是integer，然而我想知道具体是int8、int16、int32、int64就很难了，要知道这个判断错了是不行的。这个问题同样也是需要辅助手段来解决，所以想获取服务端模型必须通过CID模型文件，而不能通过网络接口获取，尽管表面上提供了很多获取模型的接口，但是你只能获取100%的MMS模型，而无法获取100%的IEC61850模型；

其他问题

为什么不再需要功能约束为“CO”的数据模型

控制有专门的接口，但是在MMS里面控制是写操作，需要先在MMS模型中完成写操作才能转译到IEC61850的控制操作，尽管IEC61850中的ctlVal、operTm、origin、ctlNum、t、test、check都只是临时值，也就是模型中不需要存在，但是为了完成MMS的写动作，对应的MMS模型必须存在，而MMS模型是由IEC61850模型映射过去的，这也就导致了IEC61850模型必须建立为了完成MMS写操作对应的ctlVal、operTm、origin、ctlNum、t、test、check模型，而这些模型就统一采用了功能约束为“CO”数据模型，这里大家必须清楚IEC61850里面没有功能约束CO，这个只是单纯为映射MMS模型加的。
加功能约束CO的模型还必须针对控制模型设置进行调整，比如直接控制，加Oper下面的ctlVal、operTm、origin、ctlNum、t、test、check就可以了，如果是需要操作前选择，就必须加SBOw下面的ctlVal、operTm、origin、ctlNum、t、test、check，如果支持取消，就必须加Cancel下面的ctlVal、operTm、origin、ctlNum、t、test、check。怎么样是不是有点小麻烦？
而CMS版本不需要这些，采用IEC61850同样的接口，直接把IEC61850需要的控制值送过去就可以了。

隐藏的控制块功能约束

在MMS版本，通讯上要访问缓存报告控制块是通过读写实现的，然后引用上带上了BR功能约束，这个BR大家在建模的时候是无需设置的，也就是没有的，是在IEC61850模型中将缓存报告控制块映射MMS模型中增加的，只有这样才能在MMS模型中区分出有名变量对应的是IEC61850的缓存报告控制块，所以“RP”“LG”“GO”等也是一样的道理。

MMS模型重复建设了SE模型

其实和CO是一样的道理，尽管可编辑定值是临时量，但是在MMS里面必须存在对应的模型，这也就导致了MMS模型必须重复建设SE模型，使得MMS模型里面存在一模一样的SG和SE模型才能正常运作。

CMS的其他优点

1、直接映射TCP层，网络通讯更加简洁高效；（MMS是七层协议）
2、采用PER编码，同样容量的报文可传输更多的有效信息；
3、支持传输层应用层加密，最重要的是国密算法；
4、最后也是最大的优点是我们国家完全自主可控的协议规范。

其他讨论

为什么会采用MMS

通过上面的介绍，不难分析MMS存在很多的问题，IEC61850映射MMS是非常牵强的，但是制定标准的专家为什么还要采用MMS，并如此大费周章的做强行的映射呢？要知道从西方世界来的东西，难免都有资本的介入，这里面总有利益的博弈。可惜苦了芸芸追随者和开发者。

自己开发CMS可取吗

首先CMS的开发难度要比MMS会降低很多，但这并不带表自己开发CMS是可取的，因为主要的工作量还是在IEC61850本身，整体的难度还是很高，加上CMS协议也还是存在一定难度，所以不推荐智能产品供应商自行开发CMS，而是应该选择与专门提供IEC61850协议栈开发包的企业合作，自己则把精力放在专业产品的研发上。

CMS和MMS会并存很久吗

答案显然是的，CMS刚刚起步，全面替代MMS需要漫长的过程，可能还需要多年的时间，甚至为了国外的设备兼容，可能国内并不会彻底的放弃MMS。

有没有可以平滑过渡的协议栈产品

有的，大连云行科技有限责任公司出品的YX-PIS协议栈开发包分为MMS版本和CMS版本，并且封装了几乎相同的IEC61850接口，使用YX-PIS协议栈可以使用相同的用户层代码即可轻松实现MMS和CMS的切换。
这里顺便提一下选择这类产品的一些建议：
1、优先选择是有多年IEC61850协议栈产品研发经验的企业，产品更可靠服务更专业；所谓宝剑锋从磨砺出，没有多年的打磨就说产品和服务如何如何好这是绝对不现实的；
2、选择有售后技术支持的企业，最好能提供一定培训的企业；
3、选择与头部企业有合作的企业，国内很多大厂非常的专业，他们的选择往往是非常正确的，而且与大厂产品的对接的风险也是最低。

总结

IEC61850规范是非常优秀的，有着先进理念的专业规范，但是唯独没有自己专用的通讯协议（除了GOOSE/SV），而是选择了映射MMS模型，采用MMS通讯。通过文中的分析也侧面回答了一开始抛出的疑问，我们确实需要替代掉MMS协议，而此刻我们自主可控的CMS通讯协议的诞生无疑是电力行业的特大喜讯，CMS全面支持了IEC61850规范，也会使IEC61850更优秀，更完善。希望CMS能够全面的推广，全面取代MMS。

本文为云行科技原创，转载请注明出处