标题:陕西省煤矿供电系统监测预警平台软件设计

文档介绍:

1 绪论

1.1研究背景与意义

煤炭行业是我国能源产业极为重要的一部分,这个行业一直把安全生产当作最核心的发展诉求,供电系统就像是煤矿生产的“动力心脏”,负责给矿井变电站,主要通风机,井下排水泵以及提升机这些关键设备供电。该系统的设备一旦出现运行异常情况,就很可能造成生产停止,设备损坏,还可能会产生安全事故,所以,国家矿山安全监察局和财政部共同出台的《煤矿及重点非煤矿山重大灾害风险防控创建工程总体方案》专门提出,要给重点煤矿里的主要设备安装智能检测终端,从而及时掌握电流,电压,负载等参数的变化状况,并且力求到 2026 年把全国在册煤矿的重大灾害风险防控工程全都创建起来。 陕西省属于煤炭资源大省,煤矿井下环境复杂,供电设备种类较多而且分布较为分散,传统的人工巡检方式存在效率低下,缺乏即时性,故障察觉较迟等不足,难以符合现代矿山安全生产的需求。

在此种背景之下,设计出一套智能化的煤矿供电系统监测警报平台软件十分必要,该软件依靠自动化数据采集,智能化状态评定以及随时化风险警报来达成对煤矿供电设备运行状态的全过程控制,具备重要的现实意义。其一,平台能够取代人工巡检做到7×24小时不间断监测,极大地优化了监测效率并改良了数据准确度;其二,经由把机器学习算法和规则引擎结合加以运用,可以预先警报设备故障,给设备维护保养以及故障处理赢得时间,减小事故发生的概率;而且,平台具备数据分析和可视化的功能,这会给予煤矿经营人员决策按照,促使煤矿供电系统向着智能化,精准化的方向去发展,有益于陕西省煤矿行业做到安全稳定经营并达成高质量发展目标。

1.2国内外研究现状

国外针对矿山供电系统安全观察以及智能化运作方面的研究开始得比较早,所以已经创建起比较系统的理论框架与技术应用情况,它们的研究着重放在供电系统的可靠性考量,故障预示,智能守护以及依靠先进电力电子技术来改善能效这些方面。

俄罗斯学者Nepsha等针对供电系统的建模与可靠性分析展开深入探究,其创建起煤矿采区供电系统的计算机仿真模型,以此来考量系统处于各种工况时的运行特征,而且就是否可以在煤矿供电系统当中采用FACTS(柔性交流输电系统)设备从而提升电能质量与系统稳定性实施探讨[26],这些学者还给出了一种评定煤矿供电系统达到最佳电压调节效果的办法,希望经由改善电压等级来缩减系统能量损耗[27]。

在故障检测与系统保护领域,国外的研究有着较高的技术成熟度,Pang等人给出一种依靠3AC的煤矿供电系统漏电检测方法,该方法优化了接地故障识别的灵敏度和准确性[4]。Efremenko等人着重探究当电力系统供电中断时,怎样维持煤矿处于无故障状态,他们研究了备用电源切换以及系统重构策略[5],更早些的研究可回溯到Mittra等人所提出的针对采取限制中性点接地系统供电的煤矿的新型故障安全接地保护方案,此方案在保护原理上存在改进之处[32]。

在分析供电质量对安全的影响时,Zhonghua探讨了煤矿供电电压暂降问题以及其给安全检测系统可靠性带来的影响[22],从智能化和自动化角度看,Trenczek等人概述了包含煤炭开采工艺流程在内的供电系统,计算机技术和自动化的革新之处,这显示出早期把信息技术和供电系统紧密结合起来的研究情况[31],Chen等人针对矿山供电系统的安全性展开了综合性探究[23]。

国外的研究具备理论深厚,重视系统性分析以及前瞻性技术应用这些特征,格外在系统建模,特定故障保护原理以及电能质量控制方面取得了诸多成果,给本课题给予了重要的方法论参照,但是它们的研究大多按照通用的电力系统理论或者特定的国外矿山情况,和中国陕西省煤矿繁杂的地质条件,独特的供电网络结构以及密集的机电设备负荷特性关联度较低,方案的直接运用会遭遇适应性难题。

国内有关煤矿供电系统检测与警报技术的研究紧跟国家安全生产需求以及智能化矿山创建战略,发展速度很快,其特点是朝着智能化警报方向转变,也朝着综合平台方向发展,原先只是自动化检测而已。

国内学者在供电观察系统的设计与达成上做了诸多面向应用的研究,张瑞军探讨了煤矿井下电力观察系统的形成与功能[1],郭伟等围绕井下供电观察系统的实际设计及工程执行展开了研究[2],张宇杰论述了供电自动化观察技术的应用[13],这些研究稳固了系统随时数据收集与监测(SCADA)的根基。

近年来,智能化升级和综合平台创建成为热门研究话题,王勇等设计出依靠人工智能的井下供电智能检测系统,并探究智能算法应用于检测时的情况[8],李政民规划出煤矿智能供电系统综合分析平台,重视数据整合与综合分析的意义[10],王兵等提出依托大数据分析的供电系统安全智能经营平台的设计想法[19],李明生等针对矿井智能供电检测系统展开设计和应用方面的研究[20],这显示出国内研究正在朝着“监测 - 分析 - 警告 - 经营”一体化的方向前进。

能效守护和节能观测的研究同绿色矿山理念相融合,王怀志等人设计出煤矿供电系统综合节电监测平台[14],韩朝等人则设计出依靠SVG的煤矿供电节能监测系统[17]。

李艳丰针对智能检测和故障通知展开了专项研究,对矿用供电系统的智能检测以及故障通知系统实施了设计并加以研究[6],申浩探究了煤矿智能综合供电监测系统的技术[7],翟军存等人员探究了煤矿智能供电安全保障系统的规划设计及其应用[18],这些研究着眼于警示算法的研发以及系统的达成,2023年,国家能源局公布了《煤矿井下供电无人值守检测系统技术要求》(NB/T11106 - 2023),这给系统设计赋予了标准依照[21],宋建成团队先前针对矿井通风及供电系统安全状况检测和故障判断通知系统开展了研究[28],刘建甫等人也对井下供电即时检测系统展开了应用研究[30],这些都为后续的发展形成了根基。

值得注意的是,虽然国内研究成果丰硕,但在实际应用中仍存在一些亟待深化的问题:系统当前的合成度尚需优化,当下的研究或是偏重观测方面,要么偏重某个具体功能(诸如防越级,节能之类),但能把全面观察,立体度告警,智能判断,能效评定以及协同调控紧密结合于一体的综合型软件平台还是空白。而且,告警模型缺乏足够的智能化和精确度,不少系统依旧过度依靠阈值提示,利用机器学习或者深度学习来预估设备健康状况(即 SOH),针对复杂故障实施精确判断并找到产生原因的功能比较弱,平台软件对于标准化,可定制性,可拓展性的考量明显缺失,很难符合陕西大大小小,开采情况各异的煤矿的不同需求,另外,对大量即时数据和过往数据的价值探寻不够透彻,无法彻底达成从数据迈向决策的知识转变。

