1. EG1 functionalities of the Smart Grid and Smart Meters Omar Elloumi (Alcatel-Lucent), ETSI representative to EG1 June14th 2010

2. EG1 Identity card Name: functionalities of the Smart Grid and Smart Meters Number of delegates: ~25 Representing: Cenelec, DLMS, Cen, ETSI, T&D Europe, Digital Europe, CECED (European Committee for Domestic Equipment Manufacturers), etc. Working Methods: Presentations made on the vision of different actors at the first meeting (ETSI was not represented) Drafting group (composed of three people representing Cenelec, DLMS and a DSO) works on a report. ETSI is not represented despite delegate and official DG request Comments made on the report during subsequent meetings Comments are taken into account during a drafting session if agreed by the participants ETSI vision is supported by Digital Europe and T&D Europe 2

3. EG1 original document structure TSO Domain DSO Domain Customer Domain already in a process of increasing their smartness Main focus area Smart meters will allow the full capabilities of a SG to be realised SG Services Services are mostly known and built-in the DSO domain SM and DSO may share the same communication infrastructure 3

4. Some illustrations from EG1 report Their development (SG) will be facilitated by the wide-scale deployment of smart metering, as envisaged in 3rd Energy Package, Directive 2009/72/EC. It is expected that the enhanced operation and control of networks and the introduction of new services and functionalities will mostly impact the distribution side. SG actors: Grid providers: transmission and distribution system/network operators (DSOs/DNOs). Grid users: generators, consumers (included mobile consumer), storage owners. Other actors: suppliers, metering operators, ESCOs, aggregators, ICT hub providers, power exchange platform operators. Etc. 4 Alignment with the final EG3 report should help in clarifying the role of ICT

5. They way we want the document to evolve IP-based network plane M2M-based Service plane SG applications TSO Energy plane DSO Energy plane Customer Energy plane All actors can play a role in the different domains (but level of involvement may defer). SG applications are mostly M2M applications 5

6. Next steps ETSI provided comments to EG1 Aligned with comments provided to EG2 and EG3 Comments reflect the vision of ICT and ETSI Comments still need to be endorsed A level of frustration remains because our preference is to change the structure of the document to align with the three planes strategy ETSI document under preparation to convey our vision ETSI views are very aligned with Digital Europe and T&D Europe ETSI is requested to rewrite chapter 11 on standards recommendations 6

7. Proposed structure for chapter 11 Vision & Framework Influential Bodies Service plane Control & connectivity plane IERN, ICER US: FERC, EU: ER-GEG / ACER, CEER China: SERC France: CRE UK: OFGEM Etc. Energy plane Standards Bodies Policy & Regulation IEEE P2030, ITU-T, IEC Smart Grid Strategy Group ANSI C12, IETF, Zigbee, ETSI IEC 60870, 61868-70, Cenelec ANSI C12, IETF, Cenelec, IEEE 1686, 1588, IEC 61850, 62351, Zigbee, ETSI, 3GPP IEEE PES, 1547, C37, IEC, NERC NIST, EPRI, SG-ETP SEA, INCITS, OpenADR DLMS, OpenADR, OPC-UA, DLMS, IPSO DNP, NEMA Cen, Cenelec and ETSI recently created a joint group to advise and influence the commission mandate 7

8. Annex: T&D Europe proposals (impacting ICT standards) Harmonize the Smart Grid use's cases Ensure standardisation bodies are working on the same understanding of the issues to solve Entitle one "prefered body" to host and harmonise Smart Grid use's cases Share the same formalisation method of use's cases At the end, share the same understanding of needs for information exchange (what to exchange ? under which constraints (frequency, response time, quality, integrity, confidentiality,...) ?...) Harmonize Smart Grid data modelling and description language This is a MUST for machine to machine understanding The ultimate target would be to get the exact same data modelling and description language (UML for example) An intermediate target would be to get formal and validated translation rules (UML for example) from one world to another (including wording, semantic and grammar) Harmonize communication protocol This is the last step (and not the first) If protocols are well structured, applications can be written in a way it makes them independent from the protocol One first step could be to harmonise an abstract definition of communication services A second step could be to validate mapping of this abstract communication services set on selected "communication layers" We can understand that protocols may face such different constraints that this leads to different solutions 8