简介《南方电网一体化电网运行智能系统技术规范 第1部分 第2篇术语和定义》Q/CSG 110017.12-2012是南方电网发布的智能电网领域企业标准面向电网规划、二次系统设计、标准编写及系统集成人员重点解决二次系统种类繁杂、运行信息割裂、缺乏统一建设与运行标准等问题。该篇作为整套系列标准的总则组成部分以术语和定义为切入点为后续各篇规范提供统一语言基础。资源包仅含一个Word文档压缩后约两百一十一KB包含目次、前言与标准正文。整套系列标准共八个部分、七十二篇覆盖总则、架构、数据、平台、主站应用、厂站应用、配置、验收等环节正文中的标准体系结构表逐列列出各篇编号与名称便于定位查阅目前已有三百二十四人学习/下载。文档价值在于帮助读者快速厘清系统术语边界与体系脉络理解各篇规范的引用关系同时可了解IEC 61850实施规范、电网运行公共信息模型、全景建模等关键技术方向为新建或技改项目提供标准化落地参考适合作为电力智能化建设与标准应用工具资料。1. 一份术语标准凭什么决定电网智能化的成败做电网二次系统集成的人几乎都遇到过这种场面变电站里两台来自不同厂商的保护测控装置A 厂说自己的“保护动作时间”是从故障起始到发跳闸令B 厂说那是从模拟量产生到出口继电器动作——两边争论半小时最后发现是定义口径不一致。调试窗口就那么多时间全耗在扯概念上了。Q/CSG 110017.12-2012 这份标准解决的就是这类问题。它是南方电网一体化电网运行智能系统系列标准的第 1 部分第 2 篇72 篇标准里看起来最“软”的一篇却恰恰是其他 71 篇能对得上话的前提。它统一定义了从合并单元、保护测控装置到电力系统运行驾驶舱的一百多个核心术语凡是要做网、省、地县主站和厂站系统新建或技改的团队都得按这套口径立项、设计、验收。对调度自动化工程师、继保整定人员、系统集成商和实施项目经理来说读这份标准不是走过场而是避开返工的必修课。它不管电压等级不管设备型号只管一件事所有人说的“延时”“动作时间”“容灾指标”是不是同一个东西。2. 一部 8 部分 72 篇的标准体系先看清它怎么拆2.1 从总则到验收为什么要分成八个部分这套系列标准不是一份文件而是一整套工程约束。正文里写得很清楚它分 8 部分共 72 篇从顶层描述一路落到现场验收覆盖了一个电网智能系统从立项到投运的全生命周期。可以把它想象成一栋建筑的设计施工图集总则是设计总说明架构是结构图数据是管线综合图平台是机电系统图主站应用和厂站应用是功能房间布置图配置是施工详图验收是竣工验收标准。每一部分服务于不同阶段的决策者和执行者但所有图纸必须共享同一套图例——这套图例就是本标准的术语定义。分部编号逻辑值得注意。Q/CSG 110017.11-2012 是第 1 部分第 1 篇“基本描述”Q/CSG 110017.12-2012 是第 1 部分第 2 篇“术语和定义”。编号规则是“110017 部分号 篇号”部分号与篇号之间用点分隔同一部分内的多篇按顺序递增。数据部分出现了 9.1、9.2、9.3 这种带小版本号的编号是因为该部分篇目太多按主题细分了三篇接口协议部分内容篇数典型编号第 1 部分 总则基本描述、术语和定义2 篇Q/CSG 110017.11、.12第 2 部分 架构总体、主站、厂站架构3 篇Q/CSG 110017.21 ~ .23第 3 部分 数据数据源、模型、接口协议12 篇Q/CSG 110017.31 ~ .310第 4 部分 平台主站/厂站平台、OSB 总线6 篇Q/CSG 110017.41 ~ .45第 5 部分 主站应用数据、监视、控制、管理、驾驶舱26 篇Q/CSG 110017.51.1 ~ .55.2第 6 部分 厂站应用数据中心、装置、远动机15 篇Q/CSG 110017.61 ~ .67.9第 7 部分 配置主站/厂站配置及接线标准6 篇Q/CSG 110017.71 ~ .76第 8 部分 验收主站/厂站验收规范2 篇Q/CSG 110017.81、.82从篇数分布能看出建设重心主站应用占 26 篇厂站应用占 15 篇说明这个体系对“云”和“端”两侧都做了纵深拆解不是只做调度端大屏。2.2 术语篇为什么放在“总则”而不是“附录”很多企业标准把术语放在文末附录这本偏偏放在第 1 部分第 2 篇位置仅次于基本描述。这传递了一个工程意图术语不是查完就扔的字典而是后续所有篇目的“共同协议”。标准的范围章节写了三行字——标识和解释其他部分用到的术语和缩写引用了 IEC 60050、DL 890/IEC 61970、DL 860/IEC 61850、DL 1080/IEC 61968 四份文件作为术语来源基准。换句话说这份标准不是自己另搞一套词汇而是在国际电工词汇和国内电力行业标准之上做了收敛把“南网口径”钉死。这里有一条实际的坑IEC 61970 和 IEC 61968 分别面向输电网能量管理系统和配电网应用集成IEC 61850 面向变电站通信网络。当一套主站系统同时对接调度侧和厂站侧时同一个概念在三个标准里可能长得不一样。本标准的作用就是做消歧。举一个具体例子3.44 条对“合并单元 MU”的定义引用了 IEC 60050 的表述“用以对来自二次转换器的电流和或电压数据进行时间相关组合的物理单元”并追加注“合并单元可以是互感器的一个组成件也可以是一个独立的单元”。这个注不是废话它决定了工程采购时 MU 究竟算互感器的附件还是独立设备——直接影响预制舱接线方案和接口验收边界。2.3 术语总览一百多条定义里藏着哪些高频关键词标准 3.x 条目覆盖了几大类对象数据链路类MU 传输延时、电子式互感器采样延时、插值法、存储转发、背靠背帧系统架构类电力系统运行驾驶舱PSOC、变电运行驾驶舱SOC、面向服务的体系SOA、运行服务总线OSB工程文件类SCD 文件、CID 文件、ICD 文件、IID 文件、SVG 公共图形运维指标类恢复点目标 RPO、恢复时间目标 RTO、降级容灾、黑启动测试、72 小时连续运行测试性能测试类大容量雪崩测试、工厂验收 FAT、差异、偏差、缺陷这些术语不是均匀分布的数据与接口类的占比明显高于其他类别。这跟南网当时面临的核心矛盾一致——二次系统种类繁杂、运行信息割裂首要任务是让数据先“说同一种方言”。作为读者抓术语的重点也应该放在数据语义和时延定义上这两类直接决定主站能不能算出可信的结果。3. 数据链路的关键术语从采样到接线的精度账3.1 一条测量值从互感器走到主站中间经过几道“延时”定义电子式互感器场景是这份标准里定义最细致的地方因为它直接关系保护动作的快速性和测量精度。3.26 定义电子式互感器采样延时为“从一次模拟量产生时刻到电子式互感器对外接口输出数字量的时间”3.9 又定义了 MU 传输延时——“从一次模拟量产生时刻到 MU 对外接口输出数字量的时间”。注意看这两个定义的区别前者止步于互感器对外接口后者止步于 MU 对外接口二者之间夹着电子式互感器把采样值发给 MU 的过程。标准还专门在 3.9 里做了工程化的补充说明对电子式互感器MU 传输延时应包含电子式互感器的采样延时对常规互感器MU 传输延时应包含互感器传变角差、模拟低通滤波器及变换器传变角差。这意味着什么意味着如果你在项目里只核对“保护整组动作时间”这一个总指标而不去分解中间每一段延时等到现场联调时会发现整组动作时间远超预期却定位不到是哪一段多了 1ms。标准在 3.5 和 3.6 里把“保护装置动作时间”定义为保护收到故障起始数据到发出跳闸命令的时间“保护整组动作时间”则从一次模拟量产生算到智能终端出口动作。两者的差值里就藏着采样链路、GOOSE 网络传输和执行机构的全部开销。3.2 插值法不用全站同步时钟的对时方案里藏着什么算法3.12 条对插值法的定义值得细读“电子式互感器各自独立采样并将采样的一次电流或电压数据以固定延时时间发送至 MUMU 以本地时钟为基准并对电子式互感器的固定延时进行补偿并以此作为插值时刻采用插值重采样算法来实现相间采样同步。”定义最后补了一句关键结论“插值同步方式不依赖于全站同步时钟源。”这句话在工程上的分量很重。IEC 61850 体系里采样同步通常依赖 IRIG-B 或 PTP 对时一旦全站对时源失效常规同步方案下的采样值会出现相间角差进而威胁差动保护。插值法绕开了这条依赖链——只要每个 MU 的固定延时已标定就能在本地时钟基准上用重采样对齐各相采样序列。作为一个做数据接入的工程师你至少要从这里面读出三个信息MU 的“固定延时”必须由厂家在出厂前标定并写入配置文件采购时不能只看精度等级还要看延时稳定性指标做一致性测试时插值同步方案要单独设计测试用例不能和依赖同步时钟的方案混用同一套测试流程在 SCD 文件配置阶段需要把每个 MU 的延时补偿参数准确填进 IED 实例配置否则保护装置算出的插值点会整体偏移。3.3 几个厂站设备概念的边界保护测控装置、智能终端、一体化装置标准里场站端设备定义分布在 3.4、3.7、3.10、3.44、3.57、3.67 等多条。结合这套体系的第 6 部分厂站应用篇设备边界大致如下设备本标准的定义要点工程常见误读保护测控装置保护 测量 监视 控制集成于一体和“保护装置”混用漏掉测控职责合并单元 MU电流/电压时间相关组合的物理单元当成互感器附件忽略其对时、转发职责存储设备降低存储成本、处理海量报文的设备直连一体化装置当成普通 NAS忽略专用高速接口要求智能终端操作回路出口隐含于 3.6 条与合并单元混为一谈一体化装置不丢报文条件下实时记录、分析的最大对象个数以接入 MU 数为指标只看 CPU 主频不看接入能力指标。注意这个指标只在 3.57 条给出验收时容易漏我用粗体标出的是最容易在技术协议阶段踩空的点。比如“接入能力”这条3.57 明确以“接入合并单元MU数量”为指标单位而不是用“模拟量路数”或“遥测点数”。如果技术协议里写“支持 1024 个遥测点”那跟标准说的不是一回事验收时根本没法对应。4. 平台与应用层术语把“驾驶舱”和“驾驶舱”区分清楚4.1 PSOC 与 SOC决策端和厂站端的两种驾驶舱3.19 定义电力系统运行驾驶舱PSOC关键词是“服务于公司高层管理决策领导和电网运行关键岗位”“通过运行服务总线OSB”“采用态势感知技术”“一站式决策支持工具”。3.2 定义变电运行驾驶舱SOC关键词是“厂站系统中”“基于四大智能应用中心提供的数据和功能”“为厂站运行管理、设备检修、现场值班等专业人员提供的一站式平台”。两条定义同属“驾驶舱”服务对象和定位完全不同对比维度PSOCSOC部署位置主站端厂站端服务对象高层决策领导、运行关键岗位厂站运行、检修、值班人员数据来源四大智能应用中心四大智能应用中心厂站级核心能力KPI 展示、异常预警、决策支持监视、分析、查询、操作两家都有一个“依托四大智能应用中心”的前提但数据粒度不一样。PSOC 面向全景风险SOC 面向现场操作。做界面设计的团队如果只看到“驾驶舱”三个字就开始画大屏很容易把厂站操作界面做成调度驾驶舱的下钻版——这正是标准想要避免的。4.2 OSB、SOAP、JMS、SNMP总线里跑的什么协议平台部分的 OSB 在术语篇里没有单列定义但 3.54、3.55、3.52 分别定义了 SOAP、SNMP、JMS。这三个协议放在一起基本勾勒出 OSB 的形态SOAP 用于跨应用的标准化数据交换走 HTTP(S) 或 JMS 通道JMS 提供异步消息能力适合订阅发布模型SNMP 管网络设备监控告警。对实施团队来说看到 OSB 和 SOAP/JMS 的组合第一反应应该是检查接口文档里有没有明确“服务契约无关性”。3.68 SOA 的定义里强调了“接口是采用中立的方式进行定义的它应该独立于实现服务的硬件平台、操作系统和编程语言”。落到开发层面这意味着服务提供方发布的接口描述文件必须是平台中立的不能出现“这个服务我们只提供 Java SDK”之类的话——有这种话术的接口方案和 SOA 原则是冲突的。订阅发布机制在 3.21 条也有独立定义发布者不关心谁订阅订阅者只接收感兴趣的消息。这个机制在电网场景里最常见的应用就是告警分发——主站把告警事件发布到总线调度台、值班台、短信平台各取所需而不是点对点轮询。做告警子系统架构时如果消息模型里没有“类别订阅”的概念回头接 OSB 时会发现总线侧根本不支持你这种直连方式。4.3 容灾指标RPO、RTO、降级容灾怎么落到技术协议里3.47 恢复点目标 RPO 定义为“灾难发生后系统和数据可以恢复到的时间点要求”3.48 恢复时间目标 RTO 定义为“从停顿到必须恢复的时间要求”3.56 降级容灾定义为“灾备系统功能和性能、处理能力、可靠性等指标低于原系统”。这三条放在一起是写灾难恢复方案时最有力的依据。工程上常见的问题是需求方只写“需要容灾”四个字不量化指标导致设计方做出一套全等热备成本翻倍验收时双方都不满意。用标准里的定义去拆需求流程应该是确定 RTO业务中断多少秒/分钟内必须恢复这决定了切换是热备自动切换还是冷备人工拉起确定 RPO允许丢失多长时间的数据这决定了数据同步是同步复制还是异步复制判断是否允许降级容灾如果允许主备资源不必 1:1成本能降不少。这里给一个我在写容灾方案时常用的指标表模板可直接贴进技术协议| 项目 | 指标 | 依据 | | --- | --- | --- | | 恢复时间目标 RTO | ≤ 5 分钟 | Q/CSG 110017.12-2012 第 3.48 条 | | 恢复点目标 RPO | ≤ 1 分钟 | Q/CSG 110017.12-2012 第 3.47 条 | | 降级容灾允许 | 允许缺失非核心模块在线计算功能 | Q/CSG 110017.12-2012 第 3.56 条 | | 黑启动时间 | FAT 时实测记录不做硬性指标 | Q/CSG 110017.12-2012 第 3.46 条 |黑启动测试在这里指的是主站系统的启停时间检测不是电网全停后的黑启动很多刚接触标准的人会把这两个概念搞混谈技术协议时一定要说清是哪个“黑启动”。5. 验收与测试术语FAT差异偏差怎么界定5.1 从工厂验收到现场验收阶段怎么划分3.40 定义工厂验收 FAT 为“主站系统通过工厂预验收后由建设单位组织、上级系统运行部主持及制造单位参加进行的系统出厂验收检验”。注意这个表述里有两个关键动作建设单位组织、上级系统运行部主持。也就是说FAT 不是厂商自测也不是建设方单独验而是建设方牵头、运行部主持的三方活动。3.75 定义了 72 小时连续运行测试——在所有设备同时投入运行状态下连续 72 小时不间断运行。这条要和差异/偏差/缺陷三条放一起看。3.10 差异、3.41 工程化问题、3.71 偏差、3.76 缺陷四者在标准里的关系是类别定义要点处理方向差异实现的功能/性能/硬件设备与合同技术文件不符或新提出的技术要求逐条记录按合同判定是否整改工程化问题因参数未正确配置或工程化工作未完成导致的功能不正确现场补充配置后复测偏差不满足合同条款但不影响稳定运行可通过简易修改纠正记录在案限期修改不必中止验收缺陷不满足系统基本功能和主要性能指标影响稳定运行必须修复后重新测试相关项目实际执行中我会按这张表给测试问题定级。原则很简单缺陷必须关掉才能签 FAT偏差和工程化问题可以带着清单走但清单要写明整改责任方和截止时间。这样做的好处是验收会不至于因为一个小问题僵持也不至于把大问题漏过去。5.2 大容量雪崩测试和两个细则验收时最容易犯的错3.13 说雪崩测试是“在工厂模拟测试环境下采用专业的模拟测试系统模拟接入的厂站和信息量、以及电网事故条件下的雪崩数据与主站系统进行实时通信的状态下”进行的测试。这里有个常见的认知偏差雪崩测试不是“突发大流量压测”而是模拟电网事故条件下的信息雪崩。真实事故场景里一个 500kV 变电站故障瞬间会产生大量 SOE 事件、遥信变位、保护动作报文这些数据以极短时间窗涌入主站。普通压测是持续加压看系统吞吐上限雪崩测试是突发冲击看系统在消息堆积时能不能按优先级处理会不会漏报文、丢事件。3.13 强调的是“模拟接入的厂站和信息量、以及电网事故条件”因此测试设计要有故障场景脚本不能只是把报文速率调高。3.66 两个细则指的是南方区域的两个并网运行管理实施细则一个管并网运行管理一个管辅助服务管理。这条术语容易被忽略但它决定了并网审核和考核评价功能的实现范围。如果你的项目涉及并网管理模块必须回到这两个细则原文去核对考核项与评价项目术语篇只给出处不给细节。6. 建立术语一致性台账一个可复用的落地技巧6.1 用标准做“术语-出处-工程用词”三列映射表我处理标准类项目时有一个习惯把 Q/CSG 110017.12-2012 的术语抽出来做成工程术语台账格式如下标准术语标准编号/条目工程常见叫法冲突风险保护整组动作时间3.6出口动作时间/跳闸时间高合并单元 MU3.44采集单元/就地模块中差异3.10问题单/整改项中降级容灾3.56轻载容灾/非全等容灾低这个台账挂在需求文档的最前页每次评审先过术语关再讲功能。它能挡住大量“我说 A 你说 B 但都认为在说同一件事”的会议。6.2 用脚本检查一致性把术语表变成配置文件如果你手里有标准文本可以用 Python 把它转成 JSON 字典在配置评审时做关键词扫描import json import re # 将标准术语条目转为字典key 为英文缩写或关键词 term_dict { MU传输延时: 从一次模拟量产生时刻到MU对外接口输出数字量的时间, 保护整组动作时间: 从一次模拟量产生时刻到智能终端操作回路出口动作的时间, RTO: 灾难发生后系统或业务功能从停顿到必须恢复的时间要求, RPO: 灾难发生后系统和数据可以恢复到的时间点要求, } def scan_doc(text, term_dict): hit_list [] for term, defn in term_dict.items(): # 查找正文中是否使用了该术语但没有给出标准定义 if term in text: cnt len(re.findall(term, text)) hit_list.append({term: term, count: cnt, definition: defn}) return hit_list doc_text 本方案中保护动作时间为保护装置收到故障数据到出口动作的时间... result scan_doc(doc_text, term_dict) for r in result: print(r[term], r[count], r[definition])这段脚本的逻辑很简单把标准里定义过的术语放进字典扫描你的需求文档或技术协议凡是出现该术语的地方都列出来人工核对上下文里的解释是否与标准一致。用这个方式我曾在一次评审里抓出 11 处自造定义其中两处直接导致了后续参数整定的偏差。更进一步的做法是把这份术语字典纳入公司内部的文档规范要求新项目在“名词解释”一章里直接引用标准条款号而不是自己重新写一遍定义。这样项目实施到后期每个人翻开文档看到“保护整组动作时间Q/CSG 110017.12-2012 第 3.6 条”都知道标准的确是唯一的口径来源。本文还有配套的精品资源点击获取
