电力两票系统开发实战：升压站倒闸操作全流程管控

干过发电厂升压站运维的朋友都知道，“两票”这两个字的分量。它不是挂在墙上的管理制度，而是从一次次事故教训里逼出来的硬规矩。升压站作为发电厂与电网之间的枢纽，操作密集、风险等级高，倒闸操作稍有疏漏，轻则保护误动，重则设备损坏甚至人身伤害。我参与设计和开发的这套“两票”操作票系统，正是围绕升压站日常倒闸操作与检修作业的全流程管控展开，把传统纸质票的拟票、审核、执行、终结环节整体搬到线上，最终实现了操作步骤强制校验、票务状态全程可追溯、统计分析自动汇总。

这个项目适合谁参考？一是电厂信息部门或技术支持团队，需要建设类似安全管控系统；二是升压站运行人员、值长，想理解系统背后的业务逻辑；三是做电力行业信息化的开发者，需要了解“两票”业务的建模思路和实现细节。这篇文章我会从需求拆解、系统设计、流程实现、常见问题、部署运行五个维度完整复盘，尽量讲透每个关键设计背后的原因。

1. 需求拆解：升压站为什么要上“两票”系统

1.1 纸质两票的痛点比想象中严重得多

升压站的倒闸操作有严格的顺序要求，比如停电时先拉开断路器、再拉开隔离开关，送电时顺序相反。这套顺序靠的是操作票逐项写清楚，执行时逐项打勾确认。纸质票时代，痛点是系统性的：票面填写不规范，有的人漏写设备双重称号，有的人把操作项顺序排错；审核环节只能靠值长人工看，眼一花就容易放过逻辑错误；执行过程更是全凭自觉，操作人是否真的走到设备前、是否按顺序操作，监管手段非常有限。

我调研过某区域的升压站，纸质票的全年合格率只有八成出头，剩下一成多都是各种低级错误。更重要的是，纸质票做完就归档，想统计分析哪类操作最容易出错、哪个班组执行效率低，全靠人工翻票本，费时费力还得不到准确结论。这个背景决定了系统不是简单的“把纸换屏”，而是要真正做到流程闭环、逻辑防误、数据留痕。

1.2 核心角色与关键诉求

“两票”系统的用户角色相当清晰，每个角色的诉求也不一样。运行值班员需要快速拟票、便捷执行、减少重复填写；值长/审核人需要可靠的审批工具，能一眼看出票面问题和逻辑风险；安全管理人员需要完整的过程数据，用来分析违章行为和票务合格率；检修人员则需要工作票与操作票联动，检修前停电到位、检修中安全措施明确、检修后恢复送电不留尾巴。

调研中有一个很典型的场景：检修人员到现场后发现安全措施没有全部落实，只能停下作业联系运行人员补票，一来一回至少耽误半小时。所以系统设计里必须把“工作票与操作票的关联关系”作为核心功能，检修申请批准后系统自动校验对应停电操作已完成，才允许开工许可，这就把跨角色协同从“人等流程”变成了“系统推着流程走”。

1.3 合规性要求与安全底线

两票制度在电力行业已经执行多年，各地监管要求也有细化的趋势。系统在设计时除了满足内部管理，还要考虑满足上级检查与合规审计的要求。这意味着票面格式、审批流程、操作记录都必须符合行业惯例，电子签名要具备法律效力，关键操作要留存完整的时间戳和操作人信息。系统上线后，第三方审计时可以直接从系统导出合规报告，这也成为项目验收的一个重要加分项。

注意：合规不是上线后补出来的。需求阶段就要把票面模板、审批链路、归档规则定义清楚，否则后期改造流程会牵扯大量历史数据迁移，非常痛苦。

2. 整体系统设计与技术选型

2.1 架构选型：为什么用B/S加移动终端

两票系统的使用场景分为两类：一类是主控室固定办公，需要大屏展示和完整PC操作；另一类是现场执行，操作人员拿着移动终端在设备区逐项操作确认。考虑到升压站内网环境稳定、终端数量有限，系统采用B/S架构，后端一套服务同时支撑PC浏览器和移动终端访问，避免了C/S架构的客户端分发和升级问题。

移动终端这块我建议采用加固平板或工业PDA，支持条码扫描和拍照留痕。现场执行时打开操作票任务，逐项扫描设备条码，系统自动匹配当前步骤对应的设备，确认无误才能打勾，这一步从技术上杜绝了“走错间隔”的可能。终端离线问题通过本地缓存机制缓解，网络恢复后自动同步执行记录。