国内外的研究给本课题赋予了牢靠的理论与技术支撑,不过鉴于陕西省煤矿供电系统独具特性,营造起一个集高集成度,智能警报,精确判断,灵活设置于一体的综合检测警报软件平台,仍然是当下学术研究及工程应用当中的一项关键且急迫的任务,本研究会全面借鉴已有的成果,尽力弥补前面提到的短缺之处,力求规划出更为符合当地实际需求,技术更为出色的新一代软件系统。

1.3 主要研究内容

本研究旨在设计一个功能全面、性能稳定的煤矿供电系统监测预警平台软件,以满足当前煤矿产业对供电系统智能化管理和安全运行的迫切需求。参考《煤矿安全规程》(2022版)和NB/T 11106-2023《煤矿井下供电无人值守监控系统技术要求》,系统将综合利用现代物联网技术、大数据分析、人工智能算法及工业自动化控制技术,实现对煤矿供电系统的全方位实时监测和智能化预警管理。具体研究内容包括五个方面:要达成关键供电参数的即时观测,精准采集煤矿供电系统里的电压,电流,功率,功率因数,电能质量以及设备温度等关键参数,形成高效的数据处理与分析机制,塑造稳定高效的数据处理流程,做到对观测数据的快速采集,智能分析和正确存储,开发精确的故障警报与判断功能,遵照全面的数据分析结果创建科学的故障警报模型,可以及时,准确地预估供电系统可能出现的故障,并发出分级警报信号,创建系统的应急反应机制,制订完备的故障处理流程和应急预案,加快系统对于突然故障的反应速度并优化处理效率,改良系统的稳定性和扩展性,采用模块化设计和分布式框架,保证系统在各类规模的煤矿中具有适应性和可扩展性。

在技术指标方面,本研究设定了明确的目标:电压监测范围是0~35kV,误差不超过±0.5%FS,电流监测范围是0A~3000A,误差不超过±0.5%FS,温度监测误差不超过±1℃,电能质量谐波分析精度可到50次,系统响应性能上,数据采集周期不大于1s,警报响应时间不大于2s,故障定位时间不大于5s。从可靠性指标看,系统可用性不低于99.9%,平均无故障时间不低于5000小时,故障判断准确率不低于95%,警报准确率不低于90%,要达成前面这些目标,本研究会采用依靠微服务的分布式架构,把整个平台分成数据采集服务层,数据预处理层,业务逻辑层,智能分析层和用户交互层这五个分层的服务模块,并经由Docker容器化部署和Kubernetes编排,保证系统的高可用性和弹性伸缩能力。

1.4论文结构安排

本文围绕陕西省煤矿供电系统监测预警平台的软件设计展开研究,核心涵盖平台整体架构设计、核心算法设计、软硬件技术栈选型、数据库设计、前后端功能模块开发及接口设计等关键内容,整体结构安排如下:

绪论:阐明研究背景及其意义,整理煤矿供电系统检测警报领域国内外的研究情况,界定本研究的关键部分和技术指标,并阐述文章的整体架构规划,从而为后续研究形成研究根基与导向。

平台整体设计:确定平台设计的五个关键原则,形成起涵盖数据采集层,流处理层等六个层级的总体架构;细致规划三项主要算法,依靠物理限定建模的设备遥测数据采集算法,利用梯度改善融合学习的机器学习健康度评价算法以及可设置规则引擎的警报算法,塑造设计的核心技术系统。

平台技术栈选型与项目结构设计:根据业务需求和技术成熟情况,选择适合的后端,流处理,机器学习服务,前端,数据库等各层级的技术栈,并确定相应的技术版本及其用途,而且用模块化,分层化的设计理念来划分 backend,frontend,python - ml 这三个主要模块,规划这些模块的具体项目结构,从而保证开发具有规范性且便于后续的维护工作。

平台数据库设计:按照第三范式,数据一致性等相关原则,选定了 H2 Database 2.x 作为平台数据库,规划了 User, Device, Measurement, Alert 这四张核心数据表的细致结构,并明确了各个表之间的外键联系,依靠 Spring Data JPA 来规划数据库访问方法,再加上事务守护机制来保证数据操作又快又一致。

平台功能模块与 API 接口设计:按照用户角色(ADMIN/USER)来完成权限分级的功能模块设计,将功能模块划分成公共,经营商专用,普通用户这三类,并且明确各个模块的功能,按照RESTfulAPI规范,设计认证,经营商,普通用户这三类接口,弄清楚接口的方法,路径,参数及其功能,还要制订前端接口调用规范以及后端全局异常处理机制,以保证接口交互的稳定。

平台性能验证与分析:选择数据采集,机器学习推理,警报分类以及接口响应这四个关键性能评价指标,并且制订对应的评价标准,在模仿煤矿现场环境的服务器环境下执行性能评定,然后对这些评定的结果加以分析,遵照平台的运行规律,采取缓存改良,索引改良,分表改良等诸多性能改进方法,以进一步加强平台的性能。

在致谢部分体现对研究过程的感激之意,并且罗列出参考文献,从而给研究内容赋予理论及文献层面的支持。

 

2 平台整体设计

2.1设计原则

陕西省煤矿供电系统监测警报平台的软件设计依照五个核心原则,即即时性,可靠性,智能化,可扩展性和易用性,即时性原则规定,平台的数据采集间隔不能大于5秒,其流处理过程也要有低时延,如此才可做到设备运行状况的即时反馈并保证风险警报尽早发出。所谓可靠性原则,从架构设计上体现为高可用性,利用机器学习服务和规则引擎的降级兜底机制,防止因某项服务出现问题而造成整个系统停止运作,并维持数据收集和传送的真确无误,智能化原则则要平台结合机器学习与物理学方面的知识,以精确评定设备的健康水平以及智能地识别各类别的风险,并非仅仅依靠预设的界限值来作出判定。 可扩展性原则表明,平台需执行模块化设计,要具备设备数量扩充,监测指标增多以及算法模型更新的能力,从而适应不同煤矿的具体需求,易用性原则显示,平台前端界面应简明易懂,操作步骤清晰可见,而且要达成权限分级管理,以符合经营人员与普通使用者的操作需求。

2.2整体框架

