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的详细差异，大家就一目了然了。
模型差异
MMS需要建立模型，模型差异如下
而CMS完全采用了IEC61850的模型，无需映射。
引用差异
CMS采用IEC61850引用
服务映射的差异
首先我们看看IEC61850和MMS版本服务服务的映射关系
可以看到还是存在相当多的差异的，而上述接口在CMS版本与IEC61850接口完全一致，除此以外CMS标准中还增加了如下接口
数据类型的差异
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模型才能正常运作。
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。