火电厂热力系统建模与通用计算软件——让“纸上公式”变成“指尖工具”

当热力系统发生变化时，不要每次重写代码，只需修改几个结构参数——这是“通用计算”的核心价值，也是从手工计算走向软件化、智能化的关键一步。

论文基本信息

精读提示：本文将重点解读姬文亮2004年的这篇硕士学位论文。与王宁玲2011年博士论文（侧重数据挖掘驱动的智能诊断优化）不同，本篇侧重于热力系统基础建模的通用化与软件化——如果说王宁玲的工作是“用数据驱动节能”，那么姬文亮的工作就是“让热力计算工具从手工作坊走向工业化生产”。

两篇论文在时间上相差7年，在方法论上构成了从“通用计算工具”到“智能诊断系统”的演进脉络。

第一章：绪论——软件化是电厂精细化管理的必由之路

1.12004年前后火电行业的三大背景：

第一，体制变革。国家电力公司改组为五大发电集团（华能、大唐、华电、国电、中电投），发电企业从“完成发电量指标”转向“提高经济效益、降低运营成本”的独立市场主体。竞价上网的趋势要求电厂必须精细化运营。

第二，能耗差距。当时我国火电厂平均供电煤耗为408g/kWh，比发达国家高出50g/kWh以上。美国EPRI的研究表明，机组实际热耗比可能达到的最佳值高出近100kJ/kWh，其中约50%是可以通过各种途径控制的——而控制的先决条件，就是准确掌握当前运行状态。

第三，技术条件成熟。 DCS系统已普遍应用，SIS系统逐步推广，大量实时数据可以采集，但缺乏好用的分析工具——传统“小指标考核法”依赖手工抄表和人为经验，评价片面且滞后，已不适应现代电厂管理需求。

论文的使命就是：建立一套通用的热力系统计算模型和软件工具，把热力计算从“手算+定制编程”升级为“自动计算+通用组态”。

1.2落地措施与建议

·正视“软件工具”在节能管理中的基础地位：性能计算软件不是“锦上添花”，而是精细化管理的“基础设施”。没有准确的实时煤耗、缸效、热耗数据，任何节能决策都是“拍脑袋”。

·明确工具开发的通用化原则：电厂热力系统千差万别（再热/非再热、加热器数量不同、汽泵/电泵切换等），如果每换一种工况就要改程序，软件就无法真正用起来。通用化是工具走向实用的前提。

·瞄准“一线可用”而非“学术完美”：论文从立项之初就强调软件要“适于现场应用”而非“学术实验”，这一务实定位值得借鉴——电厂软件开发的成败，往往不取决于算法的先进性，而取决于操作人员愿不愿意用。

第二章：热力系统通用数学模型——把“千人千面”的热力系统用同一套公式算清楚

热力系统性能计算的核心是回热加热器抽汽量的计算——因为各级抽汽量一旦确定，机组热耗、煤耗、缸效等所有经济性指标都能推算出来。但不同机组的加热器类型（表面式、混合式、带疏水泵的）、台数、布置方式千差万别，传统方法需要为每一台机组“量身定做”计算程序。

论文的核心创新是：用“级控制体”和“结构参数”将差异抽象化，导出统一的抽汽系数计算公式。

第一步：划分“级控制体”。

将热力系统按抽汽级数划分为若干控制体，每个控制体包含一级抽汽加热器及其关联管路。

关键边界点包括：汽轮机抽汽口、加热器出水口、上游加热器出水口、疏水管路等。轴封加热器并入相邻的抽汽加热器级中处理。

第二步：建立通用加热器模型。

将表面式（分三种：简单型、带给水泵型、带轴封加热器型）、混合式（除氧器）、带疏水泵的表面式等加热器类型，用一个统一的物理模型描述，兼顾能量平衡和质量平衡，纳入门杆漏汽、轴封漏汽、对外抽汽、泵功升焓等所有辅助汽水因素。

第三步：引入“结构参数”Aᵢ和Bᵢ。这是论文最具“软件思维”的设计：

·当Aᵢ = 0, Bᵢ = 1 → 有疏水的表面式加热器（疏水放热量 = h_{s(i-1)} - h_{si}）

·当Aᵢ = 1, Bᵢ = 0 → 混合式加热器（疏水放热量 = h_{s(i-1)} - h_{w(i+1)}）

这样，一个抽汽系数的通用计算公式，通过两个结构参数的取值变化，就能适配所有加热器类型：

