【张聘亭 华能吉林发电有限公司新能源分公司博士】2022智慧电厂论坛（第一期）文字实录
主持人：感谢张老师的分享。华能吉林分公司通过建设覆盖运行、检修、安全、备件管理生产全过程的智慧运维系统，实现公司生产业务的数据分析、故障诊断、智能运维、统一管控、潜能挖掘以及决策支撑。下面我们有请华能吉林发电有限公司新能源分公司博士张聘亭作《区域集控模式下风电大数据应用分享》的主题发言。有请张博士。
张聘亭：谢谢主持人，谢谢主办方。
我是代表华能吉林新能源分公司和大家分享一下，我们在区域集控模式下智慧运维的建设经验和大家分享。
原来主办方跟我说被安排最后一个做分享，我很犯愁，各位专家领导已经把他们很多先进技术以及一些成熟的经验和大家做了分享，该怎么样准备这个分享，想了很多，所以今天果然是跟我想象的一样，我们在会场听到了有从整个集团的智慧运维建设层面去分享，也有兄弟单位从区域公司层面做经验的分享，更有听到来自于未来一些科幻般一样的分享，个人还是非常的激动和兴奋。
在这里从一些在区域集控模式下，智慧运维具体的落地实践这一块和大家做分享。说是具体的实践，其实更多是趟过坑的分享。
我是华能吉林分公司，我叫张聘亭。分享几个分析：
首先建设背景和目标。提到基础数据平台，其他的一些应用。逐个和大家介绍一下。
华能吉林分公司目前来说17家发电厂，总装机量440多万，其中大约一半清洁能源，风电占了主要部分，今年还会有两个风电场会并网，应该在60千瓦，明年还会有200万千瓦的装机，对华能吉林来讲会有非常多的风机要去运维，在现有人员，人员不扩张的模式下，怎么样提高风机的运维效率，提高运维的质量和水分，这是值得我们探讨的课题。
我们在2019年的时候，就成立了这样的集控中心，集控中心不仅对所有风电场监测运行和远程控制，同时它也是我们的一个远程控制中心，生产调度指挥中心，大数据分析中心和运维管理中心。现在已经接入风、光、水、火，不仅仅承担新能源的运维，对于火电起到一个监视以及统计分析的智能功能。
集控中心也是华能里面比较早实现远程集控的单位，吉林省首家实现直接远程调度的单位。
在建设集控中心的时候，在探讨区域集控下的运维模式时，其实面临的困境和大家一样。在这里不多做介绍。
在我看来面临核心的问题只有一个，新能源的设备非常多，华能吉林现在有1千多台风机，有些风机10几年之前850的风机，也有现在5兆瓦，4点多的大风机，我们明年还将投入二三百的装机，一个班次三到四个人怎么样去面临1千多台风机的监视、控制以及后面运行的调度指挥的职能，在建设集控中心的时候首先要考虑的问题。所以从集控中心以及电厂数据的交互层面，以及业务流动的层面做了比较多的设计。
一个核心整体思路和目标。首先现在调度，直接调集控中心，对于有一些风电场站通过AGC、AVC调我们的风电场站，更当的调度任务和集控中心来运行，比如说升压站的停电操作等等。那我们后续的风电厂，所有的升压站的并网操作，首次并网的倒闸操作，都是通过集控中心完成的。完成之后，实现无人值班的目标。对于少人值守，区域化检修的模式又是怎么样在这方面做一些工作。这里面建立一个基础数据平台，基于基础数据平台做了一些工作，大家提到智能预警以及设备健康管理的工作，各个专家已经和大家分享很多，做了业务指标的挖掘，对于指标异常的风机和前面提到的设备智能预警提出的一些健康欠佳的风机，我们称之为亚健康的风机，会把它推送到一个任务调度的平台，形成待登机的缺陷确认之后，可以自动开除工单或者工作票，基于工单和工作票形成闭环的管理。同时在现场配备无人机或者是轨道式移动机器人的终端，包括智能安全帽的情况，当然智能安全帽和看看VR安全帽，这种时代上的差距是很大的，所以在这边有很多工作要做。
总得来说，建设这样一个区域集控中心核心整体的思路，用数据提醒我们，刚刚提到人要管理这么多设备其实非常困难，怎么样把人的精力解放出来，用计算机代替，用数据代替人去发现问题，让运维人员去实现专注于解决问题，这是设计的一个核心整体思路。
业务逻辑的设计。做了一个基础数据平台，这个基础数据平台后面做所有应用的基础，为什么做基础数据平台？刚刚提到在规划集控中心以及智慧运维中心的时候，它不仅仅是远程控制中心，是数据中心，也是指挥调度中心和分析决策中心，非常赞同邹总提到的观点，数据流动起来才会有用，振动的传感器可以利用SCADA本身带的传感器，把它的一些数据和CMS的数据做一些对比，或者和一些运行的数据做对比，特别提到偏航时间振动这样一个案例，这个案例非常好，很能说明这里面一个问题，原来各个集控中心建设应用的时候，各个应用都是竖井式建设，这种竖井式建设确实在前期减少投资，加快建设的进程。但是在后期应用的时候发现很多问题，借鉴兄弟单位的经验，比如发电量的数据，发现很多系统中发电量的数据并不一致，但是发电量的数据对后面的应用非常重要，报表就是重要的应用，对于低效机组的挖掘也是非常重要的参数和指标。虽然是同一个源头的数据，经过不同的系统加工之后，数据已经出现不一致的情况出现。比如功率曲线的数据，对于系统的应用建设非常重要，在这里希望获得一个比较完好一致的数据，所以在这里建设基础数据平台，这个基础数据平台不仅仅把所有的底层监视系统和复控系统的数据全部做了采集和规整，还把需要处理一些中间数据，按照统一的标准和要求去做了处理，比如说我们生成分功率曲线的时候，我们需要10分钟的数据，那我们集控中心按照我们目前的技术水平，通常采集的是秒级的数据，那秒级的数据怎么样生成10分钟的数据，这个时候做了统一的方法和标准，后续所有的基于这个风功率曲线的应用，或者基于10分钟级别的应用，都基于这个数据，应用建设的难度自然就降低，数据的准确率也提升，带来建设可以加快，并且可以把更多的精力放在业务上，让业务人员参与到系统建设过程当中来。这是基础数据平台建设的初衷。
这里面用到数据库的技术，数据仓库的技术，大数据的技术，包括一些实时历史数据库和其他的技术，已经有很多专家作了很好的分享。我们现在平台里面的数据量，秒级标签的数据大概在150亿条每天，这个里面可能由于数据的变化上送，每天都会不一样，但是基本上的数量级这样，生成10分钟级的数据，在100万条/天，这个数据量相对来说还是比较大的。
下面的分享基本上全是趟过的坑。
第一个坑，在数据应用的时候发现很多数据标准不一致的情况，华能吉林公司建设比较早，还有很多老旧的风机，像Gamesa850的风机也是我们的老风机，还有很多1.25的风机，我们最新的机组已经到5兆瓦，这样的话，20几种机型在区域公司里面存在，运维的难度非常高，而且它的数据的标准不一样，不同风机对于风机状态的标识不一样，有些风机状态虽然都叫待机，待机的含义不一样，有些风电状态都叫发电，有的时候发电把限电从发电里面剔除，有的限电没有从发电里面剔除，所以面临后续数据分析的时候，出现很多问题，在这里核心做的第一个事情数据要标准。只有数据标准化之后，才能很好的做后面的应用，否则很多时候只能去不停纠缠于数据，这个数据到底是好还是不好，不好该怎么办，目前数据治理的工作一遍又一遍的充分开展，没有达到理想的效果。
这里面还有很多数据错误的问题。很多时候，我们有一些集控中心可能报表来自集控中心，但是比如晚上12点生成报表的时候，很多报表需要手工去生成，需要做各种数据的修正，这个修正不仅仅基于业务方面或者其他管理因素方面的原因，就是基于本身数据质量存在的原因，原来的情况可能是在晚上12点开始报报表，1点钟之前调度的报表要报出去，但是在平台建完之后，原来报表可能每天晚上花3到5个小时，晚上3到4个值班员，保障值长和主值副值，他就会成天忙于这个报表，因为报表是每天要报出来的，那对于风机的状态关注很少，这个时候起不到智慧运维的作用，在对错误的数据，以及早期的数据，尤其是电量的数据，特别是单风机的电量数据，把它治理完之后，把它的跳变，把它的一些结余的数据，把数据的早期数据处理完之后，我们就很好的实现报表的自动化，现在的报表情况，差不多是在每天晚上12：15分，报表可以全自动的生成，生成的时间，每天报100来张报表，由于资产结构比较复杂，这100两张报表差不多在5分钟之内全部生成，进一步通过IPA的技术把报表上的数据全部取出来，送到各个报表的口径，这样值班人员，尤其晚上的值班人员可以把他的精力从繁琐每天3到5个小时报表的工作中解放出来，更多关注风机的状态，更多关注风机究竟哪台风机发电少，哪台风机故障多，而不会出现风机故障停机放在那，而不去管它的情况，这是对数据错误和数据噪音的处理。
另外还有一个处理对于数据预处理的问题。刚刚提到在集控中心里面，所有数据采集的时候基本上秒级数据为主，集控中心在数据采集的时候，将风电场SCADA全量的数据上传到集控中心，而且秒级上传到集控中心，秒级的数据对于数据的分析、数据的应用非常有好处，非常棒，存在的问题，如果所有的应用从秒级数据开始，会存在很多的问题，在这里对数据做了很多预处理，包括几方面：第一对性能、指标分析的数据，做了10分钟级别数据的预处理，比如说实时的损失电量，10分钟平均的风速，10分钟平均的功率，10分钟平均的矩角，10分钟平均的平衡夹角等等这样的一些数据，都做了统一标准的处理，统一标准的处理对后面的应用起到比较好的支撑作用。
第二个数据预处理风机一些故障记录，有的可能通过故障码生成，有的通过开关量生成，如果这些故障码和开关量全部用实时数据存储，会占用非常多的存储空间，我们通过一些数据解析，形成了一条一条的故障记录，并且把故障记录和故障码做了标准化，这样通过一条一条故障记录非常快的统计，风机到底发生哪些故障，哪些系统故障偏多，有可复位的不可复位到底系统占比多少，这样对于风机的状态做一个比较好的判断。
在这里常常听到有一些地方在运行过程中要求统计超温的情况，统计超声的情况，统计偏航次数的情况，统计超速的情况，都会做一些统计，这种统计如果完全基于时许数据去开展，也会存在很多的困难，在这里基于平台比较灵活自主的配置功能，可以在不同的时间段，针对不同的季节环境和环境温度，对它的温度振动这样的情况设定一个域值，这种域值设置之后，系统生成，采集数据的时候，把这些数据的时候全部以记录的形式生成，记录在数据库，这种记录形式生成对后面的统计分析，就会形成比较好的一个助力，促使在运维过程中更多关注这样统计指标。
实践证明，对于温度的统计发现很多风机的异常，有一些异常可能不需要通过一些长短时的时间网络，LSTM模型去发现，其实通过人对温度的统计分析可以发现这样的情况。
我们在建设基础数据平台采用的一些方案。比如说设备标准化，我们对设备拓普、设备点表、设备编码都做标准化，对所有的机型做了标准化，这样在后续建设应用过程中就不会存在不停的找点，点还找错的情况，这种情况对我们来说已经成为历史了。
数据标准化的内容，按照集团的要求，对设备的状态做了两类标准化，一种运行状态，一种可靠性状态，运行状态满足监盘的需求，可靠性状态满足闭环管理，以及损失电量分解的要求，从这两个角度对设备的标准化。运行状态的话完全基于风机PSE自身的状态，以及风机的其他特点，风速和功率是遥测点或者遥信点给出，可靠性状态，这里面很大程度上依赖于集控人员对风机自身的判断给出挂牌的状态，其实这里面挂牌，对于风机来讲并没有涉及太多安全的考虑，更多的是对风机的状态做一个标识。
基础数据平台这一块，刚刚提到故障告警和事件的标准化，故障解析的内容，前面我们已经提过了，这是我们具体的一些操作的方式。把故障码以及按位和开关量的信号，全部转变为标准的故障停机记录，有开始时间，有结束时间，有机组的品牌故障的类别，故障编码，甚至该条故障码出现以后的处理建议也都一并在这里面能够有所体现。在这样一个解析之后，当集控系统出现某个风机告警之后，监盘人员对告警进行分析，同时查看到告警所产生的故障码，带来一些处理建议，再对它进行后续运维的操作，可以形成一条闭环管理的要求。
这是对数据清洗一些技术手段，核心从数据的变化特征，以及统计量这个上面，结合上下线的特征，做数据质量的检查，使得数据质量比较好，对于有一些缺失的数据需要补全。
尤其对于电量的数据比较关注，可以说是整个新能源指标中最重要的指标，单风机电量的数据对我们运维非常有帮助。
对数据清洗这一块，数据状态的标记，刚刚看到有一些同仁分享应用的时候看到过类似的图，对于风机来讲，正常生成风功率曲线有很多的异常数据，这时候需要对数据进行标识，这些异常数据，不是说数据是错的，其实因为风机本身自身的特性造成数据分布的特征不一样，如果在生成风功率曲线的时候，不考虑异常数据剔除掉的话，会造成风功率曲线不能代表我们实际运行的曲线。所以我们在这里做了一些数据状态的标识，通过数据状态的标识，可以把这一组数据，不光包括风速和功率了，按照时间节点来标识数据的话，把前面异常的数据也可以做一个标识，标识之后按照不同的应用，再来对数据进行筛选。就可以根据应用实际需求做数据的筛选，最后对数据质量进行评价。
还有数据预处理的情况，数据预处理后续进一步把工单的数据，工时的数据，备份备件的数据核算进来，形成全生命周期的经营分析，把它的实时的发电成本和运维成本都考虑在内，可以开展这样的工作。
基础数据平台开展一些工作，一些经验和大家分享。
通过基础数据平台的建设，还是取得比较好的成果，在性能分析，指标的对标，故障的预判这个上面都取得成果，通过下面的应用建设和大家一起分享。
在考察风机性能的时候提到的，大家很知道，风机和风场发电量有比较大的差别，因为我们是高原，阵列式的风场，差别还不是很大，对于山地的风电厂，风电量差别很大，很多时候发电量差别不能代表风机本身好和坏，或者机型好和坏。更多是代表风资源可能出现问题。所以对风机性能的评估根据可以量化的一些指标来判断，发现一些风场或者风机运维过程中的薄弱点。
（图示）开展的一些工作，对时间可利用率，能量可利用率，损失电量的分解，绩效榜，风机、风场、机型的绩效榜都做功能应用。并且对于功率曲线做了比较好的拟合，拟合的结果比较好的反映风机实际运行情况。有功率曲线的评估，有各种BIN曲线评估，变桨风速、转速功率等等各种各样的功能。也提供比较好的数据交叉分析的功能，可以分析在不同风速下风机什么时候开始收桨，转速和功率是否匹配这样的情况，挖掘风机过程中一些异常的情况。曾经发现过有一台风机，在某个时间段可能被限制叶片比例，运维人员忘记取消它，但是通过这样的分析，很快找到异常的情况，就会发现那个时间点之后的变桨风速的风功率曲线，BIN曲线明显和其他的时间段有异常，很简单一查，就知道是叶片比例被限制，通过非常简单的操作可以挽回比较多的电量。
刚刚提到，这样一个方案大家都会比较关注，1千多台风机，怎么样去找到风机，刚好要看到这个风机，才能对风机进行分析，这个时候人脑可能不太够用，所以在这边做了几个策略：
一个低发电量机组的挖掘，针对平原风场，同比同时间段内发电量永远位于最后排名那几台风机做一个排名，做一个挖掘，并且实时给找出来。或者对于山地风场，整个风场内风速不是很均匀的风场，对同行、同域的风机做损失电量的挖掘，把损失电量比较靠前，同时差异率比较大的风机，能够实时提醒给监盘人员。同时对性能量化的机组，对一段时间内，风功率曲线一直在下降的机组做这样的挖掘。跟设计曲线偏离比较大的机组做这样一个挖掘，这样从1千多台机组中，能够找出几十台，二三十台机组，提醒我们的监盘人员，让人员提醒风场对这些风机进行比较好的维护，解决一些问题。实践证明，效果还是比好。去年的时候差不多累计挖掘900多个台次的机组，命中率大概在300多个台次，900多个台次里面有很多重复的机组，不停的出现，后来更新算法，把重复的机组剔除掉。总的来说，通过运行期的功率曲线跟实际的风速去做一个真实的损失电量计算，大概提升总的发电量大概在900多万度电，成绩还是比较振奋人心的。
而且发现一个更加好的事情，在今年到现在为止，挖掘的电量提升的远远不到900多度，说明在某种程度上可以认为风机状态在变好，而且在去年的时候，原来定时每周挖掘一次，后来发现每周挖掘一次有点太频繁，改成每月挖掘一次，每月挖掘一次，数量并没有增加，其实从数据挖掘角度来讲，代表着策略已经起效，而且整个风场，整个公司风机的状态发生比较好的改变。性能分析这一块通过数据挖掘成果的分享。
（图示）看一下右边这张图上面有一个红色柱子和绿色的柱子，红色柱子指的是如果不对风机进行维护，在历史上的损失电量可能会这么多，绿色的柱子，如果不对它进行维护，用原来的风功率曲线和现在的风功率曲线，按照实际经历的风速对比，它提升的发电量，可以看到有明显的提升。对于处理的机组，可能提升的电量高到10%几，甚至20%，低的也有1%—2%，2—3%，当然也有处理之后没有提升，也是一个正常的情况。毕竟从1千多的风机把目标聚集到二三十台，三四十台风机，已经是非常好的体验。
在智能预警这一块做了一些工作，这个事情，风机的预警发生潜在故障，很多人分享过，这里不再说它的原理等等，包括建模方式、一些模型都不再多做介绍。
说另外一个事，预警在这里，预警是很难的事情，风机的预警某种程度跟股票的预测差不多，把风机的状态真正的预警好，但是在这里另辟蹊径，用预警模型做什么事？用它来代替监盘人员想发现什么问题，监盘人员在集控中心值班过程中，关注什么问题？关注的比如传感器死值，可能会影响风机的风险，会影响风机的安全，关注这个时候可能有降容运行，想知道降容运行的原因是什么？关注的是这个时候风机温度是不是跟气得风机比偏高，这个温度跟历史的温度比是不是偏高的，关注是这些问题。所以想用它来把人监盘的策略，通过预警建模的方式去实现建模，现在目前做了四类模型：
第一类传感器的异常，通过移动平均，比较简单的策略，对传感器死值、零值、飘移这样的过程做了一个监视。在这些模型刚上线的时候绘制一张矩阵图，当时把800多台风机的矩阵图全部画在那里，一上线之后发现这上面一片红，红色当然非常契合今天的主题，但是红色对于运维人员来讲是非常糟糕的现象。发现很多传感器坏了，在这个里面有短路、断路，死值这样一些问题，所以通过不停的维护，到现在为止传感器监视模块，发现几乎很少有传感器坏了，这里面起到比较好的效果。
第二类想发现风机降容运行。这里面通过神经网络模型做这样一个功能，对风机所有降容运行的情况做了一个实时的提醒，当风机出现降容运行之后，可以考虑到底因为振动还是因为湍流的原因，因为风机自身设备的原因。比如齿轮箱油温高了，还是自己主动限制降容，还是由于电网调度的原因，都可以做一个实时的提醒。
第三类对大部件重要温度的建设，通过对比轴承前后温度，比如前轴承和后轴承变化的趋势，以及绕组的温度，油温趋势的监视，变化率的监视做了一些工作，通过这样的工作也发现一些设备提前损坏的征兆。其实跟前面提到的，通过温度超限情况的对比，发现的东西比较接近。从这个程度上来讲，这样两种方式都可以提前发现设备潜在的一些异常情况。
还做了一类模型，比如把性能分析10分钟的数据取过来之后，对控制策略做了监视。比如风机的切入风速相同，机型的风机切入风速做了一个监视，对切入风速比较高的风机，能够实时提醒出来，对风机收桨的这个角度以及究竟在哪个风速下到了满负荷这样的情况都做了监视。这样通过预警，把它用在智能监盘上，已经可以在很大程度上代替值班人员对风机异常情况发现做一个比较好的发现。我们的人才能真正关注于设备的健康状态，而不是忙着去查看数据，发现这些设备的异常。在预警经验的分享。
另外，基于前面数据平台，一个数据的流通以及闭环管理做了一个知识库，知识库分成两个部分：一个静态知识库，一个动态知识库。静态的知识库主要是一些分阶的技术参数，更主要是故障代码的处理建议以及发生的原因。这个时候对风机厂商提供的故障代码进行比较大的修订，把熟悉各种机型的专工以及检修人员做了组织进行修订，力求使得故障代码对应处理的建议能够和具体的运维实践相符合。同时做了一个动态的故障知识库，动态故障知识库实际上就是一个检修的历史库，以及一些故障案例。有点类似于核电领域的经验反馈系统，当然比核电的经验反馈系统要简单很多。通过生产管理系统KKS的关联，实现经验的反馈，同时也会有人定期去对两票或者工单提交的检修交待做一个梳理，力求进入到故障知识库里面的描述能够标准化、规范化，有更好的参考经验，而不是描述浮于表面，起不到太多的参考作用。在这里面也做了大量的工作。实践经验证明如果不去梳理基本上故障知识库是废的。
生产管理系统大家有过分享，并且做了电子两票以及移动两票的应用。在应用的过程中，最大的感触是通过集控端发起闭环的管理，能够实现很多的工作。
比如在集控运行的时候，对某一个风机进行挂牌之后，比如挂故障牌，会自动生成待登记的缺陷，待登记的缺陷，后面检修人员要去维护，一定要通过集控这边去操作风机的启停。在维护完之后，集控这边对它进行启停操作的时候，一定审核工单和工作票里面提交的解决交待是否符合要求。这种闭环反馈就会把以往很多的经验都会承接起来。刚刚提到的预警系统以及性能分析系统里面，挖掘出来的低效风机，低效机组，以及预警系统里面提到可能潜在缺陷都会无缝推送到生产管理系统里面去，统一做闭环管理。在这样一个管理模式下，设备的全生命周期，当然不谈设备的建设时期，谈设备服役之后，所有的异动过程，都会清晰、详细被记录下来，也为以后的运维奠定一个非常好的基础。
生产管理系统按照这样一个标准导入，过程管控和改进提升三个步骤做的。这些内容大家耳熟能详。不再介绍。
总的来说，在新能源智慧运维过程中，最大的体会数据要做好标准化，尽量用数据去解放监盘人员的精力，更多关注设备的状态，关注设备的问题，而不是忙于填写报表，忙于查看这些数据。
分享到此结束，谢谢大家！
注：文字实录未经专家整理核实，仅作参考使用，具体解释权归本次会议主办方所有。
未经授权，请勿转载
