Iec ts 62746 3 2015

I E C TS 62 46-3 ® Edition 201 5-1 TE C H N I C AL S P E C I F I C ATI ON colour i n sid e S ys tem s i n terface between cu s tom er en erg y m an ag e m e n t s ys tem an d th e power m an ag em en t s ys te m – IEC TS 62746-3:201 5-1 0(en) P art 3: Arch i te ctu re T H I S P U B L I C AT I O N I S C O P YRI G H T P RO T E C T E D C o p yri g h t © I E C , G e n e v a , S wi tz e rl a n d All rights reserved Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from either IEC or IEC's member National Committee in the country of the requester If you have any questions about I EC copyright or have an enquiry about obtaining additional rights to this publication, please contact the address below or your local I EC member National Committee for further information IEC Central Office 3, rue de Varembé CH-1 21 Geneva 20 Switzerland Tel.: +41 22 91 02 1 Fax: +41 22 91 03 00 info@iec.ch www.iec.ch Ab ou t th e I E C The I nternational Electrotechnical Commission (I EC) is the leading global organization that prepares and publishes I nternational Standards for all electrical, electronic and related technologies Ab o u t I E C p u b l i ca ti o n s The technical content of IEC publications is kept under constant review by the IEC Please make sure that you have the latest edition, a corrigenda or an amendment might have been published I E C Catal og u e - webstore i ec ch /catal og u e The stand-alone application for consulting the entire bibliographical information on IEC International Standards, Technical Specifications, Technical Reports and other documents Available for PC, Mac OS, Android Tablets and iPad I E C pu bl i cati on s s earch - www i ec ch /search pu b The advanced search enables to find IEC publications by a variety of criteria (reference number, text, technical committee,…) It also gives information on projects, replaced and withdrawn publications E l ectroped i a - www el ectroped i a org The world's leading online dictionary of electronic and electrical terms containing more than 30 000 terms and definitions in English and French, with equivalent terms in additional languages Also known as the International Electrotechnical Vocabulary (IEV) online I E C G l os sary - s td i ec ch /g l oss ary More than 60 000 electrotechnical terminology entries in English and French extracted from the Terms and Definitions clause of IEC publications issued since 2002 Some entries have been collected from earlier publications of IEC TC 37, 77, 86 and CISPR I E C J u st Pu bl i s h ed - webstore i ec ch /j u stpu bl i sh ed Stay up to date on all new IEC publications Just Published details all new publications released Available online and also once a month by email I E C C u stom er S ervi ce C en tre - webstore i ec ch /csc If you wish to give us your feedback on this publication or need further assistance, please contact the Customer Service Centre: csc@iec.ch I E C TS 62 46-3 ® Edition 201 5-1 TE C H N I C AL S P E C I F I C ATI ON colour i n sid e S ys tem s i n te rface between cu s tom er e n erg y m an ag em en t s ys tem an d th e power m an ag em en t s ys te m – P art 3: Arch i tectu re INTERNATIONAL ELECTROTECHNICAL COMMISSION ICS 33.200 ISBN 978-2-8322-2951 -4 Warn i n g ! M ake su re th a t you obtai n ed th i s pu bl i cati on from an au th ori zed d i s tri bu tor ® Registered trademark of the International Electrotechnical Commission –2– I EC TS 62746-3:201  I EC 201 CONTENTS FOREWORD I NTRODUCTI ON Scope Norm ative references Terms, definitions and abbreviations Terms and definitions Abbreviations Architectural overview Application area Actors, roles and relationships 1 Concepts 4 Components/Entities 5 Message transport and services 20 Transport requirements 20 Supporting m essaging standards 21 Message payloads 21 Message construction 22 5 Messaging patterns 23 5 General 23 5 Transactional request/repl y message patterns 23 5 Query request/reply messages 24 5 Event Messages 25 5 Presence 27 Publish/subscribe messaging 27 Security 28 Scalability and availability 29 Annex A (informative) Requirements 31 A General 31 A Principles 31 A Additional comm unication-specific functional requirem ents 31 A Non-functional requirem ents 32 Annex B (informative) Message payload profiles 34 Bibliograph y 35 Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure – Relationship of I EC 62746 to other standards – Resource-level view 1 – High-level exam ple of actors, roles and relationships – Exam ple Com munication Dom ain hierarch y – Expanded communication domain exam ple including operations – Communication dom ain – Exam ple realization of VTNs and VENs in multiple comm unication dom ains – Exam ple for multiple comm unication dom ains – Technical space of a single communication domain in I EC 62746 – Example application of I EC 62746 I EC TS 62746-3:201 Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure  I EC 201 –3– 1 – CEM and resource relationships 20 – Example payload 22 – Transactional request/repl y initiated by VTN 24 – Transaction request/repl y initiated by VEN 24 – Query request initiated by VTN 25 – Query request initiated by VEN 25 – Example of VTN initiated events 26 – VEN initiated events 26 – Example of publish/subscribe nodes 27 20 – Security overview 29 21 – Configuration for scalability and availability 30 B – Profile structure 34 –4– I EC TS 62746-3:201  I EC 201 INTERNATI ONAL ELECTROTECHNI CAL COMMISSI ON S YS T E M S I N T E RF AC E B E T WE E N M AN AG E M E N T S YS T E M C U S T O M E R E N E RG Y AN D T H E P O W E R M AN AG E M E N T S YS T E M – P a rt : Arc h i te c t u re FOREWORD ) The I nternati on al Electrotechni cal Comm ission (I EC) is a worl d wid e organization for stan dardization com prisin g all n ation al el ectrotechnical comm ittees (I EC National Comm ittees) The object of I EC is to prom ote internati onal co-operation on all q uestions concerni ng stand ardi zati on in the el ectrical an d electronic fi elds To this en d and in additi on to other acti vities, I EC pu blish es I nternational Stan dards, Techn ical Specificati ons, Technical Reports, Publicl y Avail abl e Specificati ons (PAS) and Gu ides (h ereafter referred to as “I EC Publication(s)”) Th ei r preparation is entrusted to tech nical comm ittees; any I EC N ational Comm ittee interested in the subj ect dealt with m ay partici pate in this preparatory work I nternational, governm ental an d n on governm ental organ izations l iaising with th e I EC also participate i n this preparation I EC collaborates closel y with the I nternational Organi zation for Stand ardization (I SO) in accordance with ditions determ ined by agreem ent between th e two organi zati ons 2) The form al decisions or ag reem ents of I EC on tech nical m atters express, as n early as possible, an i nternati onal consensus of opi nion on the rel evant subjects since each technical com m ittee has representati on from all interested I EC N ational Com m ittees 3) I EC Publications have the form of recom m endations for intern ational use an d are accepted by I EC National Com m ittees in that sense While all reasonable efforts are m ade to ensure that th e tech nical content of I EC Publications is accu rate, I EC cann ot be h eld responsi ble for th e way in which th ey are used or for an y m isinterpretation by an y en d u ser 4) I n order to prom ote intern ational u niform ity, I EC National Com m ittees und ertake to apply I EC Publications transparentl y to the m axim um extent possible i n their national an d regi on al publicati ons Any d ivergence between an y I EC Publication and the correspondi ng national or regi on al publicati on sh all be clearl y in dicated in the latter 5) I EC itself d oes n ot provi de an y attestation of conform ity I n depend ent certificati on bodies provi de conform ity assessm ent services and, in som e areas, access to I EC m arks of conform ity I EC is not responsi ble for any services carri ed out by ind ependent certification bodi es 6) All users shou ld ensure that they h ave the l atest editi on of thi s publicati on 7) No liability shal l attach to I EC or its directors, em ployees, servants or ag ents inclu din g in divi dual experts an d m em bers of its tech nical com m ittees and I EC Nati on al Com m ittees for any person al i nju ry, property d am age or other dam age of any n ature whatsoever, wheth er di rect or indirect, or for costs (includ i ng leg al fees) and expenses arisi ng out of the publ ication, use of, or relian ce upon, this I EC Publicati on or any other I EC Publications 8) Attention is drawn to th e N orm ative references cited in th is publ ication Use of the referenced publ ications is indispensable for the correct applicati on of this publication 9) Attention is drawn to the possibility that som e of the elem ents of this I EC Publication m ay be the su bject of patent rig hts I EC shall not be held responsibl e for identifyi ng any or all such patent ri ghts The main task of I EC technical comm ittees is to prepare I nternational Standards I n exceptional circumstances, a technical committee may propose the publication of a technical specification when • • the required support cannot be obtained for the publication of an I nternational Standard, despite repeated efforts, or the subj ect is still under technical development or where, for an y other reason, there is the future but no imm ediate possibility of an agreem ent on an I nternational Standard Technical specifications are subj ect to review within three years of publication to decide whether they can be transform ed into I nternational Standards I EC TS 62746-3, which is a technical specification, has been prepared by I EC technical comm ittee 57: Power system s management and associated inform ation exchange I EC TS 62746-3:201  I EC 201 –5– The text of this technical specification is based on the following docum ents: Enqui ry draft Report on votin g 57/1 527/DTS 57/1 61 0/RVC Full inform ation on the voting for the approval of this technical specification can be found in the report on voting indicated in the above table This publication has been drafted in accordance with the I SO/I EC Directives, Part A list of all parts in the I EC 62746 series, published under the general title Systems interface between customer energy management system and the power management system , can be found on the I EC website The comm ittee has decided that the contents of this publication will remain unchanged until the stability date indicated on the I EC website under "http: //webstore iec.ch" in the data related to the specific publication At this date, the publication will be • • • • • transformed into an I nternational standard, reconfirm ed, withdrawn, replaced by a revised edition, or amended A bilingual version of this publication may be issued at a later date I M P O R T AN T th a t it – Th e tai n s u n d e rs t a n d i n g c o l o u r p ri n t e r of ' col ou r i n s i d e' c o l o u rs i ts wh i ch c o n te n ts l og o a re U s e rs on th e cove r p ag e c o n s i d e re d sh ou ld to t h e re fo re o f th i s be p ri n t p u b l i cati o n u s e fu l th i s fo r i n d i cate s th e d o cu m en t c o rre c t u si n g a –6– I EC TS 62746-3:201  I EC 201 INTRODUCTION The purpose of this part of I EC 62746 is to define an architecture for I EC 62746 series of standards that can be leveraged for the m anagem ent of customer energ y resources and DER These resources m ay be a com bination of load , generation and storage resources that can be managed to respond to signals provided by grid and/or market operators These resources may be identified and managed as individual resources with specific capabilities, or as virtual resources with an aggregated set of capabilities The focus of this architecture is to leverage the I nternet for communications between grid operators, m arket operators, distribution system operators, electricity suppliers, aggregators, service providers and energy resources This Technical Specification leverages existing I EC standards The data model of I EC 62746 is based on the Common I nformation Model and I EC 61 850 I EC 62746 is transportindependent Figure shows the relationship of I EC 62746 to other I EC and I SO standards IEC F i g u re – R e l a t i o n s h i p o f I E C t o o t h e r s t a n d a rd s I EC TS 62746-3:201  I EC 201 –7– S YS T E M S I N T E RF AC E B E T WE E N M AN AG E M E N T S YS T E M P a rt : C U S T O M E R E N E RG Y AN D T H E P O W E R M AN AG E M E N T S YS T E M – Arc h i te c t u re S cop e This part of I EC 62746, which is a Technical Specification, establishes an architecture that is supportive of interfaces between the Customer Energ y M anagem ent System and the Power Managem ent System A DER Managem ent System can also be a Customer Energy Management System N o rm a t i ve re fe re n c e s The following docum ents, in whole or in part, are norm ativel y referenced in this docum ent and are indispensable for its application For dated references, onl y the edition cited applies For undated references, the latest edition of the referenced docum ent (including an y amendments) applies I EC 61 968-9: 201 3, Application integration at electric utilities – System interfaces for distribution management – Part 9: Interfaces for meter reading and control I EC 61 968-1 00, Application integration at electric utilities – System interfaces for distribution management – Part 100: Implementation profiles I EC 62351 (all parts), Power systems management and associated information exchange – Data and communications security IEC TR 62746-2: 201 5, Systems interface between customer energy management system and the power management system – Part 2: Use cases and requirements IEC 62443 (all parts), Industrial communication networks – Network and system security T e rm s , d e fi n i t i o n s a n d a b b re vi a t i o n s For the purposes of this docum ent, the following terms, definitions and abbreviations appl y T e rm s a n d d e fi n i t i o n s a g g re g a t i o n collection of the capabilities of m ultiple resources into a single virtual resource Note to entry: A comm on u se of agg regati on is to collect m any sm all resources an d offer th eir capabiliti es i n the form of a single l arg er resource to a m arket ca s ca d i n g event which occurs when a message published in one communication dom ain causes another message to be published in one or more other comm unication dom ains at a different level of a hierarch y –8– I EC TS 62746-3:201  I EC 201 3.1 communication domain logical association of a VTN with a set of VENs supported by an underlying communication infrastructure Note to entry: This provid es for authentication of VENs and secu re comm unication services Since VTN and VEN are roles within a Comm unication Dom ain, it is possible for an actor to take a VTN rol e in on e Com m unication Dom ain an d potenti all y on e or m ore VEN rol es in oth er Com munication Dom ains Note to entry: This term is defin ed by this tech nical specification 3.1 customer energy manager CEM central m anaging function used by the custom er to manage the flow of information between the grid and connected smart devices at the custom er prem ises Note to entry: This is defin ed in m ore d etail i n I EC TR 62746-2 3.1 demand response DR incentivizing of custom ers by costs, ecological information or others in order to initiate a change in their consumption or feed-in pattern (“bottom -up approach” = Custom er decides, based on EURELECTRI C Views on Demand-Side Participation [1 ]) Note to entry: Alternati ve d efinition: I n I EC 60050-61 7: 2009, 61 7-04-1 it is d efin ed as: action resultin g from m anagem ent of the electricity dem and in response to su ppl y conditions 3.1 distributed energy resource specialized energ y resource with a flexible load and/or suppl y generall y at the distribution level 3.1 message m ethod of conveying information between parties in a comm unication network Note to entry: The inform ati on m ay refl ect a descri ption of an object an d/or data rel ated to the object 3.1 node logical destination address for messages that are published using a publish/subscribe communication infrastructure Note to entry: Dependi ng upon the specific comm unication infrastructu re this m ay also be called a ‘topic’ or ‘subject’ 3.1 publish/subscribe communication pattern where a m essage sent from a source may be received by zero or m ore interested subscribers SEE: I EC 61 968-1 00 3.1 request/reply communication pattern where a request m essage is sent from one process to another process, where there is that the expectation that a response message will be returned by the receiver of the request m essage SEE: I EC 61 968-1 00 – 24 – I EC TS 62746-3:201  I EC 201 IEC Figu re – Transactional request/reply initiated by VTN Where Figure describes the transaction being initiated by the VTN, Figure shows a similar pattern where the transaction is initiated by the VEN IEC Figu re – Transaction requ est/reply initiated by VEN 5.5.3 Query request/reply messages Query request/reply m essage patterns are used where the initiator is requesting that specific inform ation be returned by the target I n terms of I EC 61 968-1 00, this involves the use of the ‘get’ verb within the I EC 61 968-1 00 message envelope Figure describes the interactions where the query is initiated by the VTN to a VEN I EC TS 62746-3:201  I EC 201 – 25 – IEC Figure – Query requ est initiated by VTN Figure describes the interactions where the query is initiated by a VEN to the VTN IEC Figu re – Query request initiated by VEN 5.5.4 Event M essages Within I EC 62746 there are two categories of event messages The first case is where VENs subscribe to content of interest and corresponding events are then published by the VTN Figure provides an exam ple where a set of interested VENs subscribe to information that might be published to a defined ‘node’, which then enables a copy of related events to be sent to the VEN when published VENs that not subscribe will not get a copy of the event – 26 – I EC TS 62746-3:201  I EC 201 IEC Figu re – Example of VTN initiated events The second category are events that are initiated by a VEN use a simpler pattern, as they are simpl y a message from the VEN directl y to the VTN and not require the use of a multicasted publish/subscribe This is described in Figure IEC Figure – VEN initiated events I EC TS 62746-3:201 5.5.5  I EC 201 – 27 – Presence Presence m essages are used to report the state of a VEN These are published by a VEN to the comm unication infrastructure These may represent a change in state of the VEN, or simpl y be reflective of a periodic heartbeat to the communication infrastructure 5.6 Publish/subscribe messaging Event messages may be initiated from a VTN to man y VENs Because the message has m ore than one destination, publish/subscribe m essaging is needed The logical address of a publish/subscribe m essage is specified using a logicall y named ‘node’, which is equivalent to a J MS topic I n this pattern, VENs subscribe to one or m ore well known ‘nodes’ When using publish/subscribe m essaging, the messages are addressed to defined nodes Once these nodes are defined, the VENs m ay subscribe to them N odes m ay be organized hierarchically An exam ple is provided in Figure IEC Figure – Example of publish/subscribe nodes – 28 – I EC TS 62746-3:201  I EC 201 Security Cyber security is a key issue for this Technical Specification, especiall y given the need for many parties to interact over the I nternet Ph ysical security is outside the scope of this Technical Specification The com munication server functionality described in this clause may be implem ented in the VTN Special attention shall be given to I EC 62351 and I EC 62443 The security requirements for private networks have to be exam ined on a case by case basis For VENs to accept inbound connections, ports would need to be opened in firewalls creating many points of vulnerabilities However, this problem may be avoided if all connections are made out bound to a comm unications server in a DMZ or cloud The communications server is then responsible for authentication, protecting against DoS, etc Figure 20 describes the relationships between VTNs, VENs, a communication server and network infrastructure Each VTN and each VEN shall have an account on a comm unication server I n the case where a VEN belongs to more than one com munication dom ain it m ay have a separate account for each domain The com munication server and the VTNs and the VENs are authenticated by certificates or other suitable means A VTN m ay include the comm unication server functionality Role-based access control shall be used to manage the privileges to access and m anage the virtual resource An account can be assigned one or m ore roles The roles m ay dictate which specific information or actions are perm itted As an example, access to specific publish/subscribe nodes is controlled by role VTNs and VENs shall allow the assignment of individual properties of virtual resources to one or m ore roles The communication between the comm unication server and the VTNs and the VENs is secured using mechanism s such as mutuall y authenticated TLS N on-repudiation shall be supported The details of the security implem entation are defined as a part of the transportspecific m appings The communication server is a trusted entity for all other parties to forward messages including information on groups for comm unication, generate event notification, and store pub/sub information The implications of key management shall also be addressed as a part of the transport-specific m appings The objective of the design shall be to minimize the security burden for the VEN ’s and VTNs as much as possible, however the security requirements for VTNs and VENs connected to the Internet remain significant I f a VTN includes comm unication server functionality it inherits the corresponding security requirements The main burden of security is on the com munication server side This includes protection against attacks from the internet like port scans, denial of service or similar attacks which is very resource consum ing I EC TS 62746-3:201  I EC 201 – 29 – Internet Private Network VEN Private Network DMZ (or Cloud) Communication Server(s) VTN Private Network VEN Private Network VEN IEC Figu re 20 – Security overview The diagram shows three types of network segm ents: • Private networks, which may be networks provided by a customer or market operator • • and shall rem ain protected from inbound connections I nternet, which is viewed as an unsecure comm unication infrastructure A DMZ or cloud used for the deployment of a supporting communications server This will allow inbound connections on designated comm unications ports using secure authentication mechanisms Firewall capabilities may be leveraged to further protect the com munication server from denial of service attacks Scalability and availability The com munication server functionality described in this clause m ay be im plemented in the VTN Scalability and availability are largel y accomplished by the additiona of communication servers, where the communication to VENs is federated among the comm unication servers The communication server shall provide availability by redundancy of the servers themselves and associated databases or other means as in server cluster For scalability the distribution of messages is done by the com munication server Requests for pub/sub data or m eta data are handled by the com munication server, e.g if a VTN provides a real tim e price then this price is forwarded by the comm unication server to all addresses VENs The communication server may be realized as a server cluster – 30 – VEN I EC TS 62746-3:201  I EC 201 VEN VEN Com m unication Server VEN VTN VEN Com m unication Server VEN VEN VEN IEC Figure 21 – Configuration for scalability and availability Availability of VTNs has to be addressed by the VTNs themselves, e g by redundancy I EC TS 62746-3:201  I EC 201 – 31 – An nex A (informative) Requ i remen ts A General The requirem ents are made on the background of mainl y comm ercial use cases Additional requirements from operations m ay be added A Pri nci pl es The following are key architectural principles to be followed for this Technical Specification, which are at least in part a distillation of the functional and non-functional requirem ents • • • • • • • Possibilities of cyber attacks crossing the interfaces are to be prevented I nterfaces shall be based upon open technologies and standards I nterfaces shall be based upon or permit the use of comm on software technologies I nterfaces shall be inherently extensible, allowing for new application messages to be defined over tim e as well as the introduction of new elem ents into existing m essages I nterface developm ent shall be agnostic with respect to programming languages and operating systems, but at the sam e tim e shall not preclude the use of Java, C ++ , C#, Python, Linux, Windows, Android, etc I nterface specifications shall be agnostic with respect to communication technology in order to allow for multiple protocol m appings Shall establish a low end technology threshold for end point devices and related software com ponents in order to avoid lim iting the capabilities and technical reach of the architecture in order to support ‘constrained’ devices that can not readil y support I nternet-based comm unications I t is the intent that these principles will provide an architecture that will be viable for decades into the future A Ad di ti on al communi cati on -speci fi c functi onal requi rem ents The functional requirem ents for I EC TS 62746-3 are to som e extent defined within IEC TR 62746-2 The focus of this subclause is to describe additional functional requirements that are more focused on the functionality to be provided by the interfaces and functional responsibilities associated with the technical roles defined by this Technical Specification The architecture is intended to address a set of im portant functional requirements as related to comm unications directl y to and indirectl y in support of devices that may be connected to the electrical grid The following are functional requirem ents: • Resources/virtual resources shall have a unique identity This identity m ay be used as • • • a logical address for comm unications Resources/virtual resources shall be configured with credentials that enable them to m ake authenticated connections to a trusted com munication infrastructure Adequate security measures shall be included to ensure the protection of inform ation carried over the internet E g comm unications over the I nternet shall be encrypted Resources/virtual resources shall not be required to accept inbound connections, where there shall not be the need to open ports in firewalls to allow them to – 32 – • • • • • • • • • • • I EC TS 62746-3:201  I EC 201 communicate over the I nternet Virtual resources will only make outbound connections to the comm unication infrastructure using their credentials Resources/virtual resources shall be able to receive m essages asyn chronousl y, without the need to poll a controller Group comm unications shall be supported, where a controller can address a message to all m embers of a group Virtual resources may have m embership in zero or more groups This m eans that each message shall have a single source, but potentiall y m any destination addresses where a destination address m ay be a group address that is m aintained and m anaged by the com munication infrastructure I t shall be possible for a controller to readil y determ ine the presence and state of a device The order of m essages shall be preserved I n this way a device will see all of the commands issued by a controller in the proper order, and a controller m ay see all of the events issued by a device in the proper order There shall be m echanism s for time synchronization and timestamps on m essages Message content shall be extensible I f a message contains additional information not understood by a device, it can be ignored and the sender shall realize and accom modate for this fact Resources/virtual resources shall be configured with param eters that control aspects of their behavior and identify their capabilities Some of these m ay be public and some m ay be private Devices shall submit their public param eters to the comm unications infrastructure Existing proven protocols shall be used as the basis of the comm unications infrastructure Resources/virtual resources or controllers shall support a role based security model which defines access down to parameter or message type level There shall be a mechanism to update credentials, e.g withdraw certificates Devices or controllers shall be capable to sim ultaneousl y hold m ultiple connections to different comm unication partners with different trust levels The following are needed comm unication services, where application level services would be layered upon these basic comm unication services: • • • • • • • Connection m anagem ent Authentication I ntegrity protection Publish/Subscribe m essaging Request/Repl y messaging Event m essaging Message encryption Configuration services shall be supported A N on-fu nction al requirements The architecture is also intended to address a set of important non-functional requirem ents as related to comm unications directl y to and indirectl y in support of devices that m ay be connected to the electrical grid The following are non-functional requirem ents: • Shall support connectivity over public networks, e.g the I nternet I EC TS 62746-3:201  I EC 201 – 33 – • Preference should be given within I EC intellectual property rules compliant solutions to • • • • • • • • • • • • • • • • • solutions based on non proprietary software or free licensing for the development of VENs that use the interfaces Shall not be tied to a single programm ing language or operating system , and conversel y shall allow for implem entation using a variety of commonl y used programming languages and operating systems, including those found on m obile devices Shall be scalable, where it is possible to su pport thousands of VENs with a singl e comm unication server, and allow for federation using man y communication servers I n case of single point of failure redundant solutions shall be possible (availability) Shall allow for authentication of trusted connections and encryption Shall have a scheme by which the identity of VEN devices can be trusted Shall support efficient ‘push’ com munications m echanisms without the need to open ports in firewalls to enable communication the VENs and reverse Shall allow for application-defined XML m essage payloads Shall support publish/subscribe m echanism s, including capabilities to address m essages from VTNs to groups of VENs Shall support publish/subscribe mechanism s, including capabilities to address messages from VENs to groups of VTNs Shall support publish/subscribe mechanisms, including capabilities to address messages from VTN to groups of VENs Shall support introduction of new message types without breaking the wire protocol Shall be possible to determ ine the status of VENs by VTNs (permanent life check) Shall com pl y with the I EC 62351 fram ework Shall support intermittent comm unication, where delivery guarantees are provided Shall support m obile virtual resources, which includes electric vehicles and m obile storage devices and mobile generation The ability to be externall y/locally configured and managed as necessary to define identity, connection parameters and param eters that describe capabilities as needed for participation in DR program s Shall support cascading aggregation of virtual resources – 34 – I EC TS 62746-3:201  I EC 201 Annex B (informative) Message payload profiles Figure B describes the possible structure of profiles used for messages This is provided here for convenience purposes IEC Figure B.1 – Profile structure Payloads are to be realized using XML, where payload structures are defined using XML schemas I EC TS 62746-3:201  I EC 201 – 35 – Bibliography [1 ] I ETF RFC 6272, Internet Protocols for the Smart Grid, June 201 [2] XM PP XEP-0060, Publish-Subscribe messaging extensions , J ul y 201 [3] I EC PAS 62746-1 0-1 , Systems interface between customer energy management [4] The Smart Grid Coordination Group reports http://www cencenelec eu/standards/Sectors/SustainableEnerg y/Sm artGrids/Pages/def ault aspx [5] I EC PAS 62559: 2008, IntelliGrid methodology for developing requirements for energy system and the power management system – Part 10-1: Open Automated Demand Response (OpenADR 0b Profile Specification) systems _ INTERNATIONAL ELECTROTECHNICAL COMMISSI ON 3, rue de Varembé PO Box 31 CH-1 21 Geneva 20 Switzerland Tel: + 41 22 91 02 1 Fax: + 41 22 91 03 00 info@iec.ch www.iec.ch