第四步：辅助模型补齐。

论文还建立了轴封漏汽量计算模型（采用正交多项式最小二乘曲面拟合流量比系数）、给水泵焓升模型、疏水冷却器换热模型、排污扩容器蒸汽回收模型等，形成了完整的计算闭环。

1）齿型轴封的漏气量计算基本公式

为便于计算机编程，减少计算中的判断过程，可以将曲径轴封漏气量的计算公式合并为一个单一的表达式：

流量比的拟和方法

观察上图，为了得出单一形式的流量比系数，应该按二元曲面回归方法进行拟和。为使得拟和结果具有较高的精度，本文采用了带有正交多项式的最小二乘曲面拟和方法。二元回归方程的标准形式为：

2）给水泵焓升基本公式

3）疏水冷却器的数学模型

4）排污扩容器蒸汽回收

落地措施与建议

（1）“结构参数”思想值得推广到其他设备建模：将物理差异抽象为参数配置，而不是为每种情况写不同代码——这是工业软件通用化的核心设计模式。在开发其他电厂计算工具时，建议沿用这一思路。

（2）建立本厂热力系统的“数字化模型库”：即使是同一型号的机组，因改造、解列等造成的差异也很大。利用通用计算模型，可以为本厂不同机组、不同运行方式建立对应的“结构参数配置档案”，一旦加热器解列或设备改造，只需调用相应的参数配置即可重新计算。

（3）重视辅助汽水对煤耗的影响：轴封漏汽、排污扩容蒸汽回收、给水泵焓升等“小流量”常被简化处理，但论文将它们全部纳入通用模型。在精度要求较高的性能计算中，这些“小项”的累积效应不可忽视。

（4）流量比系数的曲面拟合方法可复用：论文对轴封漏汽流量比系数进行的二元正交多项式最小二乘曲面拟合（p=3, q=4），是一种处理二维插值问题的有效方法，可推广到其他需要依据双变量查图的场景（如风机特性曲线、水泵性能曲线等）。

第三章：热经济性分析数学模型

第二章解决了“怎么算准”的问题，第三章解决的是“算完之后怎么分析”——即热经济性分析。

热经济性分析的目标是：不仅要知道当前机组效率是高是低，还要知道是哪些因素导致的、影响有多大、该往哪个方向调。

3.1缸效计算。

论文建立了高、中、低压缸的相对内效率计算模型。

3.1.1高压缸相对内效率模型

3.1.2中压缸相对内效率模型

中压缸相对内效率的计算较为简单，只需将中压缸进出口处的有关热力参数得到，就可按照定义计算。

3.1.3低压缸相对内效率模型

其中低压缸排汽焓的确定是一大难点——因为排汽处于湿蒸汽区，干度和焓值难以直接测量。

论文采用ASME PTC6A-1982推荐的方法：利用整机能量平衡反推排汽焓，再扣除末级余速损失和湿汽损失，得到用于缸效计算的终点焓。余速损失按速度三角形计算，湿汽损失按干度与有效焓降的乘积估算。

现场运行过程中，给水流量的获取很容易实现，而且精度也比较高。以给水流量作为基准值，通过整机的质量平衡来导出汽轮机的进气量，由公式（3－4）求出等效焓降。若末级处于湿蒸汽区，先预测末级抽气焓，根据整机能量平衡和质量平衡，得到排汽量和排焓。代入公式（3－5），与公式（3－4）进行校对，当精度达到要求时，从而末级抽气焓和排气焓可求出。

3.2 热经济性能计算评价数学模型

论文建立了完整的性能计算评价模型，包括：汽轮机内效率ηᵢ、绝对电效率ηₑ、凝汽式电厂热效率η_cp、电厂煤耗率b、电厂热耗率q_cp、汽轮发电机组热耗率q、汽耗率d等。

3.3耗差分析——“找到病根”。

对火电机组运行在线分析的最终目的在于及时了解机组运行过程中的热经济性和运行状况，并对影响机组正常运行的因素加以分析和调整，使得机组尽量处于高水平的运行状态。

只对机组进行在线计算 ，还不能了解是哪些因素导致机组效率变化，也不能确定某些因素对机组性能有多大影响。

针对这一情况，国外在70年代用耗差分析方法来监控运行。

它把对能耗率影响的关键运行可控参数连续进行监督分析，将机组参数实际值与基准值进行比较，由两者差计算出对机组能耗率的影响，从而及时指导运行或者维修，使得机组能接近最佳状况运行。

