简介这是一套输电线路覆冰厚度预测系统的工程资料包面向电气工程、数据挖掘等方向的毕业设计、课程设计或创新项目。系统覆盖数据采集、特征处理到覆冰厚度预测的完整链路适合需要快速搭建预测模型或完成项目交付的学生与开发者。压缩包共334个文件约33.94MB包括Java与JSP后端逻辑java、class、jsp、JavaScript与CSS前端交互、SQL数据库脚本、XML配置文件以及PNG/GIF/JPG图示等目录结构清晰便于定位核心代码与说明文档。已有96人学习下载。资源内含完整源码、工程文件与说明文档项目代码经过运行验证功能正常可直接复现或基于现有框架扩展新功能。作者提供使用答疑支持可用于答辩参考、实验对照或初期项目立项。1. 输电线路覆冰厚度预测从气象时序到冰厚回归的完整建模路径输电线路覆冰是冬季电力系统面临的最直接威胁之一。导线上的冰层在自重和风荷载共同作用下可能让杆塔长期处于超设计负荷状态最终导致倒塔断线。覆冰厚度并不是一个可以直接观测的物理量工程上通常依赖微气象站的温度、湿度、风速、风向和降水数据结合拉力传感器或视频图像间接估算。把气象条件变化映射到未来数小时冰厚增长本质上是一个多输入单输出的回归问题。对做毕设、课设或竞赛的同学来说这个题目的价值在于它覆盖了数据清洗、特征工程、回归建模、模型部署和前端可视化一整条链路每一环都能单独拿出来讲清楚。常见做法是用微气象数据构造特征矩阵用 LightGBM 或随机森林训练冰厚回归模型再通过 Flask 封装成推理接口配合 Spring Boot 和 Vue 完成前后端交互。本文按这个方案把每个环节落地参数和坑都会说到。2. 覆冰样本构造与气象特征选择先解决没有数据的问题2.1 原始数据形态与冰厚标签的来源实际项目的原始数据一般来自两类设备微气象站的逐小时气象记录以及覆冰在线监测装置给出的冰厚标签。气象记录涵盖温度、相对湿度、风速、风向、降水量、气压等冰厚标签来自监测塔上的称重传感器或图像识别结果。两者在数据表里表现为一个时间对齐的序列每一行是某一时刻的气象观测值加上当前冰厚值。样本构造就是把这张表按时间展开得到特征矩阵X和标签y。难点在于标签的可获取性。不少公开数据集没有直接给出冰厚而是给出绝缘子串风偏角或导线拉力值。此时需要用拉力传感器的标定曲线反算总拉力减去导线自重和风附加力剩余部分折算成冰重再按导线长度和冰密度换算为等效冰厚。换算公式各厂家不一致做课设时如果拿不到标定参数退而求其次的做法是把拉力增量直接作为回归目标虽然物理意义稍弱但趋势预测依然成立。样本构造的关键是时间对齐。冰厚增长有明显滞后性当前时刻的冰厚不仅取决于此刻的温度和降水还依赖过去数小时的累积效应。因此常见做法是把过去 6 到 24 小时的气象窗口做滑窗统计生成滚动特征后再与当前冰厚对齐。窗口长度选择需要看数据粒度逐小时数据用 12 小时窗口比较稳妥半小时粒度可以缩到 6 小时。2.2 覆冰物理机制与 7 个核心气象特征覆冰主要有三种形成机制雨凇冻雨附着、雾凇过冷却雾滴冻结和混合凇。其中雨凇增长最快、危害最大要求温度接近 0℃、相对湿度接近饱和、有液态降水。雾凇则发生在更低温、低含水量的环境下增长缓慢但持续时间长。从机制上就能推导出哪些特征对建模最重要温度决定相态湿度决定过冷却水供应风速决定水滴碰撞量降水直接提供水源。我一般把初始特征分为三个层次来构造而不是把所有原始列直接丢进模型。第一层是单点观测值即当前时刻的温湿度、风速风向、降水和气压第二层是滑动窗口统计比如过去 6 小时温度均值、过去 12 小时累计降水量、过去 24 小时低于 0℃ 的时长第三层是物理机制衍生特征比如露点温度和饱和差。分层构造的好处是方便排查特征泄漏也便于答辩时解释每个变量的物理含义。下表是实际项目中我常用的 7 个核心特征它们的工程提取方式都可以用 pandas 向量化实现特征名物理含义工程提取方式temp环境温度决定冰的相态微气象站整点观测rh相对湿度反映过冷却水供应过去 3 小时滑动平均wind风速影响水滴碰撞量取最大阵风值与均值两列precp降水量雨凇的水源过去 6 小时累计值press气压辅助判断冻雨天气系统一阶差分wind_dir_sin/cos风向地形抬升导致局部覆冰增强按角度转 sin 和 cos 两列low_temp_hrs持续低温时长冰层累积的驱动力统计过去 24h 温度低于 0℃ 的次数注意风向不能直接填数值进模型。0 度和 360 度在数值上相差 360但物理上完全同向直接编码会让树模型产生错误的分裂。我一般会把风向拆成sin和cos两个分量既保留了角度信息又避免了环状变量的数值突变问题。2.3 缺失值处理与按冰期划分训练集气象站数据缺失是常态通信中断、传感器冻结、维护窗口都会产生空洞。不同变量的缺失处理策略不同不能统一用均值填充。温度、湿度这类缓慢变化量用线性插值效果最好风速用前向填充因为风速突变少见降水量缺失按 0 处理因为无记录通常意味着无降水风向则需要先转成 sin/cos 再插值避免角度跨越问题。import pandas as pd import numpy as np def load_and_clean(path): df pd.read_csv(path, parse_dates[ts]) df df.sort_values(ts).reset_index(dropTrue) # 温度、湿度线性插值保证首尾也补上 df[temp] df[temp].interpolate(methodlinear, limit_directionboth) df[rh] df[rh].interpolate(methodlinear, limit_directionboth) # 风速前向填充最多补3小时 df[wind] df[wind].ffill(limit3) # 降水缺失按0处理 df[precp] df[precp].fillna(0) # 风向转sin/cos df[wind_sin] np.sin(np.deg2rad(df[wind_dir])) df[wind_cos] np.cos(np.deg2rad(df[wind_dir])) return df逻辑说明interpolate对缓慢变化的温湿度序列效果好limit_directionboth保证序列开头和结尾的缺失也能补齐ffill用于短时风速缺失但limit3限制最多前向补 3 小时超过就保持 NaN后续由模型处理降水fillna(0)是因为自动气象站无降水记录即代表无降水不能用均值填充。数据集划分必须按冰期而不是随机抽样。如果把两个年份的数据混在一起随机切分模型会通过时间相关的潜在变量记住特定年份的覆冰过程导致测试集分数虚高实际部署时表现明显下降。推荐做法是用第一年完整冰期做训练第二年完整冰期做验证第三年做测试。每个集合都跨越完整的气候周期模型才能学到跨年的泛化能力。如果只有一年的数据至少按t 月之前训练、t 月之后测试来切而不是按行随机。3. 覆冰厚度预测模型用 LightGBM 建立基准回归3.1 选型对比为什么树模型是首选方案覆冰预测领域有三类主流方法物理模型、时间序列深度模型、树模型。物理模型如 Makkonen 模型在理论上严谨但需要现场标定雨凇密度、水滴中值体积直径等参数这些参数在课设环境里根本拿不到强行套用只会让结果和实测差很远。LSTM 等时序模型适合长序列依赖但对数据量要求高覆冰样本往往只有几个月有效数据训练 LSTM 容易欠拟合而且难解释。LightGBM 在表格数据上精度高、对缺失值容忍、训练速度快还能直接输出特征重要性答辩时非常有说服力。用 LightGBM 做覆冰预测需要确认一点这不是多步时间序列预测而是当前气象状态到当前冰厚的监督回归。第一版就做标准回归输入是过去 12 小时滑窗统计特征输出是此刻冰厚不要引入上一时刻的预测值作为特征那会造成误差累积调试难度成倍增加。3.2 构造滑动窗口特征与训练代码滑窗特征的构造有一个极其容易踩的坑窗口统计的终点必须严格早于目标时刻否则就是数据泄漏。比如要预测 12 月 10 日 14:00 的冰厚特征窗口只能用 13:00 及之前的数据不能把 14:00 的温度均值也算进去因为在真实场景里 14:00 的数据要等时刻到了才知道。from sklearn.model_selection import TimeSeriesSplit import lightgbm as lgb def make_features(df): df df.copy() # 关键shift(1) 保证只用 t-1 及之前的数据避免泄漏 df[temp_6h_mean] df[temp].rolling(6, min_periods1).mean().shift(1) df[rh_6h_max] df[rh].rolling(6, min_periods1).max().shift(1) df[precp_12h_sum] df[precp].rolling(12, min_periods1).sum().shift(1) df[low_temp_hrs] (df[temp] 0).rolling(24, min_periods1).sum().shift(1) # 删除开头因 rolling 产生 NaN 的行 df df.dropna() return df feat_cols [temp, rh, wind, precp, wind_sin, wind_cos, temp_6h_mean, rh_6h_max, precp_12h_sum, low_temp_hrs] X df[feat_cols] y df[ice_mm] # 按时间顺序切分前80%训练后20%测试 split_idx int(len(X) * 0.8) X_train, X_test X.iloc[:split_idx], X.iloc[split_idx:] y_train, y_test y.iloc[:split_idx], y.iloc[split_idx:] model lgb.LGBMRegressor( n_estimators300, # 树的数量配合 early_stopping 使用 learning_rate0.05, # 学习率调小防止过拟合 max_depth6, # 限制单棵树深度 num_leaves31, # 叶子节点数越大模型越复杂 subsample0.8, # 行采样比例 colsample_bytree0.8, # 列采样比例 random_state42 ) model.fit(X_train, y_train, eval_set[(X_test, y_test)], eval_metricrmse, callbacks[lgb.early_stopping(50)])代码里的几个参数值得展开说明。shift(1)是整个特征工程的命门少了它模型效果会虚假地好上线就崩。min_periods1是为了让序列开头的窗口也能算出统计值避免产生大量 NaN。early_stopping(50)的意思是验证集 RMSE 连续 50 轮不下降就停止训练防止树数量过多导致过拟合。eval_metricrmse是因为冰厚是连续数值RMSE 对大幅偏离的预测更敏感。3.3 LightGBM 必调参数与对冰厚分布的处理覆冰数据有一个显著特点无冰时段占比极高冰厚为 0 的样本可能超过 80%。模型如果直接训练会倾向于把大多数样本预测为接近 0 的小值因为在 RMSE 目标下这样损失最小。结果是整体误差不大但一旦真正覆冰预测值会严重滞后。解决思路有两个方向我一般先做标签变换再看是否要加权对冰厚标签做sqrt或log1p变换压缩大冰厚区间的误差权重让模型更关注小值区的精度。在fit时给冰厚大于 3mm 的样本加权重比如sample_weight设为 2强制模型关注稀有但重要的覆冰事件。训练完成后预测值要反向变换回原始尺度注意log1p对应expm1。另外一个高频参数调优点是num_leaves。在气象小数据集上num_leaves超过 64 基本就会过拟合验证集误差不降反升。建议先用默认 31 跑基线再做一轮num_leaves网格搜索配合max_depth一起约束树复杂度。feature_fraction设置在 0.7~0.8 之间能有效增加随机性让集成模型更稳。3.4 预测结果的时序平滑与评估口径单点回归输出的冰厚预测在时间轴上会抖动相邻两个时刻的预测值可能相差 2mm这在工程上不可接受。覆冰是缓慢过程冰厚不可能在 1 小时内剧烈跳变。常见做法是对预测序列做指数平滑让输出曲线更贴近真实物理过程。def smooth(y_pred, alpha0.3): out [y_pred[0]] for v in y_pred[1:]: # 新预测占30%历史趋势占70% out.append(alpha * v (1 - alpha) * out[-1]) return outalpha越小曲线越平滑但对新变化的响应越慢alpha越大响应越快但抖动抑制变差。0.3 是一个兼顾响应速度和稳定性的常用取值。评估指标上MAE 直观但不利于反映大误差RMSE 对超过 5mm 的预测偏差更敏感。更推荐的评估口径是归一化 MAE用 MAE 除以测试集冰厚的标准差方便不同地区、不同数据规模之间横向对比。4. 覆冰预测系统前后端实现从模型到可演示的毕业设计4.1 系统整体架构与模块边界毕设级别的覆冰预测系统不需要微服务三块结构足够Python 推理服务、业务后端、展示前端。Python 服务负责加载训练好的模型和特征构造函数接收气象序列输入返回预测冰厚业务后端一般用 Spring Boot负责接收前端请求、做参数校验、调用 Python 服务、把结果存入数据库前端用 Vue 或纯 HTML 页面展示预测值和趋势图。我建议在三个模块之间明确约定接口协议气象输入统一用 JSON 数组每个元素包含时间戳、温度、湿度、风速、风向、降水等字段输出统一用{ ts: 2024-12-10 14:00, ice_mm: 12.5 }的格式。这样做的好处是训练时的特征处理函数和推理时的处理函数完全共用前端、后端、模型三端解耦替换任一模块都不影响其他部分。4.2 用 Flask 封装模型推理接口推理接口的设计比训练代码更讲究。模型文件通过 joblib 保存特征构造函数要单独复用训练脚本里的版本不能推理时重写一份否则训练和推理的特征列顺序不一致预测结果就会系统性偏移。from flask import Flask, request, jsonify import joblib import pandas as pd app Flask(__name__) model joblib.load(lgb_ice.pkl) feat_cols [temp, rh, wind, precp, wind_sin, wind_cos, temp_6h_mean, rh_6h_max, precp_12h_sum, low_temp_hrs] app.route(/predict, methods[POST]) def predict(): data request.get_json() # 前端传入的历史气象序列 df pd.DataFrame(data[history]) # 复用训练时的特征构造函数 feat make_features(df) feat feat[feat_cols].iloc[[-1]] pred model.predict(feat)[0] return jsonify({ ts: data[ts], ice_mm: round(float(pred), 2) }) if __name__ __main__: app.run(host0.0.0.0, port5000)几个细节说明host0.0.0.0是为了让同网段的 Spring Boot 容器能访问到该服务开发环境可以改用127.0.0.1增加安全性。iloc[[-1]]只取特征构造后的最后一行因为前端传入的是完整历史序列目标预测点是序列末端。round(..., 2)控制返回精度避免前端展示长尾小数。推理接口里不要做模型训练或重载模型实例在服务启动时加载一次即可。4.3 Spring Boot 调用 Python 推理接口的数据流转Spring Boot 在整体架构中的角色是中间编排层接收 Vue 提交的 JSON对气象参数做基础校验再通过 RestTemplate 调用 Python 推理接口拿到结果后写入 MySQL 用于曲线回放最后把预测结果返回前端。调用 Python 服务时有两个注意点超时时间一定要设置Python 推理如果处理慢会导致前端长时间挂起异常要兜底Python 服务挂了不能把 500 错误直接暴露给用户。PostMapping(/forecast) public Result forecast(RequestBody ListWeatherRecord records) { String pyUrl http://localhost:5000/predict; RestTemplate rt new RestTemplate(); HttpHeaders headers new HttpHeaders(); headers.setContentType(MediaType.APPLICATION_JSON); HttpEntityListWeatherRecord entity new HttpEntity(records, headers); ResponseEntityString resp rt.postForEntity(pyUrl, entity, String.class); if (!resp.getStatusCode().is2xxSuccessful()) { return Result.error(推理服务不可用); } return Result.ok(resp.getBody()); }这段代码的关键在于把records列表直接作为请求体传给 Python字段名必须和 Flask 接口约定的history字段一致。RestTemplate是同步阻塞式的毕设够用如果 QPS 要求高可以换WebClient做异步调用。Result是统一响应体把异常情况和正常返回区分开前端处理起来更简单。4.4 前端提交气象参数并回显冰厚曲线前端部分不求复杂但要把两个能力展示清楚手动录入气象参数发起单次预测、上传 CSV 文件做批量预测并绘制冰厚趋势折线图。这里最容易被答辩老师提问的是数据从哪来我的建议是把历史 CSV 上传和单条录入都做出来演示时用 CSV 批量数据回放曲线效果远比手动点按钮有说服力。// Vue 3 里调用后端接口示例 const resp await axios.post(/api/forecast, historyList.value) if (resp.data.code 200) { const ice resp.data.data.ice_mm chartData.value.push({ time: resp.data.data.ts, value: ice }) renderChart(chartData.value) }前端图表用 ECharts 的折线图即可横轴时间、纵轴冰厚再加一条阈值红线比如 10mm 预警线冰厚预测值越过红线时用颜色标记。这段代码里historyList是最近 24 小时的气象记录数组由用户上传 CSV 或手动录入生成。字段名必须与后端WeatherRecord实体严格对应否则 Spring Boot 反序列化会得到全是 null 的对象。5. 覆冰预测项目的进阶验证与 3 个常见踩坑点5.1 按冰期滚动回溯验证模型稳定性一次性划分测试集只能说明模型在某个连续时间段的泛化能力但覆冰预测系统的真实使用方式是每天运行一次预测未来数小时冰厚变化。这意味着验证方式也应该模拟这个操作以天为单位滚动切分窗口每天用前 24 小时的气象数据预测当天冰厚把每天的预测误差累积起来看整体表现。for start in range(0, len(df) - 48, 24): train df.iloc[:start 24] test df.iloc[start 24: start 48] model.fit(train[feat_cols], train[ice_mm]) pred model.predict(test[feat_cols]) errors.append((pred - test[ice_mm]).abs().mean())滚动验证与一次性切分的核心差别在于它暴露了模型在连续运行过程中对高低不同冰厚区间的适应能力。如果滚动 MAE 比静态测试集 MAE 差很多说明模型过拟合了特定时段此时优先加大训练数据跨度而不是盲目调参。5.2 增加覆冰预警等级作为输出维度回归模型输出冰厚数值但这个数值在展示场景里并不友好。实操中我建议在回归之上增加一个分类映射层冰厚 0-3mm 为无风险、3-10mm 为轻度覆冰、10-20mm 为中度、20mm 以上为重度。预警逻辑也可以设计成两个独立维度当前冰厚等级和 3 小时增长量后者超过 1.5mm 时无论当前冰厚等级如何都触发预警因为快速增厚比高基数更危险。在答辩演示场景里这个小的后处理逻辑比单纯回归 MAE 的提升更有系统感。前端页面上显示当前冰厚值、预警等级、最近 3 小时冰厚增长率三个指标老师一眼就能看出系统的实际价值。5.3 数据泄漏、样本不平衡与数据漂移的排错覆冰预测项目的三个高频踩坑点都是真实上线后才暴露的问题。第一是数据泄漏症状是训练集 MAE 极低、测试集也异常低但部署后完全不可用。排查方法是对每个特征做滞后相关性分析如果当前时刻特征与未来时刻标签的相关性异常高说明窗口没有shift。第二是样本不平衡导致模型倾向于预测小冰厚症状是整体 MAE 不错但冰厚超过 10mm 的样本预测偏差很大。第三是数据漂移去年训练的模型今年效果变差因为覆冰机制受气候条件影响各年差异明显。对应的处理手段是保留每年有效的原始数据在新冰期到来时用最近一年的数据微调模型而不是完全重新训练这样既保留历史规律又适应当前气候特征。本文还有配套的精品资源点击获取