iec61970的接口规范研究.pdf
适合国际标准IEC 61970和IEC 61968的智能楼宇能源管理系统设计
Intel丨igent Building 眷能建筑适合国际标准IEC61970和IEC61968的智能楼宇能 源管理系统设计Smart Building Energy Management System Design under International Standard of IEC 61970 and IEC 61968袁心怡，邵峥达，陈博，曾真，高非池，赵艳敏（国网上海市电力公司，上海200051)摘要：国际电力标准IEC61970、61968系列提出了应用集成框架、信息模型和接口规范，是电力系统管理及其信息交换领域的重要标准，应 及时跟踪、分析、研究和应用。
对电力行业“信息孤岛”现象进行了分析，介绍了 IEC61970、61968系列标准的应用情况，特別是为该标准 在智能楼宇能源管理中的应用提供了系统构架及案例。
研究结果可供相关行业参考。
关键词：电力标准；IEC61970 ;IEC61968 ;智能楼宇中图分类号：TU18 文献标识码：A文章编号：1674-814X(2021) 02-051-031背景概述1.1智能楼宇能源管理系统现状在我国经济高速发展的趋势下，公共建筑（大型商场、酒店、办公楼、宾馆等）的能源消耗问题曰益显现。
公共建 筑中暖通空调系统和照明系统的用能占据了建筑整体能耗的 绝大部分。
智能楼宇能源管理系统的建设目的是实现新建公共建筑 的节能降耗，其主要功能是通过建筑能耗模型的建立，对建 筑楼宇、用能系统设备的能耗数据进行监测和分析，挖掘建 筑节能潜力，实现建筑用能系统高效运行。
1.2 IEC61970 和 61968 应用情况随着计算机通信技术的发展，国际电工技术委员会(IEC)的第57技术委员会（IE C T C57)为了解决建筑电 力系统对数据信息的集成共享问题，制定了一系列标准，包 括电力标准IEC 61970和IEC 61968。
通过电力系统信息模 型进行数据的共享，实现能源数据的获取、分析和动态调控 管理。
IEC61968、61970简介
第503部分：CIM XML模型交换格式
7
CIM建模表示法
CIM 用面向对象的建模技术定义。
具体地说，CIM规范使用统一建模语言(UML)表达方法
将CIM定义成一组包，每一个包包含一个或多个类图， 用图形方式展示该包中的所有类及它们的关系。 根据类的属性及与其它类的关系，用文字形式定义各
个类。
8
CIM包
系来描述电力企业的所有主要对象，特别是那些与电力
运行有关的对象 公共信息模型(CIM)是一个抽象模型
3
编制单位
IEC 61970系列标准
国际电工委员会57技术委员会（电力系统控制及其通
信委员会）制定的 定义了能量管理系统的应用程序接口（EMS-API）。
4
内容和意义
IEC 61970系列标准主要包括公共信息模型（CIM）和组 件接口规范（CIS）两方面内容。
9
CIM 301 部分的包图
10
CIM包
IEC 61970-302 — 能量计划包（Energy Scheduling） — 财务包（Financial） — 预定包（Reservation） IEC 61970-303 — SCADA包 IEC 61968 —资产包（Asset） —用户包（Consumer） —核心2包（Core2） —配电包（Distribution） —文件包（Documentation）
其目的和意义在于：
（1）便于来自不同厂家的EMS系统内部各应用的集成； （2）便于EMS系统与调度中心内部其它系统的互联； （3）便于不同调度中心EMS系统之间的模型交换。
5
组成部分
第1部分：导则和基本要求
第2部分：术语 第301部分：公共信息模型（CIM）基础 第302部分：公共信息模型（CIM）财务、能量计划和 预定
基于IEC 61970标准的电力系统HSDA接口的研究
１ Ｉ Ｅ Ｃ ６ １ ９ ７ ０标准简介
Ｉ Ｅ Ｃ ６ １ ９ ７ ０标 准 是 由 国 际 电 工 委 员 会 Ｉ Ｅ Ｃ ｆ Ｉ ｎ ｔ ｅ ｒ ｎ ａ ｔ ｉ ｏ ｎ ａ ｌ Ｅ ｌ ｅ ｅ ｔ ｒ ｏ ｔ ｅ ｅ ｈ ｎ ｉ ｅ ａ ｌ Ｃ ｏ ｍ ｍ ｉ ｓ ｓ ｉ ｏ ｎ ） 分 管电力 系统控 制和有关通信 的第 ５ ７ 技 术委员会制定 的 标 准针对能量 管理 系统 Ｅ Ｍ Ｓ ｆ Ｅ ｎ ｅ ｒ ｇ ｙ Ｍ ａ ｎ ａ ｇ ｅ ｍ ｅ ｎ ｔ Ｓ ｙ ｓ ｔ ｅ ｍ ） ， 定义了一系列应 用程 序接 口（ Ａ Ｐ Ｉ ） Ｉ Ｅ Ｃ ６ １ ９ ７ ０标准核心 问题 是信息交换 ． 使 用公共信息模 型 Ｃ Ｉ Ｍ和组件访问接 口规范 ． 打破各个 Ｅ ＭＳ厂家数 据库的信息壁 垒．提 升控制 中心环境 内外各种完全不 同 的系统之 间交换信息的能力
Ｓ ｃ ｉ ｅ ｎ ｃ ｅ ＆ Ｔｅ ｃ ｈ ｎ ｏ ｌ ｏ ｇ ｙ Ｖｉ ｓ ｉ ｏ ｎ
科 技 视 Ｗｌ ｔ
科技・ 探索・ 争鸣
基于 Ｉ Ｅ Ｃ ６ １ ９ ７ ０ 标准的电力系统 ＨＳ Ｄ Ａ接 口的研究
程 琳 （ 重庆 邮 电大 学 ， 中国 重庆 ４ ０ ０ ０ ６ ５ ）
【 摘 要】 随着计算机和现代通信技术的飞速发展 ， 以及 电力企业信息化的进 一步完善 ， 大批综合性分布 式应 用系统逐渐建立起 来， 电力 系 统正向着 网络化 、 组件化的方向发展 。通常而言 ． 电力 系统中各 个子 系统的设计 开发过程相对独立分散 ． 设计重 点集中于为特定问题提供完善 的解决方案 。 而往往忽视 了系统之间接 口的设计 ， 这将导致企业应 用成为信息孤 岛． 整个电力系统无法统一管理调度各个子 系统。为
基于IEC 61850与61970的无缝通信体系的研究
０ 引 言
随着 电网结 构 Ｈ趋 复 杂 ， 网容 量 不 断 扩 大 ， 电 需 要实 时传 送 的信息 量成倍 增 多 ， 对变 电站 自动 这
化 系 统 （ Ａ ，ｕ ｓ ｔ ｎＡ ｔ ｔ ｎＳ ｓ ｍ） 能 量 Ｓ Ｓ Ｓ ｂｔ ｉ ｕｏ ｉ ｙｔ 和 ａｏ ｍａ ｏ ｅ 管 理 系 统 （ ＭＳ Ｅ ｅｇ ｎｇｍｅ ｔ ｙｔ Ｅ ， ｎ ｒ Ｍａ ａｅ ｎ ｓ ｍ） 数 ｙ Ｓ ｅ 的
合这 ２种标 准 的系统 之 间 的通 信连 接 问题 ， 内外 国 都研 究甚 少 。 根 据 Ｔ ５ Ｃ ７战 略 咨 询 小 组 的 要 求 ， 现 有 技术 水 平 的通 信 体 系 总 体 应 该 是 无 缝 连 接
的 。文 献 ［ ５ 都 只是 粗略 地 总结 概 括这 ２种标 ４— ］
从 系统通 信数 据模 型 的建 立 和 总线 接 口标 准 的 统
一
来 讨 论 基 于 ＩＣ ６ ８ ０ ６ ９ ０标 准 的 电 力 自 动 Ｅ １５／ １７
化 系统之 间 的无缝 通信 问题 。
１ ＩＣ ６ ５ Ｅ １ ０标 准 概 述 ８
Ｉ Ｃ６ ８ ０标 准 是 国 际 电 工 委 员 会 第 ５ Ｅ １５ ７技 术
准在 高层 上 的应用 ， 有给 出具体 的转换 方 式 。 没
针对 此 问题 ， 文作 了 比较 细 致 的讨 论 分 析 ， 本
据通 信 提 Biblioteka 了更 高 的 要 求 。 目前 ， 这 ２个 系统 在 中， 每个产 品 供 应 商 可 能 都 有 １套 各 自的通 信 标
准 ， 样整 个 电网就 存在 多种规 约 。 这 针对 这 种 情 况 ， ＣＴ ５ Ｉ Ｃ ７小 组 先 后 制 定 了 针 Ｅ 对 Ｓ Ｓ的 Ｉ Ｃ６ ８０标 准 和 Ｅ Ｓ 的 ＩＣ ６ ９ ０标 Ａ Ｅ １５ Ｍ Ｅ １７
基于iec61970电能计量系统.pdf
其中 括电 葬 备 模 、 备 件的 接 包 力 统设 元件 型 设 元 连
拓扑关系、电能量数据、 瞬时量数据等。 随着电 力 市场的不断发展， 电能量计量系统的应用范围越来 越广，电 能量计量系统迫切需要和其他异构系统实 现数据共享， 进而为电力市场系统的运营和电 力企 业的 辅助管理决策提供支持。 传统的电能量计量系 统通常采用私有的信息模型， 和其他系统的 数据共 享采用专用接口 的方式。 随着和需要电能量计量系 统交互的系统越来越多， 这种方式己 经不能满足电 能量计量系统应用的需求。 ＩＣ １ ０ Ｅ ６９ 标准是国际电 ７ 工组织第５ 分会第１ ７ ３
方案。
关键词：电 能量计量系统；ＩＣ １ ０ ＣＭ； Ｅ ６９ ； ＣＳ ７ Ｉ Ｉ
０ 引言 近几年来，电能量计量系统（ Ｒ的发展，为 Ｔ ） Ｍ 电力市场的正常运营、公平竞争、 准确结算打下了 坚实的 基础。 但随 着电网的商业化、 市场化的 深入 发展，各个市场运行模式和规则不断修改和完善， 对电 能量采集系统提出了 更多 方面的要求， 步 进一 要求电能量计量系统具有更强的开放性和灵活性， 可方便地和其他系统包括电 力市场技术支持系统、 调度自 动化系统、 调度管理信息系统、 综合数据平 台系统和营销管理系统等实现信息共享和互操作。 电 能量计量系统包含大量电 力系统运行数据，
变压器绕组
电容器
负荷 刀闸
ｇｏｄ ｃｎｅｍ ｒｕ ｄｓｏｎｃ ｉ
接地刀闸
熔丝
ｔ－ ｕ ｆ Ｐ ｕ Ａ ｓ Ｖ ｅ
ｇ ｅ ｔｎ ｉ ｅ ｒｉ ｕ ｔ ｎ ａｏ ｎ
开关 负荷刀闸
机组
１ 系统模型中类之间的 ． ４ 继承关系 在ＣＭ模型中， Ｉ 基类和派生类之间 存在着继承 关系。 在电能量计量系统中， 遵循ＣＭ类之间 可以 Ｉ 的 继承关系， 利用面向 对象的技术， 实现模型中的 类和类之间的继承关系， 派生类继承基类的属性和 关联， 并使用Ｄ Ｏ ＩＢ Ｒ Ａ Ｅ 实体ＥＢ等技 Ａ ， Ｅ Ｎ Ｔ 、 － Ｉ Ｊ 术中的 对象继承支持加以实现。 １ 图 为系统中各个 设备类之间的继承关系图。 １ 系统模型中类之间的关联关系 ． ５ 在 ＣＭ 模型中，类之间的关联关系非常多， Ｉ 电 能量计量系统可以 遵循ＣＭ的原则， Ｉ 建立系统模 型中各个类之间的关联关系， 为电能量计量系统的 各个应用以及和其他系统的交互提供数据模型支 持。由于篇幅所限，图２ 为厂站、电压等级、变压 器、 变压器绕组之间的 关系图．
IEC_61970系列标准介绍
1.2 关于IEC TC57 WG13
• IEC是The International Electrotechnical Commission— —国际电工委员会的简称。IEC是一个全球性的标准化组 织，由各国电工委员会（IEC国家委员会）组成。IEC的 目标是就电工与电子领域内有关的各种标准化问题促成国 际间的合作。为此，IEC发布国际标准，技术规范，技术 报告和导则等出版物 • TC57是IEC的一个技术委员会，负责电力系统控制及其通 信的相关标准的制定 • WG13是TC57的一个工作组，负责制定与EMS专业相关 的IEC 61970标准
Dis tribution M anage m e nt Sys te m s
Public Data Programs
ICCP
2、CIM介绍
• • • • • • 2.1 CIM是什么 2.2 CIM的组成和使用范围 2.3 CIM的表示法 2.4 CIM包 2.5 CIM类和关系 2.6 CIM XML文件
•名称 •电压等级 •连接关系 •通常状态 •遮断容量
Wires 电线包
Swtich 开关刀闸类
Breaker 断路器类
2.5 CIM类和关系
• 每一个CIM包的类图展示了该包中的所有的 类及它们之间的关系。 • 类
- 一个类是对现实世界中发现的一种对象的表示。
• 类的属性
- 类具有描述对象特性的属性。 - 只有各个EMS应用共同感兴趣的那些属性才包括在类的描述中。
IEC 61970系列标准培训资料
IEC 61970系列标准介绍
国电南瑞科技股份有限公司
61970系列标准CIS部分介绍详解
Part 401~449：指定组件接口所支持的通 用服务。这些规范定义了任何一个应用 与其它应用交换信息或访问公共数据所 使用的通用服务
(1)通用服务的目标
使企业应用集成所需工作最小化 将应用与底层中间件技术分离开来 充分利用CIM 限制创建粒度过小的API 防止不兼容的CC API成为标准
3.2 CIS Level 1文档结构
–
Part 401 ：CIS架构
本文档提供了CIS系列标准的总概，并说明了在一个系统实 现和系统集成项目中如何使用这些标准。
–
Part 402-449 ：详细说明组件接口所支持的通用服 务。
这些规范定义了一个应用与其它应用进行信息交换和访问 公共数据的通用服务。
(3) CIS各部分之间的关系
Part 401~449: 通用服务(HOW) Part 501:将以UML形式表达的 CIM翻译成为机器可读的XML格 式的规则。具体地，使用资源描 述框架（RDF）模式规范语言来 表达模式。 技术映射 Part 450~499: 应用相关的信息交 换模型(WHAT) Part 4xx: CIS Level 1: 与具体实现技术无关的规范 Part 503 用于交换基于CIM 的模型信息所需的格式和规则
– Part 450-499： WHAT:交换什么
3.2 CIS Level 1
由于许多组件接口服务为多个应用类型 所共需，通用服务的定义与使用它们的 应用之间应保持独立。
– 通用服务组织在一个系列中 401~449 – 使用这些服务的特定应用及其交换的信息内
容则组织在另一个系列中 450~499
Identifiers（标识服务）
IEC61970、61968标准及应用
系统A
系统B
系统F 系统E
系统C 系统D
系统A
系统B
系统F
平台
系统C
系统E
系统D
平台构建基础
达成共识的信息模型：CIM 或 ECIM 提供符合标准的组件接口 对象标识规范化，建立与平台相关系统的交叉映射
主标识（Master Resource Identifier） MRID与URI的关系？
适配过程需要进行接口开发，有一定的工作量
内容
IEC 61970、61968标准体系 基于标准构建平台及应用系统
标准符合性验证 标准应用的问题及讨论
标准符合性验证
声明符合标
准，如何验 证？
信息模型正确性
通过GDA模式查询访问被测服务器，校核模型服务器的模式正 确性
对象数据正确性
基于对象关联（典型的如拓扑）的数据分析检查
应用其他规则
构建“原生式”标准支持的系统
数据存储体系与信息模型完全对应（意味着可能需 要重新设计系统架构）
整体映射，选择符合性能和扩展要求的O-R映射方案， 无信息损失
表-类 记录-对象 字段-属性 正确处理继承关系 关联处理：一对一、一对多、多对多
建立恰当的依赖层级
（电网）模型 基于模型构建数据访问视图（DAIS、HDAIS、GES） 基于数据访问视图支持数据访问（实时、历史、事件）
对同一个对象而言，只有一个MRID，但在不同系统中建立该对象 对应的信息对象时，可以有多个URI——不同视图下的标识可以不 同
对象标识标准化的基础
信息模型标准化 集中的标识分配（不易实现）
元数据管理 数据管理 （模式驱动）
平台结构示意
iec61970-cim-intro
An Introduction to IEC 61970-301 & 61968-11: The Common Information ModelDr Alan W. McMorranInstitute for Energy and EnvironmentDepartment of Electronic and Electrical EngineeringUniversity of StrathclydeGlasgow, UKJanuary 2007The copyright of this publication belongs to the author under the terms of the United Kingdom Copyright Acts. Due acknowledgement must always be made of the use ofany material contained in, or derived from, this publication.1 Background1.1IntroductionSince deregulation, both in the UK and internationally, there has been an increasing need for power companies to exchange data on a regular basis. This is to ensure thereliable operation of the interconnected power networks owned and operated by anumber of different utilities. Power companies use a variety of different formats tostore their data, whether it be asset and work scheduling information in a proprietaryinternal schema within a database, topological power system network data within acontrol system, or static files used by simulation software.While much of this data is only required within a company, there is often a need toexchange the data both internally between different applications and externally withother companies. The large number of proprietary formats used by these applications requires a myriad of translators to import and export the data between multiplesystems. This exponential growth in complexity when integrating increasing numbersof applications and exchanging between multiple companies has driven the requirementfor a common format that covers all the areas of data exchange in the power electrical domain.The IEC standard 61970-301 [1] is a semantic model that describes the components of a power system at an electrical level and the relationships between each component. The IEC 61968-11 [2] extends this model to cover the other aspects of power system software data exchange such as asset tracking, work scheduling and customer billing. These two standards, 61970-301 and 61968-11 are collectively known as the Common Information Model (CIM) for power systems and currently have two primary uses: to facilitate the exchange of power system network data between companies; and to allow the exchange of data between applications within a company.The development of the CIM has primarily taken place in North America, where the North American Electric Reliability Council (NERC) has adopted the CIM as the format for exchanging network data between transmission companies. The majority of the application integration activities have similarly taken place within North American utilities.This paper describes the pitfalls of the traditional methods of storing power system data, then introduces the concepts behind class modelling and how this approach is used to define a power system in the IEC 61970 Common Information Model (CIM) standard. The use of the Extensible Markup Language (XML) to encapsulate this data for the exchange of both full power system models and inter-application messages is then described.1.2Power System Data FormatsSince the advent of the modern digital computer, power system engineers have utilised the capabilities of this tool in a variety of areas, whether it be performing complex analysis calculations on a power system or to control its operations in real-time. All of these applications require the operator to digitally store and exchange data about the system.Large-scale Energy Management Systems (EMS) and asset-management systems use database schemas for defining the structure of the data storage data, often custom-written to reflect the operator’s specific requirement. Offline applications for performi ng load-flow and fault-level analysis simulations use application-specific file formats that represent the data required by each application.In modern utilities’ IT infrastructures, large-scale applications such as the EMS andasset-management system comm unicate with each other, generally using a vendor’sown custom format based on the internal database schema. In the past this often required the user to purchase each piece of enterprise-level software from the same vendor to ensure compatibility when integrating them.The deregulation of the power industry, however, has resulted in multiple utilities,running software from a number of different vendors, having to exchange large datasets on a regular basis. The use of proprietary, custom formats complicates this exchange, requiring complex translation between each of the custom formats. Similarly, offline applications traditionally use a rigid, proprietary format containingonly the data required by that particular version of the application. When subsequent versions of the program require additional details the file format is changed, resulting in multiple formats for a single application. Of course, such a scenario is not limited to power system applications. Changing the file format for each new software version is common practice within the software industry but usually only causes minor irritation since each new version of a vendor’s software contains import facilities to convert previous versions of the file format into the new format.Problems occur when companies need to exchange data between software applicationsfrom different vendors, and/or have multiple versions of the same software runningwithin their company. Such a scenario requires a company to either:1. Maintain multiple copies of the same data in multiple formats2. Store the data in a format compatible with every piece of software, requiring theremoval of application-specific data and a subsequent loss in precision3. Store the data in a single, highly-detailed format and create software to translatefrom this highly-detail format to the desired application file formats4. Use a highly detailed format that is compatible with every application and whosestandard format contains the basic data required to represent the power systemwhile simultaneously allowing additional, detailed, application-specific data tobe contained without invalidating the format.The third option requires additional software engineering on the part of the company to create translation tools, but requires them to maintain only a single format containing allthe data required. The fourth option represents the ideal solution, allowing a companyto maintain a single, highly detailed format that is compatible with any of their software.This option does, however, requires three things:▪ A highly detailed model to describe the power system▪ A file format capable of storing extended data without affecting the core data ▪ Power system software vendors and utilities to either adopt and embrace this data model and format either for economic or regulatory reasonsThe Common Information Model (CIM) for Power Systems has the potential to meet the first requirement of the above list while the eXtensible Markup Language (XML),combined with the Resource Description Framework (RDF) offers a means of fulfilling the second requirement. The remaining requirement can be considered more of a commercial challenge than a technical one. Universal acceptance of this format requires both utilities and vendors to acknowledge the benefits of adopting the standard. At present, all of the major power system application vendors are active participants in theCIM Interoperability tests and the popularity of the format is spreading.This paper will provide some background on the CIM and the CIM RDF XML format.To understand the structure of the CIM, however, it is important to have anunderstanding of class hierarchies within the object-oriented software paradigm and the benefits of using such an approach to model the components of a power system. The following sections will provide some general background on class hierarchies, followedby more detailed background information on the CIM. Finally, it will be shown how thisdata can be represented in the RDF XML format.2 Class Hierarchies and UML Class DiagramsWhen building any system to represent data, whether it be a software architecture or a database schema, the design of the system will define how extensible and scalable the system is, and ultimately, whether it succeeds or fails at its given task. This paper provides an introduction to the concept of Class Hierarchies and how they are used in system design, along with the Unified Modelling Language (UML).Within a system, a class represent a specific type of object being modelled. A class hierarchy is an abstract model of a system defining every type of component within asystem as a separate class. A class hierarchy should reflect the real-world structure ofthe system.While a full description of UML is outwith the scope of this thesis, UML class diagrams provide a useful means of visually representing object hierarchies. This section will provide a simple case study to show how a class hierarchy representing a small segmentof a University system can be constructed independently of the final platform on whichthe design will be utilised.2.1ClassesEach class can have its own internal attributes and relationships with other classes. Eachclass can be instantiated into any number of separate instances, known as objects, each containing the same number and type of attributes and relationships, but with their own internal values.Figure 2.1 The Person ClassA simple example of a class is that of a Person as shown in Figure 2.1. The Person class contains two basic attributes: Name and Gender. If the system being created were to represent every person in the University, it would require only this single class since every person within the University can be represented at the most basic level by the attributes defined in Person.For a University containing 10,000 students and staff, the system would create 10,000 separate instances of the Person class, each containing a value for Name and Gender independent of the other 9,999 instances (although not necessarily unique).If the system is required to store more information than just a person’s Name andGender, and differentiate between staff, students and the different types of each, thenthe class diagram becomes more complex.2.2Inheritance (Generalisation)Inheritance (also known as Generalisation) defines a class as being a sub-class of another class. As a sub-class, it inherits all the attributes of its parent, but can also contain its own attributes.Figure 2.2 Class Hierarchy of people at a UniversityFigure 2.2 provides a class hierarchy to represent some of the different types of peoplethat exist within a University system. This diagram, as with all subsequent class diagrams uses standard UML symbology. Student and Staff are both sub-classes of Person. A Student is still a person and still has a Name and Gender, but has additional attributes to denote the year they are in, their student number and the course they are studying. Similarly, if someone is Staff they are still a Person, but have gained a new attribute to indicate their salary.The Student class itself has two sub-classes, Undergraduate and Postgraduate, both inheriting all the attributes of Student (and in turn, of Person), but independent of each other. The Postgraduate class also has two subclasses, Masters and PhD. A PhD is a Postgraduate and a Student and a Person, with all of their attributes, but with theaddition of its own ResearchTopic attribute.The Staff class also has two sub-classes, Research and Academic, both of which retain all the attributes of Staff and Person.So while a PhD is a Postgraduate, a Student and a Person, not all Students are PhDs. Similarly, an Academic is Staff and a Person, but not every member of Staff is an Academic.2.3AssociationSection 2.2 has shown how a class hierarchy can be formed to describe sub-classes of Person, but other than the inheritance there are no other relationships defined between classes the classes in Figure 2.2.Figure 2.3 Class hierarchy of students, staff and subjectsIn Figure 2.3 we have introduced two additional classes: Subject and Period. Neither of these classes are a type of Person, and as such do not inherit from the Person class. The Subject class does however, have a relationship with the Undergraduate and Academic classes.An Undergraduate can study a number of subjects and an Academic can teach a numberof subjects. These relationships are shown on the diagram as associations between the classes.For the Undergraduate-Subject association, the role is given as “Studies” while thelocation of the arrowhead indicates that it is the Undergraduate who Studies the Subject(if the arrow were reversed, it would mean that the Subject studied the Undergraduate). At each end of the association link is the multiplicity. For the Undergraduate-Subject association, these indicate that a Subject must have from 1 to many (1..*) Undergraduates, but an Undergraduate can have from 0 to many (0..*) subjects (since itis possible that some Undergraduates may not be studying any subjects due toindustrial placements, sabbaticals etc. It is assumed that a subject will not exist in the system if no students have chosen to study it).Similarly, a Subject will have from 1 to many Academics who teach that Subject, but an Academic may teach from 0 to many Subjects (since not all Academics have to teach). The other additional class, Period, with Day, Time and Duration attributes, represents a particular timetable period and as such a Subject has an association with a Period. Aswith the other associations, the Subject-Period association has a role, isTaughtDuring andmultiplicities which indicate that a Subject will be taught during 1 to many periods and that a Period will have from 0 to many Subjects taught during its time-period.This demonstrates how classes relate to each other on a very basic level and how UML Class Diagrams provide a means of graphically displaying these relationships.2.4AggregationFigure 2.4 Class Hierarchy of a University and BuildingThe Aggregation relationship defines a special kind of association between classes, indicating that one is a container class for the other. In the example shown in Figure 2.4, two new classes University and Building have been introduced, each very simple classes containing only a single attribute to denote their name. The multiplicity on the diagram operates in the same manner as to that of the Association, indicating that a Building canbe part of 0 or more Universities (we are assuming that some Universities operate joint schools and not every building within the system will necessarily be part of a University). The second multiplicity indicates that a University can contain 0 or more buildings (0 if it operates solely by remote learning for example).Unlike a simple Association relationship the line denoting a relationship on the diagram contains a diamond instead of an arrowhead. This indicates that the two classes have an Aggregation relationship. This can be though t of as “The University is made up of 0 or more Buildings”, indicating that the relationship is stronger than a simple association.The clear diamond, however, indicates that the two are not completely inter-dependent,and that if the University were destroyed the buildings would still exist (assuming the destruction was not a literal demolition but instead indicated that the University hadceased to exist).2.5CompositionFigure 2.5 Class Hierarchy of a University, Building and RoomCo mposition is a specialised form of Aggregation where the “contained” object is a fundamental part of the “container” object, and that if the “container” is destroyed, allthe objects that are related to it with a composition are similarly destroyed. An example of this is shown in Figure 2.5 between the new Room class and the Building class. The line here has a solid diamond, indicating that the relationship is a composition. The multiplicity states that a building will have 1 or more rooms (since even an empty building can be thought of as one giant room) and that a room will be contained within1 building only. This reflects the real world makeup of rooms and buildings. If a building is destroyed then the rooms within it are also destroyed.Any system that implements this design will know that if a Building object is destroyed, any Room objects that are contained within that particular instance will also be destroyed.2.6SummaryFigure 2.6 Class diagram showing some of previous classes and their relationships The previous sections should have provided you with a basic understanding of what a class hierarchy is and how this can be represented on a class diagram. Figure 2.6 shows some of the classes from the previous sections (along with two extra sub-classes of Room), and how the separate diagrams in Figure 2.3, Figure 2.4 and Figure 2.5 all relate to each other. It should be clear that the system could be extended further to incorporate more details about the University system such as timetables for studentsand staff or the computing facilities available in each room. Both of these examples would make use of the existing classes by association along with the introduction ofnew classes.These fundamentals of the class system are essential in the understanding of the CIM as described in the following sections.3 The Common Information Model for Power SystemsThis section provides some history of the CIM and how it represents the common components within a power system. Examples are given to show where a common power system component fits into the class hierarchy, how connectivity is represented using CIM classes and how an example circuit, shown as a line diagram, can be converted to CIM objects. Finally, each of the packages in the IEC 61970-301 standard is summarised.3.1HistoryExchanging power systems data between utility companies is always problematic when proprietary formats are used. In the past, a company would traditionally use a single software system, whether it is a custom in-house solution, or purchased from a large software company, and there would be a single proprietary data standard and format used. With the deregulation of the power industry both in the UK and abroad, there is now a greater need to be able to share such power system data between companies. The increase in choice provided by the number of power system software vendors, and the different software packages and architectures available add to the challenge of data exchange. These issues point to a requirement for a single, open standard for describing power system data and to aid the interoperability between software packages and exchange of information both within one company and between companies.The Common Information Model (CIM)[1][2] is an open standard for representing power system components developed by the Electric Power Research Institute (EPRI) in North America. The standard was developed as part of the IEC TC57 WG13 on developing a Control Centre Application Programming Interface (CCAPI) to provide a common model for describing the components in power systems for use in a common Energy Management System (EMS) Application Programming Interface (API). The format has been adopted by the major EMS vendors to allow the exchange of data between their applications, independent of their internal software architecture or operating platform.The data model itself is language-independent, defining the components of a power system as classes along with the relationships between these classes: inheritance, association and aggregation; and the parameters within each class are also defined. This provides the foundation for a generic model to represent all aspects of a power system, independent of any particular proprietary data standard or format. This simplifies the interoperability between software applications, since there need only exist a translator to convert to and from the CIM based data, where previously there would have been the need for translators to convert to a nd from every other third party company’s proprietary format.For an engineer the format of the Common Information Model (CIM) may at first appear confusing compared with a flat file format. This paper will explain how the CIM was created using a class structure to describe components of a power system network; the advantages of this approach; and how a power system network model can be translated into a number of CIM objects.3.2CIM Class StructureThe CIM hierarchy currently has no official common super-class (i.e. a class from which every component inherits). The majority of CIM classes, however, inherit from the IdentifiedObject class so for this section it can be considered the base class for the hierarchy.3.2.1 Example: The Breaker ClassA simple example will be used to explain why it is advantageous to use a class structurefor defining components instead of simply specifying attributes for every different typeof component in the CIM as an independent entry.A Breaker is one of the most common components in a power system described as a “mechanical switching device capable of making, carrying and breaking currents undernormal circuit conditions and also making, carrying for a specified time, and breakingcurrent under specified abnormal circ uit conditions”[1]. To understand how this fitsinto the CIM class hierarchy the Breaker can be thought of at different levels of abstraction.At the most detailed level it is a Breaker, but since a breaker’s most basic functionality isthe ability to be open or closed it can be described as a specialised type of switch. Withinthe power system a switch is part of the physical network that conducts electricity, andas such can be considered a type of conducting equipment. Since the power system may contain equipment that does not conduct electricity directly, conducting equipment canbe considered a type of generic equipment. A piece of equipment can similarly be considered as a being resource within the power system.A Breaker can therefore be considered to be a Power System Resource, a type of Equipment, a type of Conducting Equipment and a type of Switch. This corresponds toa class inheritance structure shown in Figure 3.1 below.Figure 3.1 Breaker Class Inheritance HierarchyThe Naming class is the root class for this particular branch of the CIM class hierarchy and other CIM classes in the Breaker hierarchy are:▪ PowerSystemResource, used to describe any resource within the power system, whether it be a physical piece of equipment such as a Switch or an organisationalentity such as a SubControlArea.▪ Equipment, which refers to any piece of the power system that is a physical device, whether it be electrical or mechanical.▪ ConductingEquipment, used to define types of Equipment that are designed to carry current or that are conductively connected to the network and contains anattribute to denote the phases (A,B,C,N or any combination of each).▪ Switch, a generic class for any piece of conducting equipment that operates as a switch in the network and hence has an attribute to define whether the switch isnormally open or closed.▪ ProtectedSwitch, a switch that can be operated by protection equipment▪ Breaker, a specific sub type of ProtectedSwitch, with additional attributes to define the current rating and transit time.As with the University system example in Section 2, all subclasses inherit the attributesfrom their parent class, and as such a Breaker will contain a normalOpen, from theSwitch class, and phases attribute, from the ConductingEquipment class, as well as itsown native attributes.3.2.2 Subclasses of SwitchAs well as Breaker, the CIM standard contains multiple subclasses of Switch, including Jumper, Fuse, Disconnector, LoadBreakSwitch and GroundDisconnector.Figure 3.2 Switch class with Breaker and LoadBreakSwitch subclassesFigure 3.2 shows an example of how the LoadBreakSwitch class, a subclass of ProtectedSwitch fits into the class hierarchy. Both Breaker and LoadBreakSwitch inheritfrom ProtectedSwitch which in turns inherits from Switch, so they both contain a normalOpen attribute whilst maintaining their own, internal attributes.As well as dealing with them as their native class, the system can treat a Breaker or LoadBreakSwitch component as being a ProtectedSwitch, Switch, a piece of Conducting Equipment, a piece of Equipment, a Power System Resource or just an IdentifiedObject. For example:If a piece of software is performing a topological analysis on a power system networkthen it will need to know whether a switch is open or closed to determine the status ofthe network. The software does not need to know whether the Switch is a Breaker, a LoadBreakSwitch or any other subtype of Switch since the attribute it is concerned with, normalOpen, exists in all the classes that inherit from Switch. As the software traverses the network model, if the component it reaches is of the class Switch or any of its subclasses it extracts the value of normalOpen and proceeds accordingly.Figure 3.3 Switch Class diagram with new subclasses of Switch and BreakerIf a new type of Switch, NewSwitchType is added to the standard at a later date as shown in Figure 3.3, assuming the original Switch class is not modified, then the software will still be able to treat NewSwitchType as if it were a Switch when performing its analysis. Even though the class did not exist when the software was originally written it is looking for any components that are of a class that inherits from Switch.Similarly, if a new subclass of Breaker, NewBreakerType, is added (as shown in Figure 3.3), it is still a type of Switch (since its parent class, Breaker is a subclass of ProtectedSwitch which itself is a subclass of Switch) and can be treated as Switch, ProtectedSwitch or a Breaker by the software.As has been shown, this use of an inheritance hierarchy to define components allows classes within the system to be defined as specialised subclasses of a general parent class until the desired level of detail has been reached, from the generic PowerSystemResource right down to the Breaker or LoadBreakSwitch class.This use of a class hierarchy also allows extensions to be made to the standard by extending the existing classes instead of introducing completely new, independent entries. This approach, as shown, can allow existing software applications to interpret the new data, albeit at a higher level of abstraction, without necessarily requiring extensive modification.3.2.3 Defining Component InterconnectionsWhen defining how components within a power system network join together, rather than define direct connection between components, the CIM uses Terminals and Connectivity Nodes.To understand why this approach is taken consider the very simple, circuit shown inFigure 3.4 below.Figure 3.4 Connectivity Example circuitThis circuit, containing a Breaker, Load and Line, would require three CIM Objects to represent the pieces of physical conducting equipment: An Energy Consumer (to represent the load), a Breaker and an AC or DC Line Segment for the line.The CIM does not model interconnections by associating each component with the other components it connects to, since having Breaker 1 contain associations to Load A andLine Alpha; Load A contain associations to Line Alpha and Breaker 1; and Line Alpha contain associations to Breaker 1 and Load A would result in the interconnections being defined as shown in Figure 3.5.Figure 3.5 Connectivity Example circuit with direct associationsInstead, the CIM uses a Connectivity Node to connect equipment, so that should threeor more pieces of equipment meet at a T or Star point, the connectivity is accurately represented as shown in Figure 3.6.Figure 3.6 Connectivity Example circuit with Connectivity NodeIn CIM, however, pieces of conducting equipment are not directly associated with Connectivity Nodes. A piece of conducting equipment will have one or more Terminals associated with it, and these Terminals in turn are associated with a single Connectivity Node.。
IEC 61970、61968公共信息模型及其应用方式_14
2021/7/12
OGC标准
GML （地理标记语言）
WFS（要素Web服务） WMS（地图 Web 服务） WCS（栅格 Web 服务 ）
4
从统一视角看IEC 61970、61968 CIM
公共信息模型
CIM 是一个抽象的模型，描绘典型情况下电力 信息化应用系统信息模型中所包含的电力企业 所有主要对象，这是许多应用程序都需要的
—员工才艺秀：加强员工互动，展现员工风采
标准是允许扩充和修改的，而且规定了一些规则
想要修改的话，一定要首先论证清楚是否真正需要修 改
要考虑好修改可能带来哪些负面影响 在标准的应用中遇到具体的问题时，不能简单地说行或者不行
应该明确地描述所遇到的问题，用用例规格说明提出问题，然 后研究信息模型以得到一个合理的解释，确定是否需要修改或 扩展
2021/7/12
23
资源、资产与文档
描述信息的管理－文档
2021/7/12
24
其他CIM包
Work：工作包 Customer：消费者包 InfERPSupport：ERP支持包 Finacial：财务包 InfGMLSupport：GML支持包
2021/7/12
25
主题
61970、61968 CIM总体介绍 CIM应用于EMS、DMS系统 CIM对GML的融合 CIM的应用方式
2021/7/12
36
扩展CIM的原则
将采用从简单到复杂的扩展策略：
向一个类已有的属性中增加附加值 向已有的类中增加属性 增加新的类，此类是已有类的特例 增加新的类，关联到已有的类
其主要目标就是最大可能地重用现有的CIM。从 封装的角度来看，现有的包都应当可以扩展。如 果扩展包括了新的应用领域，那么就应当考虑对 增加的内容建立新的包，但仍然建立与现有的包 之间的必要关联。
基于iec61970的电力数据持久化与重构的研究
iec61970标准系列简介
iec61970标准系列简介
IEC 61970标准是一系列国际电工委员会（IEC）发布的电力
系统自动化标准，旨在提高电力系统的性能，安全性和可靠性。
IEC 61970标准主要涵盖电力系统的自动控制，设备监控，故
障诊断，设备管理和设备保护等方面。
它还涉及电力系统的控制，设备和网络的组织，信息交换，通信和数据处理等。
IEC 61970标准还包括对电力系统的安全性，可靠性和可操作性的
要求。
IEC 61970标准的实施将有助于实现更高效的电力系统，更安全的电力系统，更可靠的电力系统，更灵活的电力系统，更有效的电力系统管理，更高效的设备管理，更安全的设备保护，更可靠的故障诊断，更高效的通信和数据处理等。
IEC_61970系列标准介绍
2.4 CIM包
• 由于整个 CIM 很大，为了便于管理，CIM 的开发者把 CIM 中的类和类图组织为几个逻辑包（Package） –一个包表示要建模的整个电力系统的一个特定部分
• 往往对应某些应用范围
– Cim10_030501 包含 13 个逻辑包
• 257 个类 • Domain 包 118 个类 • 其余 12 个包 139 个类
1.5 61970目前的进展情况
• IEC标准的状态流程如下：
– WD(工作组草案) – CD(委员会草案) – CDV(委员会投票草案) – DIS(IEC标准草案) – FDIS(最终IEC标准草案) – IS(IEC标准)
标准编号
标准名称
最新版本
最新时间
61970-1
61970-2 61970-301 61970-302 61970-401 61970-402 61970-403
标准的意义：节省时间和金钱
• 标准化的目标之一就是使设计和生产更简单、更清晰、更 可靠 • 使用标准，你可以不必每次重复开发，而是将精力专著于 改进质量，促进技术进步 • 通过以下几个方面使应用和系统间的互操作所花精力最小
– 语义 – 语法 – 服务
• 标准化的知识将帮助研究和发明正确的技术 • IEC工作组的工作，会让人们了解到很多新的、有价值的 想法，从而避免犯大的错误
1.3 为什么需要IEC 61970？
• IEC 61970目的就是推动：
– 由不同厂商开发的EMS应用的集成； – 独立开发的完整EMS系统之间的集成； – EMS系统与有关电力系统运行的其他系统之间的集成， 例如发电或配电管理系统。
• IEC 61970使EMS的应用软件组件化和开放化：
IEC61968、61970简介说课讲解
PowerSys tem Res ource
(f rom Core)
1 +PSR
+ConductingEquipment 1 ConductingEquipm ent
(f rom Core)
+SwitchingOperations 0..n SwitchingOperation 0..n
20
Financial 包
21
财务包支持结算和帐单。 这些类代表了在正式或非正式协定中出现的实体。
OpenAcces s Product
ContractOrTariff
0..* OfferedBy
Offers
PowerSys tem Res ource
Contains
(from Core)
0..* Memb erOf
6
组成部分
第405部分：通用事件和订阅（GES） 第450部分：信息交换模型 第451部分：SCADA CIS 第452部分：CIM模型交换服务 第501部分：CIM资源描述框架（RDF）模式 第502部分：CDA CORBA映射 第503部分：CIM XML模型交换格式
7
CIM建模表示法
CIM 用面向对象的建模技术定义。 具体地说，CIM规范使用统一建模语言(UML)表达方 法 将CIM定义成一组包，每一个包包含一个或多个类图， 用图形方式展示该包中的所有类及它们的关系。 根据类的属性及与其它类的关系，用文字形式定义各 个类。
12
拓扑包 (Topology)
这个包是Core包的扩展 它与Terminal类一起建立连接性（Connectivity）的 模型，而连接性是设备怎样连接在一起的物理定义。 另外，它还建立了拓扑（Topology）的模型，拓扑是 设备怎样通过闭合开关连接在一起的逻辑定义。拓扑定 义与其它的电气特性无关。
输变电设备状态监测统一信息接口技术规范(~
华东电网有限公司企业标准Q/GDW-08-J×××-2010输变电设备状态监测统一信息接口技术规范（征求意见稿）2010-XX-XX发布 2010-XX-XX实施 华东电网有限公司标准化工作委员会发布目录1 范围 (3)2 引用标准（Normative References） (3)3 定义（Definitions） (3)4 缩写（Abbreviations） (4)5 输变电设备状态检测信息接口 (5)5.1 IEC TC57名字空间 (5)5.2 公共服务 (7)5.2.1 资源标识服务 (7)5.2.2 资源描述服务 (8)5.3 通用数据访问（GDA）服务 (8)5.3.1 GDA读访问 (8)5.3.2 GDA写访问 (8)5.3.3 GDA事件 (9)5.3.4 GDA 服务顺序图示例 (9)5.4 高速数据访问（HSDA）服务 (10)5.4.1 信息模型 (12)5.4.2 接口功能 (13)5.4.3 HSDA服务请求顺序示例 (14)5.5 基于名字服务的对象实现 (19)1范围本规范适用于华东电网应用IEC 61970系列标准的输变电设备状态检修系统的开发、设计、测试、应用等。
本规范规定了变电站输变电设备在线监测系统在应用IEC 61970系列标准时系统接口的规范性，并规定了在实际应用中进行信息接口时应遵循的原则等。
2引用标准（Normative References）下列标准所包含的条文，通过在本标准中引用而构成为本标准的条文。
本标准出版时，所示版本均为有效。
所有标准都会被修订，使用本标准的各方应探讨使用下列标准最新版本的可能性。
61968 电力企业的应用集成－配网管理系统接口TC57IEC61970 电力企业的应用集成－能量管理系统接口IECTC573定义（Definitions）公司（Company）：公司是一个拥有和运行电力系统资源的合法实体。
61970系列标准CIS部分介绍详解
Part 5xx: CIS Level 2: 将4xx规范映射到具体实现技术的规范
(4) CIS目前的状态
Part 401~449:通用服务
– Part 401,402,403,404,405,407已经基本涵盖了电力应用信息交
换所需的接口 – 目前尚未完善 – 是目前工作组的工作重点
Part 451~499:IEM
– Part 450-499： WHAT:交换什么
3.2 CIS Level 1
由于许多组件接口服务为多个应用类型 所共需，通用服务的定义与使用它们的 应用之间应保持独立。
– 通用服务组织在一个系列中 401~449 – 使用这些服务的特定应用及其交换的信息内
容则组织在另一个系列中 450~499
数据访问示意图
测试举例
测试举例
测试举例
GDAFilteredQuery
由于和DAFQUERY大部分功能相似，不同之处增 加了筛选条件，如： ResourceDescriptionIterator get_filtered_extent_values( in PropertySequence properties, in ClassID class_id, in CSPropFilters propertyFilters ) 功能：读取某一类中按照某些域（非关联域）筛选后 得到的所有记录的相关属性列的信息。 输入：欲读取记录的类ResourceID（class_id）,欲读取 的相关列的信息PropertySequence，筛选条件 propertyFilters。关于CSPropFilters主要内容如后图。 输出：该类所有记录相关列的信息的一个指针。 异常：UnknownResource, QueryError。