平台采取前后端分离的分布式架构,整体包含数据采集层,流处理层,机器学习服务层,业务逻辑层,前端显示层以及数据持久化层这六大核心层级,各层级经由标准化接口达成数据交互,该架构整体上为松耦合,高内聚的形式。数据采集层依靠物理限定建模算法,做到每五分钟收集一次煤矿供电设备的电压,电流,温度,负载率等远测数据;流处理层利用 Kafka 作消息队列来达成数据的大量并行传送,凭借 Flink 作流处理引擎来做即时运算及风险剖析,而且做到机器学习服务与规则引擎的自动转换;机器学习服务层依靠 Python 和 FastAPI 包装梯度加强集成学习模型,给予设备健康度评定与风险等级划分的推断服务;业务逻辑层依靠 Spring Boot 来形成,做到用户认证,设备管理,警报守护,能效分析等主要业务功能的处理;前端显示层依靠 Vue 3 和 ECharts 形成,赋予数据可视化,随时观察,拓扑显示,历史趋势分析等交互界面; 数据持久化层把H2嵌入式数据库当作工具,对用户信息,设备信息,遥测记录,警报记录等数据执行存储与经营,这个平台的整体框架做到了从数据收集,传送,处理一直到分析,表现,警报这一整套流程的循环,可以满足煤矿供电系统检测警报在各类情况下的需求。

图2-1 架构图

数据采集层:平台的数据源入口包含陕西省煤矿五种核心供电设备的相关信息,其一是一号变电站,其二是二号高压柜,其三是主通风机电控柜,其四是井下排水泵,其五是提升机供电柜,创建这些设备的参数档案,并保存它们持续运行时的状态向量 [V, I, T, L],利用负载率随机游走,温度热惰性模型,电压负载压降模型以及电流负载率关联模型这些状态转移方程,做到对遥测数据实施物理约束建模采集,保证数据合乎设备运行的物理法则,免除无效数据与异常数据带来的影响,数据采集服务每隔5秒就会自动执行一次,它采集到的结果会立即被推送到Kafka消息队列当中。

流处理层:由 Kafka 和 Flink 构成的部分是平台即时数据处理的核心所在,Kafka 建立起特别的 Topic(device - telemetry - events),以此达成遥测数据的高并发,高可靠传送,而且具备海量数据的分布式存储能力,Flink 是流处理引擎,经由 FlinkRiskAnalysisJob 作业来消费 Kafka 内的遥测数据,并随时调用机器学习推断服务以做到对设备健康度的考量及风险提示,若机器学习服务出现故障,则会自动退回到规则引擎来做阈值判定,流处理的结果会立即推送到业务逻辑层,并且同步到数据持久化层当中。

机器学习服务层:以 Python 3.9 + 开发并利用 scikit - learn 来达成梯度优化整合学习模型的训练及部署工作,经由 FastAPI 进行封装变成 HTTP 推理服务,该服务运行在 18082 端口上。此层存在两个模型,其一为健康度回归模型(HealthRegressor),另一个是风险分类模型(AlertClassifier),它们从业务逻辑层获取设备遥测数据请求,并给出健康度评分(范围0~100),风险警报状况,风险级别以及可信度等信息,而且每次推理历时少于 5 毫秒,符合时效需求。

业务逻辑层:依托 Spring Boot 3. 3. 6 开发而成的部分充当着平台的“大脑”,其职责在于协调各个层级之间的交互以达成核心业务功能,此部分包含有设置模块,控制模块,数据传递对象模块,实体模块,数据访问层模块,业务服务模块以及流处理交互模块,具备用户认证与授权,设备信息管理,遥测数据整合,警报记录处理,能效分析,故障判断,报警规则设置等功能,并做到与机器学习服务层,流处理层的数据交换及接口调用。

前端展示层:前端基于 Vue 3.5.13和 Vite 开发,用 Axios 来达成与后端的HTTP请求交互,靠ECharts做到数据可视化显示,利用SVG达成供电拓扑图的可视化,前端包含登录页,管理控制台和普通用户界面,支持权限分级显示,管理员能执行系统全部功能操作,普通用户只能查看监测数据和警报信息,界面采用深色侧边栏加白色内容区的工业观测风格,操作直观,响应快速。

数据持久化层:使用 H2 Database 2.x 这种独立式的文件数据库时,它具备多连接功能,也就是 AUTO_SERVER = TRUE 这个特性,而且将 JPA DDL 策略设置成 update 方式,这样就可以做到数据表自动创建以及结构上的自动调整,这个数据库里主要有四张关键的数据表,分别是 User, Device, Measurement 和 Alert,它们分别用来保存用户资料,设备资料,遥测数据以及警报记录等内容,而且这四张表相互之间经由外键形成联系,从而保证数据既一致又完整,还方便执行高速查询和相关统计分析操作。

2.3设备遥测数据采集算法

设备遥测数据采集算法是平台数据真实性和准确性之根基,此算法以物理限制建模法为依照,并融入煤矿供电设备运作时的物理原理,塑造出设备状态转移方程,从而达成对电压,电流,温度,负载率这四个关键指标实施5秒一次的定时采样,免除因传感器原始数据存在噪声干扰及异常值而给采样数据带来不良影响,使得采样数据能够如实反映设备的实际运行情况。

为每一台煤矿供电设备创建一个连续运行状态向量[V, I, T, L],这个向量包含四个要素,V代表设备端电压(单位是伏特V),I代表运行电流(单位是安培A),T代表设备温度(单位是摄氏度℃),L代表负载率(单位是百分比%)。按照陕西省煤矿五类核心供电设备的实际参数来创建设备参数档案,档案会记录每台设备的额定电压,额定电流,负载基准以及负载区间这些重要参数,从而给状态转移方程赋予基本参数支持,比如一号变电站(MINE - 001)其额定电压是6150V,额定电流为120A,负载基准为62%,负载区间位于42%到88%之间,主通风机电控柜(MINE - 003)的负载基准为80%,负载区间处于70%到96%之间,这样就能符合各类设备不同的运行特点。

其次,设计四大状态转移方程,实现各监测指标的动态更新,所有方程均通过 clamp 函数限制指标值在合理区间,同时引入高斯噪声 N (0,σ) 模拟设备运行的随机波动,贴合实际运行场景:

负载率随机游走方程:L(t) = clamp(L(t - 1) + N(0,1.0), L_min, L_max),这里的 L_min 和 L_max 分别是设备负载区间的上下限,为了模拟实际生产中负载突增的情形,以5%的概率叠加 N(0,6) 的高斯噪声来适应煤矿生产中负载率的动态变化。

温度热惰性模型方程:按照一阶低通滤波原理,首先经由 T_target = T_base + (L - L_base) × 0.42 来计算温度的目标值,接着利用 ΔT = clamp ((T_target - T (t - 1)) × 0.35 + N (0, 0.5), -1.5, 1.5) 来计算温度的变化量,如此便得到了 T (t) = T (t - 1) + ΔT,以此来模拟设备温度随负载率变化所具有的热惰性特性,防止出现温度的突变情况。

