YX-PIS-CMS/GSP 国产IEC61850协议栈

云行科技YX-PIS-MMS IEC61850协议栈产品,已在国内外畅销多年,其成熟度及易用性获得众多用户青睐,帮助用户节省大量学习、研发、一致性测试成本。YX-PIS-MMS针对储能等高负载场景的性能优化及高并发边缘计算方案,更是从技术层面解决了用户痛点,帮助用户快速完成IEC61850业务部署。

YX-PIS-CMS国产协议栈版本也通过了开普实验室的通信规约一致性测试。在原有MMS版本的基础上,CMS版本正式推向市场,助力电力客户快速实现国产化通信协议。

YX-PIS-CMS继承了YX-PIS-MMS的全部优良特性,并针对CMS协议的特性进行了大量改进。用户可以保持使用旧版本YX-PIS-MMS的应用程序源码不变,只需要替换协议栈及执行库即可支持新协议,从而最大保护用户的现有投产设备及协议栈投资。“YX-PIS-MMS + YX-PIS-CMS”的组合,可以帮助客户一次开发即可同时实现对国内、国际标准的支持,无需维护多个协议栈及业务实现。

YX-PIS协议栈同时支持最新版的IEC61850 Ed2.0 以及目前还在普遍应用的Ed1.0,支持CMS、SV、GOOSE等IEC61850标准所规定的所有通信机制,并能够适用于各种硬件平台及操作系统。

YX-PIS提供完善的IEC61850服务接口ACSI的实现支持,不需要二次开发,只需在您的程序中调用简单的4个API函数,就能使您的装置实现对IEC61850的支持。简便易用、源码极易理解的特性将为您节省大量的开发投入,使您专注于原有产品功能及性能的提升,而不是陷入对IEC61850的复杂通信和模型的研究与开发之中。

特性

IEC61850 支持:

  • 同时支持IEC61850 Ed1.0和Ed2.0,只需简单的修改一个宏参数即可进行版本切换
  • 支持完整的ACSI服务接口,包含CMS、GOOSE和SV三种通信机制
  • 支持直接的CID文件配置模型,不需要生成中间格式的模型配置文件
  • 代码通过开普实验室一致性认证

平台支持:

  • Microsoft Windows XP, 2003/2008, Windows 10/11 以及 Vista
  • Linux (x86,x64,LoongArch)
  • Embedded Linux (ARM, Coldfire)
  • openEuler
  • Beck @Chip SC1x3 RTOS
  • SylixOS(x86/ARM/LoongArch)
  • RT-Thread
  • Docker 容器(x64/x86/Arm),方便部署于主流边缘计算平台
  • OpenHarmony for LiteOS-A/Linux Kernel
  • 任意其他您所要求的OS/平台(按需定制)

协议栈特性:

  • ANSI C源码,兼容性极强
  • 直接通过SCL配置,不需要模型配置的转换
  • 最小用户接口设计
  • 面向低资源嵌入式设备定制、面向储能等高性能场景定制
  • 可按需支持C#/Rust/Java/Golang等各种接口
  • 采用事件驱动方式实现数据获取,不需要主动获取数据,减少CPU的使用
  • 支持实时操作系统(RTOS),满足严苛性能要求
  • 出色的KAL(OS Kernel Adaptation Layer)设计,具备优秀的移植性

相关配套产品:

联络我们:

销售/咨询电话:+86 183 0405 9577 (李经理)

固定电话: 0411-88254852 /‭ 0411-66320416

单位地址:辽宁省大连市高新技术产业园区

电子邮件:li.dd@yunxing.tech / yx@yunxing.tech

云行科技YX-PIS-CMS通过开普通信规约一致性测试

日前,云行科技研发的YX-PIS DLT860(CMS)国产协议栈,通过了许昌开普检测研究院股份有限公司国家继电保护及自动化设备质量检验检测中心组织的通信规约一致性测试。

执行标准:

- 自主可控新一代变电站二次系统技术规范通用类系列规范 4- DL/ T860 通信报文(试行)

- 国家电网有限公司自主可控新一代变电站二次系统 DLT860(CMS) 通信报文一致性检测技术方案

CMS是传统智能变电站广泛采用的MMS工业协议的国产替代方案,在自主知识产权、通信效率、安全性等方面进行了全面的加强。云行科技的CMS版协议栈,继承了YX-PIS MMS版的优秀设计,兼容原有API,设计现代、执行高效、使用便捷,必将为国产自主可控智慧电力系统提供新的助力。

 

 

GSP替代MMS!IEC61850国产化已在路上

在当前国家电网即将全面推行用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正式的道一声永别。