在电力信息化和智能电网项目中最让人头疼的往往不是写代码而是梳理业务对象、接口关系和数据流向。一个标准文档几百页光靠文字很难在团队里形成统一认知。本文用 UML 来拆解电力与智能电网领域的行业标准从用例图、类图到时序图、状态图结合一套“分布式光伏并网监测”的建模实战帮你走通从标准文本到可落地代码的完整路径。用UML表示的行业标准01电力和智能电网-2上一篇我们梳理了电力与智能电网行业标准的整体范围也讨论了为什么标准文本必须经过一层“结构化翻译”才能真正指导系统设计。这次我们把重心放到具体的 UML 建模方法上围绕智能电网中的典型业务场景分别讲解用例图、类图、时序图、状态图和活动图的建模思路并给出一个从模型到代码的完整示例。文章内容更适合正在做电力信息化、综合能源、新能源接入或用电采集系统的开发人员阅读。如果你还在学习 UML也可以通过智能电网的例子理解“标准如何映射成模型、模型如何映射成代码”。1. 为什么用 UML 建模电力行业标准1.1 标准文档和系统开发之间的鸿沟电力行业标准通常由 IEC、IEEE、国家或行业标准化组织发布不同类型的标准侧重点完全不同。有的是协议标准例如 IEC 61850 定义了变电站内智能电子设备之间的通信服务有的是信息模型标准例如 IEC 61970/61968 系列的 CIMCommon Information Model公共信息模型用于描述电网中的设备、拓扑、量测和资产对象有的是业务流程标准例如需求响应、电力市场交易等场景中的角色交互规则。这些标准有一个共同特点文本描述非常严谨信息密度很高但直接拿给开发团队使用时会遇到三个问题理解不一致不同开发人员对同一个术语可能有不同理解。边界不清晰标准中涉及的参与者、设备、系统之间的边界很难从文字中直接画出。无法直接落地标准给出的往往是逻辑模型和交互框架并不直接对应某个编程语言的类或数据库表。UML 的价值就在这个阶段体现出来。它用图形化的方式把标准中的参与者、对象、关系、交互顺序、状态变化表达出来让标准从“可读”变成“可讨论、可评审、可编码”。1.2 UML 在标准建模中的角色UML 在电力行业标准建设中实际承担三种角色。第一种是描述角色。许多国际标准在制定时就以 UML 模型作为正式或半正式的表达形式。比如 CIM 的类图就是典型的 UML 表达标准文档中的“Class”、“Association”都能直接在 UML 类图中体现。读者看模型往往比读长段文字更快。第二种是对齐角色。电力系统涉及一次设备、二次设备、通信规约、主站系统、终端设备等不同专业领域。UML 用例图可以表达“谁在什么场景下完成什么目标”帮助不同专业的人对齐需求时序图可以表达“跨系统跨设备的消息交换顺序”帮助通信和业务人员对齐接口。第三种是工程落地角色。在项目开发中UML 类图可以转换成 Java/Python/C 的实体类也可以转换成数据库表设计用例图和时序图可以直接指导接口测试用例设计。这样标准就不再是墙上挂着的 PDF而是代码仓库里可追溯的设计依据。1.3 适用场景与建模边界并不是所有标准内容都适合画 UML。这里需要先做一个判断适合建模的内容角色、对象、属性、关系、状态、交互流程。不适合强行建模的内容纯物理参数公式、通信报文逐字节定义、算法性能指标。也就是说UML 建模的重点是信息结构和业务行为而不是物理细节。遇到协议报文时更合适的表达方式是报文结构定义表或代码生成工具UML 类图可以作为上层抽象但不要试图把每一个比特位都画成类。2. 电力与智能电网的标准基础2.1 常见的标准体系智能电网是一个跨专业、跨系统的庞大体系涉及的常见标准包括标准/系列主要覆盖范围与 UML 建模的关系IEC 61850变电站自动化、智能电子设备通信信息模型、逻辑节点、通信服务适合用类图与用例图表达IEC 61970 / 61968能量管理系统与配电管理的 CIM 模型类图几乎是标准默认的表达方式IEEE 2030.5智能电网应用协议面向 DER、EV、储能等支持用类图和时序图描述设备注册、上报、控制流程DL/T 645多功能电能表通信协议通信报文偏底层更适合用协议结构描述IEC 60870-5-104远动通信规约适合用状态图与序列图表达链路建立和报文交互上面这些标准在具体应用时会有不同版本和配套文档本文不针对某一版本的细节展开重点是讲清“用 UML 的哪张图表达标准中的哪类内容”。实际项目中请以你使用的标准正式版本为准。2.2 行业标准建模的三个层次把标准转化为 UML 模型可以按三个层次推进。第一层是业务用例层回答“系统要支持哪些参与者完成哪些业务目标”。例如“运维人员通过主站系统读取光伏逆变器运行数据”就是一个用例。这一层对应 UML 用例图。第二层是信息模型层回答“业务中涉及哪些对象、对象有哪些属性、对象之间是什么关系”。例如“光伏逆变器”是一个类“逆变器属于某个电站”是聚合关系“逆变器实时量测”是关联关系。这一层对应 UML 类图。第三层是行为交互层回答“对象之间如何协作完成一个业务流程”。例如“主站系统下发数据召唤指令采集网关转发给逆变器逆变器返回运行参数主站更新数据库”。这一层对应时序图、状态图和活动图。这种分层方法和软件工程中的“用例驱动开发”是一致的。先确定业务边界再确定数据模型最后确定交互逻辑。智能电网系统的建模也可以按这条路径展开。2.3 标准建模的整体流程建议把标准建模当成一个独立的设计阶段来做流程如下划清系统边界明确本次建模覆盖哪些子系统、哪些外部参与者。提取业务用例从标准中找出参与者、场景和业务目标。抽取领域对象识别名词性概念转化为类图。细化交互过程对关键业务流程画时序图。补充状态约束对设备、任务、订单等有生命周期特征的对象画状态图。评审与追溯每条模型能否对应到标准条款每条标准要求是否都有模型承载。3. UML 核心视图在智能电网中的应用3.1 用例图从参与者到业务边界用例图在电力标准建模中的主要作用是表达参与者与系统功能之间的关系。例如在高级计量架构AMI中主要参与者包括用电客户、抄表员、计量主站、智能电表、费控系统。标准中会定义这些角色之间的业务关系。UML 用例图就把这些关系画成“参与者 椭圆用例 连线”的形式。画用例图时最容易出现的问题是粒度不一致。建议遵循一个原则用例必须是参与者可以感知的完整业务目标。“读取电表数据”是一个用例“解析电表报文”只是一个内部步骤不应该出现在用例图中。在智能电网项目中常见的用例包括用电信息自动采集远程费控分布式电源并网监测充电桩有序充电需求响应执行停电事件主动上报每个用例都要能从标准文本中追溯到依据。3.2 类图从标准信息模型到领域模型类图是电力标准建模中信息量最大的一张图。以 IEC 61970/61968 的 CIM 模型为例标准中用“包Package”来组织类例如 Core 包、Topology 包、Wires 包、Meas 包、Assets 包、Metering 包等。UML 类图中的 Package 可以直接对应这些分包Class 对应标准中的对象Association 对应对象之间的关系。在画类图时需要明确四种关系关系类型UML 表示语义典型例子关联一条实线对象之间存在引用或连接电表与用户之间的关联聚合空心菱形整体与部分部分可独立存在电站聚合逆变器逆变器可独立迁移组合实心菱形整体与部分部分不可独立存在变电站包含间隔间隔离开变电站无意义继承空心三角箭头子类是父类的一种逆变器是一种发电单元对于标准建模来说关联和继承最常用。聚合和组合要看语义是否严密切合不要为了形式上的丰富而乱用。3.3 时序图从跨系统交互到接口契约智能电网系统通常是“主站 - 终端”两级或多级结构。时序图特别适合表达主站系统、采集网关、终端设备之间的消息交互顺序。在画时序图时需要重点标记生命周期线每个参与者的存在时间范围。消息名称建议使用标准中定义的服务名或操作名。返回消息用虚线箭头表示返回内容尽量注明数据类型。循环和条件片段例如“循环采集多个电表”“如果数据越限则上报告警”。时序图越接近接口契约对开发的指导价值越大。建议把时序图中的消息逐一登记到接口文档里形成“模型到接口”的映射表。3.4 状态图从设备状态到状态机电力设备几乎都有明确的状态生命周期。例如一个充电桩可能的状态包括空闲、充电中、故障、暂停、离线。一个光伏逆变器可能的状态包括待机、运行、限功率、停机、故障。这些状态和状态迁移条件在标准或产品规范中通常有定义。UML 状态图可以精确表达状态机的转移关系。绘图时要注意每个状态要说明进来和出去的事件条件。初始状态和终止状态只能各有一个。状态迁移名称建议写成事件或条件表达式例如“收到启动命令 / 电网电压正常”。状态图在后续编码阶段可以直接转化为状态模式或工作流配置价值很高。3.5 活动图从业务流程到逻辑编排活动图适合表达带有分支、并行、循环的业务流程。例如需求响应业务系统聚合用户可调节负荷接收调度指令分解为各用户控制策略下发控制命令跟踪执行结果最后汇总上报。这个流程中既有并行执行又有条件判断活动图比时序图更适合表达整体编排逻辑。活动图的关键元素包括起始节点、活动节点、判断节点、并行分支、合并节点和结束节点。画图时建议把判断条件写得具体例如“响应速率大于阈值”而不是“是否满足条件”。4. 实战分布式光伏并网监测的 UML 建模下面用一个完整的“分布式光伏并网监测”案例把前面几类 UML 图串起来。这个场景在低压分布式光伏快速发展的背景下非常常见也适合用来理解“标准如何落地到系统设计”。4.1 场景边界与需求说明场景假设如下多个分布式光伏电站接入配电网每个电站有多台逆变器。采集网关部署在电站本地负责采集逆变器运行数据。主站系统部署在监控中心定时召测电表和逆变器数据。电网调度或运维人员需要实时查看电站出力、电压、电流、功率因数等数据。当逆变器故障或通信中断时系统需要产生告警。参与者包括运维人员、调度人员、采集网关、逆变器、智能电表。建模目标梳理清楚“数据从哪里来、经过谁、存到哪里、发给谁”。4.2 用例图设计用例图主要表达参与者和系统功能之间的关系。在“分布式光伏并网监测”场景中关键用例包括实时监测光伏电站运行数据。历史数据查询与统计分析。逆变器远程参数设置。故障告警处理。发电量统计与上报。这里给出 PlantUML 代码示例方便你直接在本地生成图片startuml left to right direction actor 运维人员 as Operator actor 调度人员 as Dispatcher rectangle 分布式光伏并网监测系统 { usecase 实时监测光伏电站运行数据 as UC1 usecase 历史数据查询与统计分析 as UC2 usecase 逆变器远程参数设置 as UC3 usecase 故障告警处理 as UC4 usecase 发电量统计与上报 as UC5 } Operator -- UC1 Dispatcher -- UC1 Operator -- UC2 Dispatcher -- UC2 Operator -- UC3 Operator -- UC4 Dispatcher -- UC4 Operator -- UC5 Dispatcher -- UC5 enduml在实际项目中用例图要能回答两个问题每个用例是给谁用的每个参与者能做什么如果有参与者或用例是多余的说明系统边界没有划清楚。4.3 类图设计类图是这个案例的核心它把光伏电站里的设备抽象成可编程的对象。主要类包括光伏电站PVStation逆变器Inverter电表Meter采集网关Gateway遥测数据TelemetryData告警信息AlarmInfo它们之间的关系如下光伏电站聚合多台逆变器。光伏电站关联一台或多台电表。采集网关属于某个电站。遥测数据关联逆变器和电表。告警信息关联电站。用 PlantUML 表达如下startuml class PVStation { - stationId: String - name: String - location: String - capacity: Double getCurrentOutput(): Double } class Inverter { - deviceId: String - ratedPower: Double - currentOutput: Double - status: String reportStatus(): void setLimit(limit: Double): void } class Meter { - meterId: String - readTime: Date - activePower: Double readValue(): Double } class Gateway { - gatewayId: String - ipAddress: String - status: String collectData(): void forwardData(data: TelemetryData): void } class TelemetryData { - dataId: String - timestamp: Date - voltage: Double - current: Double - power: Double - energy: Double } class AlarmInfo { - alarmId: String - alarmType: String - level: String - detail: String - createTime: Date } PVStation 1 o-- many Inverter PVStation 1 -- 1..* Meter PVStation 1 -- 1 Gateway Inverter 1 -- many TelemetryData : 产生 Meter 1 -- many TelemetryData : 产生 PVStation 1 -- many AlarmInfo : 产生 enduml这里要注意区分聚合和关联。电站和逆变器之间使用聚合是因为逆变器即使被拆走也可以安装到别的电站生命周期不绑定在某个电站上。而遥测数据和逆变器之间是普通关联数据一旦离开设备就没有独立业务价值不建议使用组合关系。类图中属性只需要提取核心字段不必把标准中的每一个属性都画上去。标准中可能定义了 40 多个字段但项目一期只需要 8 个就以项目实际需要为准。4.4 时序图设计时序图用来描述“监控人员查看实时数据”的完整调用链。在这个场景中参与者包括监控人员、主站系统、采集网关、逆变器、电表。基本流程如下监控人员在主站界面点击“召测”。主站系统生成召测指令。采集网关接收指令并转发给逆变器。逆变器返回电压、电流、功率数据。采集网关同时读取电表数据。采集网关汇聚数据并上送主站。主站入库并展示给监控人员。PlantUML 示例startuml actor 监控人员 as Operator participant 主站系统 as EMS participant 采集网关 as Gateway participant 逆变器 as Inverter participant 电表 as Meter Operator - EMS: 查看实时数据 EMS - Gateway: 下发召测指令 Gateway - Inverter: 读取运行参数 Inverter -- Gateway: 返回电压/电流/功率 Gateway - Meter: 读取电能数据 Meter -- Gateway: 返回电能量 Gateway -- EMS: 上送聚合数据 EMS - EMS: 数据校验与入库 EMS -- Operator: 展示实时监测画面 enduml时序图中的消息名称要尽量和接口定义对应。比如“下发召测指令”在代码里可能是HTTPS POST /api/collect/command在标准里可能是某个服务名。建议画完时序图后再补充一列“接口映射”后续开发直接参考。4.5 状态图设计逆变器是光伏并网监测中状态最核心的设备。根据常见运行逻辑逆变器的状态可以设计为待机Standby设备已上电等待开机条件。运行Running正常发电并网。限功率Limited因调度指令或电网约束限制输出。故障Fault发生异常停止并网。离线Offline通信中断或失电。状态迁移条件包括启动命令、停机命令、电网电压异常、通信超时、故障恢复等。PlantUML 示例startuml [*] -- Standby : 设备上电 Standby -- Running : 收到启动命令且并网条件满足 Running -- Limited : 收到限功率指令 Limited -- Running : 收到恢复功率指令 Running -- Fault : 检测到过压/过流/过热 Fault -- Standby : 人工复位或故障清除 Running -- Offline : 通信超时 Offline -- Running : 通信恢复 Offline -- Standby : 设备下电后重新上电 Fault -- [*] : 设备退出运行 enduml状态图的价值在于它能让开发人员一眼看到设备所有合法状态和迁移路径。在编写代码时每个状态转换都要有对应的事件处理逻辑不能出现“未定义的状态跳转”。4.6 从 UML 模型到工程代码UML 类图最终要转化成代码才能落地。下面给出一个简化版的 Java 实体类示例对应上面的逆变器类// 文件路径src/main/java/com/example/pvmonitor/domain/Inverter.java package com.example.pvmonitor.domain; import java.time.LocalDateTime; public class Inverter { private String deviceId; private Double ratedPower; private Double currentOutput; private String status; private LocalDateTime lastReportTime; public void reportStatus() { // 实际项目中这里可以组装遥测数据并上报 System.out.println(逆变器状态上报 status); } public void setLimit(Double limit) { // 远程设置有功功率限值 this.currentOutput Math.min(currentOutput, limit); } public String getDeviceId() { return deviceId; } public void setDeviceId(String deviceId) { this.deviceId deviceId; } public Double getRatedPower() { return ratedPower; } public void setRatedPower(Double ratedPower) { this.ratedPower ratedPower; } public Double getCurrentOutput() { return currentOutput; } public void setCurrentOutput(Double currentOutput) { this.currentOutput currentOutput; } public String getStatus() { return status; } public void setStatus(String status) { this.status status; } public LocalDateTime getLastReportTime() { return lastReportTime; } public void setLastReportTime(LocalDateTime lastReportTime) { this.lastReportTime lastReportTime; } }这里只展示了实体类。在实际项目中还会继续拆分 Repository、Service、Controller 等层次。建模阶段的类图决定了实体类的骨架后续的业务逻辑都在这个骨架上生长。时序图中的“下发召测指令”可以映射为下面的 Controller 接口// 文件路径src/main/java/com/example/pvmonitor/controller/CollectController.java package com.example.pvmonitor.controller; import com.example.pvmonitor.service.CollectService; import org.springframework.web.bind.annotation.*; import java.util.Map; RestController RequestMapping(/api/collect) public class CollectController { private final CollectService collectService; public CollectController(CollectService collectService) { this.collectService collectService; } PostMapping(/command) public MapString, Object issueCollectCommand(RequestBody MapString, String request) { String gatewayId request.get(gatewayId); String deviceId request.get(deviceId); return collectService.collect(gatewayId, deviceId); } }这样从用例图到类图、时序图、状态图再到代码就形成了一条完整链路。标准模型不再只是文档而是真正变成了系统实现的一部分。5. 常见问题与排查思路在用 UML 表示电力行业标准时几个问题出现频率很高。问题现象常见原因解决思路类图画完开发看不懂类图中堆了太多标准字段缺少边界只提取当前项目需要的属性标准中的扩展字段放入附录或后续版本用例图粒度不一致有的人画系统功能有的人画内部步骤统一约定用例必须是参与者能感知的业务目标时序图和实际代码对不上时序图画完没有同步更新接口文档把时序图作为接口评审的输入模型更新时强制更新接口文档状态图缺少异常迁移只画了正常流程漏了通信中断、设备故障专门列出异常事件清单逐项补全状态迁移标准更新后模型同步困难手工维护成本高建立标准条款编号和模型元素的映射表评审时逐项核对5.1 标准类图与数据库表结构的差异类图中的关联关系并不总是需要建外键。例如电站和逆变器的聚合关系在数据库表中可以直接用station_id字段表达而不一定需要物理外键。建模阶段表达清楚逻辑关系编码阶段再根据是否需要强一致性来决定落库方式。5.2 多标准并存时的模型冲突同一个系统可能同时涉及 IEC 61850 和 IEC 61970两个标准对同一个实体的定义可能不一致。例如“设备”和“逻辑节点”之间的关系在不同标准视角下不同。这种情况下建议在上层建一个领域模型层统一项目内部术语再分别映射到不同标准的模型。5.3 工具选择导致模型无法协作不同工具生成的文件格式不同团队成员可能有人用 Enterprise Architect有人用 StarUML还有人用 Draw.io。建议项目组统一一种中间交换格式例如 XML 格式的 XMI 文件或统一使用 PlantUML 作为协作语言避免“模型各画各的合不到一起”。6. 工程实践与最佳实践6.1 建模粒度要控制模型不是越细越好。建议按“能指导编码”的标准来控制粒度用例图画到参与者和业务目标层级。类图只需要体现核心实体、关键属性和主要关系。时序图重点画跨系统、跨设备的交互。状态图重点画有状态生命周期管理的对象。如果类图一张图超过 30 个类建议按包拆分。如果时序图消息超过 20 条建议拆成多个子流程。6.2 命名规范与包结构在电力行业标准建模中命名规范直接影响后续代码质量。建议类名使用标准中的英文术语不自己造词。属性名统一使用小驼峰。枚举值统一使用大写下划线。包名按业务域组织例如domain、service、collect、alarm。例如标准中定义Inverter就不要在代码里写成NiBianQi。这不是教条而是因为电力系统项目往往需要和外部系统联调统一术语能降低沟通成本。6.3 模型评审与版本管理UML 模型同代码一样需要评审和版本管理。建议在项目启动阶段安排模型评审至少覆盖四个方面用例是否覆盖标准要求的业务范围。类图是否有遗漏的关键对象或关系。时序图中的接口会不会出现数据不够或字段冗余。状态图是否覆盖了异常路径。模型评审记录建议保留在项目文档库中并和标准条款编号建立映射。6.4 从标准到模型的追溯这是容易被忽视的一点。建议在模型元素上增加一个“标准来源”标签。例如用例UC1来源IEC 61968 配电管理用例文档。类Inverter来源IEC 61850 逻辑节点 DCAL / 光伏逆变器模型。状态Limited来源并网运行控制标准相关条款。这样当标准更新或审计时需要追溯时可以快速定位到对应模型元素。6.5 模型与代码保持同步电力项目周期长标准版本也可能更新。如果模型和代码长期脱节模型就变成了一堆没人维护的“死图”。推荐做法把模型文件纳入版本控制。在每次迭代提交时要求相关模型同步更新。用 PlantUML 这类文本化建模工具时可以结合 CI 自动生成图片避免手工导出。这样模型才能持续发挥设计文档和沟通桥梁的作用。7. 总结与后续方向这篇内容围绕“用 UML 表示电力与智能电网行业标准”展开从标准文档和代码之间的鸿沟出发梳理了几类核心 UML 视图的适用场景并以分布式光伏并网监测为例完整走了一遍用例图、类图、时序图、状态图到代码落地的流程。实际项目中先把标准范围划清楚再选择对应的 UML 图逐步细化比一上来就画大而全的模型更有效。建议你找一个自己参与过的电力业务场景按本文的流程先画用例图再补类图和时序图最后对照代码看看有多少设计可以直接复用。如果后续想看“用 UML 表示行业标准”系列其他行业的建模思路或者想深入某一张图的具体画法都可以继续关注。建模本身不难难的是让模型真正服务于开发和沟通这一点值得在项目中反复练习。