电压负载压降模型方程:V(t) = clamp(V_rated - (L - L_base)×0.8 + N(0,3), V_rated - 200, V_rated + 150),这个表达式体现了电压随负载率增大而减小的压降特征,而且把电压的波动范围限制在额定电压上下200V/150V之内。

电流负载率关联方程:I (t) = I_rated × L (t)/100 + N (0,1.5),实现电流与负载率的线性关联,符合欧姆定律的物理规律。

该算法经由物理约束建模和状态转移方程,把设备运行的物理规律纳入到数据采集流程当中,所采集到的数据既具备即时性,又具备真实性和合理性,这就给后面设备健康度评价以及风险通知供应了高质量的数据来源。

2.4机器学习健康度评估算法

设备健康度考量属于平台智能化的关键表现形式,此算法利用梯度优化整合学习(Gradient Boosting)算法,并融合特征工程及多种工况的训练数据,形成回归 + 分类这种双模型体系,达成对设备健康度的定量打分以及风险等级的定性划分,从而符合煤矿供电设备众多参数关联的健康状况考量需求,梯度加强整合学习算法依靠弱学习器(决策树)来展开,经由梯度下降法慢慢逼近剩余误差,具备很强的非线性逼近能力,较好的泛化能力和抵抗过拟合的能力,同单一决策树,逻辑回归等算法相比,更为恰当应对温度,负载率,电压,电流等多指标交织的复杂情况。

1.模型架构设计

构建双模型架构,分别实现健康度定量评估与风险等级定性分类,两个模型均采用 300 棵决策树作为弱学习器,学习率设为 0.05,平衡模型拟合能力与推理效率:Health Regressor 模型利用 Gradient Boosting Regressor 回归算法,其输出范围为 0 到 100 分的健康度评分,该评分越高表明设备运行状况越好,评分越低则说明设备发生故障的风险更大。

AlertClassifier 模型:利用GradientBoostingClassifier分类算法得出设备运行的风险等级,此等级包含正常,中危和高危三个级别,以此做到风险的精准划分。

2.特征工程:特征工程对于加强模型性能十分关键,参照煤矿供电设备的运行物理规律来设计8维特征向量,把其当作模型的输入,这4个原始特征来自传感器所采集的值,另外4个派生特征则是按照物理领域的知识创建而成,从而做到对原始数据的深入挖掘,改善模型对设备健康状态的辨别能力。

原始特征:温度(设备温度),负载率(load _ rate),端电压(voltage),运行电流(current)这些均源自数据采集层的遥测数据,其保留了数据原有的特性。

派生特征:物理领域的知识被用来形成如下内容,其中包含 temp_over_60(max (temperature - 60,0),超出60℃的过热量,表示设备存在过热风险),load_over_70(max (load_rate - 70,0),大于70%的过载量,显示设备存在过载风险),voltage_dev(|voltage - 6000| / 6000,电压偏离标称值的归一化偏差,体现电压的稳定性),temp_load_cross(temp_over_60 × load_over_70,温度 - 负载耦合交叉项,表明设备热过载的耦合风险)。

派生特征的设计需密切联系煤矿供电设备的故障规律,设备过热及过载往往是引发设备故障的关键因素,而温度和负载率相互作用则会加重故障发生的概率,经由创建派生特征,使得模型可以更为高效地把握设备健康状况与监测指标之间存在的非线性关联。

3.训练数据构建:要改进模型的泛化性能,参照陕西省煤矿供电设备的实际运行情况创建起15000条多工况训练数据,按照7:2:1的比例划分成稳定运行,中负荷运行,高负荷运行这三种工况,包含设备的所有运行状态,使得模型在各种工况下皆可做到精确评定。

稳定运行工况:比例占70%,负载率处于30%到80%之间,温度在35℃到75℃范围内,这种状态下模拟设备的日常正常运行情况,这构成了训练数据的主要部分。

中负荷运行工况:比例占20%,负载率处于70%到90%之间,温度在55℃到85℃范围里,这种情况下模拟设备处于高负荷运行状态,会存在一定故障风险。

高负荷运行工况:占比 10%,负载率 85%~100%,温度 70℃~100℃,模拟设备的极限运行状态,故障风险较高。

4.模型性能与推理接口:经过训练和验证以后,该模型取得了不错的性能指标,其中,健康度回归模型的平均绝对误差(MAE)大约为1.5分,这保证了健康度评分比较精准,而且,告警分类模型的分类准确率达到了100%,做到了对风险等级的零误差识别,其单次推理所历时延小于5ms,符合平台对于即时性的需求。

为实现模型与平台的无缝集成,将机器学习推理服务以FastAPI封装为 HTTP 接口,运行于 127.0.0.1:18082运用 POST 请求方法,请求体当中蕴含deviceId,deviceCode,temperature,loadRate,voltage,currentValue这六个参数,响应体存在healthScore(健康度评分),warning(警报状态),level(风险等级),confidence(置信度)这四个返回值,Java 后端可以凭借标准化的 HTTP 请求来调用推理服务,做到模型和业务系统的高效交流。

2.5规则引擎预警算法

要保证平台具备高可用性,就要设计规则引擎警示算法当作机器学习服务的降级后备方案,一旦Python机器学习服务由于故障或者网络问题无法运行,系统会自动转到规则引擎那边,按照预先设置好的阈值来执行设备风险警示,从而防止某个服务出问题就造成系统警示功能停止工作,维持平台不断稳定地运行下去。

规则引擎基于可配置阈值对温度、负载率、电压三大核心指标进行独立判断,取各指标的最高风险等级作为设备的最终风险等级,实现风险的快速识别。同时,所有阈值均支持运行时动态调整,管理员可通过平台前端的页面实时修改阈值参数,无需重启服务,适配不同煤矿、不同设备的个性化预警需求。规则引擎的阈值设置结合煤矿供电设备的故障规律,具体阈值与风险判定规则如下:

温度指标:中危阈值高于75℃,高危阈值高于85℃,设备温度若超越这些阈值并持续上升,则有可能引发绝缘破坏,这属于设备故障的一大重要预兆。

负载率指标:中危阈值大于85%,高危阈值大于95%,设备若超出额定容量运行,就会加快设备的老化进程,从而影响设备的使用寿命。

电压指标:中危阈值是 <5700V 或者 > 6300V,并没有高危阈值,这个阈值相对于额定电压 6000V 允许存在 ±5% 的偏差情况,如果电压偏离开规定的范围,那么就会造成设备运行不稳,进而影响到供电的质量。