耗差分析的可控参数基准值还随负荷，环境温度而变化，故这种方法更切合实际。

耗差分析的目标是将热耗偏差分解到各可控参数上。基本公式：

Δq = (∂q/∂h₀)·Δh₀ + (∂q/∂h_fw)·Δh_fw 

+ (∂q/∂α_zr)·Δα_zr + (∂q/∂Δh_zr)·Δ(Δh_zr) 

+ (∂q/∂α_c)·Δα_c + (∂q/∂q_c)·Δq_c + (∂q/∂η_i)·Δη_i

耗差分析的核心方法是：将运行参数的实际值与“应达值”（基准值/目标值）比较，差值乘以该参数对热耗的敏感系数（偏导数），得到该参数偏离造成的热耗损失。

常规的应达值确定方法有“试验法”“变工况计算法”“统计分析法”，但论文认为这些方法要么工作量大、成本高，要么计算复杂、精度难以保证，且会随着机组老化而越来越不准。

其中最具代表性的主要是变工况计算法，通过一系列的变工况计算而得到热力系统运行主要调整参数的应达值，从而指导运行人员进行经济性调整，降低机组热耗，这种方法的最主要的缺点就是计算非常麻烦，而且结果不一定精确。

通过热力系统理论分析，热耗的变化方向随可控参数的变化方向有一致或者相反的规律，那么，可控参数的应达值的确定就可采用机组运行参数的安全值，这样即考虑到机组的经济性又考虑到机组的安全性。

论文提出了一种“新思路”：用“安全值”作为应达值。理由是：热耗变化方向与可控参数变化方向具有明确的一致性（主汽温↑→热耗↓，背压↑→热耗↑），只要明确了参数的安全运行上限或下限，就相当于确定了经济性最优的方向。虽然低负荷时某些参数可能“够不到”额定工况的安全值，但这部分“够不到”属于不可调整损失，不影响对可调整部分的诊断。

对“安全值法”的评价：坦率地说，这一方法在理论严谨性上确有不足——它没有解决“低负荷时到底应达多少”的问题，只是把问题转移给了运行经验。但它对当时的工程实践确有积极意义：它打破了“应达值必须精确计算”的思维定式，让大家意识到——判断“往哪个方向调”，比纠结“精确调到多少”在实操中更重要。在实际运行中，往往是先明确调整方向，再逐步逼近最优值，而非一蹴而就达到某个理论目标。该方法更适合作为一种快速诊断的辅助手段，而非精确计算的替代方案。

“安全值法”的定位：这不是一个“精确求解”的方法，而是一个“快速判断调整方向”的实用工具。它对当时行业“非精确计算不可”的思维定式是一种有益的松动，在实际操作中可以与变工况计算或数据挖掘方法配合使用——先用安全值法判断方向，再用精确方法确定具体数值。

3.4热耗偏差的定量计算。

论文给出了热耗对主汽焓、给水焓、再热份额、再热焓升、凝汽系数、排汽放热量、内效率等变量的偏导数解析式，可在汽态线修正的前提下精确计算各参数变化对热耗的影响。

落地措施与建议

（1）分两步推进耗差分析：第一步，用“安全值法”判断调整方向（往高调还是往低调），指导日常运行操作；第二步，对有条件的核心参数（如最优初压、最佳氧量），用变工况计算或数据挖掘方法精确定量目标值。

（2）将耗差分析结果“责任到人”：主汽温度偏低归运行人员，加热器端差偏大可能归检修人员，真空偏低则可能是循环水系统或凝汽器清洁度问题——在报表中增加“责任归属”字段，让考核有据可依。

（3）低压缸排汽焓的在线计算是性能监测的关键难点：论文采用的ASME PTC6A能量平衡反推方法，虽然计算量较大，但不需要额外测点，适合在性能监测系统中实现。建议在软件方案中优先采用此方法，而非过于简化的经验估算。

第四章：通用计算软件的开发——把理论“写”成能用的工具

这是论文的技术落地章节，也是最体现工程价值的部分。论文基于Visual C++ 6.0开发了一套热力系统通用性能计算软件，核心设计思路如下：

4.1面向对象的模块化架构。软件将热力系统拆分为若干独立模块，每个模块对应一个C++类：

所有辅助模块类从CSteamer派生，便于在模块内部直接进行焓熵查询。