2.2 技术栈与数据设计

后端采用Java Spring Boot框架，核心原因是电力行业信息化系统普遍以Java技术栈为主，后续运维团队接手门槛低。数据库选用MySQL，存储结构化票务数据；Redis用于流程状态缓存和并发控制；前端采用Vue框架，PC端管理后台与移动端H5共用一套接口。

数据建模有一个关键点：操作票的内容是分步骤的，票本身是一张主表，每一步是一条明细记录，状态单独管理。这样的设计支持“操作到第5步、第6步待执行”的精细控制。工作票和操作票之间通过关联字段建立依赖关系，形成闭环。设备台账单独建表，作为防误校验的基础数据来源。

2.3 防误校验引擎的设计思路

这个系统里最有技术含量的部分就是防误校验。它并不是简单判断“设备当前状态是否为拉开”，而是要在拟票阶段和执行阶段做两级校验。拟票阶段，系统根据设备初始状态推导每一步操作后的目标状态，如果某一步会导致逻辑冲突则提示开票人修改；执行阶段，每一步操作执行前再次核对实时状态和前置条件，不满足则不允许确认。

举个例子，一张停电操作票里“拉开线路侧隔离开关”这一步，前置条件是“断路器已拉开”“负荷侧隔离开关已拉开”。如果操作人试图直接执行隔离开关操作但断路器仍在合位，系统会立刻阻止并提示“操作顺序错误，当前设备带电”。这种校验完全靠状态机的预演推导实现，不依赖操作人记忆，效果远好于纸质票。

3. 核心功能与实操流程实现

3.1 操作票全生命周期流程

操作票从生成到归档，完整链路是：操作申请 → 拟票 → 审核 → 预令 → 执行 → 回令 → 归档。系统在PC端完成申请、拟票、审核、预令四个环节，移动端承接执行与回令，归档由系统自动完成。每一步都有时间戳和操作人身份记录，确保可追溯。

具体操作上，运行值班员接到调度指令后在系统中新建操作票，选择操作类型（送电/停电/倒负荷），系统自动带出标准操作模板并匹配当前设备状态，生成初稿。值长审核时能够查看完整的步骤序列和防误校验结果，操作票被退回时会附上修改意见，修改记录全部留痕。预令环节确认执行人、监护人到位情况，然后推送到移动终端开始现场执行。

3.2 工作票与操作票的联动闭环

单独做操作票功能并不难，难的是让工作票和操作票形成关联。检修工作开始前需要完成停电、验电、装设接地线等操作，这些操作以操作票形式执行；操作执行完毕后，工作票才能办理开工许可。系统实现时，工作票的状态迁移绑定关联操作票的完成状态，操作票未终结时工作票无法进入“许可”状态。

这个设计投入产出比非常高。以前运行人员和检修人员之间靠口头交代，现在系统自动卡控，杜绝了“票还没做完就开始干活”的违章场景。检修结束后，工作票终结才能触发操作票的送电流程，形成完整的“停电—检修—送电”闭环。

3.3 防误校验与状态同步的实现细节

防误校验的核心是设备状态同步。升压站的设备状态来自监控系统，实际项目中通过接口定时同步断路器、隔离开关的分合位信号，同步周期设置为秒级，确保操作票执行时读取的状态是最新的。考虑到网络偶发中断，系统还支持手动强制刷新状态，但操作日志会对这类行为单独标记，供安全人员审查。

校验逻辑在服务端统一实现，不依赖终端本地判断，避免终端被绕过。伪代码如下：

// 操作票步骤顺序校验核心逻辑 public boolean validateStep(OperationTicket ticket, OperationStep step) { if (step.getStepOrder() != ticket.getCurrentStep() + 1) { return false; // 上一步未完成，不允许跳步 } DeviceStatus status = deviceStatusService.getRealTimeStatus(step.getDeviceId()); if (!status.matches(step.getPreCondition())) { publishEvent("设备状态不满足前置条件"); return false; } ticket.setCurrentStep(step.getStepOrder()); return true; }

状态同步和校验逻辑必须配合好，否则会出现执行时提示“设备状态读取失败”的尴尬。实际项目中，我们增加了状态读取超时重试和降级策略，保证移动端在现场弱网环境下也能顺畅执行。

4. 开发过程中的常见问题与排查实录

4.1 票务状态错乱与并发控制