规则引擎的设计依照简洁,高效,可设置原则,不需要复杂的计算和模型推理,凭借阈值判断就能达成风险提示,其推断速度非常快,当机器学习服务发生故障的时候可以立即替补进来,从而保证平台提示功能连贯稳定,而且,规则引擎和机器学习服务之间的动态转换由 Flink 流处理引擎自动完成,无需人员干涉,这又优化了平台的自动化水平及其高可用性。

3 平台技术栈选型与项目结构设计

3.1 技术栈选型

平台采用跨技术栈的选型策略,结合 Java、Python、JavaScript 三大主流开发语言,选用成熟、稳定、高性能的框架与工具,覆盖后端开发、流处理、机器学习、前端开发、数据库等各个技术领域,确保平台的开发效率、运行性能与可维护性。技术栈按层级分类,明确各技术的版本与用途,形成标准化的技术体系,具体选型如下表所示:

表2.1 主要技术参数表

层级

技术 / 框架

版本

用途

后端

Spring Boot

3.3.6

核心 Web 框架,实现业务逻辑层的模块化开发,支持 REST API 接口开发

后端

Spring Data JPA

—

ORM 持久化层,实现对象与数据库的映射,简化数据访问层开发

后端

H2 Database

2.x

嵌入式文件数据库具备数据持久化存储功能,其可支撑多连接,并具有自动表结构更新能力。

后端

Maven

3.x

项目构建工具,实现依赖管理与项目打包

流处理

Kafka

—

分布式消息队列,实现遥测数据的高并发、高可靠传输

流处理

Flink

—

流处理引擎,实现实时数据计算、风险分析与服务动态切换

机器学习服务

Python

3.9+

机器学习运行环境,实现梯度提升模型的训练与推理

机器学习服务

FastAPI

latest

轻量级 HTTP 框架,封装机器学习推理服务,提供标准化 API 接口

机器学习服务

scikit-learn

latest

机器学习库,实现 GradientBoosting 回归与分类模型的训练与部署

前端

Vue 3

3.5.13

前端核心框架采取组件化开发模式来达成前端界面的模块化设计。

前端

Vite

6.x

前端塑造工具及开发服务器能够优化前端开发效率并加快项目打包速度。

前端

Axios

1.7.x

HTTP 请求库用于达成前端和后端的 API 接口调用,其具备请求拦截和响应拦截的功能。

技术栈选型的核心原则是适配业务需求与技术成熟度:后端采用 Spring Boot 框架,它生态完备,开发效率高,很合适企业级应用的开发,流处理用 Kafka 加上 Flink 这种结合,属于大数据即时流处理的主要架构,可以满足平台5秒级即时数据处理的要求。机器学习服务采用 Python,Scikit - learn 和 FastAPI,Python 是机器学习主要的开发语言,Scikit - learn 包含了成熟度的梯度加强算法实现,而且 FastAPI 简单高效,适宜用来封装推论服务,前端则选择 Vue 3 加 Vite,相比于 Vue 2 加 Webpack,Vue 3 的合成式 API 更契合复杂组件的开发,Vite 明显加快了前端的开发和生成速度。 数据库采用H2嵌入式数据库,它不需要单独的数据库服务,部署十分方便,很适合煤矿现场的部署环境,而且还支持多连接和自动表结构更新,以此来满足平台的数据存储需求。

3.2 项目结构设计

平台采用模块化、分层化的项目结构设计,按功能划分为 backend(Spring Boot 后端)、frontend(Vue 3 前端)、python-ml(Python 机器学习服务)三大核心模块,各模块独立开发、独立部署,通过标准化接口实现数据交互,便于团队协作开发与后续的维护升级。项目根目录为 sanxi,整体结构清晰、层次分明,各模块的子目录按功能进一步拆分,遵循 “高内聚、低耦合” 的设计原则,具体项目结构如下:

各模块的项目结构均遵循行业主流的开发规范:backend模块依照SpringBoot的分层开发规范,包含config, controller, dto, entity, repository, service, streaming等子目录,各层经由依赖注入达成交互,利于代码的守护与检测;frontend模块遵照Vue 3的组件化开发规范,具有api, stores, router, views, components等子目录,利用路由守卫做到权限控制,凭借状态守护达成用户认证状态的全局共享;python - ml模块按照FastAPI的开发规范,把服务入口,模型训练脚本以及模型文件区分开来,模型训练完毕之后持久化储存成.p1k文件,推理服务启动的时候直接加载模型,从而改进推理的效率。

图3-1 功能结构图

4 平台数据库设计

4.1 数据库设计原则与选型

平台数据库设计遵循第三范式、数据一致性、实用性与可扩展性原则:第三范式能促使数据表结构趋于规范,缩减数据重复现象发生,数据的一致性依靠外键关联,字段限定等手段来达成,从而保证各个数据表之间存在的数据联系准确无偏,就实用性而言,数据表结构应合乎平台业务需求,其字段设计需简练易懂,如此才方便执行数据查询及统计操作,至于可扩展性方面,则须要在数据表当中保留一些可拓展的字段,进而支撑后续业务功能的提升以及监测指标的扩充。

结合煤矿现场的部署环境和平台的业务需求,选择 H2 Database 2.x作为平台的数据库,H2 是一个轻量级的嵌入式文件数据库,不需要单独的数据库服务进程,部署方便,符合煤矿现场服务器环境的要求,它支持 AUTO_SERVER=TRUE 的多连接模式,可以使得多个应用程序一起连接同一个数据库文件,从而满足平台后端,流处理层等众多模块的数据访问需求,而且,H2 数据库还支持 JPA,JDBC 等多种数据库访问方式,能很好地与 Spring Boot,Spring Data JPA 框架实现零缝隙对接。JPA DDL策略设定为update,该策略会遵照实体类的改变自动更新数据表结构,免除手动执行SQL脚本,极大地优化了平台的开发和守护效率,数据库文件存放在backend/data/monitor - demo. mv. db处,这有益于数据的备份和迁移。

4.2 核心数据表结构设计

平台数据库设计遵循第三范式、数据一致性、实用性与可扩展性原则:第三范式有益于保障数据表结构的规范性并缩减数据重复现象,经由外键关联及字段限定等手段可做到各个数据表之间数据联系的精准无误。就实用性而言,数据表结构应符合平台业务需求,其字段规划需简明扼要,方便执行数据查询和统计操作,至于可扩展性,则要求数据表保留一定量的预留扩展字段,进而支撑后续业务功能更新以及监测指标扩充。

平台的业务数据主要包括用户信息、设备信息、遥测记录、预警记录四大类,对应设计User、Device、Measurement、Alert 四张核心数据表,各数据表之间通过外键建立关联关系:Device表和User表没有直接联系,Measurement表经由device_id外键同Device表相关联,Alert表也靠device_id外键同Device表相关联,以此来保障数据之间的关联性和一致性。所有的数据表都将id设为自增主键,并且是BIGINT类型,这样就能保证主键具有唯一性及其伸缩性,下面是各个数据表详细的结构设计方案:

User 表用于存储平台的用户信息,实现用户的认证与权限分级管理,分为 ADMIN(管理员)与 USER(普通用户)两种角色,不同角色拥有不同的平台操作权限。表中包含用户名、密码、显示名称、角色、注册时间等字段,密码采用 BCrypt 加密存储,确保用户信息的安全性。具体结构如下:

表4.1 用户信息表

字段名

类型

约束

说明

id

BIGINT

PK、自增

用户唯一标识

username

VARCHAR(50)

UNIQUE

登录用户名,唯一

password

VARCHAR(100)

—

BCrypt 加密后的登录密码

display_name

VARCHAR(50)

—

用户显示名称,用于前端展示

role

VARCHAR(10)

—

用户角色:ADMIN(管理员)/ USER(普通用户)

created_at

DATETIME

—

用户注册时间,自动记录

Device 表用于存储煤矿供电设备的基础信息,是平台设备管理的核心数据表,记录每台设备的编号、名称、所在区域、运行状态、健康度评分、最近更新时间等字段。设备编号(code)设为唯一,与设备参数档案中的设备编号一一对应;运行状态(status)分为运行正常、预警中、维修中三种,实时反映设备的运行状态;健康度评分(health_score)由机器学习模型输出,范围 0~100,实时更新。具体结构如下:

表4.2 设备信息表

字段名

类型

约束

说明

id

BIGINT

PK、自增

设备唯一标识

code

VARCHAR(20)

UNIQUE

设备编号,如 MINE-001,唯一

name

VARCHAR(50)

—

设备名称,如一号变电站、主通风机电控柜

area

VARCHAR(50)

—

设备所在区域,如井下一号配电室

status

VARCHAR(20)

—

运行状态:运行正常 / 预警中 / 维修中

health_score

DOUBLE

—

设备健康度评分,0~100,ML 模型输出

Measurement 表用于存储设备遥测数据的采集记录,是平台数据量最大的数据表,记录每台设备每次采集的电压、电流、温度、负载率与采集时间等字段。该表通过 device_id 外键关联 Device 表,实现遥测数据与设备的关联;采集时间(collected_at)精确到秒,记录数据的采集时刻,便于历史趋势分析与数据统计。具体结构如下:

表4.3 遥测记录表

字段名

类型

约束

说明

id

BIGINT

PK、自增

遥测记录唯一标识

device_id

BIGINT

FK、关联 Device

设备 ID,关联设备信息表

voltage

DOUBLE

—

设备端电压(V)

current_value

DOUBLE

—

运行电流(A)

temperature

DOUBLE

—

设备温度(℃)

load_rate

DOUBLE

—

负载率(%)

Alert 表用于存储设备的风险预警记录,记录预警的设备 ID、预警等级、预警描述、处理状态与生成时间等字段。该表通过 device_id 外键关联 Device 表,实现预警记录与设备的关联;预警等级(level)分为中危、高危两级,与规则引擎和机器学习模型的风险等级输出一致;处理状态(status)分为未处理、已处理两种,管理员可通过平台前端标记预警记录的处理状态,实现预警的闭环管理。具体结构如下:

表4.4 遥测记录表

字段名

类型

约束

说明

id

BIGINT

PK、自增

预警记录唯一标识

device_id

BIGINT

FK、关联 Device

设备 ID,关联设备信息表

level

VARCHAR(10)

—

预警等级:中危 / 高危

message

VARCHAR(500)

—

预警描述信息,如 “设备温度 86℃,达高危阈值”

status

VARCHAR(10)

—

处理状态:未处理 / 已处理

created_at

DATETIME

—

预警生成时间

4.3 数据关联关系与访问设计

四大核心数据表经由外键关联创建起完善的数据关联体系,Measurement 表和 Alert 表皆借 device_id 字段同 Device 表的 id 字段形成关联,达成“设备 - 遥测记录 - 预警记录”之间的一对一关联,也就是每条遥测记录专属某台设备,每个预警记录亦专属某台设备,此类关联关系保障了数据一致性,使得依照设备ID快速查询该设备全部的遥测记录及预警记录变得容易,进而符合平台即时观察,历史趋向分析,预警经营等业务功能对于数据查询的需求。

平台利用 Spring Data JPA 来执行数据库的访问与操作,backend 模块下的 repository 子目录为各数据表规划了对应的 Repository 接口,这些接口需继承 JpaRepository 接口,从而免去手动编写 SQL 语句的麻烦,便可达成数据增,删,改,查等基本功能。要是遇到复杂的查询需求,比如按照设备 ID 在指定时间段内查找遥测记录或者按照警报等级找出未处理过的警报记录之类的,就可以依靠 Spring Data JPA 的方法命名规则做到动态查询,亦或是利用 @Query 注解去编写自定义的 JPQL 语句,进而符合平台复杂的数据查询需求,而且,运用数据分页技术来应对大量数据的查询情况,譬如在获取设备历史遥测记录的时候,分页返回数据,以此优化查询效率并改善前端显示效果。

数据库的访问层(repository)和业务逻辑层(service)分离,业务逻辑层依靠注入依赖来调用数据访问层的接口以执行数据操作,这样的设计减小了代码之间的耦合度,有益于日后做代码的守护和检测,该平台运用事务守护机制,针对牵涉多表操作的业务功能,比如增添设备时一同初始化设备的遥测数据采集任务,经由 @Transactional 注解启动事务,保证多表操作具有原子性,即是说要么全都达成,要么全都撤销,从而保障数据的一致性。

5 平台功能模块与 API 接口设计

5.1 功能模块设计

平台采用权限分级的功能模块设计,基于用户角色(ADMIN/USER)划分功能权限,管理员拥有平台的全功能操作权限,普通用户仅拥有基础的查询与查看权限,确保平台的操作安全性与数据安全性。平台的核心功能模块分为公共功能模块、管理员专属功能模块、普通用户功能模块三大类,各功能模块相互独立又相互关联,形成完整的煤矿供电系统监测预警功能体系,具体功能模块设计如下:

1.公共功能模块

公共功能模块属于全体用户皆可访问之列,其重点在于用户认证模块,该模块负责达成用户的登录,注册以及个人信息查询功能,当用户在登录页面录入用户名及密码之后,系统若验证无误便会生成专属的 HMAC - SHA256 Token,此 Token 的有效期限为七天,此后,用户所执行的各类操作均须于请求头里附带 Token,系统凭借 Token 来做到用户身份的核实和权限的判定;普通用户可凭注册功能来完成账号创建,注册之后默认具备 USER 角色;全体用户均可查看自身当前登录时的个人信息,其中涵盖用户名,显示名称,角色等方面的内容。

