【电力行业标准(DL)】 能量管理系统应用程序接口(EMS-API) 第401部分：组件接口规范(CIS)框架

ICS27.100
备案号：19442-2007
中华人民共和国电力行业标准化指导性技术文件DL/Z 890.401 - 2006 /IEC 61970- 401 TS:2005能量管理系统应用程序接口（EMS-API）第401部分：组件接口规范（CIS）框架Energy management system application program interface (EMS-APD) Part 401: Component interface specification (CIS) framework(IEC61970-401TS:2005,IDT)
2006-12-17发布
2007-05-01实施
中华人民共和国国家发展和改革委员会发布
规范性引用文件，
3术语和定义
基于组件的接口
：4.2DL890.4XX的文件结构..
通用API服务标准概述
5.1通用服务的目标
5.2已有标准的使用
5.3EPRIGID.
5.4.DL890通用服务与现有标准和GID的关系附录A（资料性附录）
参考文献
组件使用的API
DL/Z890.401—2006
DL/Z890.401—2006
本标准是根据《国家发展改革委办公厅关于下达2004年行业标准项目计划的通知》（发改办工业［2004］872号）的安排制定的。DL890标准是采用IEC61970《能量管理系统应用程序接口（EMS-API)》制定的，主要包括公共信息模型（CIM）和组件接口规范（CIS）两方面内容，由以下部分组成：DL/T890.1能量管理系统应用程序接口（EMS-API）第1部分：导则和一般要求；DL/T890.2能量管理系统应用程序接口（EMS-API）第2部分：术语；DL/T890.301能量管理系统应用程序接口（EMS-API）第301部分：公共信息模型（CIM）基础；DL/T890.302能量管理系统应用程序接口（EMS-API）第302部分：公共信息模型（CIM）财务、能量计划和备用。
DL890标准还有DL890.4XX和DL890.5XX两个子系列。前者规定了接口的功能需求，后者描述了实现这些消息的特定技术。每一子系列包括若干部分，各部分的编号及名称还没有最终确定。参见本部分的4.2。
本部分等同采用IEC61970-401TS：2005《能量管理系统应用程序接口（EMS-API）第401部分：组件接口规范（CIS）框架》（英文版）。IEC61970-401TS不是标准，而是技术规范，因此，本部分也不是标准而是标准化指导性技术文件。本指导性技术文件仅供参考。有关对本指导性技术文件的建议和意见，请向中国电力企业联合会标准化中心反映。
本部分的附录A是资料性附录。
本部分由中国电力企业联合会提出。本部分由全国电力系统管理及其信息交换标准化技术委员会归口并负责解释。本部分起草单位：中国电力科学研究院、国网南京自动化研究院、山东大学。本部分主要起草人：潘毅、周京阳、张慎明、陈道元、曹阳、云昌钦、李晓露、刘崇如。I
DL/Z890.4012006
DL890标准采用IEC61970国际标准。IEC61970标准定义了能量管理系统（EMS）的应用程序接口（API)，目的在于便于集成来自不同厂家的EMS.内部的各种应用，便于将EMS与调度中心内部其他系统互联，以及便于实现不同调度中心EMS之间的模型交换。将该国际标准转化为我国标准并贯彻执行，对于实现异构环境下软件产品的即插即用，使EMS与其他系统能互联、互通、互操作显然会有很好的作用。
本指导性技术文件是DL890.4XX中的一部分。DL890.4XX规定接口的功能需求，即一个组件（或应用）应实现以一种标准的方法与其他组件（或应用）交换信息和/或访问公共的可用数据。这些组件接口描述了应用可以为此目的而使用的特定的事件类型和消息内容。本部分为第1级（技术无关）功能需求文件的规范提供了一个框架。框架中，这些规范分为两组：第一组定义了组件用来同其他组件交换信息或访间公共数据的通用服务，本部分给出了这些通用服务的概述和文档编排；另一组定义了组件或系统与其他组件交换消息的信息内容，DL890.450给出了这一组的概述。
这些组件接口规范涉及DL890.3XX系列（包括DL/T890.301）中定义的电力系统域实体对象。m
1范围
DL/Z890.4012006
能量管理系统应用程序接口（EMS-API）第401部分：组件接口规范（CIS）框架:
DL890的本部分规定了能量管理系统应用程序接口（EMS-API）组件接口规范（CIS）的规范框架。CIS规定了一个组件（或应用）为了用标准的方式与其他组件（或应用）交换信息和/或访问公共可用数据所应该实现的各种接口。
\：DL.890的第1部分给出了作为本标准基础的EMS-API参考模型。它介绍了本标准使用的术语并解释了CIS的作用。
本部分提供了第1级功能需求文件规范的框架。在框架中这些规范分为两组：第一组定义了组件用来同其他组件交换信息或防问公共数据的通用服务；另一组定义了组件或系统与其他组件交换消息的信息内容。
本部分也给出
CIS标准包括的功能的总览。这些功能作为一套通用服务用文本叙述条款、统一建模语言（UML）
描述。这些通用服务可以被任何应用用于与另一个独立开发的应用或系统交换信息以符号
及访问公共数据。
这些通用服务规定了应用为实现此目的所能够使用的特定的事件、方法和性质。这些规范定义了任何应用之间交换信息或访问公共数据的通用服务。它还提供了路线图来解释DL890.4XX部分每个所结合的基础工业实际标准
规范的内容以及
另一个系列D
L890.5XX部分描述了DL890.4XX部分在实现中与特定技术的映射。为了保证互操作性，每个接口对每+种技术必须有标准的映射。如果选择Java作实现技术，就需要使CIS文件中规定的发布/计阅服务和Java服务之间有一种标准的映射2规范性引用文件
下列文件中的条款通过本部分的引用而成为本部分的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本部分，然而，鼓励根据本部分达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本部分。DL/T890.1能量管理系统应用程序接口（EMS-API）第1部分：导则和一般要求DL/T890.2．能量管理系统应用程序接口（EMS-API）第2部分：术语公用事业管理系统（UMS）数据访问设施（DAF），OMG采用的规范版本2.0，正式/2002-11-08（以下简称“OMG文件1\）
工业系统数据采集规范（DAIS），OMG采用的规范版本1.0，正式/2002-11-07（以下简称“OMG文件2”）
工业系统历史数据采集规范（HDAIS），：OMG采用的规范，dtc/2003-02-01（以下简称“OMG文件3\)
OPC数据访问接口规范，2.05版，OPC文件：opcda205_cust.doc，OPC基金会，2000-12-17（以下简称“OPC文件1”）
OPC告警与事件接口规范，1.02版，OPC文件：opcae102_cust.doc，OPC基金会，1999-11-02（以下简称“OPC文件2”）
OPC历史数据访问接口规范，1.1版，OPC文件：opc_hist_cust.doc，OPC基金会，2001-01-26（以下简称“OPC文件3\
DL/Z890.401—2006
3术语和定义
DL890.2中的术语和定义适用于本部分。4基于组件的接口
4.1概述
将来的DL890.4XX系列规定了一个组件（或应用）以一种标准的方式与其他组件（或应用）交换信息和/或访问公共可用数据所应该实现的接口。这些组件接口描述了应用为此目的所能够使用的特定的事件、方法和性质以及交换的信息内容。CIS的目的是规定应用或系统所使用的接口，·从而可以方便地与其他独立开发的应用或系统集成。EMS-API项目的部分内容是要明确典型的应用和组件°，其目的并不是要定义组件本身，而是帮助定义需要传输的信息类型。组件厂商应能自由地将不同的组件接口包装到组件包里，同时还保证满足DL890标准。
对基于消息的信息交换来说，CIS的主要目标是规定在两个或更多的应用之间进行交换的信息内容，以及用什么服务来传递这些消息。对于新的应用说来，允许被开发的应用预先知道什么信息在处理时是可用的和如何使用这些信息，以及接收的应用期望获得什么样的信息和如何获得这些信息。对于现有系统的集成来讲，CIS能实现以给定的基础技术构建单一的且不依赖于其他系统开发商的适配器。
4.2：DL890.4XX的文件结构
既然很多组件接口服务是多种应用类型共同需要的，那么服务的定义应当看作是通用的服务而不依赖于它的特定应用。因此，这些通用服务被编排在一个标准系列中，而使用这些服务的特定类别的应用，以及特定应用使用这些服务所交换的信息内容被编排在另外一个标准系列中，具体如下：a）DL890.401部分：CIS框架—该文件给出了CIS系列标准的总览，并解释了在系统实现和系统集成项目中怎样应用这些标准。b）将来的DL890.402到449部分：这些部分规定组件接口支持的通用服务。这些规范用文本叙述条款、统一建模语言（UML）描述标准化的接口功能。这些规范定义了任何应用之间用来交换信息或访问公共数据的通用服务。c）将来的DL890.450部分：CIS信息交换模型规范指南一—该文件提供了定义信息内容的使用案例过程的总概及用CIS标准进行系统集成的例子。同时也提出了将来的DL890.451到499规范的公共需求。
d）将来的DL890.451到499部分：这些将来的部分保留用来规范DL890.1中定义的典型应用类别的特定信息交换需求。这些规范定义了应用之间标准信息交换的信息内容。这些信息内容定义为一些事件，但是，可以用多种方式交换，包括作为消息发布、作为紧随一个请求的通知、或者作为一个XML文件。如果需要，每个接口所支持的特性和方法也可以定义。相关的支持文档包括应用案例图和事件序列图。根据应用类别预想的交换类型，可以规定一些特定的通用服务以确保不同厂家开发的组件之间的互操作性。应用这些标准的意图是确保互操作性的同时，在选择用于实现信息交换的中间件上尽可能地灵活。
对于每种应用类型，信息内容用信息交换模型（IEM）描述。0见IEC61970-1中列举出的在EC61970标准范围内典型应用和系统的列表和描述。2
5通用API服务标准概述
5.1通用服务的目标
DL/Z890.401-2006
本章给出了DL890.4XX包含的通用服务的概述。这些通用服务的基本目标是：a）：减少企业应用集成所需的工作：这些通用服务是对主要的软件工业新技术的补充，例如Java连接架构、W3C的Web Services相关建议以及微软的.Net架构。这些规范的目的就是使这些通用技术能更方便、快捷地用于企业环境中。b）将应用与底层的中间件技术分离：这样就可以使满足标准的软件组件用于不同的中间件技术，如消息代理甚至数据库。另外，它还可以保证在系统已建成或运行后，如果由于某种原因底层的中间件技术需要被替代或扩展，应用环境受到的影响可降到最低限度。c）可充分利用CIM的优点：很多API都不包含统一数据模型概念。例如，许多API仅将数据表示成一组记录而没有明确它们之间的关系。但CIM提供了一个框架，使得每个单个记录，如维修命令，可以与整个电力系统模型相关联。d）限制创建过分详细的为应用专用的API：为减少集成者/程序员需熟悉的API的数量，：也为了减少控制中心底层提供者需完成的维护工作量，这里只提供有限的API。其目的是定义一套数据交换机制，对于所有应用都是公共的，而且足够满足所有预想的应用的需求。e）防止不兼容的控制中心API：程序员喜欢使用一致的且易于使用的API。本部分的.API不包括这些内容，但提供编程模型作为所有API的补充。5.2已有标准的使用
5.2.1概述
通用服务都基于已有的国际或工业标准，以满足扩展的可能性。特别是这些服务基于5.2:2和5.2.3中描述的标准。
OPC是一种基于微软.OLE（现行的ActiveX）、COM（组件对象模型）和DCOM（分布式组件对象模型）技术的工业标准。OPC（最初用于过程控制的OLE）包括用于过程控制和自动化制造业应用的接口、特性和方法的一整套标准。ActiveX/COM技术定义了各个软件组件怎样相互作用和共享数据。OPC提供公共接口以便与不同的过程控制设备通信，不论过程的控制软件或设备是什么。
管理这一标准的组织是OPC基金会。该基金会在全世界拥有300多名成员，包括世界上几乎所有主要的控制系统、仪器和过程控制系统的生产商。他们的宗旨是基于微软COM、DCOM和ActiveX技术的功能需求，开发一套开放的可以互操作的接口标准，以促进自动化与控制的应用、现场的系统与设备，以及商务与办公应用间的更广泛的互操作。OPC规定了很多函数类型的API，但只有一些特定部分可以被DL890标准引用。总的来说，直接可用的API是那些为客户端提供服务的部分：订阅量测数据；
订阅报警和事件；
获取和设置保留在文档中的历史数据。包含在通用服务中的特定API有：a）数据访问（DA）自定义接口规范：一种OPC标准，定义了用来读写带质量和时间标识的数据的一些对象，包括一个服务端，一个组和一个项（见OPC文件1）。OPC的服务端对象保留了服务端的信息并作为OPC组对象的一个容器。OPC的组对象保留它自已的信息并提供一种机制来包含和从逻辑上组织OPC各数据项到一个数据集。OPC的数据项与数值、时标和质量等属性关联。
DL/.Z890.401—2006
b）报警和事件（AE）自定义接口规范：一种OPC标准，定义了规定的事件和报警情况发生时通知OPC客户端的机制。AE还提供一些服务，允许OPC客户端确定OPC服务端支持的事件和条件，并获取其当前状态（见OPC文件2）。c）历史数据访问（HDA）自定义接口规范：一种OPC标准，定义了访问数据值时间序列的些对象。HDA包括同步、异步读写时序数据以及订阅更新和回放数据的方法（见OPC文件3)。
其他的OPCAPI通过它们被用在5.2.3中所提及的OMG标准而被间接地包含进来。在将来的DL890.4XX标准中将规定一些包含OPC标准的通用服务；而且会提出一些具体的参考文献。5.2.3:OMG
OMG（对象管理组）成立于-1989年，通过引入标准化的对象软件来建立基于组件的软件市场，目前由世界各地大约800名成员组成，实际上包括了计算机领域的所有大公司和上百家小公司。它的宗旨是建立工业导则和详细的对象管理规范，以便为应用的开发提供公共框架。满足这些规范就意味着它可能开发出异构的计算环境，跨越所有主要硬件平台和操作系统。目前，在世界上很多操作系统中可以找到OMG规范的使用。OMG系列规范详细描述了分布式对象计算必需的标准接口。它的网络协议IOP（因特网ORB间协议）正在被许多技术公司作为底层基础结构使用，如Netscape、Oracle、Sun、IBM和其他上百家公司。
OMG将对象管理定义为软件开发，可以通过“对象”描述对现实世界建模。这些对象是软件可识别的程序组件的属性、关联和方法的封装。面向对象系统的主要优点是功能可以扩展，可以扩展现有组件并增加新的对象。对象管理的结果是应用开发快捷，维护简便，可伸缩性很大，以及软件可以重用。OMG规范原来必须基于CORBA技术（公共对象请求代理体系结构）。但OMG认识到了中间件独立的重要性。因此，现在OMG的基础规范都是多平台的模型驱动结构（MDA）。在MDA中，一个规范开始于用UML定义的独立于平台的模型（PIM)，然后，基于MDA的开发工具将在不同平台上产生特定平台的模型以及实现定义。这使MDA支持应用的可移植性和互操作性，可以跨越广泛的中间件平台，并可以将OMG扩展到CORBA范围外的其他平台，如企业Javabeans（EJB），XML/SOAP（可扩展的标记语言/简单对象访问协议），.Net等。有了这种变化，OMG的标准化部分将是UML，而映射到至少一个特定目标［称为协议集，例如XML（可扩展的标记语言元数据交换）的XML，CORBA，Java，EDOC（企业中间件），可能还有.Net（尚未确定）的规则将被规定为另一个OMG标准。通过引用包含在将来的DL890.4XX.标准中的具体的OMG规范有以下几种：a）UMS（公共事业管理系统）DAF（数据访问工具）：一种OMG标准，提供面向对象的对元数据和实例数据的只读访问（见OMG文件1）。它提供：基于CIM的接口，用于导航和获取（只读）储存在EMS中的数据，包括分析的输入数据，分析结果和物理模型数据；
-这些数据变化的粗略的通知；
一简单的交易支持以便读取一组首尾一致的数据。b）DAIS（工业系统的数据采集）：一种OMG标准，提供从一个工业过程（如SCADA系统或EMS）向多个客户端（见OMG文件2）实时有效地传输大量数据的API接口，支持参数的查询和参数数值的更新。
DAIS扩展了OPC，使得OPC更兼容DAF并能满足信息模型（如CIM）（见OMG文件2）。这种扩展允许OPC不加改变就作为微软环境的一个兼容子集使用。因此，OPC的数据访问和OPC的报警和事件接口可以称为DAIS的微软COM定制产品。HDAIS（工业系统的历史数据访问）：一种新出现的OMG规范，提供对历史数据的访问（见c）
OMG文件3），包括：
查找可用的历史数据类型；
查找历史数据所记录的对象数量；查找可用的累计计算值；
-访问记录的或计算的数据；
订阅记录的数据。
DLYZ890.4012006
HDAIS力图扩展DAIS，使其具有与OPC的历史数据访问标准相似的功能（见OMG文件3）。5.3EPRIGID
GID（通用接口定义）提供了一套用于应用软件数据访问和与其他应用交换信息的API（参考文献1）。它建立于现有的接口标准，提供增加的功能和裁剪以适应处理企业运行的应用的需求。这些API不依赖于应用，因此它们被看作是所有应用之间通用的和公共的（所以叫GID）。通过使用GID，系统集成者或软件开发者能够构建不同的软件组件而避免必须开发软件来满足多种和可能相冲突的编程模型。
GID的开发是由EPRV控制中心应用程序接口（CCAPI）项目提出的。GD规范通过一种建议请求（RFP）过程得到，R印P程已被CCAPI工作组采纳。该过程要求所有感兴趣的参加者针对CCAPI工作一个规范。本部分的课题GID规范就是从提交的获胜者中产生的。组提供的技术需求提交一
GID定义了以类接口：公共数据访问、方法调用、事件生成，以及接口声明和查找。它建立于以上现行API工业标准
特别是OMGDAF，DAIS，和5.2描述的OPCAPI。GID通过定义以下名字、主题过滤、发布/订阅和数据更新等新的服务扩展了这些标准a）IECTLL备字空间模块：信息模型通过OPC或DAIS接口进行描述的一种机制；b）通用的事件和订阅（GES)：OPC/DAIS简单事件的扩展，允许组件更有效地发布/订阅与元数据和复
对象（如量测、报警或工作流程）的数据变化相关的记录；c）公共数据访问（GDA）模块：DAF的扩展，包括写/编辑元数据、实例数据以及细致的查询和事件的能力
d）GDA过滤模块：属性值与已知量进行比较的一e）公共服务
接和交易模块：
种机制；
该组件支持没有使用组件
件执行系统的服务。
隐含在GID后面的主要概念是现有接口能作为应用程序族的接口而通用。实际上，“GID”是一个总的术语，代表着DL890.4XX部分定义的所有接口（402449），尽管开始的EPRIGID只局限于DL890的402～407部分。
5.4DL890通用服务与现有标准和GID的关系5.4.1概述免费标准下载网bzxz
在这些OMG和OPC标准基础上编制将来的DL890.4XX标准的具体方法是将来的DL.890.402到449部分的主要内容，这些部分预留着用来规定前面解释的那些服务。图1用图形的方式说明在出版时定义的每一部分和底层OMG与OPC标准的关系。每一部分包括了整个通用服务的一个不可再细化的子集。虽然任何具体组件使用哪部分的服务是设计选择问题，但是，遵循这个技术规范就需要完全实现将来的DL890.402部分规定的公共服务（在下面解释），加上一个或多个其他部分（将来的DL890.403～449部分）规定的服务。
以下各条给出了每个通用服务标准文档内容的概要。附录A给出了组件使用这些通用API的示例。5.4.2将来的DL890.402：公共服务将来的DL890.402包含的API服务是基本的服务，而且是任何遵从将来的DL890.4XX标准的组件所需要的。这些基本服务包括以下内容：a）命名：IECTC57名字空间使CIM可以通过OPC或DAIS接口呈现的一种机制，它本质上是如①任何类似于CIM的信息模型都能用这种机制描述成一种接口。5
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。