系统上线初期遇到最多的问题是并发操作导致的票务状态错乱。比如同一台设备涉及两张操作票，一张在执行送电、一张在执行停电，两边的校验都读到旧状态，导致后执行的一方操作被错误放行。核心原因是没有做好操作票级别的锁机制。

解决方案是引入Redis分布式锁，以设备ID为维度加锁，同一时间只允许一张涉及该设备的操作票进入执行环节。同时增加乐观锁版本号，更新票务状态时对比版本号，不一致则重试或提示冲突。这个修改上线后，并发问题几乎消失。

4.2 移动端离线执行与数据补传

现场执行时，升压站某些信号死角网络不好，移动端无法实时提交执行记录。最开始设计是禁止离线执行，结果实际操作中经常出现“人等到终端”的尴尬，运行人员怨言很大。后来改成允许离线缓存，执行记录先存本地数据库，网络恢复后自动补传。

这个功能实现起来简单，但有一个隐患：离线期间如果涉及的设备状态发生重大变化，系统无法实时校验。为了安全，系统对离线超过一定时长的票做强制校验失效处理，操作人必须重新拉取最新状态才能继续，避免基于过期状态判断。

4.3 流程审批卡死与自动催办

试运行阶段出现过审批卡死的情况，票提交给值长审核后迟迟没有动静，也没有任何提醒。业务流程不是天天走的，有时候值长忙于其他事务就把待审任务漏掉了。排查后发现是缺少待办提醒机制，系统只在首页有红点提示，值长没登录就完全感知不到。

加了一套自动催办规则：待审批超过30分钟推送一次提醒，超过2小时再次推送并抄送值班负责人。同时支持待办列表与短信通知。上线后审批平均耗时从原来的数小时降到半小时以内，运行人员反馈顺畅多了。

经验：流程类系统最怕“静默”。任何环节长时间未处理，系统都要主动发提醒，这不是功能问题，是使用体验和业务可靠性的底层需求。

5. 部署现场与运行效果复盘

5.1 部署环境与数据迁移

系统部署在升压站内网机房，采用双机热备部署，数据库主从同步，应用层通过Nginx负载均衡。考虑到电力内网环境的特殊性，系统做了国产化适配，支持主流国产操作系统和数据库，在实际部署中验证通过。

历史纸质票数据的迁移是项目里最容易被低估的环节。几百张近三年的纸质票需要人工录入电脑，再导入系统。实际执行时发现，很多票面填写不规范，设备名称存在同物异名的情况，必须建一个“设备别名映射表”来统一清洗。这个工作花了团队将近三周时间，但完成后系统内的数据准确率大幅提升，防误校验的可靠性也才有保障。

5.2 运行数据与效果分析

系统投运稳定运行六个月以后，我拉了一组数据做复盘：操作票平均开票时间从原来的15分钟降到4分钟，票面一次通过率从85%提升到97%以上，执行环节未再出现操作顺序错误。每月自动生成的两票统计报表，让安全管理人员从翻票本的工作量里彻底解脱出来。

更直观的收益体现在安全层面：系统上线后的周期内，升压站未发生一起因票务管理缺失导致的违规操作事件。这个结果并不意外，当系统把每一道关都卡住的时候，人为失误的空间就被压缩到了最小。

5.3 人员培训与系统推广

系统上线不是技术交付就结束，运行人员的习惯转变是最难得一关。一些老师傅习惯纸质票的手感，对移动终端操作有抵触。我们没有强行推动，而是先选了操作频次高、接受度强的班组试点，再让试点班组的人做内部推广，用实际效率说话，其他班组看着确实省事，自然就用起来了。

培训内容重点不在软件操作，而在业务流程调整后的变化：什么时候需要在系统里操作、移动端的确认动作对应原来纸票的哪个环节、异常情况怎么回退。把业务逻辑讲通了，操作培训半小时就够用。我始终认为，给电力运行人员做系统培训，讲“为什么”比讲“怎么点”更重要。

写在最后的一点体会

这个项目做完，我最大的感受是：两票系统本质上不是软件项目，而是把安全管理的逻辑用技术手段固化下来。系统里每一个防误校验规则、每一条审批链路，背后都是真实的生产经验和教训。设计和开发过程中，业务人员和技术人员必须反复对齐，绝不能凭想象去做流程抽象。我现在跟团队讲得最多的一句话是：多去现场看看操作人员怎么干活，再回来写代码。这个项目后续如果要扩展，可以考虑跟智能巡检、作业行为识别联动，把安全管控从“流程管控”推向“现场感知”，不过那是另一个故事了。