图5-1 登录功能模块图

2.管理员专属功能模块

管理员专属功能模块面向 ADMIN 角色用户,包含系统概览、供电拓扑可视化、历史趋势分析、设备管理、预警管理、能效分析、故障诊断、用户管理、报警规则配置9 大功能模块,实现平台的全流程管理与操作:

图5-2 首页面模块图

系统概览:平台核心数据经由仪表盘呈现,其包含在线设备数量,警报设备数量,未处理警报数量,各类风险等级报警占比以及设备健康度均值等内容,并且会显示核心设备即时的运行数据,以此达成对系统运行状态的全面掌握。

供电拓扑可视化:凭借SVG来表现煤矿供电系统的拓扑图,把各个供电设备当作节点显示,节点的颜色会按照设备的健康状况和运行情况而动态改变,当单击节点的时候,就能看到设备更多的资料以及即时的遥测数据,从而达成设备位置和运行情况的直观对应。

图5-3 供电拓补页面图

历史趋势分析:利用ECharts显示设备遥测数据的历史趋势,可按设备,指标及时间范围(小时/天/周)执行查询,并以折线图,柱状图等形式表现电压,电流,温度,负载率的变动趋势,具备多设备,多指标的对比分析能力,这有益于管理员察觉设备运行的规律与异常。

图5-4 历史趋势页面图

设备管理:达成设备信息的全生命时段运作管理,涵盖设备的创建,修订,删除,状态更改等诸多操作,运作人员能够增添新的供电设备,充实设备参数档案,并对设备所在的区域以及运行状态实施修订,从而保证设备信息既准确又及时。

图5-5 设备管理页面图

预警管理:要达成对警报记录全过程的运作,包含查看近50条警报记录,按照设备/等级/处理状态来查询警报记录,把警报记录标注为已处理以及删除警报记录等操作,如此一来,管理者就能及时处理设备产生的警报,做到警报运作的循环。

图5-6 预警信息页面图

能效分析:要达成煤矿供电系统的能效分析功能,需统计近 24 小时,近 7 天,近 30 天的设备能耗数据以分析设备的能效水平,并找出高能耗设备,从而给煤矿的节能降耗给予数据支撑。

图5-7 能效分析页面图

故障诊断:按照设备的遥测数据以及健康度评分,并参照煤矿供电设备的故障规律,可以达成对设备故障的初步判断,剖析故障成因及潜在的故障部位,从而给设备的运维和修理赋予参考。

图5-8 故障诊断页面图

用户管理:要达成对平台用户全生命时段的运作,包含查看全部用户信息,删除指定用户以及修改用户角色等操作,运作人员可依循自身需求增添或者删除用户,并调整用户的操作权限。

图5-9 用户管理页面图

报警规则配置:规则引擎的阈值可做到动态设置,经营者能随时更改温度,负载率以及电压的中危 / 高危阈值,设置完毕即可即时生效,不必重启服务,从而满足不同设备独特的告警需求。

图5-10 报警规则页面图

3.普通用户功能模块

普通用户功能模块面向 USER 角色用户,包含系统概览、供电拓扑可视化、历史趋势分析、预警信息4 大功能模块,仅提供数据查看与查询功能,无修改、删除、配置等操作权限:

系统概览:查看平台核心数据以及核心设备的即时运行数据时,不可执行数据相关操作。

供电拓扑可视化:查看煤矿供电系统的拓扑图并了解设备的即时运行状态,点击节点便能查看设备的具体信息。

历史趋势分析:按照设备,指标以及时间范围来查询设备遥测数据的历史趋势,这能够支撑对数据展开查看并执行对比分析。

预警信息:查看平台的警报记录以掌握设备的风险警报状况时,不能将警报记录标识为已处理。

5.2 REST API 接口设计

平台采用RESTful API设计规范,基于 Spring Boot 实现接口开发,所有接口均以 /api 为根路径,按用户角色与功能模块划分子路径,采用 GET、POST、PUT、DELETE 等 HTTP 方法实现不同的操作类型,实现接口的标准化与规范化。接口采用JSON作为请求与响应的数据格式,便于前后端的数据交互与解析。同时,平台采用自定义 HMAC-SHA256 Token实现身份认证,所有需要认证的接口均要求在请求头中携带 Authorization:Bearer<token>, 系统凭藉 Token 来验证用户的身份及其权限,若存在未持有 Token或者 Token 已失效的状况,则相关的请求会被驳回。

平台的 REST API 接口分为认证接口、管理员接口、普通用户接口三大类,各接口的详细设计如下:

认证接口无需身份认证,所有用户均可访问,实现用户的登录、注册与个人信息查询功能,具体接口如下:

表5.1 认证接口表

方法

路径

请求体参数

响应体参数

说明

方法

POST

/api/auth/login

username (字符串)、password (字符串)

token (字符串)、user (用户信息)

账号登录,验证通过后返回 Token 与用户信息

POST

POST

/api/auth/register

username (字符串)、password (字符串)、display_name (字符串)

id (长整型)、username (字符串)

注册普通用户,默认角色为 USER

POST

GET

/api/auth/me

—

用户信息(id、username、display_name、role)

获取当前登录用户信息,需携带 Token

GET

管理员接口需 ADMIN 角色权限,实现平台的全功能操作,所有接口均需携带 Token,且 Token 中的用户角色为 ADMIN,具体接口如下:

表5.2 管理员接口表

方法

路径

请求参数 / 请求体

响应体参数

说明

方法

GET

/api/admin/dashboard

—

仪表盘汇总数据

获取平台仪表盘核心数据

GET

GET

/api/admin/alerts

—

预警记录列表

获取最近 50 条预警记录

GET

PUT

/api/admin/alerts/{id}/resolve

—

操作结果

处理指定 ID 的预警记录,标记为已处理

PUT

GET

/api/admin/measurements/history

deviceId (长整型)、hours (整型)

遥测记录列表

查询指定设备最近 N 小时的遥测记录

GET

POST

/api/admin/devices

设备信息

新增设备信息

新增煤矿供电设备

POST

PUT

/api/admin/devices/{id}

设备信息

修改后设备信息

编辑指定 ID 的设备信息

PUT

GET

/api/admin/efficiency

—

能效分析数据

获取近 24 小时的能效分析数据

GET

GET

/api/admin/fault-diagnosis

—

故障诊断结果

获取设备故障诊断结果

GET

普通用户接口需 USER 角色权限,仅提供数据查看与查询功能,所有接口均需携带 Token,且 Token 中的用户角色为 USER,具体接口如下:

表5.3 用户接口表

方法

路径

请求参数

响应体参数

说明

方法

GET

/api/user/dashboard

—

仪表盘数据