4.2“结构参数”驱动组态。

这是软件通用性的核心机制。用户只需在一张对话框上输入若干结构参数（加热器级数、除氧器位置、疏水泵位置、是否再热、汽泵/电泵选择等），程序就能自动“组装”出一个完整的热力系统计算模型。当系统发生变化（如加热器解列、汽源切换），只需修改结构参数即可重新组态，无需改动任何源代码。

以200MW机组为例，输入：抽汽级数=8，除氧器位置=4，疏水泵位置=7，程序自动生成对应的热力系统流程图并完成全部计算。

4.3完整的计算流程。

软件执行流程为：系统组态→从实时数据库读取数据（或手动输入）→数据预处理→辅助汽水计算→回热系统逐级计算→末级排汽焓迭代→热经济性指标计算→耗差分析→结果显示。其中回热系统计算从第1级加热器开始逐级向后推进，按通用抽汽系数公式(2-3)计算每一级抽汽量，直至末级前一级；末级排汽焓采用能量平衡迭代方法确定。

4.4验证案例与落地建议

论文以国产200MW再热机组为例（初压12.75MPa/535℃，再热冷段2.47MPa/312℃/热段2.16MPa/535℃，排汽压力5.2kPa，8级回热抽汽），用开发的软件进行计算，与文献[10]的手工计算结果对比——抽汽系数最大偏差约0.002（相对偏差<4%），热耗偏差约10.3kJ/kWh（相对偏差0.12%），汽耗偏差约0.02kg/kWh（相对偏差0.07%），精度满足工程要求。

4.5落地措施与建议

（1）“结构参数”方案可直接借鉴：对希望自建或定制热力计算软件的电厂和科研院所，这篇论文的“结构参数+通用计算公式”方案是成熟、可直接复用的技术路线，无需从零设计。

（2）考虑技术栈升级：论文采用VC++ 6.0和MFC，在当时是主流选择，但如今已相对陈旧。实际开发中可考虑升级为C#/.NET或Python+Qt，界面更友好，数据库访问更便捷，也更易与现有SIS/MIS系统集成。

（3）模块化设计思想是灵魂：即使更换开发语言和技术平台，论文的模块化设计思想（加热器类、轴封类、排污扩容器类、管理类）仍可直接沿用。这种设计便于分工开发、单独调试和后续扩展。

（4）边界条件的处理要认真：论文特别指出“第一级加热器前需假设一个虚拟加热器”以避免循环计算溢出——这种细节往往是软件能否跑通的关键，在开发时应充分重视。

（5）计算精度验证必不可少：论文用文献数据进行了对比验证，这是工业软件开发的必要步骤。在定制开发类似软件时，建议至少用3-5台不同容量等级机组的已知工况数据进行校核，确保计算内核的可靠性后再投入在线运行。

4.6Python 实现方案——让通用计算落地现代技术栈

论文原软件基于 VC++ 6.0 + MFC + ActiveX，技术栈已相对陈旧。Python 完全可以实现相同功能，甚至更高效，原因如下：

Python 实现的核心代码结构

4.6.1物性查询模块（替代 CSteamer 类）

4.6.2 通用加热器模块（替代 Cheater 类）

4.6.3 回热系统计算引擎（替代 CManage 类）

4.6. 4 TESPy 框架方案（更高级的通用建模）

TESPy 的优势：

内置 IAPWS-IF97 物性

支持design/offdesign 双模式计算

支持 (火用) 分析

通过 pygmo API 支持优化

4.6. 5 Python 落地步骤路线图

第五章：历史趋势曲线控件——让数据“动起来”

在线计算给出了“当前”的数值，但分析问题的演变趋势、诊断故障原因，还需要查看历史数据的变化轨迹。论文第五章开发了一个ActiveX历史趋势曲线控件，它的核心价值在于：

5.1基于COM技术的可复用性。控件采用ActiveX标准，开发完成后只需注册一次，就可以拖放到任何应用程序界面上使用，无需编写额外代码。这体现了“一次开发、多处复用”的软件工程思想。

5.2 ADO数据库访问。控件通过ADO（ActiveX Data Objects）技术连接Access历史数据库，使用SQL语言查询指定测点在指定时间段内的历史数据。ADO是基于COM的高层数据库访问接口，代码简洁、访问灵活。控件可同时显示8根颜色各异的曲线，并具备游标功能——鼠标移动时自动显示对应时刻的数据值。

