DLT890.1-2007能量管理系统应用程序接口(EMS-API)第1部分导则和一般要求(非正式版标准内容仅供参考).pdf 31页

'DL/T890.1—2007ICS27.100F20备案号：22290-2008中华人民共和国电力行业标准DL/T890.1—2007/IEC61970-1:2005能量管理系统应用程序接口（EMS-API）第1部分：导则和一般要求Energymanagementsystemapplicationprograminterface(EMS-API)−Part1:Guidelinesandgeneralrequirements(IEC61970-1:2005,IDT)2007-12-03发布2008-06-01实施中华人民共和国国家发展和改革委员会发布I DL/T890.1—2007目次前言·······································Ⅱ引言·······································Ⅲ1范围······································12规范性引用文件·································13术语和定义···································14系统集成····································14.1集成场景···································14.2集成考虑···································24.3基于组件的接口································34.4与IEC61968标准的关系····························45EMS-API参考模型································55.1概述·····································55.2控制中心环境·································55.3应用上下文··································65.4应用·····································65.5组件·····································65.6遗留应用和封套································65.7组件模型···································75.8组件容器···································75.9组件适配器··································75.10组件执行系统································85.11中间件···································85.12通信协议子集································95.13参考模型应用举例······························96EMS-API标准··································106.1概述·····································106.2CIM·····································106.3CIS·····································126.4CIS技术映射·································127通常需要的基础设施功能·····························137.1概述·····································137.2组件容器···································137.3中间件····································147.4通信协议子集服务·······························147.5电力企业特定的服务······························14附录A（资料性附录）组件模型···························15附录B（资料性附录）典型应用和功能························18附录C（资料性附录）电力企业使用标准组件模型的有关问题··············24附录D（资料性附录）组件执行系统和中间件产品举例·················25参考文献·····································26II DL/T890.1—2007前言本部分是根据《国家发展改革委办公厅关于印发2006年行业标准项目计划的通知》（发改办工业［2006］1093号）的安排制定的。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）基础；IEC61970-302能量管理系统应用程序接口（EMS-API）第302部分：公共信息模型（CIM）财务、能量计划和备用；DL/Z890.401能量管理系统应用程序接口（EMS-API）第401部分：组件接口规范（CIS）框架；IEC61970-402能量管理系统应用程序接口（EMS-API）第402部分：组件接口规范（CIS）-公共服务；IEC61970-403能量管理系统应用程序接口（EMS-API）第403部分：组件接口规范（CIS）-通用数据访问；IEC61970-404能量管理系统应用程序接口（EMS-API）第404部分：组件接口规范（CIS）-高速数据访问；IEC61970-405能量管理系统应用程序接口（EMS-API）第405部分：组件接口规范（CIS）-通用事件和订阅；IEC61970-407能量管理系统应用程序接口（EMS-API）第407部分：组件接口规范（CIS）-时间序列数据访问；IEC61970-453能量管理系统应用程序接口（EMS-API）第453部分：组件接口规范（CIS）-图表定义交换（公共图形交换）；DL/T890.501能量管理系统应用程序接口（EMS-API）第501部分：组件接口规范（CIS）-公共信息模型的资源描述框架（CIMRDF）模式。本部分等同采用IEC61970-1：2005《Energymanagementsystemapplicationprograminterface（EMS-API）−Part1：Guidelinesandgeneralrequirements》。它提供了应用EMS-API接口标准所需要的一组指导原则和一般的基础设施能力。本部分描述了一个参考模型，为EMS-API标准其他部分的应用提供一个框架。本部分的附录A、附录B、附录C、附录D是资料性附录。本部分由中国电力企业联合会提出。本部分由全国电力系统管理及其信息交换标准化技术委员会归口并负责解释。本部分起草单位：国网电力科学研究院、山东大学、中国电力科学研究院、国家电力调度通信中心。本部分主要起草人：曹阳、许慕樑、云昌钦、潘毅、李毅松、王康元、李晓露。III DL/T890.1—2007引言DL890标准采用IEC61970国际标准。IEC61970标准定义了能量管理系统（EMS）的应用程序接口（API），目的在于便于集成来自不同厂家的EMS内部的各种应用，便于将EMS与调度中心内部其他系统互联，以及便于实现不同调度中心EMS之间的模型交换。将该国际标准转化为我国标准并贯彻执行，对于实现异构环境下软件产品的即插即用，使EMS与其他系统能互联、互通、互操作显然会有很好的作用。本部分提供了应用EMS-API接口标准所需要的一组指导原则和一般的基础设施能力。本部分描述一个参考模型，为EMS-API标准其他部分的应用提供一个框架。这一参考模型是基于组件体系结构的，使得本标准的重点集中在一个控制中心环境中各种应用之间交换信息用的组件接口上。本模型也可以应用于控制中心各个应用系统和该控制中心环境之外的各个系统，如其他控制中心、独立系统运营机构（ISOs）、区域输电机构（RTOs）以及配电管理系统（DMS）之间类似的信息交换。本部分还包括集成基础设施的一般能力，这一基础设施虽然不是本标准的组成部分，但所提供的支持EMS-API接口标准的某些服务是必不可少的。IV DL/T890.1—2007能量管理系统应用程序接口（EMS-API）第1部分：导则和一般要求1范围DL890的本部分提供应用EMS-API接口标准所需要的一组指导原则和一般的基础设施能力。本部分描述了应用这些标准的一些典型的集成场景和要集成的应用类型。本标准定义了一个参考模型，这个模型为应用EMS-API标准中的其他部分提供了一个框架。这一基于组件架构的参考模型使得本标准的重点集中于控制中心环境内各种应用之间交换信息的组件接口上。虽然EMS-API的首要目的是支持控制中心内各个应用的集成，但这个参考模型也可以应用于控制中心各个应用系统和该控制中心环境之外系统之间的信息交换，例如与其他控制中心、ISO、RTO以及配电系统之间的信息交换。本部分描述了本标准其他部分的作用，包括DL890中的公共信息模型（CIM）部分、DL890中的组件接口规范（CIS）部分和DL890中的技术映射部分。本部分还包括集成基础设施所需要的一般能力，该集成基础设施有利于通过CIS规定的组件接口交换信息。虽然集成基础设施本身并不是本标准的组成部分，但它所提供的支持EMS-API接口标准的某些基本服务是必不可少的。在第6章中列举了这些服务。本部分不规定特定的实现或产品，也不限制计算机系统应用内的信息表示。本部分规定了为支持不同厂商提供的各种产品的互操作性所必需的外部可见接口，包括语义和语法。2规范性引用文件下列文件中的条款通过本部分的引用而构成为本部分的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本部分，然而，鼓励根据本部分达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本部分。DL/T890.2能量管理系统应用程序接口（EMS-API）第2部分：术语DL/T890.301能量管理系统应用程序接口（EMS-API）第301部分：公共信息模型（CIM）基础3术语和定义DL/T890.2中的术语和定义适用于本部分。4系统集成4.1集成场景能量管理系统是各种软件子系统（SCADA、发电控制、负荷预报等）的一个集合，为此领域（或部分为此领域）而形成的指导原则适用于一些不同的集成场景。这项工作认为具有独特接口的现有系统需要逐渐过渡到使用此标准中定义的接口。以下设想了不同类型的集成情况。虽然这是一些典型的场景，但也只是各种可能范例的一个子集。a）不同供应商开发的应用集成到一个同构系统中：在这一场景中，独立开发的应用组件［如最优潮流（OPF）］都集成到一个系统中（该系统包含支撑基础设施）。这允许系统集成商更容易地将单个组件集成到任何系统中，无论是已有系统或是新开发的系统。b）独立系统间的在线数据交换：控制中心需要与公司内部或企业间的其他独立系统进行通信。需要用松耦合的集成方案来交换信息。这样的例子包括与DMS、公司结算系统以及其他EMS之间的信5 DL/T890.1—2007息交换。企业集成场景通常属于这一范畴。c）共享某些工程数据的独立系统的集成：这对应于来自不同厂商的应用包使用部分重叠的工程模型数据（例如线路阻抗）的情况。d）不同系统的相同应用之间串行化数据的交换：使用文件传输技术可以实现有限的集成，在这种类型的导出/导入交换中使用约定的格式。这种场景的一个例子就是在电力系统模型交换时使用文件传输协议（FTP）和基于可扩展标记语言（XML）格式的文件（或文档）。e）在一个同构系统中开发新的应用：厂商或电力企业在开发新应用并集成入他们现有的系统（不同于集成到其他系统）时在应用接口中使用这些标准。4.2集成考虑4.2.1概述这些标准所要支持的集成范围分为以下两个粗略定义的范畴：a）实现EMS或类似系统，软件组件的集成；b）独立系统的集成。为了实现正确的交互，软件组件和系统都需要一个公共信息模型（CIM）来为被交换或访问的信息提供一个公共的、一致的含义（即语义）。例如，为了交换变压器阻抗信息，需要有变压器的设备分类以及阻抗值的属性名。有了这些信息，变压器的一个特定实例就与其对应的阻抗紧密联系起来。CIM（参见6.2）提供了这些现实世界对象的语义名（以及它们的属性、描述和与其他现实世界对象的关联）。然而，在其他方面，集成的这两个范畴，如下面章节中讨论的，有一些稍许不同的需求。EMS-API标准的意图是对两个范畴都进行处理，而且它们都以组件接口的形式呈现。4.2.2系统内软件组件的集成4.2.2.1概述为了把独立开发的软件组件集成到一个系统中，需要处理几个问题。a）软件组件的交互：为了使系统能够正常运行，软件组件需要以一种合作的方式来交互。这种交互可以采用性质访问、方法调用和事件处理的方式。为了支持软件组件的集成，应该确定包含性质、方法和事件的公共接口，并且规定有关使用它们的规范。只要在系统中存在相似的交互场景，一致接口模式的规范就可以简化系统的集成和维护。b）初始化公共的工程模型数据：实际电力系统以及相关信息由CIM所表达的工程数据模拟。各种软件组件共享这些工程数据的各个方面以实现其功能。当软件组件启动时，它需要用被仿真的实际系统的一个一致和精确的模型来进行初始化。用于访问这些公共、共享数据的公共接口为软件组件提供了初始化其内部模型的一个一致的机制。一旦初始化了，软件组件的交互机制就可以用来保持其工程模型为最新。c）部署打包：为了打包和交付给系统集成，软件组件需要以特定的形式来实现。当今软件行业所存在的几种主流技术框架各自有其打包格式。本标准规范应该提高实现可能性方面的灵活性，同时促进独立开发软件的集成。为了实现这一目标，软件组件交互应该以一种能够兼容特殊技术和语言的抽象形式来规定。为支持这种类型的集成场景，组件接口使用的属性、方法和事件以及信息交换的数据内容都需要标准化。4.2.2.2应用类别EMS-API标准的范围包括那些通常可以在控制中心环境见到的所有应用，以及支持实时运行所需要的与外部系统间的接口。可是，由于EMS-API标准的意图是定义接口标准，而不是定义标准应用，因此考虑EMS-API标准所支持的这个应用类别列表能够最好地理解本系列标准的范围。把CIS中规定的组件接口实际打包到应用中的工作将留给应用提供商完成；因6 DL/T890.1—2007此，任何试图根据名字来定义一系列单个应用的做法，都会对提供商造成不必要的限制。表B.1中给出了本标准所支持的应用类别和典型应用列表。下面是这一列表的摘要：——监视控制和数据采集（SCADA）；——告警处理；——拓扑处理；——网络应用；——负荷管理；——发电控制；——负荷预报；——电能量/输电计划；——会计结算；——维护计划；——历史信息存档；——数据工程；——通用用户接口；——动态仿真；——调度员培训仿真；——外部系统（例如：DMS、天气、趸售电力市场等）。4.2.3系统间的集成在异构系统的集成中，运行环境和所施加的控制很可能没有相似之处，重点主要是在支持松耦合的异步“文档”交换上。在这一上下文中，“文档”可被看作一种大而丰富的数据结构，例如XML文档。文档交换意味着所交换的数据是复杂的、结构化的和自描述的。这种交换更可能涉及单个的、原子的信息传送，这里涉及如何处理该信息和/或在传输中所需操作的全部信息是自包含的，而不像多步事务中信息传送的处理可能视前面的信息传送或事件而定。4.3基于组件的接口EMS-API标准的一个目的是通过开发组件接口标准来鼓励独立开发可重用的软件组件并促进它们在建设各种控制中心系统中的集成。软件行业，包括主要的能量管理系统（EMS）厂商和EMS应用程序供应者，都经历了从基于自顶向下的模块化软件设计的软件工程概念到面向对象方法以及最新精化的使用基于组件的体系结构的发展过程。由公共对象请求代理体系结®1）®2）®®®3）构（CORBA）、Sun的EnterpriseJavaBeans（EJB）和Microsoft的分布式公共对象模型（DCOM）所倡导的组件模型是这一趋势的最好的例证（这三种组件模型在附录A中描述）。这些基于组件的方法也促进了不同来源的软件和完整系统的集成。对于这类任意对任意的集成，XMLWeb服务提供了另一种基于互联网的集成模型。XMLWeb服务允许应用利用早期被称为“文档交换”的信息交换类型通过互联网来交换和共享数据，并不关心操作系统和编程语言。这些服务提供了一种在企业对企业（B2B）信息交换中更为普遍的组件执行环境的一个例子。（参见附录A中的XMLWeb服务描述）基于组件的接口对EMS-API的影响是把焦点转移到开发交换和访问公共信息的软件组件接口标准上，而不是对提供这些能力的集成框架服务进行标准化。预期的前景是支持这些标准的应用能够独立地交付并重用于多个系统。虽然在实际的系统中可能还需要其他基础设施服务，如目录服务和安全性，但这并不是本标准的目的。实际上，它们是系统集成者或系统提供者所需要考虑的领域（即作为EMS系统平台的一部分，而不是可重用的即插即用组件）更为恰当。1）CORBA是OMG提供的产品的商标。提供这一信息是为了方便本国际标准的用户，并没有IEC认可该产品的意思。如果其他等价产品能够证明可以得到相同的结果，也是可以使用的。2）Sun是美国Sun微系统公司的缩写。提供这一信息是为了方便本国际标准的用户，并没有IEC认可该公司的意思。3）Microsoft是美国微软公司的缩写。提供这一信息是为了方便本国际标准的用户，并没有IEC认可该公司的意思。7 DL/T890.1—2007EMS-API标准的目的不是开发中间件的标准接口。实际上，目的正相反——要不依赖于任何一组特定的中间件服务。这使得集成者可以为每一个系统选择恰当类型和规模的基础设施。它使得各种服务设计都可以发展和创新，同时简化了组件的开发。这也意味着软件开发者不必直接和这些服务打交道。系统集成者提供“胶水”来把这些组件插入到系统环境中。这给集成者更多的自由来配置组件和选择最适合所实现系统需求（如性能、可用性等）的服务。下面的两个例子阐明了组件的这种独立性：——CORBA组件并不特别强调使用CORBA通知（或任何一种特殊的服务）作为其事件系统。——无论所部署的环境是否有分布事务处理协调器（DTC）和/或微软消息队列（MSMQ），COM+组件都用完全相同的方式来编写。表1列出了这种基于组件的接口标准方法的一些优点。表1基于组件接口的优点明确致力于EMS-API项目中软件即插即用的目标对整个系统的设计和各个服务的选择与设计都不作规定与整个软件行业的方向相吻合，可以使用主流工具来开发组件和配置系统使EMS-API项目不必为“即插即用”软件的许多问题去重新发现和重复发明解决方案提供一个包括打包（装载在组件光盘CD上）、文档、版本等重要方面的更为完整的解决方案不需要设计和/或规定中间件服务，特别是事件、命名和事务服务，而是允许使用商业化的产品来提供这些服务为基于本项目开发的电力公司专用标准提供一种规范形式，使得开发者能够把接口定义直接机器翻译成他们首选®4）的接口语言：对象管理组织（OMG）/国际标准化组织（ISO）接口定义语言（IDL）、Java接口语法或MicrosoftIDL允许EMS-API项目集中为电力企业应用设计接口和事件，不必等待所有的中间件问题都得到解决。这使得厂商可以在他们应用产品中用符合EMS-API的接口来更快地进入市场4.4与IEC61968标准的关系IEC61968标准处理配电管理系统的系统接口。这些标准在很大程度上与IEC61970（DL890）类似，不仅是在范围上重叠，而且IEC61968标准也是基于CIM的。IEC61968标准建立在IEC61970-301（DL/T890.301）中所规定的CIM基础之上，尽可能通过扩展它来包含已有类的新的子类，同时也增加一组全新的类对配电问题域中发现的对象进行建模。因此，要理解CIM的整个范围，需要同时查看涉及CIM的IEC61970（DL890）和IEC61968两个标准。类似于IEC61970-4××（DL890.4××）标准，IEC61968标准也关注配电业务功能之间的信息交换，但并不试图定义应用程序接口（例如，要由组件实现的服务），而是预想在IEC61968标准中定义的标准消息可以通过IEC61970（DL890）标准中定义的API传输。5EMS-API参考模型5.1概述EMS-API参考模型是一个抽象体系结构，提供所处理的问题空间的一个直观显示，提供描述和讨论解决方案的一种语言，定义术语，并提供有助于使用EMS-API标准来解决问题以达成共识的其他类似的帮助。这个参考模型不是一个设计，也不试图描述各个软件层，尽管隐含的分层方法是难以避4）Java是Sun微系统公司提供的产品的商标。提供这一信息是为了方便本国际标准的用户，并没有IEC认可该产品的意思。如果其他等价产品能够证明可以得到相同的结果，也是可以使用的。8 DL/T890.1—2007免的。参考模型的主要功能是清楚地展示问题空间的哪些部分是EMS-API标准的主题，哪些部分在EMS-API项目范围之外及其原因。它还试图展示本标准的不同部分之间的相互关系。图1是这个参考模型的一个图解，阴影区域代表在参考模型中本部分是本标准的主题。非阴影区域代表一个系统中对于创建可重用应用组件框架是不可或缺的那些部分。这个模型的每一部分都将在本文件中讨论。图1EMS-API参考模型5.2控制中心环境这个参考模型是专门应用于控制中心环境的。控制中心环境通常由通过局域网（LAN），有时还通过广域网（WAN）连接起来的计算机网络构成。一个控制中心可能包含多种系统以支持电力系统运行，包括EMS、DMS以及ISO和RTO业务功能所需的其他系统。它支持一定数量的不同用户群体和机构功能，包括值班操作人员、运行管理人员、操作员培训、运行计划、数据库维护和软件开发。在一个EMS中，许多应用都在多个这样的应用上下文中使用，因此重要的是一个应用可以容易地配置（最好是自动地配置）以用于不同的应用上下文。这是通过使用和每一个组件接口关联的性质（properties）而不是修改组件的内部代码来实现的。5.3应用上下文5）一个应用上下文（applicationcontext）包含了作为一个组织单元一起工作以实现某个高层次目的的一组应用。一个应用上下文定义一个时间范围和一个执行环境。表2包含EMS应用上下文的一些例子：表2EMS应用上下文举例实时电力系统在线控制运行研究执行网络应用程序以研究和/或分析运行实践（短期）5）“上下文”这个术语在这里的用法和在讨论组件模型EJB与CORBA时的用法是不同的。在讨论组件模型时，上下文用来说明组件容器为组件实现提供对组件容器所实现的运行时服务的访问。这些服务包括事务、安全、事件和持久性。9 DL/T890.1—2007扩展规划研究执行网络和/或仿真研究以评价各种选择方案（未来/长期）培训为操作员提供培训环境，需要仿真和分析应用虽然在参考模型中没有明确说明，大家都理解几个上下文可以同时存在，每一个上下文都有可能在不同的数据交换中涉及同样一些应用。此外，还可能有一个特定上下文的多个实例共存的情况。例如，在运行研究上下文中可能会为两个操作员同时运行两个或多个研究，同时同样的这些应用还在实时上下文中运行。5.4应用一个应用由在一个给定领域内完成某些业务功能的一个或多个组件组成，它由领域专家设计和编写。组成该应用的各个组件的粒度由设计者选择。应用的构建者可以组合来自不同开发者或厂商的组件以构成一个应用。应用的开发者应能无须接触组件的源代码就可以充分使用该组件。组件可以通过一组外部性质值来定制以适合应用的特殊需要。例如，按钮组件有一个规定出现在该按钮上的名字的性质。当然，允许定制的数量取决于该组件的开发者提供足够的外部性质值的远见。这有点像程序设计中的一个早期概念，即通过指定适当的配置参数值而不是必须修改源代码来定制程序。附录B.1中是应用类别、抽象名和所执行功能的列表。5.5组件组件是一种可重用的软件构建块。它是预先构建的一段封装起来的应用代码，可以和其他一些组件及手写代码组合在一起快速生成一个定制应用。要成为一个合格的组件，应用代码必须提供一个标准的接口，使得该应用的其他部分能够调用其功能并访问和操作该组件内部的数据。这种接口的结构由组件模型定义。各种组件的粒度是不一样的。一个组件可以很小，例如一个简单的图形用户接口（GUI）部件（例如，一个按钮），也可以大到能够实现整个复杂的应用，例如状态估计应用。在后一种情况下，该应用可以作为一个单一的组件从头设计，也可以由被封装起来以符合组件接口标准的一个遗留应用组成（参见下面对遗留应用的讨论）。可以把组件放在一个可传送的介质中，如一张CD，以便在提供组件容器的系统中使用。各种组件一般都通过一个集成基础设施来公开展露其方法、性质和“事件”。其中要特别关注的是事件，因为正是这些事件使得集成各种独立开发的组件成为可能。通过使用标准的事件集，组件A不需要知道组件B接口的任何其他细节，甚至不需要知道组件B是否存在。这里的关键是：被标准化的是组件的接口，而不是集成基础设施。5.6遗留应用和封套遗留应用与前面给出的应用的定义差别很大。遗留应用可以是电力企业在为集成目的而建立任何组件模型之前所购买或自行开发的执行某一业务功能的单个应用，也可以是作为其他一些系统所需要/发布的数据的源/宿的一个完整系统，这些系统需要集成在一起以促进信息交换。例子包括：——用FORTRAN实现的未考虑组件接口的机组经济组合应用；——一个完整的EMS，没有开放、发布接口给配电系统提供SCADA数据，没有从检修管理系统接收其电力系统模型更新信息。遗留应用封套用来封装不符合组件接口标准的遗留应用或系统。它把遗留程序的输入/输出变换为一个或多个组件接口，使其能够在一个基于组件的系统体系结构中参与信息交换。这样，使用遗留应用封套的意图就是使遗留应用或系统可以像即插即用组件那样，能够通过公用基础设施或框架来和其他组件交换信息。遗留应用封套可以由开发或拥有遗留应用或系统的领域专家（例如，EMS厂商）设计和实现，然后提供这种封套以便在使用组件技术的多系统装置中使用。另外一种情况是，遗留程序是独一无二的定制“企业”应用，系统集成者可能得编写所需要的封套，而且只用于该10 DL/T890.1—2007系统中。5.7组件模型组件模型定义组件的基本体系结构，规定组件接口的结构和该组件与组件容器及其他组件交互的各种机制。这种组件模型提供创建和实现组件的导则，这些组件能够一起工作以形成一个更大的应用。组件构建者不必在每一个组件中实现多线程、并发控制、资源池（resource-pooling）、安全保证和事务管理。而且，如果在每一个组件中实现这些服务，要达到真正的即插即用式的应用装配将是非常困难的。组件模型使这些服务的使用标准化和自动化。现在软件行业内部广泛接受的有四种主要的组件模型。这些组件模型在附录A中描述。软件行业已经决定，正如在所有这四种组件模型中所规定的那样，从组件中消除对特定组件容器或基础设施的依赖是迈向可以独立开发、组装和部署组件的境界的一个主要步骤。但是，由于有四个独立的模型，组件厂商可能要为每一个模型各提供一个稍微不同的组件版本以方便使用底层组件容器和执行系统的所有可能特性，还能够继承其固有的一些性能优势。但这并不是必须的。在组件厂商约束其组件设计以确保在这四个模型的任意一个中能够正确运行的时候，这些差别就可以通过组件适配器来弥补，组件适配器由被选定的在特定系统实现中使用特定组件技术的系统集成者提供。系统集成者也可以选择组合多种组件技术和使用桥接技术来实现不同技术之间的互操作（例如，CORBA执行系统与MicrosoftDCOM执行系统互操作）。5.8组件容器组件在一个容器内执行。容器为一个或多个组件提供一个上下文并为这些组件提供管理和控制服务。在实际的系统中，容器提供一个操作系统进程或线程来执行组件。它把该组件和运行时平台相隔离。当一个客户程序调用一个服务器组件时，这个容器就自动分配一个进程或线程并初始化该组件。容器管理组件所使用的所有资源，还管理该组件和各个外部系统之间的所有交互。典型情况下组件容器由系统提供者提供，作为组件执行系统的一部分。为组件提供的典型服务是命名、事件、事务、安全和持久性。电力企业实时应用所需要的所有服务可能并没有作为软件供应商供给的标准容器服务的一部分来提供。附录C描述在一个实际的实现中这些服务是如何提供的。5.9组件适配器一个容器的操作和行为由其组件模型定义和支配。组件模型提供一个约定，规定如何提供容器服务和接口。这样，为一类执行系统或环境开发的组件通常不能够直接移植到任何一个其他类型的执行环境。因此，为了实现组件在多执行系统中的重用，除了组件设计时基于的那个执行系统外，其他任何执行系统都需要有一个组件适配器。可供选择的另外一种办法是，组件接口可以根据某个中立的标准定义，这样对所有的容器都需要一个组件适配器来把这种标准接口映射到该容器所提供的接口。这有点像Java企业平台中的“可移植层”，该平台是EJB的组件执行系统。组件适配器定义为处于应用（或组件）和组件容器及集成基础设施之间的软件，它提供基本的组件支持服务（例如，发布/订阅、消息队列、命名等）。如果需要，这种适配器可以处理协议差异、数据变换和数据翻译。如果组件执行环境本身没有提供安全、事务和持久性等服务，适配器也可以另外提供对这些服务的组件支持（至少从应用程序以外的角度看是如此）。组件适配器既处理（a）组件接口和所选择的执行系统环境及容器技术之间的差别，也处理（b）一个组件接口和用在系统其他部分的各个组件接口之间的差别。这包括事件定义的差别。出现这些差别的原因是：——系统是由独立开发的一些组件构成的，这些组件的接口没有预先协调（即没有标准化，这可能是普遍的情况）；——系统包含一些部分标准化的组件，但是没有标准化的部分是不兼容的；——由于标准化的各个部分反映的是标准的不同版本，所以还是不兼容的。11 DL/T890.1—2007依据组件容器所提供的环境和工具，组件适配器还可以把组件的事件入口连接到适当的事件主题并找到正确的相关组件（如果存在）的位置。组件适配器还可以实现组件在前面确定的各种EMS上下文运行所需要的电力企业专用服务，这是现成的组件执行系统所不能提供的。组件适配器通常由系统集成商或组件执行系统供应商提供。它们通常由这样的代码组成，这些代码用来：①把该组件所期望的事件类型、数据类型和服务与正在实施的特定系统中其他组件所期望的事件类型、数据类型和服务匹配起来。②为组件配置系统信息流。因此，组件适配器是由系统集成商针对每一个系统和每一个组件手工定制的。5.10组件执行系统服务器组件在由应用或组件执行系统提供的环境中执行。组件执行系统这个术语包含了参考模型中从容器层往下的所有内容，包括组件容器、中间件服务和通信协议子集。它还包括其他一些没有展现的常规平台所提供的服务，包括操作系统、持久性存储等。这些也称为容器系统，因为容器为接口标准提供了主要接口，而接口标准是本标准的主题。容器系统包括已有的一些遵守该系统所采用的组件模型的容器约定和策略的中间件产品。任何为支持组件而遵守容器约定的执行系统框架都是合格的。例如，EMS供应商可以把EMS应用执行系统设计成能够支持容器，从而可以使用内部开发的或从其他组件供应商购买的各种组件。附录D中列举了其他一些商用例子。组件执行系统通常由系统供应商提供。5.11中间件中间件这个术语用来描述各种实现集成、变换和/或翻译层作用的一组软件产品。中间件为事件、消息传输、数据访问、事务等提供一些通用接口。中间件厂商提供带专有接口的产品来支持这些通用服务的某种组合。尽管中间件厂商通6）常都为一些广泛使用的应用，如PeopleSoft、SAP等提供转换器，但是他们一般都不针对一个特定的行业。他们也许提供，也许不提供电力企业实时运行环境所需要的所有服务。作为建立公司标准的企业范围信息技术决策的一个结果，每一个电力企业都可能选择一个不同的中间件厂商，这个选择是不容易改变的。因此，必须把EMS-API组件接口标准编写成能够用各种中间件产品来部署。中间件产品还在不断地发展。EMS-API组件接口标准应该不排除在进行集成化工作时使用那些最好的可用产品。附录D列举了中间件产品的一些例子。5.12通信协议子集通信协议子集规定在一个组件执行系统中分散的各服务器平台之间信息交换用的各种特定的协议和协议服务。一些中间件产品在标准的协议子集之上工作，如CORBA和EJB使用TCP/IP之上的互联网ORB-间协议（IIOP：InternetInter-ORBProtocol）在互联网或私有的内部网上运行。其他中间件使用专有的一些协议和服务。EMS-API接口规范的意图是要独立于任何一个特定的通信协议子集。5.13参考模型应用举例本条提供两个例子来说明参考模型概念在实际系统中的应用。5.13.1用EMS-API标准构建EMS的例子图2举例说明一个符合EMS-API参考模型的EMS系统。各个单独的应用组件通过组件执行系统和组件适配器相互连接，组件执行系统和组件适配器提供各种基础设施服务，这是在各种EMS上下文中组件彼此之间以及组件与公共数据存储之间相互发现和通信所需要的。在这个例子中，假设有一个直接支持CORBA组件的CORBA组件执行系统。这样，符合CORBA组件模型的应用就不需要组件适配器。实时运行的SCADA数据来自：①封装起来以提供必要的组件接口的一个遗留SCADA系统。②连接到其他控制中心或变电站的控制中心间通信规约（ICCP）数据服务器。当有数据更新时，SCADA数据的这两个来源使用相同的组件接口来发布6）PeopleSoft是Oracle提供的一个产品的商标。给出这一信息是为了方便本国际标准的用户，并不包含IEC对所提产品的任何认可。任何能够证明可以导致相同结果的等同的产品都是可以使用的。12 DL/T890.1—2007数据更新，需要实时数据更新的应用预订并接收这些数据更新，且这和哪一个源提供这些数据无关。例子中还展示了位于控制中心之外的一个DMS系统，这个系统也能够通过订阅在SCADA数据更新出现时收到同样的数据更新。该系统还支持许多其他的应用交互。图2使用EMS-API组件标准接口的EMS5.13.2同时使用遗留封套和组件适配器的场景另一个例子是关于一个SCADA厂商的，它已经有一个系统（例如，一个典型的SCADA数据采集与控制应用），需要封装成一个CORBA组件，这样就可以作为能够与CORBA容器系统相接的一个即插即用应用出售。这个已有的SCADA应用有一个存在了好几年的专有API，而且经过了检验和严格的测试，并且用在了各种各样的装置中。仅仅为了把它做成一个CORBA组件就改写这一应用的任何一部分都是不值得的。因此，合乎逻辑的方法是用一个支持所需要的组件接口的封套来给这个“遗留应用”加一个前端处理。这个封套使这个应用（或更可能的是这个应用的一个小部分）呈现为一个标准的CORBA组件。这个封套可能要负责把已有的专有API映射到组件规定的API。这一映射会是相当精细的。现在，已经购买了这个SCADA厂商的组件化SCADA应用的顾客要把它集成到企业中。目前最可能的情况是，要和这个SCADA应用集成的大多数应用并不遵循一个单一的标准组件模型，或者根本就不遵循任何标准组件模型。这个顾客已经选择了一个集成中间件产品来帮助他完成总的集成化任务。电力企业购买该集成中间件产品的主要原因之一是它能够使各种各样的应用接口、组件或其他软件容易地适应这个集成中间件产品所提供的公共服务和信息交换模型。这个企业集成中间件产品可能并不直接支持该SCADA组件所使用的组件模型，或者完全不支持组件模型。因此，要由中间件厂商或系统集成商提供一个组件适配器。这一场景说明了参考模型中遗留应用封套和组件适配器之间的区别。这里，提供封套是SCADA厂商的职责，而提供适配器则是中间件厂商的职责（显然，电力企业可能已经选择使用专有的SCADA接口，这样一来甚至就可以不引入遗留应用封套）。在将SCADA应用包装为一个标准组件方面，中间件厂商的适配器可以被标准化。实际上，集成中间件厂商提供一些标准的适配器，典型的是用于关系数据库管理系统（RDBMS）（例如，Oracle、SQLServer等）、流行的标准应用（例如SAP、PeopleSoft等），以及其他的常用资源（例如，MQSeries等）。6EMS-API标准6.1概述如参考模型所示，公共信息模型（CIM）和组件接口规范（CIS）是模型中正在标准化的主要部分。实际13 DL/T890.1—2007上，这些正是本系列标准的各部分。本系列标准预计文档结构如下：第1部分：导则和一般要求第2部分：术语第3××部分：公共信息模型（CIM）第4××部分：组件接口规范（CIS）第5××部分：CIS技术映射6.2CIM6.2.1概述SCADA/EMS/DMS应用组件通常需要一个包括量测、网络连接关系、设备特性等的精细模型才能运行。CIM提供了这样的模型，为这些应用组件提供了一个电力系统的综合逻辑视图。CIM是一个抽象的模型，描绘典型情况下EMS信息模型中所包含的电力企业所有主要对象，这是许多应用程序都需要的。这一模型包含描绘这些对象的公用类和属性，以及它们之间的关系（见DL/T890.301）。这个模型以统一建模语言（UML）描述，保存为单个统一的RationalROSE模型文件。DL890.3××文档的主要部分是使用RationalSODA从这个模型文件自动生成的。CIM是总的EMS-API框架的一部分。通过提供一种把电力系统资源表示为对象类和属性以及它们之间关系的标准方法，CIM促进了不同厂商独立开发的各个EMS应用的集成，独立开发的各个完整的EMS系统之间的集成，或EMS系统和与电力系统运行的不同方面，如发电和配电管理，有关的其他系统的集成。这是通过定义基于CIM的公共语言（语义和语法）实现的，这些应用程序和系统可以使用这种语言访问公共数据和交换信息，而不管这些信息在内部是如何表示的。6.2.2CIM预期的使用CIM中描绘的对象在本质上是抽象的，因此可以用于大量不同的应用中。CIM的使用远不止在SCADA/EMS/DMS中的应用。应该把这个标准理解为这样的一个工具，在任何领域，只要需要用一个公共电力系统模型来促进各种独立于任何具体实现的应用和系统之间的互操作和插入兼容性，就可以使用该工具来实现集成。特别期望的CIM使用包括：——用配置数据初始化应用组件；通常在使一个应用组件可操作之前，应该在配置阶段基于该模型用当前状态和事件信息对其初始化（有时称为数据工程）。在一个应用组件的生命期中，对电力系统的扩展需要改变模型并配置数据；——重用遗留系统中存在的配置数据；——合并外部系统中存在的配置数据；——提供基础数据以支持应用组件间的在线数据交换。应用组件在在线操作中产生的数据呈现给操作员并可以作为其他应用程序的输入。应用组件也接收来自其他应用组件的数据。虽然在线数据交换是6.3中描述的CIS标准的主题，但是这些数据交换的内容是基于CIM的。6.2.3上下文和时间所有实体的CIM定义隐含地允许多个对象实例在多个时刻存在。为了区别在多个相同的应用组件中实例化的各个CIM实体，组件之间交换的信息应该包含一个上下文或环境。这可以用一个字母数字字符串，例如TRAINING（培训）、实时（REALTIME）、离线（OFFLINE）、研究（STUDY）、重演（REPLAY）来实现。然而，这些组件本身无需知道它们所运行的上下文。两个基于CIM的应用之间所有的数据交换事件都必须包含一个时间概念。依据不同的应用，这可以是隐含的（例如，这个时间就是接收应用程序的时间），或是明确的（即，数据项具有单个的或整个数据块用的时间标记）。在一个应用内部，CIM实体，如PowerSystemResource或MeasurementValue可以包含未指定方式的起始日期和时间、终止日期和时间以及当前日期和时间。不同的应用可以用不同的方式来保存时间，例如，一个全局变量、单个对象中的一个属性、一个关联的对象等。这是个设计问题，不在考虑范围内。另外，一个运行系统中的数据一般随时间发展。对象将被创建或删除，对象的性质14 DL/T890.1—2007值也会改变。因此，每个对象有一个创建时间，可能还有一个删除时间。性质值也会有创建或更改时的一个或多个时间。CIM没有明确对此建模，只有量测值有明确的最近更新时间的时标。其余的对象和性质值缺少明确的时标并不妨碍模型用于有时间记录的应用，例如，数据仓库应用。对这样的应用，建议——所有的对象都有一个“创建”时标和一个“删除”时标；——所有的性质值都有一个“最近更新”时标；——维护所有性质的“最近更新”时标及其对应的值的一个历史档案。这些数据值及其关联的时标可以通过DL890.4××CIS标准规定的API来访问。6.2.4关系和属性的一致性CIM描绘电网在一个特定状态下的一组实体、关系和属性。本文件并不规定应用应该如何控制在其内实例化的对象的关系和属性的一致性。例如，如果一个开关的状态改变了，可能需要重新计算拓扑逻辑关系和得到新的一组量测值。这可能涉及不止一个应用。应用接口负责提供证实信息交换合格所需要的一致性状态信息（例如，枚举量“ModelValid”、“TopologyValid”、“LoadFlowValid”）。对于一个特定的网络配置，导电设备可能组合到馈线中，而连接节点可以组合到拓扑节点中。信息交换上下文的一部分就是用来说明该信息是“ASBUILT”还是“CURRENT”等。当描述拓扑关系时，这原则同样适用于量测值和其他的简单属性的处理。例如，一个数据库应用可以把各个实例保持在它们的ASBUILT状态，而一个SCADA应用可能会把各个实例保持在它们的CURRENT状态。这两个应用的CIM模型是一样的，但是每一个应用中的各个实例可以有不同的值。6.2.5和IEC61968标准的关系正如前面4.4中所说，IEC61968标准也建立在CIM上，通过扩展包含在IEC61970-301（DL/T890.301）中的CIMBase以包含现有类的新的子类，同时也增加一组全新的类为配电领域中发现的对象建模。因此，要理解CIM的整个范围，必须考虑在IEC61970（DL890）和IEC7）61968两个标准中描述的CIM。6.3CISDL890.4××CIS文档的目的是指定这样一些接口，组件应该使用这些接口来促进与其他独立开发的组件的集成。虽然在附录B中标识了一些典型的应用和功能以帮助定义需要传送的信息类型，但是目的并不是试图定义组件本身。组件的提供商应能自由地将不同的组件接口集合打包在组件包里，同时仍保持遵从EMS-API标准。CIS规定组件接口有两个主要部分：a）组件（或应用）为了能够以一种标准方式和其他的组件（或应用）交换信息和/或访问公开可获得的数据所应该实现的接口。这些组件接口描述特定的事件、方法和性质，它们可以被应用基于这一目的使用。b）组件与其他组件交换的信息内容或消息。这有时称为信息交换模型。DL890.4××被组织成分别描述这两部分的文档：a）401−449部分：这部分计划用于规定组件接口所支持的通用服务。这些规范用叙述性术语以文本、统一建模语言（UML）表示法和IDL来描述接口功能。这些规范定义了任何应用可以用来与其他应用交换信息或访问公共数据的通用服务。b）450−499部分：这部分计划用于处理各种技术规范，这些规范专用于附录B中定义的典型应用类别特定的信息交换需求。这些技术规范定义了在应用程序之间标准的信息交换的信息内容，这些被定义为一些事件，但是可以用多种方式进行交换，包括作为消息发布、通知后的请求或有时以XML文档来交换。如果需要，也将标识每个接口支持的性质和方法。支持文档包括用例和事件序列图。7）支持这两组标准的扩展CIMUML模型由负责IEC61968系列标准的IECTC57WG14负责维护。15 DL/T890.1—2007根据为应用类别所预见的交换类型，指定所使用的特定通用服务，以确保不同厂商开发的组件间的互操作性。应用这些标准的意图是为实际完成信息交换的中间件的选择提供尽可能多的灵活性，同时确保互操作性。对于每一种应用类别，信息内容是在一个信息交换模型（IEM）文档中描述的。DL890.4××CIS技术规范是以一种独立于实现它们的底层技术的方式在文档中描述的。因此，DL890.4××系列文档有时称为第1级CIS。在6.4中描述的DL890.5××系列CIS文档提供了从DL890.4××CIS规范到特定的基础设施技术的映射，因而有时称为第2级CIS。6.4CIS技术映射由于CIS文档独立于底层基础设施技术的设计，在实现中，应该把它们映射到特定的技术。为保证互操作性，从每一个接口到每一种技术，都应该有一个标准的映射。例如，如果选择Java作为实现技术，就需要有CIS文档中规定的发布和事件订阅服务到Java服务的一个标准映射。类似地，对于每一种应用类别，IEM中包含的来自CIS文档的事件定义，需要映射到用于信息传递的特定语言。例如，如果要使用一个消息代理来传递XML消息，那么CIS事件就需要映射到XML。当这些标准被部署时，期望下面的映射或特化将成为这个系列中的伴随标准。其中有些是语言特定的，有些是中间件特定的：C++语言；C语言；CORBA；DCOM；Java。XML当使用基于XML的消息作为集成技术时，XML特化将为具有GID接口的独立开发的组件提供互操作性。7通常需要的基础设施功能7.1概述本章描述集成分布式组件所需要的电力企业应用间基础设施的能力。这些服务由第4章中的EMS-API参考模型所描述的组件执行系统提供。所描述的服务和功能独立于这一基础设施所使用的底层技术。在下列需求的上下文中，一个“事件”是一个信息交换单位，由其源异步发出（“推”）。一个“组件”是集成总线上的一个可重用的应用软件模块，可以作为信息交换的发布者或订阅者（接收者）。为了具有全面的应用间集成能力，组件执行系统应该提供下面列出的功能。但是，这并不意味着每一个实现都必须支持所有的这些功能。这个功能清单只是作为为一个实际的系统部署这些标准准备的一个规范的起点。对于一个部署来说，哪一些特殊的需求是重要的在很大程度上取决于该互连系统特殊的操作和性能要求。一个组件执行系统：a）应该允许组件交换具有任意复杂性的信息。b）应该能够使用各种形式的分布式组件技术（例如，CORBA、DCOM、消息代理、面向消息的中间件、关系数据库、面向对象数据库或其他技术）来实现。（参看第6章）c）应该能够让系统管理员独立于其他组件地部署各个发布和/或订阅的组件。d）应该保证所发布的信息是完全可重用的，即一旦发布了一个给定类型的事件，任何一个新的经授权的实体就可以获得该事件，无须在发布信息的组件中做任16 DL/T890.1—2007何的修改或补充。e）应该把一个通用的事件历史工具作为组件提供。这使得所有的或所选择的信息交换可以保存在一个永久的存储器中。f）应该支持基于信息交换元数据模型的事件历史模式。g）应该提供一个事件历史组件来记录发布组件发出每一个事件的时间。h）应该有能力支持事件信息模型版本和组件版本。（这样可以保存一个完全的核查跟踪数据，需要时能够用来精确地恢复历史）i）应该提供应用间监控组件，用来分析连接到电力企业专用服务的任何应用组件接口的状态。这一组件可以启用和停用，能够提供性能监视功能。这些要素有助于提供统计数据来识别瓶颈或将来需要改进的方面。管理员需要用这一信息来配置组件间的信息交换和保证可用性。j）应该让组件能够发送或请求信息而不需要知道接收组件的物理位置或当前是否连接着。接收者可能由于网络的问题而不能得到，或自然断开就像手机用户那样只是周期地接通，组件可能会由于出故障或只是在某些时间运行而不可用；当网络可用时或接收应用程序准备好处理请求时，正在等待的信息必须传送出去。下面各条规定了EMS-API组件执行系统的不同部分应该具有的功能。7.2组件容器组件容器提供一组API，供组件调用容器所支持的服务。下列服务一般都作为现成商品组件容器的一部分提供。支持EMS-API所需要的这些通用的分布计算服务如下：a）组件生存期服务（ComponentLifeCycleService）：这一服务允许启动、停止和控制要执行的各个组件。b）命名服务（NamingService）：这一服务提供一个支持层次结构的命名服务，并允许一个组件使用人可读的名字来确定其他组件的位置。这一命名服务支持使用已有的电力企业专用名字，也支持创建、删除名字和给名字赋别名。c）时间服务（TimeService）：这一服务为分布的各个组件提供一种方法，使它们都具有可配置精度的同一时间。d）并发控制服务（ConcurrencyControlService）：这一服务帮助管理分布在各个服务上的一些共享的类似项，例如多个组件关注现实中同一个业务对象的不同部分（交换、交换类型）时。e）安全服务（SecurityService）：这一服务允许应用设置并验证组件和用户进行信息交换的特权等级，以及对每次交换进行加密和解密。这一服务还支持宿主机认证，即节点的认证。f）事务服务（TransactionalService）：这一服务允许应用声明一个多步事务的开始和结束。多步事务作为一个原子单位操作要么成功要么失败。g）组件交互服务（ComponentInteractionService）：这一服务提供可选择服务质量的可靠消息传送。它还提供各种交互服务（创建、删除、复制和移动）的生命期管理和查询已经建立的交互（主要对发布和订阅交互有效）。h）发布和订阅消息服务（PublishandSubscribeMessagingService）：这一服务提供松散（匿名）的各个组件实例之间的同步和异步消息传送。i）请求/应答消息服务（Request/ReplyMessagingService）：这一服务提供耦合的、确定的各个组件实例之间可靠的同步消息传送。j）发布/应答消息服务（Publish/ReplyMessagingService）：这一服务以提供一次消息传送（发布）开始，然后以一个传送（回答）结束。k）工作流服务（WorkflowService）：这一服务允许应用级程序员创建和运行业务进程自动代理。7.3中间件为了使分布的各个应用不依赖于组件模型的使用，需要用一些带基础服务的中间件服务来支持组件容器。中间件和组件容器之间的界限是抽象的，而不是具体的。17 DL/T890.1—20077.4通信协议子集服务集成两个组件需要它们之间的一个连接。因为有多种类型的网络，不同的资源使用不同的协议，如IIOP和超文本传输协议（HTTP）。为了连接多个组件，集成系统必须使网络和协议的差异透明化以适应各个组件。DL890系列标准要求通信协议子集服务应该：a）只要网络正常工作就要保证网络消息投递到其网络目的地。b）无论网络出现故障或改变，都要提供有保证的投递，确保网络消息只投递一次。c）无论网络出现故障或改变，都要提供有保证的排序，投递消息时维持源的发送顺序。d）保证在网络消息不能够投递到网络目的地时，网络源能够接收到表明未能投递的消息。e）提供一个可选择的服务质量以按优先级排序网络消息或通过特殊网络路径投递。f）提供由网络目的节点控制的网络消息处理速度的动态适应，允许慢速目的节点提供服务。7.5电力企业特定的服务为了支持EMS中的组件，可能需要一些电力企业特定的服务，这些服务在商用组件执行系统中是未提供的。附录C中列出了属于这一类别的一些可能的服务，以及提供这类服务的一些可选方案。可以预期，如果需要用这些服务来支持应用之间的信息交换，它们就将在DL890.4××系列CIS的制定过程中被确定，并成为那些标准的一部分。18 DL/T890.1—2007附录A（资料性附录）组件模型A.1组件模型组件模型定义组件的基本体系结构，规定其接口结构和该组件与它的容器及其他组件交互的机制。这种组件模型提供创建和实现组件的指导原则，这些组件能够一起工作以形成一个更大的应用。当前软件业界内部广泛接受的有四种主要的组件模型，它们将在下面各章节中描述。®8）A.2EnterpriseJavaBeans9）EnterpriseJavaBeans（EJB）规范为JavaBeans［2］定义了一个服务器组件模型。EnterpriseJavaBeans是特殊的、非可视的JavaBeans，它在服务器而不是客户机上运行。EnterpriseJavaBeans能够和其他的小组件（beans）装配在一起以创建一个新的应用。企业小组件能够通过它的性质表及定制方法来操纵和定制。EnterpriseJavaBeans组件模型定义企业小组件类组件和企业小组件容器系统之间的关系。EnterpriseJavaBeans并不要求使用任何一种特定的容器系统。通过增加对EJB规范中定义的服务的支持，任何一个应用执行系统都能够被改造以支持EnterpriseJavaBeans。这些服务定义企业小组件和容器之间的一个约定，因此创建一个可移植层。这相当于EnterpriseJavaBeans的组件适配器，它是除了EnterpriseJavaBeans执行系统外任何一个执行系统都需要的，称为EnterpriseJavaBeans服务器（EJB服务器）。这使得任何一个企业小组件都能够在任何一个支持EnterpriseJavaBeans约定的应用执行系统或容器中运行。EJB服务器提供标准的一组服务来支持企业小组件类组件。因为EnterpriseJavaBeans是事务处理型的，EJB服务器必须提供到一个分布的事务管理服务的访问。它还必须为企业小组件提供一个容器，称为EnterpriseJavaBeans容器（EJB容器）。EJB容器实现对一类EnterpriseJavaBeans类的管理和控制服务。它还提供下列服务：——生命期管理life-cyclemanagement；——事务控制transactioncontrol；——持久性管理persistencemanagement；——透明的分布服务transparentdistributionservices；——安全服务securityservices。A.3CORBA组件®CORBA已经定义了一个与EJB规范兼容的组件模型［3］。CORBA组件模型定义：a）组件，作为一个或多个CORBA接口的提供者。一个组件：——能够提供和使用一个或多个单独的CORBA接口；——能够发出或使用一个或多个特定的事件；——具有可配置的设计期性质；——具有运行时属性；——声明一个可以用来创建该组件的实例的工厂接口。b）容器模型，用来把系统服务引入到CORBA组件的运行时环境。容器模型规定：——组件与其容器交互的本地约束接口；8）EnterpriseJavaBeans是SunMicrosystems公司提供的产品的商标。提供这一信息是为了方便本国际标准的用户，并没有IEC认可该产品的意思。如果其他等价产品能够证明可以得到相同的结果，也是可以使用的。9）方括号内的数字是参考文献号。19 DL/T890.1—2007——简化的CORBA事务版本；——生命期支持，以优化一个进程内的资源使用；——安全策略，提供如CORBA安全服务所描述的基于客户身份和委托的授权；——持久性状态管理。组件模型与EJB的映射使得EJB可以在一个提供激活、事务、安全和持久性等服务的容器中被作为CORBA组件来支持。为了在CORBA容器中自然地支持EJB，需要EJBJavaAPI和对应于CORBAAPI的Java映射之间的一个转换。反之，一个把自身限制在EJB规范定义的功能内，并且是用Java编写的CORBA组件应该可以部署在EJB容器中。CORBA容器是一些运行时上下文，它为客户端提供接口，并为组件实例提供双向（限于本地）接口，这些双向接口抽象出组件实现用的系统服务。容器将提供策略和/或API来支持事务、安全、状态管理和持久性。例如，事务和安全策略在组件部署描述符中定义。容器使用这些描述在调用所请求的对组件的操作之前恰当地调用CORBA事务服务和CORBA安全性。容器为其组件提供以下功能：——所有的组件实例在运行时都由其容器创建和管理；——某些元数据（例如，事务、安全性、事件和持久性）和组件的实现是分开的，这样就可以在部署之前先操纵它们；——可以通过编辑组件的元数据来定制该组件；——客户端对组件所提供的接口的访问由部署该组件的容器委托；——容器为组件提供标准的一组系统服务，使该组件可以在不同的容器中实现。®A.4MicrosoftCOM/DCOMMicrosoft的组件对象模型（COM：ComponentObjectModel）最初是为了支持Windows平台［4］上桌面应用程序的集成而开发的。COM是Microsoft在把其OLE（对象链接与嵌入）从第1版改进到第2版的工作中所取得的成果之一。COM最初并不支持分布环境。支持分布的COM版本称为DCOM。COM/DCOM所解决的问题是帮助把一个由一个或多个类组成的软件系统划分为一些可以彼此独立地开发和维护的分离的包。COM对组件的支持相当简单，由两个主要部分组成：1）一种称为Microsoft接口定义语言（MIDL：MicrosoftInterfaceDefinitionLanguage）的接口描述语言和一些支持把MIDL代码转换为C++或VisualBasic接口描述的工具；2）支持查找和激活组件的一个运行时环境。DCOM在运行时环境中还增加了远程通信支持。Microsoft已经在COM/DCOM顶层增加了一组标准接口，提供各种各样的系统功能和服务，如回调（可连接的对象）、持久性、简单的命名服务（monikers）、类型库和动态接口调用（OLEAutomation）等。这些接口及其运行时支持和COM/DCOM形成了OLE2.0。COM现在正扩展成为一个称为COM+的完全的组件执行系统。COM+支持简化的组件开发、简化的组件安装、事务处理、事件、发布与订阅和消息队列。利用COM+，Microsoft定义了逻辑的和物理的包装。逻辑包装是把各个类和接口拆分到一些分离的名字空间，以减少人可读类名的冲突。物理包装是部署单位，对应实际的组件或模块，一般是一个或多个可执行模块（.EXE）或动态链接装载模块（.DLL）。在由DLL实现类（和纯代理DLL不同）的情况下，装载进程可以看成是一个容器，特别是当这个装载进程只包含基本的或框架的功能时更是如此。一个组件或模块一般实现一个或多个类以及接口。对于组件或模块如何实现类或接口，并没有什么限制。这是实现者的选择。COM/DCOM也可以用于其他计算机平台，如DigitalUnix和Solaris。COM/DCOM底层支持的可移植性相当强。而和Windows桌面关联的功能（如注册）的可移植性差。A.5XMLWeb服务和Microsoft.NET20 DL/T890.1—2007XMLWeb服务为任意到任意的集成提供了一种基于互联网的集成模型。XMLWeb服务允许采用任意操作系统和编程语言的应用可以通过互联网进行通信和共享数据，如同组件一样。XMLWeb服务为任意到任意的集成提供了一种基于互联网的集成模型。其主要服务是：——UDDI（通用描述与发现信息）——发布和寻找其他服务；——XML和HTTP——通信和数据内容；——SOAP（简单对象访问协议）——基于事务的服务，用于交换信息和跨越分布式应用调用服务。.NET是微软的一种可以在任何地方提供XMLWeb服务的策略和产品，本质上是为XMLWeb服务提供的平台。创建XMLWeb服务平台需要专注于5个关键方面：a）客户端——能识别XML的所有类型的PC和智能设备。b）服务——例如为任何Web站点提供单一登录能力的Microsoft.Net的身份认证服务。c）服务器——集成的成套工具，用于运行、管理、协调Web服务和能够存储、路由、转换和桥接原有数据的各种应用。d）开发工具——例如VisualStudio.NET和.NETFramework。e）经验和解决方案——组合最好的本地服务和互联网服务。.NET是致力于所有这些方面的微软软件平台。微软.NET平台包含了建立在XML和互联网工业标准上的一个综合产品系列，用于开发、管理、使用以及体验XMLWeb服务的每一个方面。.NET框架是一个高效、基于标准、多语言的应用执行环境，提供基本的基础设施服务和轻松的配置。它提供一个应用执行环境用来管理内存、处理版本问题、改进应用的可靠性、可升级性和安全性。.NET框架由几个部分组成，包括公共语言运行时、构建XMLWeb服务用的一组丰富的类库和ASP.NET。21 DL/T890.1—2007附录B（资料性附录）典型应用和功能表B.1典型应用和功能应用类别执行者（操作员）应用名注释/说明SCADA现场操作员、变电站操作员时间同步（Time同步RTU时标synchronization）RTU和PLC通信（RTUandPLC使用RP570，IEC60870-5-101获取现场数communication）据远程中心通信（Remotecenter使用ICCP、ELCOM等进行站点间通信communication）滤波、比例变换、工程单位变换、质量检信号处理（Signalprocessing）查、限值检查通用计算、状态、模拟和累加器值、质数据处理（Dataprocessing）量处理用来在SCADA中表示的任意的现实世界对加时标（Tagging）象上加时标单线图（Singlelinediagrams）基于页的图形化过程显示状态列表（Statuslists）SCADA/EMS对象的状态报告监控（Supervisorycontrol）设备和顺序控制（互锁与非互锁）系统控制（Systemcontrol）站点间控制（Intersitecontrol）限值管理（Limitmanagement）限值集的动态条件选择带时标数据处理（Timetagged在表格或趋势显示中带时标数据的收集、dataprocessing）存储和表示故障数据采集（Disturbance事件顺序记录和事故追忆datacollection）设备统计（Equipment设备运行累计statistics）倒闸操作计划（Switchingschedules）22 DL/T890.1—2007报警处理（AlarmProcessing）报警和事件处理表B.1（续）应用类别执行者（操作员）应用名注释/说明分析设备连接性和带电状态并构建母线模输电操作员，控制区域拓扑处理（Topologyprocessing）型以支持网络功能和在用户显示上的连接表操作员示。可能包括用于故障分析的接地分析一组电力系统安全分析、安全强化和网络输电操作员、输电分析网络应用（NetworkApplications）优化工具员、控制区域操作员状态估计（Stateestimator）包括网络参数更新和母线负荷潮流网络等值（Network通过有限数据计算等值网络equivalents）对电力系统设备损耗、发电变化、母线负调度员潮流（Dispatcher荷变化和系统或其他区域量（负荷、发电、交Powerflow）换和电压）的变化的研究功能安全约束调度（Security用于计算安全约束命令和事故的OPFconstraineddispatch）短路电流分析（Shortcircuitanalysis）安全分析（SA）（Security事故筛选与评估analysis）网络灵敏度（Network罚因子计算sensitivity）功率传输能力（Powertransfercapability）动态安全分析（Dynamicsecurityanalysis）过网输电评估（Wheelingtransferevaluation）安全校正调度（Security用来计算安全约束命令和事故的OPFremedialdispatch）暂态稳定（Transientstability）网络化简（Networkreduction）23 DL/T890.1—2007网络参数适配（母线计划）［Networkparameteradaptation（busscheduler）］可用输电能力（ATC）（AvailableTransmissionCapacity）最优潮流（OPF）（OptimalPowerFlow）安全约束OPF（SecurityconstrainedOPF）地域定价分析（LocationDependentPricingAnalysis）安全校核投切（Security操作前核对和对命令互锁的调度员潮流CheckedSwitching）DLF表B.1（续）应用类别执行者（操作员）应用名注释/说明电压稳定性评估（Voltagestabilityassessment）输电损耗评价（Transmission网络损耗因数计算lossevaluation）输电操作员、输电分析员、控制区域操作员阻塞分析（Congestionanalysis）恢复辅助决策（RestorationAssistance）状态监视（Statemonitor）监视系统工况以证实电力系统正在按照当前的策略和规程运行倒闸操作方案（SwitchingScenarios）计划（Schedules）电压-无功调度（VoltageVAR为满足电网电压计划曲线图需求进行的调度dispatch）网络安全监视（Network监视系统工况以证实电力系统正在按照当前的策略和规程运行，识别接securitymonitoring）近运行极限的设备负荷管理（Loadmanagement）这是新的应用类别甩负荷（Loadshedding）按轮次和成片甩负荷对负的发电出力或PRL（易随价格变动的负荷计划（Loadscheduling）负荷）的计划24 DL/T890.1—2007发电控制（电力应用软件）［Generationcontrol（powerapplications）］计算区域控制误差（ACE）以自动调整本AGC电力企业控制区域内的发电机出力，且必要时发布警报经济调度/动态调度（Economicdispatch/dynamicdispatch）经济约束调度（Constrainedeconomicdispatch）电厂操作员备用监视（Reservemonitor）跟踪可用的备用，当存在短缺时就报警生产成本计算（Productioncosting）发电分配与机组控制（Generationallocationandunitcontrol）负荷频率控制（LFC）（LoadFrequencyControl）控制性能监视（Control从原始的ACE值监视AGCperformancemonitor）表B.1（续）应用类别执行者（操作员）应用名注释/说明交换交易评价A（Interchange使用相同机组，小时进行短期交易电厂操作员TransactionEvaluationA）燃料优化（Fueloptimization）频率计划（FrequencyAGC功能所需要的频率计划信息scheduling）根据历史的负荷和气象数据以及预报的负荷预报（Loadforecast）气象数据提供负荷预报，可包含每小时的短期负荷趋势发电预报（Generationforecast）提供发电预报电能量/输电计划输电/电力市场人员（Energy/transmissionscheduling）25 DL/T890.1—2007交换交易计划（Interchange运行规划人员transactionscheduler）交换交易评价B（Interchange较长期改变的机组，天数电能量计划人员transactionevaluationB）输电计划（Transmission系统规划人员（长期）scheduler）机组经济组合（Unit计划协调人员commitment）安全约束机组经济组合（Security-constrainedunitcommitment）多区域机组经济组合（Multi-areaunitcommitment）交易评价（Transaction电能量与输电交易批发电力市场人员evaluation）水火电优化/协调（Hydrothermaloptimization/coordination）水电计划（Hydroscheduling）长期运行规划（Longtermoperationalplanning）来水预报（InflowForecast）合同管理（Contract数据库和提取合同信息的工具management）检修计划（Maintenancescheduling）建设/检修监管人员停运计划（Outagescheduler）输电设备的预计划停运检修计划人员表B.1（续）应用类别执行者（操作员）应用名注释/说明输电资源管理（TransmissionATC计算和评估交换交易对电力系统的影响，以及跟踪售出的输电容量，resourcemanagement）可包括输电权合同结算/开账单（输电）监会计结算（Accountingsettlements）管人员26 DL/T890.1—2007费率处理（Tariffprocessing）支持一天不同时段的不同费率会计报表（Accountreports）电量计费（Energyaccounting）每小时读数和平衡历史数据信息系统（数据仓库应用）1）状态数据（例如每小时的负荷值）和状HIS（存档）态变化数据（例如可报警事件）；2）审计数据；3）为满足周期存档要求的数据数据工程（Dataengineering）数据库维护工程师系统管理员（一般的用户接口）（Genericuserinterface）动态仿真（Dynamicsimulation）网络的动态仿真，时间步长短于OTS调度员培训仿真（DTS）（Dispatchertrainingsimulator）教员接口与培训过程控制包括基本案例保存（永久案例保存）和教（Instructorinterfaceandsession员支持功能（场景构建）control）培训教员电力系统模型/仿真器（Powersystemmodel/simulator）数据采集系统仿真器（Dataacquisitionsystemsimulator）市场运营（Marketoperations）区域边际价格（Locational区域边际价格计算marginalprices）发送数据到开放访问即时信息系统OASIS（OASIS）和从中提取数据的接口表B.1（续）应用类别执行者（操作员）应用名注释/说明电子标记（E-Tag）交易电子标记27 DL/T890.1—2007a）其他（Other）外部（External）DMS气象（Weather）趸售电力市场（Wholesalepowermarketing）a）本部分发布时正在发展的一组功能。独立系统运行机构（ISO）和区域输电机构（RTO）将需要平衡电能供应（Balancing）、结算（settlement）、客户负荷曲线（customerloadprofile）等功能。28 DL/T890.1—2007附录C（资料性附录）电力企业使用标准组件模型的有关问题电力企业实时应用所需要的所有服务不可能都作为标准容器的服务提供。特别是，下列的服务不能够现成地从中间件厂商那里买到：a）信息交换模型访问服务：这一服务使得分布的组件能进入和发现注册的组件所使用的公共模型交换语法（例如，交换的格式和类型），而且在出现变化时被通知。b）基于目录的服务：这些服务使得能访问系统中全部可用的初始的和运行期的对象与服务。在这一服务中可以定义基于特定性质的不同视图。例如，可以对某些关键项目定义一个配置性质视图，用来和运行时性质视图进行比较以确定这些项目是否出现在服务中。这一目录还包含有组件的ID、业务对象模板（类）和实例等。c）资源ID工厂：这一服务允许创建一个唯一的ID和一些电力系统对象实例关联。由于每种类型有特殊的规则，可能有多种ID类型。例如，当把一个设备看作一件资产时，可以有一个ID在其整个生命期和该设备关联，而和该资产在电力系统网络中的使用位置无关。还可以有另一种类型的ID和电力系统网络中的一个拓扑位置关联且与该位置共存，而与该位置关联的特殊设备资产无关。d）系统管理（SystemAdministration）：这一服务接口允许管理和监视在服务中的交换和组件。组件故障和负荷平衡也是这一服务的内容。用于系统可靠运行的系统状态监视也是这一服务的内容。e）基于公共模型的配置：这一服务提供一个接口，使组件可以在启动时或在运行中对一个组件进行部分本地配置后从一个持久的数据存储中得到它们的基于公共模型的配置。f）基于公共模型的过滤：这一服务允许根据交换的类型和内容定义和应用过滤器。g）对DL890.4××CISAPI的本地化支持：DL890.4××系列描述用于在控制中心组件间交换信息的API。对这些API的支持，使得遵从DL890.4××的组件只须最少量的定制编程即可插入到集成基础设施中。h）其他服务将随着DL890.4××CIS标准的发展而确定。提供这些服务的一些可供选择的方案是：1）作为在已有容器中运行的新组件来得到这些服务。如果选择这一方案，其他的组件需要知道这些服务，以便注册来使用它们。2）修改或扩展现有的容器来为那些组件提供这些服务，类似于事务或命名服务。3）作为组件适配器层的一部分来实现，这样，这一适配器层将有两个主要的作用：——提供电力企业特定的服务；——给为其他执行系统环境设计的组件提供容器API转换。29 DL/T890.1—2007附录D（资料性附录）组件执行系统和中间件产品举例D.1典型的组件执行系统组件执行系统（也称为容器系统）包括遵守系统所采用的组件模型的容器约定与策略的已有的各种中间件产品。已经实现了容器API的中间件产品的例子包括：10）——CORBA平台，如BorlandVisiBroker或IonaOrbix。——组件事务服务器（CTS），如SybaseJaguarCTS或MicrosoftTransactionServer。——事务处理器（TP）监视器，包含事务和代表事务管理共享资源。这样多个事务能够一起工作，依靠TP监视器来协调扩展的事务。例子包括IBMTXSeries（CICS和Encina）和BEATuxedo。——Web服务器，包含Web页请求。多个Web客户能够向Web服务器提交当前页请求。作为响应，Web服务器提供HTML页或通过公共图形接口（CGI）脚本或小服务（servlet）调用其他功能。例子包括JavaWebServer，NetscapeEnterpriseServer或OracleApplicationServer。——数据库管理系统（DBMS），包括数据库请求。多个数据库客户可以同时向数据库提交请求并依靠DBMS来协调锁定和事务。例子包括Oracle、Sybase或IBMDB2。——任何其他遵循支持组件容器约定的执行系统框架。例如，EMS供应商可以将EMS应用执行系统设计成支持容器，这样既可以使用内部开发的组件，也可以使用从其他组件供应商购买的组件。组件执行系统一般是由系统供应商提供。D.2典型的中间件产品基于专有的和事实标准的中间件例子包括：——数据库访问中间件和网关产品［如开放数据库连接（ODBC），InformationBuildersSQL等］；——应用间通信中间件，如CORBAORBs、面向消息的中间件（如Vitria、ActiveSoftware，Tibco等），TP监视器。10）附录中提及的BorlandVisiBroker和其他商标名字是合适的商业产品的例子，这些信息给使用该标准的用户提供便利，并不意味着这些产品被标准认可。30 DL/T890.1—2007参考文献1.IEC61968（allparts），Applicationintegrationatelectricutilities–Systeminterfacefordistributionmanagement.2.EnterpriseJavaBeansSpecification，Version2.1，FinalRelease，November12，2003，availablefromSunMicrosystem，inc.，4150NetworkCircle，SantaClara，California95054，U.S.A..3.CORBAComponents，Version3.0，formal/02-06-65，June2002，availablefromtheObjectManagementGroup（OMG）atwww.omg.org.4.TheComponentObjectModelSpecification，DraftVersion0.9，October24，1995，availablefromtheMicrosoftCorporation.5.GuidelinesforControlCenterApplicationProgramInterfaces，EPRITechnicalReportTR-106324，Project3654-01，FinalReport，June1996.31'