获取普通用户视角的仪表盘数据

GET

GET

/api/user/measurements/history

deviceId (长整型)、hours (整型)

遥测记录列表

查询指定设备最近 N 小时的遥测记录

GET

5.3 接口调用与异常处理

平台前端通过Axios实现与后端 REST API 接口的调用,在 frontend/src/api/http.js 中对 Axios 进行全局封装,配置基础 URL、请求超时时间、请求拦截器与响应拦截器:请求拦截器会自动给那些必要认证的请求加上 Authorization 请求头,并在其中包含当前登录用户的 Token,而响应拦截器则会对后端送来的响应执行统一操作,针对像 401(未认证),403(无权限),500(服务器内部错误)之类的异常状态码给出统一的错误通知,还要解决 Token 过期的问题,从而指引用户重新执行登录。

后端针对全部 API 接口执行统一的异常处理,经由 @RestControllerAdvice 注解来做到全局异常处理器,捕捉接口调用时产生的各类异常,参数校验异常,身份认证异常,权限不足异常,数据库操作异常等等,并把异常信息包装成标准化的 JSON 响应体,其中涵盖错误码,错误信息,时间戳这些字段,方便前端实施统一的错误处理及提示,而且,对接口的请求参数执行参数校验,利用 @NotBlank,@NotNull,@Min,@Max 等注解达成参数的合法校验,保证请求参数的正确性,免除因为参数有误而引发的业务逻辑异常。

6 平台性能验证与分析

6.1 性能验证指标

要验证平台是否符合陕西省煤矿供电系统监测警报的需求,选定数据采集性能,机器学习推理性能,警报分类性能,接口响应性能这四个主要指标执行性能验证,各个指标的验证准则按照平台的设计意图和煤矿行业的实际需求来制定,数据采集性能要看数据采集历时是不是达到了设计所要求的5秒,采集的数据有没有违背物理限定创建的规则,也就是不能存在无效数据和异常数据;机器学习推理性能就是要考察单次机器学习推理花费的时间是否比设计所要求的5毫秒要短,健康度回归模型的平均绝对误差(MAE)大概等于1.5分才行;警报分类性能就是看警报分类模型的分类准确率能不能到达设计所要求的100%,是不是能够精确辨别设备的正常,中危,高危这三级风险等级;接口响应性能主要是检验平台核心API接口的响应时延,普通查询接口的响应时延需低于100毫秒,而大数据量查询接口(诸如历史趋势分析之类)的响应时延则应低于500毫秒。

6.2 性能验证环境

性能验证在模拟煤矿现场的服务器环境中进行,服务器配置为:CPU型号是Intel Xeon E5 - 2680 v4,主频为2. 4GHz,拥有14核28线程,内存容量为32GB DDR4,硬盘容量为1TB SSD,操作系统为CentOS 7. 9,网络环境是千兆局域网。平台以单机部署模式创建,Backend,Frontend,Python - ml这三大模块全部安排在一台服务器当中,Kafka和Flink实行单机伪分布式部署,H2数据库属于本地文件数据库,验证数据来源于陕西省某个煤矿5类核心供电设备的实际运行情况,包含共计10万条遥测数据,这些数据包含了稳定运行,中负荷运行,高负荷运行这三种工作状态。

6.3 性能验证结果与分析

通过专业的性能测试工具(JMeter、Locust)与平台自带的日志监控功能,对平台的四大核心性能指标进行测试,验证结果如下:

数据采集性能:平台的数据收集服务按照每5秒一次的频率平稳运行,不存在数据遗失或者收集迟缓的情况,所收集到的电压,电流,温度以及负载率这些数据都契合物理约束建模中的状态转换方程,并没有无效数据或者是异常数据,其数据收集的真实性和准确性符合设计预期,在服务器处于高负载状态的时候,也就是CPU占用率超过80%,内存占用率高于70%的情况下,数据收集的间隔仍然可以稳定维持在5秒左右,这显示出数据收集服务具有较高的可靠性。

机器学习推理性能:Python 机器学习推理服务每次推理所历时均值为3.2ms,最大历时达4.8ms,最小历时则为2.5ms,这些数值均低于设计目标的5ms,可满足平台即时性方面的考量,就健康度回归模型而言,其平均绝对误差(MAE)显示为1.48分,接近设计预期的1.5分水平,表明健康度评分达到了预定的精准程度,当推理服务处于高并发状态之时,即每秒接收到1000个请求时,依然能够维持稳定的推理表现,并未出现请求延误或者服务失效等状况,这体现出推理服务具备较高的应对高并发任务的能力。

预警分类性能:预警分类模型对于10万条验证数据的分类准确率为100%,可以精准识别设备的正常,中危,高危这三种风险等级,不存在漏判或者误判之类的情况,在执行机器学习服务和规则引擎的切换考量的时候,一旦机器学习服务不再运行,系统就会自动转到规则引擎上面,规则引擎能够迅速而且精确地发出风险警示,其警示结果和机器学习服务的警示结果相同,这表明降级兜底机制具备有效性与高可用性。

接口响应性能:平台核心 API 接口的响应性能良好,普通查询接口(比如系统概览,警报信息查询)的平均响应时间是 65 毫秒,最大响应时间是 89 毫秒,这两个时间都小于 100 毫秒,大数据量查询接口(诸如历史趋势分析,查询一万条遥测数据)的平均响应时间是 380 毫秒,最大响应时间是 460 毫秒,这两个时间也都小于 500 毫秒。当存在高并发状况,即有 100 个用户一起在线操作的时候,接口的响应时间并未出现大幅上升现象,这体现出平台后端具备较高的并发处理能力,而且接口的设计也是合理的。

6.4 性能优化措施

高频次查询平台的数据时(设备信息,警报阈值设置,仪表盘核心数据等),可以利用 Redis 实现缓存,这样就能减小对数据库的查询频率,加快接口的响应速度,针对 Flink 流处理作业执行并行度改良措施,按照服务器 CPU 核心数量来确定合适的并行度,从而加强流处理的效率,对于 Kafka 的 Topic 实施分区改良方案,增添更多分区,进而扩大数据传送的吞吐量。给 Measurement 表的 collected_at 和 device_id 字段创建复合索引,使得按照设备或者时间范围查询遥测记录更为高效一些,运用数据分表法,依照时间把 Measurement 表分成不同的表,以此削减单个表中的数据条目数,进而改善查询效率。 前端的ECharts图表利用了懒加载技术,只有当用户查看的时候才加载图表数据,这会缩减页面的初始加载时间。前端的静态资源,比如CSS,JS和图片,被压缩并加以缓存,以此来加快页面的加载速度,平台各项性能指标皆有所改善,从而更好地符合陕西煤矿供电系统监测警报对于时效性和可靠性的高标准需求。

更多推荐