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。
本文为云行科技原创,转载请注明出处