5.3灵活的曲线管理。每根曲线对应一个带颜色的标识按钮，点击按钮可随时隐藏/显示对应曲线，方便对比分析多参数之间的关联关系。

5.4落地措施与建议

（1）历史曲线是性能诊断的“火眼金睛”：许多性能问题（如设备逐步劣化、周期性波动、异常工况前兆）在实时数据中不易察觉，但在趋势曲线上一目了然。建议将历史曲线功能与性能计算数据（煤耗、缸效、端差等）打通，而非仅显示原始测点值。

（2）控件化开发模式值得推广：对于电厂信息化建设中反复需要的功能模块（报表生成、报警推送、数据导出等），采用控件/组件化开发模式可大幅降低后续项目的开发成本和维护难度。

（3）数据库设计要先想清楚：论文在第5.3节详细设计了动态数据表（时间+测点位号+测点值）和静态测点信息表（位号+名称+单位+量程+上下限+类型），这一“动静分离”的设计是历史数据管理的基础模式，可直接复用。

（4）考虑向Web端迁移：论文的ActiveX控件基于COM技术，主要适用于Windows桌面应用。当前趋势是B/S架构，建议将历史曲线功能升级为HTML5/JavaScript实现的Web控件，更易于与SIS/MIS系统的Web端集成。

六、从“定制开发”到“通用组态”——工业软件的必由之路

姬文亮这篇2004年的硕士论文，以今天的视角看，技术栈虽然已经过时（VC++ 6.0、ActiveX、Access数据库），但其设计思想和工程方法论至今仍有重要参考价值：

1、“结构参数驱动组态”的通用化思想，超越技术本身。这是论文最值得借鉴的设计理念——将一个复杂领域的多样性，通过若干参数进行抽象和配置，从而实现“一套程序、适配多种场景”。这种思想在工业软件领域具有普适性，可用于锅炉热力计算、汽轮机通流计算、管道阻力计算等多个场景。

2、“模块化+继承”的面向对象设计，是代码可维护性的基石。论文将加热器、轴封、排污扩容器、给水泵等设备分别封装为独立的C++类，所有类从水蒸气基类派生，由管理类统一调度。这种结构使得单模块的修改不影响其他模块，便于多人协作开发和后期功能扩展。

3、“通用计算+专业分析+数据可视化”的三层架构，是电厂工具软件的通用模式。论文的软件架构可以分为三层：底层是通用计算模型（第二章、第三章），中间层是计算引擎和组态管理（第四章），上层是数据可视化和人机交互（第五章）。这一架构模式在今天的电厂信息化建设中依然适用。

4、论文的历史地位与两篇论文的衔接。站在2026年回看，这篇论文是火电行业从“手算+定制编程”向“通用计算工具”转型的代表作。而王宁玲2011年的博士论文，则在通用计算工具的基础上，进一步引入了数据挖掘和智能建模方法，实现了从“算什么算什么”到“数据告诉你该怎么算、怎么调”的跨越。两篇论文相差7年，恰好勾勒出了火电节能信息化从“工具化”（2004）到“智能化”（2011）的演进路径。

姬文亮这篇论文告诉我们：通用化不是功能的减少，而是抽象能力的体现。这个道理，放在今天的AI建模、数字孪生、低代码平台等领域，依然成立。

七、可靠参考文献

八、论文提炼

1、“一个级控制体包含一个抽汽加热器” ——论文将复杂热力系统拆解为标准化“级”的基本单元，这是通用化的第一原理：把系统分解成可重复使用的“积木”。

2、“用结构参数 Aᵢ、Bᵢ实现了热力系统通用软件的开发” ——这是从“为每台机组定制代码”到“一套代码适配所有机组”的关键跨越：差异不是写在代码里，而是写在配置里。

3、“在分析了各可控参数变化与热耗变化方向一致或者相反的基础上，提出了用安全值作为应达值的原理和方法” ——这句话提醒我们：在工程中，“判断方向”往往比“精确计算数值”在实操中更重要。不追求所有工况下的绝对精确，而是用安全边界锁定调整方向。

4、“该软件运用结构参数组合热力系统，具有组态灵活、简单易用等特点。热力系统如发生变化，只需重新修订结构参数而不需要专门软件开发人员就可以重新组态” ——这是工业软件的灵魂：通用化不是让一个软件包打天下，而是让用户在业务层面就能完成定制，不需要动代码。