SG-CG/ M490/F_ Overview of SG-CG Methodologies

Transcription

1 CEN-CENELEC-ETSI Smart Grid Coordination Group Date: 08/2014 Secretariat: CCMC SG-CG/ M490/F_ Overview of SG-CG Methodologies Version 2.0

2 Document for the M/490 Mandate Smart Grids Methodology and New Applications Foreword Based on the content of the M/490 EU Mandate in its phase 1 ( ), the general scope of work on standardization of the Smart Grid might be considered as follows: CEN, CENELEC, and ETSI are requested to develop a framework to enable European Standardization Organizations to perform continuous standard enhancement and development in the field of Smart Grids, while maintaining transverse consistency and promote continuous innovation. In the light of the discussions held between the EC Reference Group (EG1) and the Smart Grid Coordination Group (SG-CG), the need to iterate the EC Mandate M/490 was considered and agreed by both sides. As a main objective of the mandate phase 2, the SG-CG wishes to implement the developed methodology, which set up the foundations for managing the continuous engineering and deployment of standards to ensure a real end-to-end interoperability for all generic use cases, including explicitly security. A further refinement of the methodology will be used for the set of consistent standards [SG-CG/G] (under item 3.1 and 3.2 of M/490). The work is based on [SG-CG/C] and [SG-CG/E]. The final report is due on September 1 st, 2014, based on the version v1.0 provided end of 2013 for commenting within the SG-CG. A set of documents is addressing this objective: The main report (this document) as a summary of different tools, elements and methodologies developed by the different working groups of the Smart Grid Coordination Group [SG-CG/F], and additional separate reports detailing specific issues of the working group Methodology and New Applications : The conceptual model and its relation to market models for Smart Grids [SG-CG/J] SGAM User Manual - Applying, testing & refining the Concepts, Elements and Tools for the Smart Grid Architecture Model (SGAM) [SG-CG/K] Overview of the main concepts of flexibility management [SG-CG/L]

3 Document for the M/490 Mandate Smart Grids Methodology and New Applications Table of Contents... Page Foreword 2 1. Executive Summary Methodology, new applications and Smart Grid standardization Objectives Structure and intended usage of this report How to read this report References Terms and definitions Symbols and abbreviations Concepts, elements and tools for the Smart Grid methodology Introduction Roles and actors in smart grids and smart markets Roles for market models Actors Modelling of roles, actors and related concepts Generic actor list Smart Grid conceptual model Conceptual domains Smart Grid use cases Introduction: Use cases and standardization Use case template Classification of use cases Organization of use cases Use cases repository Smart Grid Architecture Model (SGAM) Set of standards for the smart grid system Standards gaps, prioritization, work program Cyber security & privacy Interoperability Introduction System design and use case creation Use of standards, specifications and profiles Compliance, conformance and interoperability testing Linkages to use cases and SGAM Summary of IOP methodology Developing interoperability profiling Managing profiles Implementation of profiles in real projects Processes and management for the Smart Grid standardization methodology Overall process How the elements and tools are interlinked Introduction Preconditions From requirements to use cases From use cases to the SGAM use case analysis From use cases and SGAM analysis to standards gaps From standards gaps to standards From use cases and standards to interoperability profiles (BAP) From interoperability profiles (BAP) to testing profiles (BAIOP)

4 Document for the M/490 Mandate Smart Grids Methodology and New Applications Introduction into the process of standard development in standardization organizations List of figures Figure 1: Elements of the Smart Grids Methodology and their usage... 7 Figure 2: Meta-model of the concepts related to actors and roles Figure 3: Information flow between roles, actors and use cases Figure 4: European Conceptual Model for the Smart Grid Figure 5: Use case structure (based on SM-CG) Figure 6: SGAM Smart Grid Architecture Model Figure 7: SGAM Analysis Pattern Figure 8: Systems break-down over the SGAM plane Figure 9: V-Model including BAP and BAIOP Figure 10: Workflow of project specific profiling Figure 11: Smart Grids generic pre- and post-standardization process Figure 12: Basic process for SGAM Use Case Analysis Figure 13: Use Case Analysis with SGAM example for an analysis process Figure 14: Process from use case to interoperability on SGAM function layer List of tables Table 1 - Advantages of use case descriptions Table 2 IEC standardization process Table 3 Comparison of IEC and CENELEC processes Table 4 Comparison of IEC and ETSI processes History of document V1.0 18/12/2013 For publication and review by the BTs and TCs. V /06/2014 Integration of comments, basis for F2F meeting of WG Method on 16 th of June V /06/2014 After F2F meeting V /06/2014 Cleaned version for editors V /07./2014 Editors with changes according to comments and discussion in F2F meeting (vt, js, mm, ew) V1.9 25/07/2014 Semi-final version for check V /08/2014 Output from language check V Final for distribution to the SG-CG, commenting phase Main changes in this version 4

5 Methodology and New Applications - SG-CG/M490/F Executive Summary This document is prepared by the Smart Grid Coordination Group (SG-CG) "Methodology and New Applications" Working Group (SG-CG/Meth) and addresses the M/490 mandate s phase 2 deliverable regarding Smart Grid methodology and processes (in this report mainly used for standardization) and its applications to the development of new Smart Grid applications. In the phase 2 of M/490, SG-CG/Meth has taken over work of phase 1 with the intent to complement and harmonize it when necessary. Examples of such work elements are the SGAM or architecture models, the Use Case Methodology or the SGIS Toolbox. The report summarizes tools and methods from all working groups (WG) of the Smart Grid Coordination Group (SG-CG). The overall objective is to provide a methodology that is both complete and coherent. It must be flexible with respect to new applications and the emergence of new or different market models. All the methodology elements developed in SG-CG must be aligned and unambiguous. The Report is short and focused on the "how to use"; when details are needed, they can be found in the separate reports [SG-CG/J-L] or in references to the results of M/490 phase 1. The methodology relies on two pillars. Firstly, concepts and models (and to some extent tools to support them) are the building blocks for the analysis. Secondly, to conduct the work toward completion, processes insert these concepts and models in a specific workflow. These two aspects of the methodology are clearly differentiated and presented sequentially. The role of the methodology is to support and assist other standardization groups and to provide them with easily applicable methods and architectures and ensure an easy understanding of the approach. The methodology provides tools for the identification and structuring of requirements for new Smart Grid standards and provides a framework for their development and presentation. It considers aspects ranging from markets down to information and communication technology (ICT) and electro-technical components. Though standardization technical committees are the main intended audience of the methodology, other actors like researchers, engineers or legislators can also use it. The main concepts and models introduced (or refined) in this report are: A model of roles and actors including a 'market' view that is needed to ensure that the methodology can support the expected evolution of market structures in Europe. A Smart Grid Conceptual Model that is based on the (market) roles and actors model. It is an evolution of the one developed during M/490 phase 1. A Smart Grid Use Case model that can support standards development in the definition and design phases. Some support tools complement it. The Smart Grid Architecture Model (SGAM) as the reference model in a technology neutral manner which allows one to analyze and visualize different smart grid use cases. Methods and tools for SGIS, interoperability and system breakdown Once the main concepts are presented, the methodology describes how they are combined into an integrated and generic pre-standardization process involving new requirements, use cases, use of SGAM, up to the definition of new standards and profiles, and a short overview on conformance. [SG-CG/J] provides further details for the developments of market models based on meta models and the harmonized role model. As one result the European conceptual model is introduced. A short overview is provided in Chapter 6. 5

6 Methodology and New Applications - SG-CG/M490/F [SG-CG/K] describes the usage of SGAM in combination with use cases and possible ways for analysis. Furthermore the report provides several examples of use cases with SGAM to demonstrate the usage and to check the completeness of the proposed methodology. The basic concepts are outlined in chapter 6 of this report. [SG-CG/L] analyzes the flexibility management and the traffic light concepts. It identifies and defines the relation between the developments of market models and standards. 2. Methodology, new applications and Smart Grid standardization In the first phase of M/490, a large number of elements related to a methodology for Smart Grid standardization have been developed. Examples of such elements are the SGAM or architecture models (by the Reference Architecture WG in [SG-CG/C]), the Use Case Methodology (by the Sustainable Process WG in [SG-CG/E]) or the SGIS Toolbox (by the SGIS WG in [SG-CG/E]). The interaction between these different elements was described in the "Framework for Smart Grids Standardization" (in [SG-CG/A]). In the second phase of M/490, the "Methodology and New Applications" Working Group has taken over this work with the intent to complement and harmonize it when necessary. The result of the work is a new report (i.e. this document and its additional reports) with a new perspective and largely new content. This report makes reference to the phase 1 documents mentioned above (see references in chapter 3) and, in a few cases, reuses some of their material Objectives The overall objective is to provide a methodology that is both complete and coherent. Applicability On the one hand, the methodology must be applicable to Smart Grid standardization globally. In particular, it must be flexible with respect to new applications and the emergence of new or different market models. On the other hand, all the methodology elements developed in SG-CG must be aligned and unambiguous. Usability The second objective is usability. The first application of the methodology has been with the new applications investigated in the working group, thus offering a reality check supported by several examples. Simplicity The last objective is simplicity. The report is short and focused on the "how to use". When details are needed, they can be found in the separate reports [SG-CG/J-L] or in references to the results of M/490 phase Structure and intended usage of this report In the definition of the methodology, two kinds of elements are developed. Concepts and models (and to some extent tools to support them) are the building blocks for the analysis. To conduct the work toward completion, processes insert these concepts and models in a specific workflow. These two aspects of the methodology are clearly differentiated and presented in a sequential manner as shown in Figure 1. The role of the methodology is to support and assist standardization groups and to provide them with easily applicable methods and architectures and ensure an easy understanding of the approach. Though the main intended audience of the methodology is standardization technical committees, it can also be used by other actors like research projects testing new concepts or engineers developing Smart Grids products, or even the legislator in order to check the legislative framework. 6

7 Methodology and New Applications - SG-CG/M490/F Figure 1: Elements of the Smart Grids Methodology and their usage 2.3. How to read this report The rest of this document is structured as follows. Chapters 3, 4 and 5 provide background information (references, etc.). Similar sections may also be present in the additional reports when they are specific. Chapter 6 provides concepts, elements and tools for the Smart Grid methodology like the European view of the Smart Grid Conceptual Model, an overview of the general elements of a Reference Architecture, or the use case methodology. It introduces the viewpoints chosen as a target of the SG-CG/Meth Working Group. Chapter 7 first presents the overall process, how the various elements can be linked and how it is possible to use them across the standardization value chain (from requirements to use cases to SGAM to standards (gaps) to interoperability profiles). Then it discusses how to introduce the suggested methodologies and tools in Smart Grid standardization organizations. 3. References Smart Grids Coordination Group Phase 1 Documents [SG-CG/A] SG-CG/M490/A_ Framework for Smart Grid Standardization [SG-CG/B] SG-CG/M490/B_ Smart Grid First set of standards [SG-CG/C] SG-CG/M490/C_ Smart Grid Reference Architecture [SG-CG/D] SG-CG/M490/D_ Smart Grid Information Security [SG-CG/E] SG-CG/M490/E_ Smart Grid Use Case Management Process [Gap Prioritization] CEN-CENELEC-ETSI Smart Grid Coordination Group, 'Standardization Gaps Prioritization for the Smart Grid' v.2.1, (SGCG_Sec0028_DC), Brussels, 2011 [Work Program] CEN-CENELEC-ETSI Smart Grid Coordination Group, ' Program of standardization work for the Smart Grid' (SGCG_Sec0032_DC (version 1.6)), Brussels, 2012 [ ] 7

8 Methodology and New Applications - SG-CG/M490/F Smart Grids Coordination Group Phase 2 Documents [SG-CG/F] SG-CG/M490/F_ Overview of SG-CG Methodologies (this document) [SG-CG/G] SG-CG/M490/G_ Smart Grid Set of standards [SG-CG/H] SG-CG/M490/H_ Smart Grid Information Security [SG-CG/I] SG-CG/M490/I_ Smart Grid Interoperability [SG-CG/J] SG-CG/M490/J_ Conceptual model - market models [SG-CG/K] SG-CG/M490/K_ SGAM usage and examples [SG-CG/L] SG-CG/M490/L_ Flexibility Management References made in this document [ENTSO-E] Modular Development Plan of the Pan-European Transmission System 2050 of the e-highway2050 Project Consortium: [GWAC:2008] GridWise Interoperability Context-Setting Framework (March 2008), GridWise Architecture Council, online: [HEM-RM:2011] The Harmonized Electricity Market Role Model (December 2011), ENTSO-E, online: [IEC 61850] Communication networks and systems for power utility automation, [IEC ] Communication networks and systems for power utility automation - Part 7: Basic communication structure [IEC ] Communication networks and systems for power utility automation - Part 8: Specific communication service mapping (SCSM) [IEC 62264:2003] IEC 62262, Enterprise-control system integration [IEC 62351] Power systems management and associated information exchange [IEC 62357:2011] IEC , TR Ed.1: Reference architecture for power system information exchange, [IEC 62559] IntelliGrid Methodology for Developing Requirements for Energy Systems [IEC ] "Use case methodology Part 2: Definition of the templates for use cases, actor list and requirements list", CDV, 2013 [IEC PAS 62559:2008] IEC PAS 62559: , IntelliGrid Methodology for Developing Requirements for Energy Systems, 2008 [ISO/IEC :2012] Information technology - Object Management Group Unified Modeling Language (OMG UML) - Part 2: Superstructure [ISO/IEC 27001] Information technology - Security techniques - Information security management systems - Requirements [ISO/IEC 27002] Information technology - Security techniques - Code of practice for information security controls [ISO/IEC 42010:2011] ISO/IEC 42010: Systems Engineering Architecture description, 2011 [ISO/IEC TR 27019] Information technology - Security techniques - Information security management guidelines based on ISO/IEC for process control systems specific to the energy utility industry [Jonkers 2010] TOGAF 9 and ArchiMate 1.0 White paper, The Open Group 2010, see also and 8

9 Methodology and New Applications - SG-CG/M490/F [Mapping Tool] [NIST IR-7628] [NIST:2009] [NERC CIP] [Trefke 2012] SMART GRID STANDARDS MAPPING TOOL, Guidelines for Smart Grid Cyber Security, NIST Framework and Roadmap for Smart Grid Interoperability, Interoperability Standards Release 1.0 (2009), Office of the National Coordinator for Smart Grid Interoperability, National Institute of Standards and Technology, U.S. Department of Commerce. Online: North American Electric Reliability Corporation, Critical Infrastructure Protection "Grundlagen der Referenzarchitekturentwicklung", Jörn Trefke, in IT- Architekturentwicklung im Smart Grid, 1 ed., Berlin Heidelberg: Springer, Terms and definitions Terms related to the description of actors and meta-model 1 Actor An Actor represents a party that participates in a business transaction. Within a given business transaction an actor performs tasks in a specific role or a set of roles. EXAMPLE: Employee, Customer, Electrical vehicle, Demand-response system. Party Parties are legal entities, i.e. either natural persons (a person) or judicial persons (organizations). Parties can bundle different roles according to their business model. EXAMPLE: real organisations like Dong Energy, Liander, APX Group. Responsibility Responsibilities define external behavior to be performed by parties. EXAMPLE: Nominate Energy, Operate a grid, Determine the market energy price after applying technical constraints. Role A Role represents the intended external behavior (i.e. responsibility) of a party. Parties cannot share a role. Parties carry out their activities by assuming roles, e.g. system operator, trader. Roles describe external business interactions with other parties in relation to the goal of a given business transaction. EXAMPLE: Balance Responsible Party, Grid Operator, Market Operator. Terms related to the description of architectural concepts Architecture Fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution [ISO/IEC 42010]. Architecture Framework Conventions, principles and practices for the description of architectures established within a specific domain of application and/or community of stakeholders [ISO/IEC 42010]. Conceptual Model A Smart Grid is a complex system of systems for which a common understanding of its major building blocks and how they interrelate must be broadly shared. SG-CG has developed a conceptual architectural reference model to facilitate this shared view: the European conceptual model of Smart Grid clusters, (European 1 Refer also to clause 6.2 9

10 Methodology and New Applications - SG-CG/M490/F harmonized) roles and system actors, in line with the European electricity market and electricity system as whole. This model provides a means to analyze use cases, identify interfaces for which interoperability standards are needed, and to facilitate development of a cyber-security strategy (adopted from [NIST 2009]). Smart Grid Architecture Model The Smart Grid Architecture Model (SGAM) is a reference model to analyse and visualise smart grid use cases in respect to interoperability, domains and zones. Domain In the rest of the document (and its additional reports), this term may refer to two different concepts. In order to avoid ambiguity, the full names 'Conceptual Domain' or 'SGAM Domain' (as defined below) will be used systematically. Conceptual Domain A conceptual domain highlights the key areas of the conceptual model from the point of view of responsibility. It groups (market) roles and their associated responsibilities present in the European electricity markets and the electricity system as a whole. SGAM Domain One dimension of the Smart Grid Plane that covers the complete electrical energy conversion chain, partitioned into 5 domains: Bulk Generation, Transmission, Distribution, DER (Distributed Energy Resources) and Customers Premises. Interoperability Interoperability refers to the ability of two or more networks, systems, devices, applications, components to interwork, to exchange and use information to perform required functions. [SG-CG/I] Reference Architecture A Reference Architecture describes the structure of a system with its element types and their structures, as well as their interaction types, among each other and with their environment. A Reference Architecture defines restrictions for an instantiation (concrete architecture). Through abstraction from individual details, a Reference Architecture is universally valid within a specific domain. Further architectures with the same functional requirements can be constructed based on the reference architecture. Along with reference architectures comes a recommendation, based on experiences from existing developments as well as from a wide acceptance and recognition by its users or per definition (following [Trefke 2012]). SGAM Interoperability Layer In order to allow a clear presentation and simple handling of the architecture model, the interoperability categories described in the GridWise Architecture model are aggregated in SGAM into five abstract interoperability layers: Business, Function, Information, Communication and Component. SGAM Smart Grid Plane The Smart Grid Plane is defined from the application to the Smart Grid Conceptual Model of the principle of separating the Electrical Process viewpoint (partitioning into the physical domains of the electrical energy conversion chain) and the Information Management viewpoint (partitioning into the hierarchical zones (or levels) for the management of the electrical process [IEC 62357:2011, IEC 62264:2003]. SGAM Domain See above. SGAM Zone One dimension of the Smart Grid Plane represents the hierarchical levels of power system management, partitioned into 6 zones: Process, Field, Station, Operation, Enterprise and Market [IEC 62357:2011]. Systems A typical industry arrangement of components and systems, based on a single architecture, serving a specific set of use cases [SG-CG/B] 10

11 Methodology and New Applications - SG-CG/M490/F Terms related to the description of use cases concepts Coordinating TC A technical committee within a standardization organization taking over the responsibility for agreed use cases while involving other interested and concerned technical committees. NOTE For example the responsibility might include further detailing, analysis, maintenance and harmonization of the use case. Generic Use Case A use case that is broadly accepted for standardization, usually collecting and harmonizing different real use cases without being based on a project or technological specific solution. High Level Use Case A use case that describes a general requirement, idea or concept independently from a specific technical realization like an architectural solution. Individual Use Case A use case that is specifically for a project or within a company / organization. Involved TC A technical committee within a standardization organization with an interest in a generic use case. Primary Use Case A use case that describes in detail the functionality of (a part of) a business process. NOTE Primary use cases can be related to a primary goal or function, which can be mapped to one architectural solution. Repository A place where information like use cases can be stored (see Use Case Repository). Scenario A possible sequence of interactions. NOTE Scenario is used in the use case template defining one of several possible routes in the detailed description of sequences. Secondary Use Case An elementary use case that may be used by several other primary use cases. EXAMPLE Authentication, Authorization, Accounting Specialized Use Case A use case that is using specific technological solutions / implementations. EXAMPLE Use case with a specific interface protocol Use Case Specification of a set of actions performed by a system, which yields an observable result that is, typically, of value for one or more actors or other stakeholders of the system [ISO/IEC :2012, Information technology Object Management Group Unified Modeling Language (OMG UML) Part 2: Superstructure] Use Case Cluster A group of use cases with a similar background or belonging to one system or one conceptual description. Use Case Repository A database for edition, maintenance and administration of use cases that are based on a given use cases template. NOTE The UCR is designed as collaborative platform for standardization committees, inter alia equipped with export functionalities as UML model or text template. 11

12 Methodology and New Applications - SG-CG/M490/F Use Case Template A form that allows the structured description of a use case in predefined fields. 5. Symbols and abbreviations AMI ACSI BAP BAIOP CC CD CDV CEN CENELEC CIM CIS CTC DER DMS DPIA DSO DUT ebix EC EFET EMS EN ENAP ENISA ENTSO-E ENQ ESCO ETSI EU FDIS GUC GWAC HEM-RM HL-UC ICT IEC IETF IOP IS ISO ITU MG MICS MMS MMXU NIST NP PAIOP PAP PICS PIXIT PWI Advanced Metering Infrastructure Abstract communication service interface Basic Application Profiles Basic Application Interoperability Profiles Coordinating Committee Committee Draft for Comments Committee Draft for Voting Comité Européen de Normalisation Comité Européen de Normalisation Electrotechnique Common Information Model Customer Information Services Coordinating Technical Committee Distributed Energy Resources Distributed Management System Data Protection Impact Assessment Distribution System Operator Device Under Test (European forum for) energy Business Information Exchange European Commission European Federation of Energy Traders Energy Management Systems European Standard EN Approval Procedure European Union Agency for Network and Information Security European Network of Transmission System Operators for Electricity Enquiry Energy Service Company European Telecommunications Standard Institute European Union Final Draft International Standard Generic Use Cases GridWise Architecture Council Harmonized Electricity Market Role Model High Level Use Case Information & Communication Technology International Electrotechnical Commission Internet Engineering Task Force Interoperability Profiles International Standard International Organization for Standardization International Telecommunication Union Microgrid Model Implementation Conformance Statement Manufacturing Messaging Specification Measurement logical node National Institute of Standards and Technology New Work Item Proposal (Altern. NWIP New Work Item Proposal) Project Application Interoperability Profiles Project Application Profiles Protocol Implementation Conformance Statement Protocol Implementation extra Information for Testing Preliminary Work Item 12

13 Methodology and New Applications - SG-CG/M490/F RDF Resource Description Framework SCADA Supervisory Control and Data Acquisition SDO Standards Developing Organization SGAC SGIP Smart Grid Architecture Committee SGAM Smart Grid Architecture Model SG-CG Smart Grids Coordination Group SG-CG/Meth SG-CG Methodology and New Applications Working Group SGIP Smart Grid Interoperability Panel SGIS Smart Grid Information Security SGTF EG2 Smart Grid Task Force Expert Group 2 SM-CG Smart Metering Coordination Group ST Support Team TAP Two-step Approval Procedure TB Technical Body TC Technical Committee TF Task Force TOGAF The Open Group Architecture Framework TR Technical Report TSO Transmission System Operator UCR Use Case Repository (Altern. UCMR Use Case Management Repository) UML Unified Modeling Language WD Working Draft WG Working Groups WGI Working Group Interoperability WG SS Working Group Set of Standards XML Extensible Markup Language 13

14 Methodology and New Applications - SG-CG/M490/F Concepts, elements and tools for the Smart Grid methodology Introduction This section provides a high-level view of the concepts, elements and tools for Smart Grid methodology and processes. It is meant to be short, concise and descriptive. This chapter also includes summaries of concepts developed in other working groups of the SG-CG. More details can be found in the additional reports [SG-CG/J-L] (refer to chapter 3 References). The goal of the Smart Grid methodology is to support international standards development for Smart Grid technologies, products, components, and systems and their interfaces, to support and boost the large-scale deployment of Smart Grids and smart markets in Europe. The methodology provides tools for the identification and structuring of requirements for new Smart Grid standards and provides a framework for their development. It considers aspects ranging from markets down to ICT and electro-technical components. Another added value of these tools is a better overview: e.g. the set of standards document [SG-CG/B] [SG-CG/G] is a selection guide for users of standards Roles and actors in smart grids and smart markets The applicability of Smart Grid standards in both the current as well as the future European power system must be ensured for large-scale deployment. Therefore it is critical that the design of Smart Grid standards is compatible with the evolving market structures in the European Union. In order to guarantee that, the concepts of (market) roles and actors are introduced; these form the basic components, which are used in the European conceptual model, the SGAM model and use cases. The concept of (market) roles and actors allow for the development market structure agnostic standards, as they can be defined in terms of responsibilities that are independent from a certain market structure Roles for market models In Europe, the market models define what activities are regulated and what activities are allowed in the commercial market. In that context, the activities of smart grid parties (e.g. the various DSOs, TSOs, suppliers, Energy Service Companies (ESCOs), traders, customers, etc.) are defined by their roles and responsibilities. This role-allocation to parties may be subject to regulation / legislation. The energy transition will require an update of existing market models, which differ today, even in different EU member states. For example a DSO in the UK does not have the responsibility for electricity usage administration (this responsibility is assigned to the retailer), while DSOs in other EU member states do. The challenge is to develop standards that are applicable in different European market models and also support the development of more generic European market models. Success will come with the development of standards that support roles. ENTSO-E, ebix and EFET have created a harmonized and clear definition of the market roles in the various electricity markets of the EU member states. These roles are modeled in the Harmonized Electricity Market Role Model [HEM-RM 2011] Actors The development of system requirements is a key ingredient for the development of Smart Grid and smart market standards. Identifying the actors of and their interactions within Smart Grids and smart markets are an important step therein from the market level to the technology level (see also 6.4 on use cases). 2 This report is mainly contributed to the use of concepts elements and tools in standardization but they might be used also for other purposes like engineering or also in other technological areas than smart grid (e.g. Smart Home, Smart City, etc.) 14

15 Methodology and New Applications - SG-CG/M490/F A generic actor list, derived from generic use cases, provided by the SG-CG, includes the role-actor relationships. This supports the analysis of the business context when defining requirements of Smart Grid systems from use cases, as the first step towards standards. Moreover, it ensures the required applicability of standards based on these requirements in all market models in the current European electricity market Modelling of roles, actors and related concepts The meta-model in the figure below clarifies the relationship between roles, actors, responsibilities and parties. It only describes the elements required for the meta-model; a more detailed version, with the alignment rationale to SGAM, TOGAF and the Harmonized Electricity Market Role Model can be found in [SG-CG/J] on meta models. is described by is assumed by Responsibility Role Party defines assumes is performed by contains performs tasks in Actor represents Figure 2: Meta-model of the concepts related to actors and roles Figure 2 shows elements of the model and their relationships. The relationships can be read in both directions, using the reading direction of the labels, e.g. an Actor performs tasks in a Role. The elements of the diagram are defined as: Party Responsibility Role Actor Generic actor list Parties are legal entities, i.e. either natural persons (a person) or judicial persons (organizations). Parties can bundle different roles according to their business model. EXAMPLES: real organisations like Dong Energy, Liander, APX Group. Responsibilities define external behavior to be performed by parties. Examples: Nominate Energy, Operate a grid, Determine the market energy price after applying technical constraints. A Role represents the intended external behavior (i.e. responsibility) of a party. Parties cannot share a role. Parties carry out their activities by assuming roles, e.g. system operator, trader. Roles describe external business interactions with other parties in relation to the goal of a given business transaction. EXAMPLES: Balance Responsible Party, Grid Operator, Market Operator. An Actor represents a party that participates in a business transaction. Within a given business transaction an actor performs tasks in a specific role or a set of roles. EXAMPLES: Employee, Customer, Electrical vehicle, Demand-response system. The term Actor can be used in other contexts within smart grids methodology, particularly discussions around technology. If it helps, in the context of the discussion, the type of actor can be qualified, such as business actor in the role model and system actor when referring to technological systems. As standards and interoperability are achieved in multiple iterations in the standardization process, it is envisaged to start with a generic set of actors within the Smart Grid Coordination Group. Based thereon in the development of actual standards, technical committees (e.g. of the IEC/TC 8 WG 6) will further refine 15

16 Methodology and New Applications - SG-CG/M490/F these actors. When these standards are implemented, parties will even further refine them to take into account concerns specific to their implementation. In this chain of refinement, it is critical that the link between actors and roles is kept intact in order to guarantee robustness to the various market structures. In the context of standardization, for the widest applicability, it should be a goal that for every actor defined in the generic list there is only one role to which it relates. This is to ensure that the definition of actors in standards do not force the combination of roles in implementation. However, in specific implementations, actors may (e.g. for efficiency) in fact relate to several roles. When defining use cases as start of the process, it is key that they are built on agreed actor definitions and are reused among different uses cases as much as possible. This creates a commonly used actor list and reduces doubling of actors and misunderstanding regarding the behavior of the actors. This generic actor list (with only the most abstract actors) is given in [SG-CG/E] including its relationship to roles Figure 3: Information flow between roles, actors and use cases 6.3. Smart Grid conceptual model During the coming years the power system will undergo fundamental changes. In order to define standards that support this transition in a consistent way, applicable in all European markets, a generic European conceptual model is required. This European conceptual model is to be regarded as the starting point for all modeling activities, and for all other models, frameworks, and architectures, which are used to arrive at standards required for Smart Grids and smart markets. The conceptual model aims to highlight the key areas of attention conceptual domains and subdomains from the point of view of responsibility (refer to Figure 4). The model consists of four main conceptual domains: Operations, Grid Users, Markets, and Energy Services. Each of these conceptual domains contains one or more subdomains which group market roles from the European electricity market. To support its recognition, the Operations and Grid Users conceptual domains also show some well-known system actors that are present in those domains. Its main underpinning is the analysis of roles and responsibilities from [HEM-RM 2011]. While this model is based on the electricity market structures of the EU member states, their roles and responsibilities are cleanly defined and provide a solid basis; new parties may enter certain markets, responsibilities may be redistributed, but the fundamental roles and their respective responsibilities are expected to remain constant. 16

17 Methodology and New Applications - SG-CG/M490/F Operations and Grid Users are conceptual domains that are directly involved in the physical processes of the power system: electricity generation, transport/distribution and electricity usage. Also, these domains include (embedded) ICT enabled system actors. The Markets and Energy Services conceptual domains are defined by roles and actors and their activities in trade of electricity products and services (markets), and the participation in the processes of trade and system operations representing grid users (energy services). Markets Flexibility Market Grid Capacity Market Energy Market facilitates and coordinates trade in Operations System Operations Metering Operations facilitates and coordinates trade by trade via Energy Services Energy Trade Flexibility Trade / Balancing Grid Capacity Trade Responsibilities Grid Operations Transmission Grids provides energy services to Distribution Grids... Grid Users Production, storage and consumption Bulk Generation C&I Loads Legend: Conceptual Domain Subdomain transports power from and to DER Storage Domestic Loads Electric Vehicles System Actor Figure 4: European Conceptual Model for the Smart Grid In the creation of this conceptual model input is used from the EU-flexibility concept, [SG-CG/E], NIST, SGIP, SGAC, the Harmonized Electricity Market Role Model (HRM-RM) and European market model developments (e.g. EG3). For more detail how this information is used and which starting principles are the bases for this model, please refer to [SG-CG/J] on the conceptual model. Furthermore, [SG-CG/J] describes a more detailed mapping of all roles from the Harmonized Electricity Market Role Model and the domains in this conceptual model and a description of each of these roles. Refer also to [SG-CG/J] and [SG-CG/L] on how to define actors in the context of this conceptual model Conceptual domains The sections below provide descriptions for the domains in the conceptual model introduced above Operations The Operations conceptual domain is defined by roles and actors related to the stable and safe operations of the power system. The domain ensures the usage of the grid is within its operational constraints and facilitates the activities in the market. Actors in this domain may use services from the market to fulfill these 17

18 Methodology and New Applications - SG-CG/M490/F responsibilities. Grid Operations, System Operations and Metering Operations are identified as sub-domains in the Operations conceptual domain. System actors in this domain include grid assets such as transformers, switchgear, distribution management systems (DMS), energy management systems (EMS), as well as microgrid management systems, metering systems, control center systems, etc. in transmission and distribution grids. Roles in the Operations conceptual domain are: Subdomain System Operations Metering Operations Grid Operations Grid users Harmonized role System Operator, Control Area Operator, Control Block Operator, Coordination Center Operator, Imbalance Settlement Responsible, Reconciliation Responsible Meter Administrator, Meter Operator, Metering Point Administrator, Metered Data Aggregator, Metered Data Collector, Metered Data Responsible Grid Operator, Grid Access Provider The Grid Users conceptual domain is defined by roles and actors involved in the generation, usage and possibly storage of electricity; from bulk generation and commercial and industrial loads down to distributed energy resources, domestic loads, etc. The roles and actors in this domain use the grid to transmit, distribute and receive power from generation to the loads. Apart from roles related to the generation, load and storage assets, the Grid Users conceptual domain includes system actors such as (customer) energy management and process control systems. Grid users also provide flexibility, as they become an active participant of the energy system. Roles in the Grid Users conceptual domain are: Subdomain Production, storage and consumption Energy services Harmonized role Party Connected to the Grid, Consumer, Producer The Energy Services conceptual domain is defined by roles and actors involved in providing energy services to the Grid Users conceptual domain. These services include balancing & trading of electricity generated, used or stored by the Grid Users domain, and ensuring that the activities in the Grid Users domain are coordinated in e.g. the system balancing mechanisms and customer information services (CIS) systems. Through the Energy Services conceptual domain the Grid Users conceptual domain is connected to activities such as trade and system balancing. From the Grid Users domain, flexibility in power supply and demand is provided. This flexibility is used for system balancing (through e.g. ancillary services, demand response, etc.) and trading on the market. Also roles are included which are related to trade in grid capacity. The roles and actors from the Energy Services conceptual domain facilitate participation in the electricity system, by representing the Grid Users conceptual domain in operations (e.g. balance responsibility) and markets (trading). 18

19 Methodology and New Applications - SG-CG/M490/F 677 Roles in the Energy Services conceptual domain are: Subdomain Energy Trade Grid Capacity Trade Flexibility Trade / Balancing Responsibilities Markets Harmonized role Balance Supplier, Block Energy Trader, Reconciliation Accountable Capacity Trader, Interconnection Trade Responsible Balance Responsible Party, Consumption Responsible Party, Production Responsible Party, Trade Responsible Party, Scheduling Coordinator, Resource Provider The Markets conceptual domain is defined by the roles and actors that support the trade in electricity (e.g. on day ahead power exchanges) and other electricity products (e.g. grid capacity, ancillary services). It is reflecting the market operations possible along the energy conversion chain, e.g. energy trading, mass market, retail market. Sub domains which are identified in this domain are: Energy Market (e.g. commodity market), Grid Capacity Market (e.g. Transmission capacity market), and Flexibility Market (e.g. Imbalance market). Activities in the Markets domain are coordinated by the Operations domain to ensure the stable and safe operation of the power system. An example of system actors in this domain are trading platforms. Roles in the Markets conceptual domain are: Subdomain Harmonized role Flexibility Market Reserve Allocator, Merit Order List Responsible Grid Capacity Market Capacity Coordinator, Transmission Capacity Allocator, Nomination Validator Energy Market Market Information Aggregator, Market Operator 6.4. Smart Grid use cases Introduction: Use cases and standardization The idea of use case descriptions was developed originally for software engineering projects. In the following Table 1 some advantages are summarized highlighting the purpose of use cases in standardization: 694 Use cases gather requirements Support standards development Enable a common understanding between different stakeholder groups and its coordination Guidance for users of standards Management of standards Table 1 - Advantages of use case descriptions Use cases gather requirements, information about functionalities, processes and respective actors in a structured form. It is the intention that use case descriptions support development of standards in the design and definition phase, e.g. in areas like interoperability, terminology, safety, risk assessment, security and others. A discussion of these use cases with its requirements and descriptions should enable a common understanding between different sectors, committees or organizations. Therefore use case descriptions are mainly used for new, complex systems of cross-cutting nature. In this respect they can be seen as a link between new requirements (also from external sources representing e.g. market needs) and standardization. As use cases can be seen as a bracket for a number of standards and standardization activities, they support the management of standardization activities and provide guidance for users of standards. Depending on the level of granularity of the description the use cases support the assignment and management of standards and committees which are related to 19

20 Methodology and New Applications - SG-CG/M490/F development in complex systems Test use cases / Training Use Cases - basis for further engineering Not only for Smart Grid Use case template the respective use case as well as the development of a standardization work program. Beneath these basic functions validated use cases can be used for testing or training purposes. Therefore use cases will not only have preparatory and administrative functions for standardization organizations and the development of standards. In combination with other tools and models (refer to chapter 7 and the report of the WG Interoperability) they are needed to prove interoperability. Use Cases described in the given template are the basis for further engineering in the technical committees or even for individual projects. The use case methodology is not only used for Smart Grids, as it is general enough to be transferred to other areas in standardization as well. The template as defined in [IEC ] is a structured format for use case description that helps to describe, compare and administer use cases. The template mainly contains the following information: Administrative information (e.g. version management) Description of the function(s) o E.g. general narrative description, pictures, detailed description within the scenarios and activities The system under discussion (subject) and its design scope Actors linked to the function and activities (here activity means: one step of the detailed step-by-step description) Extended information for classification of use cases or information to link use cases to other developments (e.g. link use cases to standards or to the SGAM) The template in its detailed version is designed for an in-depth analysis of processes, information that is exchanged as well as requirements that are linked to this information exchange. Nevertheless, the author of the use case defines the granularity of his description according to his needs and the task of the respective use case description. In general an iterative approach is recommended: starting with a short description and an easy template (but using fields of the defined template according to [IEC ]), discussing and extending the description, detailing the use case, if needed, and linking it to other use cases. The template itself is linked to other databases that contain lists of related information that can be used across different use cases, like lists for actor, information exchanged, terms and definitions, references, requirements. Use cases and the related information have to be managed in order to maintain an overview. A rough hierarchy is suggested in order to manage different systems and their sub systems (system of system, refer to the report "First set of standards" [SG-CG/B]): Area (e.g. Smart Grids, smart home), o Domain / zones according to the SGAM, and Systems or groups (e.g. actors related to Smart Metering/AMI, virtual power plants) Classification of use cases Because use case descriptions support various tasks, the granularity, type and content of the use case description varies broadly. A use case in general describes functions of a system and related information 20

21 Methodology and New Applications - SG-CG/M490/F exchange, mainly in a technology-neutral way (depending on the level of detail). It identifies participating actors that for instance can be other systems or human actors which are linked to this use case. The various use case types can be classified highlighting different views and tasks of the respective use cases, e.g.: Level of detail (see Figure 5 below): for brainstorming / collection (cluster, high level use cases, conceptual description), engineering or testing; View of the use case: Business (business use case) or technical (system use case) 3 ; Users of the use case: Project (Individual use cases), technology group (specialized use cases), standardization (generic use cases) Geographical relation: national, regional or international use cases High Level of ABSTRACTION Low Conceptual Description High Level Use Case Primary Use case A Primary use case scenario Primary use case scenario Primary use case scenario Business Cases, Requirement Primary Use case B Primary use case scenario Primary use case scenario Low Level of GRANULARITY can be linked to architecture and systems Figure 5: Use case structure (based on SM-CG) A more detailed overview describing different use cases is provided in [SG-CG/K] Organization of use cases Within an area like Smart Grid a broad variety of different use cases might be established which will be highly interlinked. Some kind of coordination and categorization is required. Beneath the general grouping into area and the links to domains and zones, clusters of use cases can be established to sort use cases. These clusters can be described in conceptual description. Examples for clusters of use cases from the Smart Grid Coordination Group reports ([SG-CG/B to E]) are: Grid related generic uses cases Generic use cases related to electric vehicle charging Generic use cases related to the flexibility concept 3 or even political / legislative use cases might be possible. 21

22 Methodology and New Applications - SG-CG/M490/F Use cases repository Although it is possible to describe use cases in a word processing format, establishing a use case repository will provide a lot of advantages for standardization organizations when the methodology is introduced in a broader scale (refer to [SG-CG/K]). As example, also IEC introduces therefore a use case repository for the international standardization community Smart Grid Architecture Model (SGAM) The Smart Grid Architecture Model (SGAM) is a reference model to analyse and visualise Smart Grid use cases in a technology neutral manner. Furthermore, it supports comparison between different approaches to Smart Grid solutions so that differences and commonalities between various paradigms, roadmaps, and viewpoints can be identified. It provides a systematic approach to cope with the complexity of Smart Grids allowing representation of the current state of implementations in the electrical grid as well as the evolution to future Smart Grid scenarios by supporting the principles of universality, localization, consistency, flexibility and interoperability. SGAM builds on proven approaches from power systems as well as interdisciplinary fields like systems engineering and combines them in a simple but comprehensive model 4. Power system management distinguishes between electrical process and information management. These viewpoints can be partitioned into the physical domains of the electrical energy conversion chain and the hierarchical zones for the management of the electrical process (refer to [IEC 62357:2011, IEC 62264:2003]). This allows the foundation of the Smart Grid Plane that spans in one dimension the complete electrical energy conversion chain, partitioned into 5 domains: (bulk) Generation, Transmission, Distribution, DER and Customer Premises. And in the other dimension the hierarchical levels of power system management, partitioned into 6 zones: Process, Field, Station, Operation, Enterprise and Market. Interoperability as a key enabler for smart grids is inherently addressed in SGAM by the 5 superimposed layers: Component, Communication, Information, Function and Business. The complete three-dimensional representation of SGAM is depicted in Figure 6. 4 In particular, the work on SGAM is based on significant existing material such as the NIST Conceptual Model [NIST 2009], the GridWise Architecture Council Stack interoperability categories [GWAC 2008], the IntelliGrid Methodology [IEC PAS 62559:2008] and architecture standards like TOGAF and Archimate [Jonkers 2010] or and 22

23 Methodology and New Applications - SG-CG/M490/F Figure 6: SGAM Smart Grid Architecture Model The SGAM Interoperability Layers allow modeling of different views from business as well as technical viewpoints. On the business layer SGAM can be used to map regulatory and economic (market) structures and policies, business-related models, business portfolios (products & services) of market parties involved. Also business processes can be represented in this layer. In this way it supports business executives in decision making related to (new) business models and specific business projects (business case) as well as regulators in defining new market models. The technical views are modeled in SGAM on the four lower layers: The function layer describes functions and services including their relationships following business needs. Functions are represented independent of their physical implementation (represented by elements in the component layer). The information layer describes the information that is being used and exchanged between functions. It contains information objects and the underlying canonical data models. The emphasis of the communication layer is to describe mechanisms and protocols for the interoperable exchange of information between functions. Finally, the component layer describes all participating elements. This includes power system equipment (typically located at process and field level), protection and tele-control devices, network infrastructure (wired / wireless communication connections, routers, switches) and any kind of computers. For a specific implementation of a use case the identified functions can be mapped onto components complementing the relationships between all layers. Smart Grid use cases can be visualized and detailed with SGAM according to their physical distribution and mapped to the layers of the model to test if the use case is supported by existing standards or to identify gaps in standardization. A use case analysis with SGAM is based on the use case description outlined in Section 6.4. The fields in the use case template provide different information for the analysis, e.g. the field Domain(s)/Zone(s) specifies directly how the use case maps onto a Smart Grid plane. Furthermore, the actor 23

24 Methodology and New Applications - SG-CG/M490/F list in the use case description provides depending on the type of the actor information on the involved roles to model the business layer in SGAM or information on involved systems and devices to model the component layer. Use case descriptions vary in the level of abstraction as well as in design scope as described in detail in [SG-CG/K]. Thus, the analysis with SGAM also varies. Figure 7 provides an overview for each interoperability layer in SGAM on an exemplary level of abstraction on which an SGAM analysis can be applied Figure 7: SGAM Analysis Pattern The SGAM Analysis Patterns are intended to provide guidance on how to model with SGAM on a chosen level of abstraction starting from a concept level up to a detailed level required for implementation. Additionally, they should also support in writing use case descriptions on providing sufficient information needed for a SGAM analysis on the chosen level of detail. For each layer Figure 7 depicts some steps of successive model refinements to define interoperability requirements. Detailed information with examples is provided in [SG-CG/K]. Here are also examples provided showing the usage of the SGAM in other areas: e.g. the classification of systems (refer also to [SG-CG/G]) or usage areas of communication networks Set of standards for the smart grid system One of the main results of the work of the Smart Grid Coordination Group is the selection guide Set of standards ([SG-CG/B] [SG-CG/G] developed by working group Set of Standards). The set of standards consists of: System related standards and Cross cutting standards 1. For the analysis and guidance the smart grid system have been broken down in several subsystems (Figure 8). 2. Sub systems are described by relevant use cases for the respective system. 3. Then for each of these subsystems a (typical) reference architecture (components and interfaces) have been defined in the SGAM as described before. 24

25 Methodology and New Applications - SG-CG/M490/F Based on the standards identified in the SGAM a list of standards for each system and its interfaces can be evaluated. 5. Additionally cross-cutting standards are listed (e.g. with reference to SGIS or to communication specific issues). The report provides an overview for all experts in the field of Smart Grid standardization and a support for users in the selection of relevant standards for their purposes Figure 8: Systems break-down over the SGAM plane For more detailed please refer to the relevant documents: [SG-CG/B] SG-CG/M490/B_ Smart Grid First set of standards [SG-CG/G] SG-CG/M490/G_ Smart Grid Set of standards [SG-CG/K] SG-CG/M490/K_ SGAM usage and examples [Mapping Tool] 6.7. Standards gaps, prioritization, work program The following tools provide management support in a broad field of technology in order to focus standardization resources and provide overview and coordination of various activities. 1. Based on a structured analysis (refer to chapter 7) or on input from stakeholders a standardization gap list can be gathered. 2. In the next step the gap list can be prioritized by a voting of the stakeholders represented in the SG-CG on two criteria: Smart Grid deployment impact and Standardization gaps filling-up chance. Gaps are selected when one criteria is higher than the defined threshold. The prioritization focuses the work of the SG-CG on main topics. Nevertheless, as yet unselected gaps might be subject to a work programme of other technical bodies. 3. The work programme which is based on the gap list and the prioritization serves different needs a. List, description, status and timetable of selected gaps 25

26 Methodology and New Applications - SG-CG/M490/F b. A dashboard for each selected gap as a management tool providing information like: i. The gap to be filled. ii. The standardization bodies involved in filling the gap. iii. Each gap has a gap leader who follows up the closing of the gap and manages between the different involved groups. iv. The standards considered in this work package, with their expected impacts, and associated status. v. The plan of actions associated with the work package, including title, initial forecast completion date and updated forecast completion date, in order to monitor the follow-up of the gap filling. For more detailed please refer to the relevant documents: Current version: SG-CG Report Programme of standardisation work for the Smart Grid v2.01 [Work program]. Note: the work programme is updated on regular basis. SG-CG Report Standardisation Gaps Prioritisation for the Smart Grid, latest version [Gap Prioritization] 6.8. Cyber security & privacy An important aspect of the work of the Smart Grid Co-ordination Group is to provide Smart Grid information security (SGIS) guidance and standards to Smart Grid stakeholders to support Smart Grid deployment in Europe. Available security standards are increasingly applied to address functional, organizational or procedural requirements. Selecting the right security standards to achieve a dedicated security level on a technical and organizational or procedural level is crucial for the reliability of a European Smart Grid. Mapping to SGAM Security has been considered by reference to the Smart Grid Architecture Model (SGAM), the SGIS security levels and selected use cases. The Smart Grid is a system of systems connected and interacting with each other. Their security requirements will vary depending on the SGAM Domain/Zone in which the systems are located. By mapping selected security standards to the SGAM, their applicability in the different Smart Grid zones and domains on different layers can be identified, thus helping system designers and integrators in selecting the proper security standards to protect the Smart Grid system appropriately. SGIS - Security Levels SGIS security levels were defined in the 1st phase of Mandate M/490 with the aim of creating a bridge between electrical grid operations and information security. Considering European electrical grid stability and the power loss caused by possible ICT systems failures, a number of scenarios were identified, representing the scale of possible disruptions to the European grid. From this viewpoint of pan-european electrical grid stability, each SGAM domain/zone cell and the kind of equipment used there to manage power were then considered, and an assessment made of the maximum potential power loss involved. Guidance values could then be defined, to assist identification of the most critical areas, where security matters most from a pan-european grid stability perspective. This is the basis of the SGIS security levels proposed and illustrates a general approach, which can be applied by stakeholders as desired. Security standards In the first phase of the mandate M/490, SGIS focused on the following standards: ISO/IEC 27001, ISO/IEC 27002, IEC 62351, NERC CIP (US Standard), NIST IR-7628 (US Guidelines). Subsequently IEC has been considered further, together with the energy automation domain specific standard ISO/IEC TR 27019, extending ISO/IEC The second working period of the SGIS investigated further selected security standards applicable in Smart Grid that also relate to adjacent domains like industrial automation. 26

27 Methodology and New Applications - SG-CG/M490/F Additionally, implementation related standards from ISO, IEC and IETF were taken into account. The security standards focused in the second working period are distinguished into requirements standards and solution standards. These standards have been considered according to their nature, applicability and scope, and mapped to SGAM domains and zones, so as to assist the identification of suitable security standards for a particular use case, and potentially to suggest the need to enhance standards where necessary. Detailed consideration is given to selected security requirements standards, their current status and gaps. Moreover, new standards have been identified for further investigation, which are not covered by the work so far. European Set of Recommendations The European set of recommendations objective is to support Smart Grid stakeholders in designing and building a European Smart Grid infrastructure secure by design. In April 2014, ENISA and European Commission Smart Grid Task Force Expert Group 2 (EG2) ad hoc group, released a Proposal for a list of security measures for Smart Grids report. For consistency of work at European level the choice has been made to work with the measures proposed in this report to define the European set of recommendations. Two additional domains have been found which were beneficial to be added during the analysis work: Situational Awareness and Liability. Recommendations are presented and linked to SGIS-Security Levels, SGAM domains, zones and layers, and standards through a dashboard. Using this dashboard for the SGIS Security Level that has been identified for a given use case, recommended cyber security domains can be prioritized and an action plan proposed. As security measures, domains and security standards are mapped using SGAM, a correspondence can be established between them. Thus for a given domain of measures, available standards to support measures implementation can be identified. The European Set of Recommendations should be reviewed yearly. This is a continuous process. Cyber Security is a journey not a destination. Privacy Data Privacy and Data protection, particular in the context of smart metering, is crucial for a sustainable business. The forthcoming EU General Data Protection Regulation has been analysed to understand the potential impact on organizational and functional requirements and its relationship with the current sectorspecific regime in four member states examined. The Smart Grid Task Force Expert Group 2 (SGTF EG2) has developed a Data Protection Impact Assessment (DPIA) template. The main elements of the DPIA template specifically relevant to privacy for the individual have been considered and recommendations developed on how to improve the data protection aspect of the personal information in the SGIS Framework. It is suggested that data protection impact assessment is considered separately in the pre-assessment of the SGIS Framework, since an identical approach to security cannot be applied for data privacy. Additionally, an analysis on emerging Privacy Enhanced Technologies to support privacy by design is presented. Close liaison and co-operation has been maintained with the parallel work of the Smart Meter Co-ordination Group. SGIS Framework 5 During the SGIS Toolbox update discussions an improved approach has been defined which is more focused on the necessity to perform risk analysis than to have a general framework for risk analysis. The new approach changes the SGIS Toolbox into a methodology that could be used to create Awareness for management and/or decisions makers. 5 formerly SGIS Toolbox 27

28 Methodology and New Applications - SG-CG/M490/F It appeared that the SGIS Toolbox name was creating expectations regarding a ready to use tool that would have identified security levels and ad hoc security measures, whereas a process was, and (with the new approach) still has, to be followed. Therefore, the decision was made to rename it SGIS Framework. Conclusion The standards needed to establish the base of Smart Grid Information Security are available, but it needs continuous effort to incorporate existing and new technologies, architectures, use cases, policies, best practice or other forms of security diligence. For further information on this work, the reader is referred to the detailed report of the SGIS workgroup Interoperability Introduction A Smart Grid as a system cannot be engineered from the ground up. Instead, Smart Grid development is most likely to follow transformation processes. This means that business models as well as roles on one hand, and technical components and architectural structures on the other, are to be transformed from the current legacy state into a Smart Grid. Due to the scale of the system and its economic importance, failures in operation and especially architectural and functional planning of the system, potentially introduce high costs. In order to enable a well-structured migration process, the requirements for a Smart Grid and the current system have to be decomposed using an appropriate model. Although the majority of Smart Grid equipment is based on (inter)national or regional standards, this has not yet resulted in an interoperable Smart Grid infrastructure. This is partly due to misunderstanding of what interoperability means, what can be expected from it and what should be done to realize it. The key to reaching Smart Grid system interoperability is through detailed specifications, use of standards and testing. Therefore, as more and more ICT components are being connected to the physical electrical infrastructure, interoperability is a key requirement for a robust, reliable and secure Smart Grid infrastructure. The way to achieve Smart Grid system interoperability is through system specification, use of standards, and testing under applications of profiles. Developing an understanding of and paving the way for progress in this area has been the focus of the Working Group Interoperability (WGI). The WGI report [SG-CG/I], which is summarized in this section, provides methodologies related to these aspects, in order to reach the desired level of interoperability for Smart Grid projects. It seeks to achieve this by focusing on three different aspects and therefore tasks: System design and use case creation Use of standards, specifications and profiles Compliance, conformance and interoperability testing System design and use case creation With respect to system design, the IT Software/System Development Life Cycle provides a widely used methodology for system development, which ensures delivery of high quality software or systems effectively and efficiently. Use cases provide a basis for the specification of functional requirements, non-functional requirements, test cases and test profiles. Therefore, as a starting point, the system interoperability must be considered and well specified in the use cases, in order to develop an interoperable Smart Grid system by design. It is for this reason that the V-model (Figure 9) was selected to describe the different kind of specifications and related tests to perform in order to reach and demonstrate interoperability. Therefore, a generic system interoperability method or methodology has been developed in order to support the process of achieving system interoperability. In this methodology system design, use cases, testing, etc. were introduced. 28

29 Methodology and New Applications - SG-CG/M490/F Use of standards, specifications and profiles The definition of an application profile can be an important step to achieving interoperability as it can reduce the number of options and complexity of the full standard. Interoperability in the Smart Grid domain is further facilitated by usage of the SGAM model for Smart Grid systems. A glossary defines precisely what is meant by interoperability and other related terms to avoid misunderstanding (annex of [SG-CG/I]). It contains the most suitable definitions available for interoperability purposes such as conformity, compatibility and interchangeability. WGI strongly recommends that these definitions should be implemented and harmonized in future international standardization. Working group Interoperability (WGI) also established a methodology for profiling alongside an inventory of profiles that are already available, based on the output from the WG Set of Standards Compliance, conformance and interoperability testing To validate whether a system is interoperable within the Smart Grid, three types of tests will be required to performed, namely: Compliance tests The compliance test has the purpose to demonstrate that the applicable standard(s) are correctly implemented in the Device Under Test (DUT). Conformance tests The conformance test is to ensure the implementation is in accordance with all specified requirements or standards. Interoperability tests After the conformance test, interoperability tests should be performed to verify that communicating entities within a system are interoperable, i.e. they are able to exchange information in a semantically and syntactically correct way. During interoperability testing, entities are tested against peer entities known to be correct. Additionally, a framework for all standards, the Interoperability (IOP) tool, has been developed as a foundation for the profiling and testing process. It is helpful for identifying conformance testing and standard gaps, to select the required standards, and to derive and understand interoperability testing requirements Linkages to use cases and SGAM It is important to recognize that how and where the methodologies described in this document are applied, depends on the business needs. Therefore, in essence, [SG-CG/I] only describes the methodology how to improve interoperability. However, it is important to pin-point the key relationship between the methods developed for the prestandardization phase (refer to chapter 7) and test of interoperability in the post-standardization phase, particularly in the area of use case development and usage. In essence the degree and precision to which the use case methodology and SGAM are executed, has a direct bearing on the quality, accuracy and usefulness of the output of the interoperability methodology. Put simply, in order for IOP methodology to be fully utilized, a clearly articulated use case, following IEC template, is required, coupled with the graphical representation on the SGAM as illustrated by [SG-CG/G] Summary of IOP methodology IOP methodology can generally apply to all layers with interfaces between Smart Grid objects that are required to fulfil a defined (set of) use case(s). This means that it first needs to be defined on which layers IOP is required for these use case(s), and also in detail for each function [SG-CG/I, section 6]. The intention of the IOP methodology is the functional IOP using standards on the following layers (see also [SG-CG/B)]: 29

30 Methodology and New Applications - SG-CG/M490/F Information layer Communication layer Component layer Please refer to the [SG-CG/I] for a more detailed overview and explanation of these steps. However, the recommendation on the profile definition process is: a. Functional analysis 1. Select a set of use cases, as the use cases and the related sequence diagrams could be considered sufficiently to define functional requirements. If no use cases are available at this stage, it needs to be created first. 2. Define on which layers IOP is required to fulfil the functional requirements of the set of use cases: Business layer Function layer Information layer Communication layer Component layer b. Standards and specification selection 1. Define required physical interfaces and communication channels between objects. 2. Select (set of) standards for each interface within each required layer with the IOP tool and also identify any gaps in conformance/compliance testing (or possibly IOP testing) in this set of standards. If necessary, specifications may be taken into account additionally. b. Profiling based on standards and specifications as identified above the profile is based on business/functional requirements. 1. Build IOP profiles for each (set of) standards and specifications with possible feedback into standardization development. 2. Apply profiles in system design and testing phases. 3. Manage profiles As discussed in [SG-CG/I], by definition an IOP profile is a document that describes how standards or specifications are deployed to support the requirements of a particular set of use cases. It is therefore crucial to select the required standards or specifications as a prerequisite action for profile definition. These relevant standards for different applications within each layer can be selected with the IOP tool (refer to ). The application of the IOP tool furthermore requires the conventions used to draw the component, communication and information layer of a system mapping according to [SG-CG/B] [SG-CG/G], or another adequate mapping description. This results in multiple sets of standards for each use case cluster where all required standards within one set need to be interoperable and may require a specific IOP profile. The selection of standards also needs to represent the requirements of the system design phase of the V- Model (Figure 9), where appropriate standards for Requirement analysis 30

31 Methodology and New Applications - SG-CG/M490/F System design Architecture design Module design can be assessed with support of the IOP tool and the given filters. Backwards, the selected standards also need to be taken into consideration for the corresponding testing phases of the V-Model for compliance, conformance, IOP and acceptance tests. Nevertheless, how the selected standards are linked with profiles is part of the work item IOP profiling (refer to chapter 6.9.7) Developing interoperability profiling In general, profiling within a standard and between standards and specification helps to both improve interoperability and meet expectations of different projects where these will be implemented (refer to [SG- CG/I]). To reach the goal of interoperability a common understanding and interpretation of the related standard and the identical use of functional elements and data representation for a given domain specific application function has to be achieved by defining profiles IOP profiles An IOP profile is a document that describes how standards or specifications are deployed to support the requirements of a particular application, function, community, or context. A profile defines a subset of an entity (e.g. standard, model, rules). It may contain a selection of data models and services as well as protocol mapping. Furthermore a profile may define instances (e.g. specific device types) and procedures (e.g. programmable logic, message sequences) (refer to glossary of [SG-CG/I]). The objective of profiles is to reduce complexity, clarify vague or ambiguous specifications and so aims to improve interoperability. These generally apply for both sides of the V-Model (Figure 9) in terms of Basic Application Profiles (BAP) for the design phase and as extended versions (Basic Application Interoperability Profiles (BAIOP)) in the testing phase Basic Application Profiles (BAP) A Basic Application Profile (BAP) basically applies to the design phase of the V-Model and is based on system/subsystem specific basic application function descriptions / use cases. A BAP is an agreed-upon selection and interpretation of relevant parts of the applicable standards and specifications and is intended to be used as building blocks for interoperable user/project specifications. The key ideas of BAPs are: BAPs are elements in a modular framework for specific application systems/subsystems. Combinations of different BAPs are used in real projects as building blocks. Project specific refinement additional to the BAP might be necessary to meet specific requirements for implementation in projects. These additional requirements should be frequently fed back into a user group / standardization committee and may lead to a new or revised BAP based on user experiences and group decisions. BAPs are valid for specific application systems/subsystems (e.g. Substation automation, DER management, hydro power). They are intended to represent a user agreed common denominator of a recommended implementation or a proven best practice implementation of an application function in a specific Smart grid system/subsystem, but is not aimed to cover all possible implementation options. BAPs must not have options, all selected criteria are mandatory to achieve interoperability. If variants of BAPs for an application function are needed, different BAPs for the same application function have to be 31

32 Methodology and New Applications - SG-CG/M490/F defined. BAPs are built on the basis of international standards and will have an influence in the further development of standards as shown in Figure 11. BAPs may include: Description of the related application function (SGAM Function layer), Relevant data models (SGAM Information Layer), Communication services (SGAM Communication Layer), Component related requirements (SGAM Component Layer), Interaction diagrams, if the application function is divided into sub-functions which may be distributed in different physical devices. BAPs do not include more than black box functional behavior specification, algorithms and functional code and detailed instance definitions Basic Application Interoperability Profile (BAIOP) To reach interoperability a BAP has to be extended for interoperability testing. The extended BAP is referred to as Basic Application Interoperability Profile (BAIOP). For interoperability testing a BAP has to be extended by Device configuration, Test configuration with communication infrastructure (topology), BAP related test cases, specific capability descriptions (e.g. PICS, PIXIT, MICS in case of IEC 61850), Engineering framework for data modeling (instances) and communication infrastructure (topology, communication service mapping) Figure 9: V-Model including BAP and BAIOP 32

33 Methodology and New Applications - SG-CG/M490/F The definition and common use of BAPs and BAIOPs should lead to a win-win situation for all stakeholders involved in a smart Grid project in general, e.g.: The benefit for customers (e.g. utilities) and user groups is the chance to harmonize the various company specific application function variants to a common denominator / best practice implementation for each basic application function. This reduces the risk of interoperability problems caused by products/systems as these may be selected from standardized BAP frameworks and tested according to BAIOPs. The benefit for vendors which will use standardized BAP s in their products is the reduction of project specific or utility specific implementation variants of application functions and therefore reduce product complexity, development costs and parameterization efforts. BAIOPs can be used for internal tests before the product will be placed on the market. The benefit for Certification Bodies / Test Labs is the ability to perform interoperability tests based on BAIOPs and create a new business case out of the need for interoperability. The benefit for system integrators is that they can specifically select products conforming with BAPs and tested according to BAIOPs. This significantly reduces the efforts for integration of subsystems or devices Managing profiles It is important that profiling management will be in place in order to ensure that profiles are applied and understood in the same way by all affected stakeholders, and to avoid that diverging profiles for the same purpose will be developed and applied in parallel. Therefore WGI recommends that user groups shall take ownership of creating and managing profiles. This also means that lessons learned are fed back by users of the profiles to the corresponding user groups who are able to improve their profiles according to predefined cycles Implementation of profiles in real projects As BAPs and BAIOPs are elements in a modular framework for specific application systems/subsystems and can be used in combination as building blocks in real projects, the user involved in the project (e.g. a company or system integrator) is responsible to develop and maintain Project Application Profiles (PAP) and Project Application Interoperability Profiles (PAIOP) based on these building blocks, but specific refinement still might be necessary to meet the project requirements. To reduce the project implementation efforts, it is desired that PAPs and PAIOPs consist of BAPs and BAIOPs to the highest possible extent, so that as little refinement as necessary needs to be performed by the user. This process is basically illustrated in Figure 10: 33

34 Methodology and New Applications - SG-CG/M490/F Figure 10: Workflow of project specific profiling 7. Processes and management for the Smart Grid standardization methodology 7.1. Overall process How the elements and tools are interlinked Introduction This chapter intends to show how the different tools and elements of the concepts introduced in chapter 6 can be combined to an integrated and generic pre-standardization process recommended for the use inside standardization organizations. The description of the ideal type of process, which is based on preconditions, covers the whole design process of standards starting with new requirements (e.g. from business or regulation), use cases, SGAM, work program, new standards and profiles, and ends with a short overview of processes to prove conformance and test interoperability

35 Methodology and New Applications - SG-CG/M490/F Figure 11: Smart Grids generic pre- and post-standardization process Depending on the task the stakeholders may vary the recommended process according to their needs / application. As said for the use case template this methodology might be transferred and adopted to other systems as well, because the general principles are not specific to Smart Grids. The process starts with new ideas, requirements, processes, systems, or business cases from internal sources like the experts from technical or strategic committees of the organization itself or external stakeholders like R&D, political request (e.g. new laws, regulation, mandates) which express a need for standardization and require an early and coordinated activity as reaction. This new demand has to be analyzed making use of the tools and elements introduced in chapter 6. The steps in Figure 11 are explained below each step in one section (and in the figure a reference is made to the section number or to external source) Preconditions Before starting the description of the process some preconditions are required: A use case methodology is introduced throughout the standardization organization. 35

36 Methodology and New Applications - SG-CG/M490/F Use cases shall be described and maintained in a central use case repository (database) with a given use case template 6. The system and its processes are recognized and accepted by the relevant stakeholders. A coordinating committee (CC) is established for coordination and quality check. A support team (ST) helps the standardization experts in the committees to write use cases, to find actors and to use the tools / repository. The ST might be identical to the CC 7. The CC has established o basic definitions which are introduced for the system of interest such as a Smart Grid system: basic set of actor/roles definitions, zones, domains, terms. o A rough clustering of possible use cases, e.g. considering the conceptual model to identify affected/involved roles and responsibilities From requirements to use cases Input: Output: Process owner: Process contribution Tools: new requirements, needs (e.g. from market) validated generic use cases, actors Coordinating Committee in a standardization organization for a specific area like Smart Grid Or Technical or strategic committee in cooperation with CC Person / Organization / Committee who suggests the new requirements, technical or strategic committees within the standardization organizations Use case template, actor list, use case repository, conceptual model Within the coordinating committee established for Smart Grid use cases or within a technical body (e.g. TC, WG, TF) or suggested from external sources (market needs), the new demand is described as a use case. It is recommended for the first analysis to use a short version of the use case template. From the beginning some essential principles shall be followed: New use cases shall be suggested as generically as possible and shall not be project specific. The proposer of the new use case should check if the use case is already available or similarly available. In this case he is requested to contribute to the existing generic use case (GUC) instead of providing a new use case. By providing a new use case the author considers: o The criteria for GUC (e.g. not project specific,...) o Using the use case repository, o Accepting the exploitation rights agreement needed for standardization, o Explains links to existing GUC o Using existing definitions like roles, actors, domain, or zones as much as possible. Re-use of existing actors should be stimulated as much as possible, and around the definition of new actors a clear (centralized) governance should be established (coordinating committee). If use cases are duplicated, they should be described explicitly as alternatives to the already existing ones and should be related to them. NOTE This might be needed for instance, if a generic use case on international level will be modified at European or national level in order to match it to European or national specific circumstances like regulation. 6 The description here is independent from the SDO. But it should be noted that the upcoming IEC is defining a template which will be the basis for an IEC use case repository currently under design and programming. It is recommended to use the existing template and repository in order to harmonize the work on use cases. 7 E.g. for Smart Grid the IEC/TC 8 WG 6 Generic Smart Grid Requirements fulfills tasks which qualify the working group as CC and ST (tbd). 36

37 Methodology and New Applications - SG-CG/M490/F Granularity and depth of description of use cases should be managed flexible. The author / committee in charge decides about the appropriate form in the relevant phase (e.g. start with a short template, detailing in iterative steps after first discussions and confirmation of the relevance of the use case). Recommended process for the development of use cases 1. If new requirements are expressed from outside of the standardization organization for a first analysis, high level use cases / user stories are described and analyzed in order to develop generic use cases in the coordinating committee (CC). 2. A new use case might be discussed on working group / TC / CC level. Within a short time frame the new use case shall be suggested to the CC in order to allow other committees to provide further input and in order to achieve the aim of coordination by means of the use case descriptions. 3. After a rough review and quality check by CC checking the completeness and the mentioned basic principles the new GUC will be opened for discussion and further suggestions by the standardization community using the use case repository as a collaborative platform. 4. The CC leads the discussion and the development of the use case or designates a TC with this task. 5. Other TC s or even organizations considered to be relevant should be informed about the new use case, so that they can provide further input, comments, or changes. 6. After a defined time period the discussion will be finished and the use case is considered as broadly accepted. 7. The CC checks the result of the discussion phase and might hand over the use case to the next step. 8. A voting might officially document that the use case is considered as validated. NOTE: similar to standards a review / maintenance procedure shall define the process of revision of validated use cases. NOTE: established processes for database standards should be considered for the definition of processes within standardization organizations, e.g. for the voting process. 9. The CC might hand over this use case or a cluster of use cases for further elaboration to a Coordinating TC (CTC) specialized in the relevant issues. CC and CTC to suggest next steps like analysis, more detailed use cases, standards development etc. 10. The validated use case will be made available for the public (e.g. IEC mapping tool). The same principles shall apply for the suggestion of new actors. As use cases can be described on different levels of granularity an iterative process is recommended: Start with a high level use case (HL-UC) or conceptual description without going into details After the general ideas are accepted more detailed use cases can be established. The CC works mainly on high level use cases and conceptual descriptions having the whole system in view. The development of more detailed use cases are handed over to Coordinating TC's (CTC) which have the closest relation to the relevant use case EXAMPLE: electricity metering use cases -> IEC or CENELEC / TC From use cases to the SGAM use case analysis Input: Output: Process owner: Process contribution Tools: Use cases Analysis / SGAM reference architecture, list of standards / set of standards (refer to [SG-CG/B] [SG-CG/G] ) Coordinating Committee in a standardization organization for a specific area like Smart Grid Or Technical or strategic committee in cooperation with CC Person / Organization / Committee who suggests the new requirements, technical or strategic committees within the standardization organizations Use case repository, SGAM, Conceptual Model 37

38 Methodology and New Applications - SG-CG/M490/F As mentioned before there are various reasons, demands and needs to work with use cases in standardization. This means that the authors or the readers of use cases might have very different viewpoints on a use case or a set of use cases. The structured template for the use case provides already different fields in order to take different viewpoints when analyzing use cases. The following types of analysis are already discussed: Capturing requirements for new functions; analyzing, if these requirements can be fulfilled with the existing set of standards, or if there is a need for new standards or modification of existing ones Harmonizing functions, actors, roles across different stakeholder groups, sectors or technical bodies (e.g. terminology) Functional analysis to derive to new requirements: e.g. risk & threat analysis for IT-security or for functional safety purposes. The analysis might lead o to changes in the use cases or o to recommendation in combination with new or existing standards (e.g. recommendation of a specific security / safety level or need for standards for new safety features according to the new functionalities laid down in the use case) Information collection: together with the use cases further information can be gathered (refer e.g. to field "References", e.g. standards, legal requirements, contracts, etc.) General classifications of a use case: depth of description, business or technical viewpoint, prioritization of use cases Classification of use cases: which use cases belong to a specific role (e.g. using the Conceptual Model and/or HEM-RM), domain, actor, interface, business process, quality of the use case description etc. Test use cases: which requirements or scenarios / sequences (incl. normal, alternatives, fault scenarios) can be used for test purposes Guidance for readers who want to know which standards are necessary for their use case (in combination with the analysis in combination with SGAM below, refer also the set of standards [SG- CG/G], or the IEC mapping tool [Mapping Tool]) More detailed engineering, e.g.: o Information payload from Actor A to Actor B (interface) o Information for further programming, transfer to UML (scenarios / sequences, trigger events, information flow etc.) o Detailed requirements: e.g. quality of service, data management, information security, privacy and more (refer to the column "Requirements" in the step-by-step description of the use case Linking use case to a reference architecture like the Conceptual Model (for roles and responsibilities), SGAM and to standards (see also the following description) It is expected that in future with further works in the field of use cases and reference architectures, more analysis demands will be requested. In the following a basic process to analyse use cases to SGAM is described. A detailed example can be found in [SG-CG/K]. The mapping process can be applied to the following tasks, which are considered relevant for the present mandate M/490: Mapping of use cases in order to validate the support of standards on each SGAM layer Identifying gaps in respect to standards on each SGAM layer Identifying similar use cases by mapping the use case to SGAM domains and zones Harmonizing use cases/actors/interfaces between SGAM domains and zones Mapping of existing architectures into a general view Developing Smart Grid architectures Depending on the objectives the following process can be done iteratively. An overview of the basic process is depicted in Figure

39 Methodology and New Applications - SG-CG/M490/F Figure 12: Basic process for SGAM Use Case Analysis The example in [SG-CG/K] starts with a high-level use case which is mapped to SGAM domains and zones to define use cases. Then these use cases are described and analysed with SGAM in detail. To come from a use case description to an SGAM analysis different approaches are possible. The order in which SGAM layers are modelled depends on the use case under analysis and its viewpoint. Figure 13 describes a sequence proven-in-practice for the use case analysis with SGAM. 1. Use case description 2. Based on the use case description a business viewpoint should provide a clear view on the involved roles as well as their responsibilities and goals. 3. The analysis is complemented with the technical view on the lower layers of SGAM starting with modelling the function layer following the objectives of the use case. 4. Then, the component layer is developed to depict where functions are realised on hardware. The component layer is derived from the use case information on system/device actors. These actors are located to the appropriate domain and zone. 5. Based on the function and component layer information flows are identified and information objects can be defined on the information layer. 6. Finally, the communication layer describes protocols and mechanisms for the interoperable exchange of information. 39

40 Methodology and New Applications - SG-CG/M490/F Control reactive power of DER unit Audit Network Operations Reporting and Statistics Business Objectives Polit. / Regulat.. Framework DMS Volt/Var Control Business Layer SCADA Distribution Stabilize and Optimize Function Layer Distribution Data Collector Outline of Usecase Functions Data Acquisition DER Control Supervision Interoperability Layers Information Layer Data Model Data Model Distribution IED Distributed Generation Communication Layer Protocol Protocol Market Enterprise Component Layer Operation Grid Generation Transmission Distribution Domains DER Customer Premises Process Field Station Zones Use Case Description Business Layer Analysis Function Layer Analysis Component Layer Analysis Information Layer Analysis Figure 13: Use Case Analysis with SGAM example for an analysis process From use cases and SGAM analysis to standards gaps Communication Layer Analysis Input: Output: Process owner: Process contribution Tools: Use case(s) and SGAM analysis Gap list Coordinating Committee in a standardization organization for a specific area like Smart Grid Or Technical or strategic committee in cooperation with CC Person / Organization / Committee who suggests the new requirements, technical or strategic committees within the standardization organizations Prioritization, work program, dashboards Based on the analysis, the required functionalities, actors / roles as well as related standards and a reference architecture is available. For standardization purposes it can be checked, if the use case(s) can be performed with the referenced standards or if the standards need a modification / update or if new standards (new work item proposals) are needed. If a gap is detected, the analysis done in the previous step already provides a lot of detailed information to close the gap (like information exchange needs, payload or nonfunctional requirements related to the specific task). In reality the analysis will be more detailed if a gap is already expected, and less detailed if the use case / reference architecture is well known and state-of-the-art in standardization. If there is no gap identified, the analysis nevertheless supports the users of standards and can be seen as a selection guide which standard can be used for which task From standards gaps to standards Input: Output: Process owner: Process contribution Tools: Gap list Prioritized work program, dashboards for each gap, standardization projects, standards Coordinating Committee in a standardization organization for a specific area like Smart Grid (e.g. SG-CG) And Technical committee Technical or strategic committees within the standardization organizations Prioritization methodology, dashboard and work program templates 40

41 Methodology and New Applications - SG-CG/M490/F As already mentioned in chapter 6.6 identified gaps are summarized and prioritized. The method as described in [Gap Prioritization] might be used. The prioritized list of gaps represents the work program. In a further step for each gap, which is part of the work program, the next action item(s) are defined here the template for a dashboard might be used [Work program]. The work program can also be seen as a management of identified and selected / prioritized gaps. Based on the gap list or the prioritized gap list, and in close cooperation with the relevant technical bodies, new standards (e.g. Preliminary Work Item (PWI) or New Work Item Proposal (NP), see 7.2) or necessary modifications of existing standards will be developed. The following steps necessary to finalize the work on standards until publication are dependent on the mature practice of the relevant standardization organization as described in 7.2. If it is part of the work program of a coordinating committee (here the SG-CG/WG SS), the work progress will be monitored. This might be needed only for more complex gaps where various technical bodies are involved. Otherwise this is a task of the respective technical body From use cases and standards to interoperability profiles (BAP) Input: Output: Process owner: Process contribution Tools: Use cases, existing standards, specifications, profiles Interoperability profile related to use case (BAP) User group, standardization committee, or individual actor using the profiles User groups, standardization committees, system integrators, individual company (e.g. utility), vendors, certification bodies, test labs, regulator IOP tool, use case template, IEC use case repository, standards databases, selection guide according to [SG-CG/G], V-model, profile management It has to be defined on which layers IOP is required to fulfil the functional requirements of a use case: information layer, communication layer, component layer. Related existing standards, specifications and profiles are selected: o Define required physical interfaces and communication channels between objects. o Select (set of) standards for each interface within each required layer with the IOP tool and also identify any gaps in conformance/compliance testing (or possibly IOP testing) in sets of standards. If necessary, specifications may be taken into account additionally. Define profile definitions based on standards and specifications as identified above and on business / use case functional requirements. o Build IOP profiles for each (set of) standards and specifications (BAP) (with possible feedback into standardization development) o Apply profiles in system design (BAP) and testing phases (BAIOP, next phase). o Further definitions might be necessary for project specific implementations (PAP). Figure 14 illustrates the process from a use case to interoperability testing by using BAPs and BAIOPs. 41

42 Methodology and New Applications - SG-CG/M490/F Figure 14: Process from use case to interoperability on SGAM function layer From interoperability profiles (BAP) to testing profiles (BAIOP) Input: Output: Process owner: Process contribution Tools: BAP, specific extensions for testing purposes BAIOP user group, standardization committee, or individual actor using the profiles User groups, standardization committees, system integrators, individual company (e.g. utility), vendors, certification bodies, test labs, regulator IOP tool, V-model, profile management Extend the BAP profiles with further information as described in chapter 6.9. Further definitions might be necessary for project specific implementations (PAIOP) Introduction into the process of standard development in standardization organizations Standardization organizations established rules and processes, on how to develop standards in order to guarantee basic requirements for standardization like transparency, consensus, non-discriminatory participation etc. Each standardization organization defines its products (e.g. International Standards (IS) or Technical Reports (TR)) and the relevant processes. As example the IEC process for an International Standard (IS) is described 8 (see Table 2):

43 Methodology and New Applications - SG-CG/M490/F Table 2 IEC standardization process Preliminary Stage Preliminary Work Item (PWI) Future work is announced. Proposal stage New Work Item Proposal (NP) (Vote) Suggestion for a new standard or specification Preparatory Stage Working Draft (WD) A working draft is usually supplied with the NP. Later the last version of the working draft of the respective project team is distributed as CD. Committee Stage Committee draft for comments (CD) (comments collection) National committees are asked for comments. Enquiry Stage Committee draft for vote (CDV) (Vote) The draft can be commented and there is a vote to enter to the next step. Approval Stage Final draft International Standard (FDIS) Final vote without commenting. A positive vote is necessary for publication. Publication Stage International Standard (IS) Publication of the official International Standard (IS) Comparison of IEC and CENELEC processes (see Table 3): Table 3 Comparison of IEC and CENELEC processes Stage IEC Respective CENELEC Preliminary Stage Preliminary Work Item (PWI) Preliminary Work Item (PWI) Proposal stage New Work Item Proposal (NP) (Vote) New Work Item Proposal (NWIP) Preparatory Stage Committee Stage Working Draft (WD) Committee draft for comments (CD) (comments collection) Draft Enquiry Stage Committee draft for vote (CDV) (Vote) Draft pren (CDV/ENQ) Approval Stage Final draft International Standard Final Draft pren (FDIS/VOTE) (FDIS) Publication Stage International Standard (IS) European Standard (EN) Comparison of IEC and ETSI processes (see Table 4): Table 4 Comparison of IEC and ETSI processes Stage IEC ETSI Preliminary Stage Preliminary Work Item (PWI) Proposal stage New Work Item Proposal (NP) (Vote) New Work Item Proposal (TB Vote) Preparatory Stage Working Draft (WD) Draft for WG Approval 1450 Committee Stage Enquiry Stage Approval Stage Committee draft for comments (CD) (comments collection) Committee draft for vote (CDV) (Vote) Final draft International Standard (FDIS) Draft for TB Approval (TB vote) Approval and publication for Technical Specification, Group Specifications and Technical Reports Final draft for EN Approval Procedure (ENAP) of Two-step Approval Procedure (TAP) Publication Stage International Standard (IS) European Standard (EN) 43

44 Methodology and New Applications - SG-CG/M490/F The intention of the process is a broad worldwide consensus and non-discriminatory participation. Therefore several information, commenting and voting steps are introduced. IEC and CENELEC are closely interlinked according to the Dresden Agreement which describes the common planning of new work items and parallel voting between IEC and CENELEC. Similar agreements are established for ISO / CEN or ETSI / ITU. For other types of documents faster processes are established. Specialized standards are published as database with modified rules compared to the above-explained processes. This means that for the phase in Figure 11 called "Standardization Phase" today processes are available and mature. For the interoperability phase currently processes are established inside or outside of the standardization organizations. Suggested improvements need to be evaluated by the SDOs. The main part of the proposed new process is considering the pre- and post-standardization phase, in Figure 11 called "Analysis Phase" or Testing, as an addition to and supporting the established standardization processes. Starting with a structured collection of new requirements and tools for their analysis this process shall enable the Standards Developing Organization (SDO) to react quickly and competently as soon as new complex and more interlinked systems are evolving. Recommendations The following recommendations are describing a possible introduction of the suggested new processes and tools within an SDO: Evaluation of the suggested process Test with an example system and modification according to best practice experience 9 Establishing of o a use case repository 10 with a generic actor list o a Coordinating Committee (CC) dealing with new requirements, transferring them into generic use cases, analyzing them and providing a coordinated work program for new work item proposals 11 o common understanding of the need for a coordination and cooperation of different sectors and technical committees dealing with systems of cross cutting nature o Training on the new tools and processes / support using these tools by a Supporting Team (ST) / providing necessary templates and tools o Coordinating TC (CTC) in addition to the CC use cases or clusters of use cases might be handed over to technical committees that are most interested and specialized in this area. The CTC coordinates further detailing of these use cases, reference architectures and analysis up to the standards work program in cooperation with interested other TC's. The process needs to be transparent. A common collaborative platform like the use case repository or the mapping tool 12 will be helpful. This collaborative platform shall provide the possibility of commenting and discussion and in some cases also voting (e.g. on use cases). The process shall enable various level of granularity: easy and quick start and exchange without detailed knowledge up to a more detailed and deep analysis which can be used for the standards, test use cases or engineering. 9 E.g. the work on Smart Grid provides already first experience 10 The SG-CG developed a prototype in the first phase of the mandate. IEC is building up a repository. 11 E.g. IEC/TC 8 WG 6 "Generic Smart Grid Requirements" 12 see (Best with Chrome as browser) 44

45 Methodology and New Applications - SG-CG/M490/F New products like use cases, work program, reference architecture needs to be defined: Status of new documents, processes in detail (e.g. suggestion, commenting, voting), relation to the existing processes and products E.g. new IEC parts 1 to 3 under preparation 45

46 CEN-CENELEC-ETSI Smart Grid Coordination Group Date: 08/2014 Secretariat: CCMC SG-CG/M490/J_ General Market Model Development The conceptual model and its relation to market models for Smart Grids Version 2.0 1

47 Foreword Based on the content of the M/490 EU Mandate in its phase 1 ( ), the general scope of work on standardization of the Smart Grid might be considered as follows: CEN, CENELEC, and ETSI are requested to develop a framework to enable European Standardization Organizations to perform continuous standard enhancement and development in the field of Smart Grids, while maintaining transverse consistency and promote continuous innovation. In the light of the discussions held between the EC Reference Group (EG1) and the Smart Grid Coordination Group (SG-CG), the need to iterate the EC Mandate M/490 was considered and agreed by both sides. As a main objective of the mandate phase 2, the SG-CG wishes to implement the developed methodology, which set up the foundations for managing the continuous engineering and deployment of standards to ensure a real end-to-end interoperability for all generic use cases explicitly including security. A further refinement of the methodology will be used for the set of consistent standards [SG-CG/G] (under item 3.1 and 3.2 of M/490). The work is based on [SG-CG/C] and [SG-CG/E]. The final report is due on September 1 st, 2014, based on the version v1.0 provided end of 2013 for commenting within the SG-CG. A set of documents is addressing this objective: The main report as a summary of different tools, elements and methodologies developed by the different working groups of the Smart Grid Coordination Group [SG-CG/F], and additional separate reports detailing specific issues of the working group Methodology and New Applications : The conceptual model and its relation to market models for Smart Grids [SG-CG/J] (this document) SGAM User Manual - Applying, testing & refining the Concepts, Elements and Tools for the Smart Grid Architecture Model (SGAM) [SG-CG/K] Overview of the main concepts of flexibility management [SG-CG/L] 26 2

48 27 Table of contents Smart Grid Coordination Group Page Foreword 2 1 References Terms and Definitions Symbols and abbreviations Basics for European Market Models Meta-Models Introduction Meta model Definitions of the terms used in the meta-model Meta-model examples Bundles of roles The Conceptual Model Relationship between the domains of the conceptual model and the European harmonized electricity market role model Starting Principles European Conceptual Model of Smart Grids Alignment Alignment with the EU flexibility concept Alignment with NIST, SGIP, SGAC Alignment with Harmonized Electricity Market Role Model Alignment with EU market model developments (EG3) Conclusions The European Harmonized Electricity Market Role Model Relationship between the domains of the conceptual model and the European harmonized electricity market role model Role model role definitions List of figures Figure 1: Alignment of standards development with market model development... 7 Figure 2: Alignment process of standardization and market model development via actors and roles... 8 Figure 3: Meta-model for the business layer... 9 Figure 4: Meta-model for the business layer Grid Operator example Figure 5: Meta-model for the business layer Consumer example Figure 6: Role decomposition of Distribution System Operator (DSO) Figure 7: Role decomposition of Energy Supplier Figure 8: Meta-model for the European conceptual model for Smart Grids Figure 9: Evolution of centralized/ decentralized power systems deployments

49 Figure 10: European Conceptual Model for the Smart Grid Figure 11: Relationship between the domains of the conceptual model and the European harmonized electricity market role model List of tables Table 1 - Role model definitions History of document V1.0 18/12/2013 For publication and review by the BTs and TCs. V /06/2014 Integration of comments, basic for F2F meeting of WG Method on 16 th of June V /06/2014 After F2F meeting V /06/2014 Cleaned version for editors V /07/2014 Made role, actor etc. changes as agree in F2F V /08/2014 Fine Tuning V1.9.4 Semi-final in the WG Method V Final for distribution to the SG-CG, commenting phase Main changes in this version Chapter 5 SGAM is moved to Annex C -> new title of this documents Figure 1 Role-Actor relationship changed from is assumed by / assumes to is performed by / performs task in 5.5 Section name changed from Composed Roles to Bundles of Roles Fine-Tuning, language check 82 4

50 References Smart Grid Coordination Group Phase 1 Documents [SG-CG/A] SG-CG/M490/A Framework for Smart Grid Standardization [SG-CG/B] SG-CG/M490/B_ Smart Grid First set of standards [SG-CG/C] SG-CG/M490/C_ Smart Grid Reference Architecture [SG-CG/D] SG-CG/M490/D_Smart Grid Information Security [SG-CG/E] SG-CG/M490/E_Smart Grid Use Case Management Process Smart Grids Coordination Group Phase 2 Documents [SG-CG/F] [SG-CG/G] [SG-CG/H] [SG-CG/I] [SG-CG/J] [SG-CG/K] [SG-CG/L] SG-CG/M490/F_Overview of SG-CG Methodologies SG-CG/M490/G_Smart Grid Set of standards SG-CG/M490/H_ Smart Grid Information Security SG-CG/M490/I_Smart Grid Interoperability SG-CG/M490/J_General Market Model Development (this document) SG-CG/M490/K_SGAM usage and examples SG-CG/M490/L_ Flexibility Management References made in this document [ENTSO-E 2012] Modular Development Plan of the Pan-European Transmission System 2050 of the e-highway2050 Project Consortium: ENTSO-E RGCE ENTSO-E RGCE Operation handbook Glossary, [HEM-RM 2011] The Harmonized Electricity Market Role Model (December 2011), ENTSO-E, ebix and EFET, online: edi/library/role/role-model-v pdf [Jonkers 2010] TOGAF 9 and ArchiMate 1.0 White paper, The Open Group 2010 [TOGAF 9.1] The Open Group Architecture Framework WGSP-0400 Use Case, refer to [SG-CG/E] Terms and Definitions Refer to [SG-CG/F] 3 Symbols and abbreviations ACER ATC BT CEER Agency for the Cooperation of Energy Regulators Available Transfer Capability Technical Board (CENELEC) Council of European Energy Regulators 5

51 CEN CENELEC CIS DER DSO ebix EC EFET ENTSO-E ETSI EU HEM-RM HVDC ICT IEC IT MOL NIST NTC OT PEEES SGAC SGAM SG-CG SG-CG/SP SGIP TC TOGAF TSO UML US VAr WG Comité Européen de Normalisation Comité Européen de Normalisation Electrotechnique Customer Information Systems Distributed Energy Resources Distribution System Operator (European forum for) energy Business Information Exchange European Commission European Federation of Energy Traders Smart Grid Coordination Group European Network of Transmission System Operators for Electricity European Telecommunications Standard Institute European Union Harmonized Electricity Market Role Model High-Voltage Direct Current Information and Communication Technologies International Electrotechnical Commission Information and communication Technology Merit Order List National Institute of Standards and Technology Net Transfer Capacities Operational Technology Pan European Energy Exchange System SGIP Smart Grid Architecture Committee Smart Grid Architecture Model Smart Grid Coordination Group SG-CG Sustainable Processes Work Group Smart Grid Interoperability Panel Technical Committee The Open Group Architecture Framework Transmission System Operator Unified Modeling Language United States Unit of the reactive power Working Groups 6

52 Basics for European Market Models In the forthcoming years increased discussion is expected at a European level around market models related to Smart Grids. The EU still retains the ambition to implement a single European Market for energy. However existing market models across EU Member States differ and are therefore the prospect of a European market model may seem to some as a utopian concept at this moment in time. This poses an additional challenge for the standardization processes, namely: How to develop standards that are market model agnostic? In other words: how to develop standards that are robust against variations in the markets they are to be applied within? This challenge transcends differences in market organization in the EU. If globally useable standards are desired, they must also be agnostic to market model difference globally (e.g. between the US, Asia, and/or the EU). In this document market models are considered as the definition of responsibilities and roles which are taken by parties, either mandatory by law or regulation (e.g. a grid operator in a regulated natural monopoly) or by choice to provide or consume services (e.g. in electricity retail) in a liberalized market environment. Therefore the perspective taken here centers on the ambition that a generic set of roles is applied that supports the market model discussions current taking place at a European level. Ideally, standards are developed from use cases describing the external behavior of systems in the interaction with actors. If a unique mapping between these actors and roles is maintained, and European market model discussions are based on the same set of roles, then determining how to apply standards to different markets is straightforward. This is depicted in Figure Figure 1: Alignment of standards development with market model development To support this, the objective of the SG-CG (M/490) is to provide a generic list of roles (refer to chapter 7 as part of the methodology toolkit, which: is the basis of all market model developments, to which all actors from the uses cases uniquely can be mapped, which can be used by DSO, TSO s (and possible other market parties), which is aligned with - and form the basis for - the European network codes (ENTSO-E / ACER / CEER) With the emergence of Smart Grids, a much more intense relationship and information exchange between DSO s and TSO s is foreseen. It is therefore necessary that this generic role list is common for both TSO s and DSO (although not all roles may be applicable to both TSO s and DSO s). This therefore is the rationale for building on the well-established European Harmonized Electricity Market Role Model (HEM-RM) developed by ENTSO-E, EFET and ebix. 7

53 There is an urgent need for standards development in order to support the proliferation of demand response and flexibility services, while at the same time market model and network codes development on these topics takes place. It is therefore essential that all these developments are well synchronized. Using the methodology in which these developments are synchronized via roles, will guarantee this. The process that will have to be followed to arrive at standards that support emerging market models is depicted in Figure 2. The Process / Methodology The proces/ methodology Generic list of roles Market model discussions, regulation High Level Use case = A high level description of a required process, in which actors are defined actor role mapping role/ party mapping From this, interaction between actors follow From this, interaction between roles follow From this, interaction between parties (incl. customers) follow 195 From this, business services between actors follow From this, business services between roles follow Business services are the required standards From this, business services between parties (including customers)follow Figure 2: Alignment process of standardization and market model development via actors and roles 5 Meta-Models 5.1 Introduction Standardization of interfaces, performance of systems, etc. requires modeling of systems, their use cases, interfaces, etc. In the area of Smart Grids, this is a complex endeavor because it covers a large scope and many disciplines from energy technology to market structures. A meta-model provides a framework for expressing specific models, i.e. it depicts concepts on forehand that can exist in the respective domain to be modeled. Examples of meta-models include the Smart Grid Architecture Model, TOGAF, Archimate, to name but a few. 5.2 Meta model Figure 3 provides a graphical representation of the meta-model for the SGAM business layer (SGAM Smart Grid Architecture Model). 8

54 Responsibility defines is described by Role is assumed by assumes Party accesses is performed by contains owns and governs Business Layer performs tasks in Actor represents participates in is accessed by accesses Business Service is owned and governed by provides interface to access is realised by decomposes involves Business Process orchestrates can be accessed by is bounded by supports Function Layer Business Function Figure 3: Meta-model for the business layer Definitions of the terms used in the meta-model The Smart Grid brings different disciplines together, each with its own vocabulary, definitions and viewpoints. In defining a concise set of definitions for this meta-model, a best fit is made from the definitions of TOGAF, Archimate, SGAM, the Harmonized Electricity Market Role Model (HEM-RM) and apply the desire to model in a non-market specific way Party Responsibility Role Parties are legal entities, i.e. either natural persons (a person) or judicial persons (organizations). Parties can bundle different roles according to their business model. EXAMPLES: real organisations like Dong Energy, Liander, APX Group Responsibilities define external behavior to be performed by parties. EXAMPLES: Nominate Energy, Operate a grid, Determine the market energy price after applying technical constraints A Role represents the intended external behavior (i.e. responsibility) of a party. Parties cannot share a role. Parties carry out their activities by assuming roles, e.g. system operator, trader. Roles describe external business interactions with other parties in relation to the goal of a given business transaction. [source: adapted from [HEM-RM 2011]] EXAMPLES: Balance Responsible Party, Grid Operator, Market Operator. 9

55 Actor Business Service Business Process Smart Grid Coordination Group An Actor represents a party that participates in a business transaction. Within a given business transaction an actor performs tasks in a specific role or a set of roles. [source: adapted from [HEM-RM 2011]] EXAMPLES: Employee, Customer, Electrical vehicle, Demand-response system. NOTE this Actor represents actors typically found in a High level business use case at the Business layer of SGAM, often with a relationship to a role from the Harmonized Electricity Market Role Model. In lower level use cases actors are present that better fit e.g. an UML or IEC TC8 actor definition. A Business Service supports business capabilities through an explicitly defined interface and is explicitly governed by an organization. [TOGAF 9.1] A Business Process is a flow of interactions between functions and services and cannot be physically deployed. All processes should describe the flow of execution for a function and therefore the deployment of a process is through the function it supports; i.e., an application implements a function that has a process, not an application implements a process. [TOGAF 9.1] Meta-model examples Figure 4 and Figure 5 provide examples of the top part of the business layer meta-model introduced above. They cover the concepts: responsibility, role, party and actor. In the first example, a Grid Operator role is shown with its related responsibility. In the example a demand response system is shown as an actor which is employed in order for parties to perform the Grid Operator role. Operate a Grid is described by Grid Operator is assumed by : Responsibility defines : Role assumes is performed by Enexis : Party contains performs tasks in Demand Response System : Actor represents Figure 4: Meta-model for the business layer Grid Operator example The second example below is very similar in structure as to one above; here the main role is a Consumer using a Customer Energy Management System as an Actor. Note that these examples are by no means meant to be normative, they only illustrate the concepts introduced in the meta-model. 10

56 Figure 5: Meta-model for the business layer Consumer example 5.5 Bundles of roles Roles should be generic and atomic, i.e. they cannot reasonably be further decomposed. DSO and Energy Supplier are prominent examples that can be considered bundles of roles in terms of the EU market model. Standards should be designed around the atomic roles rather than bundles to avoid incompatibility with the market models in the EU member states. When coming across e.g. the terms such as DSO or Energy Supplier consider decomposing them as depicted in Figure 6 and Figure 7. In general one should aim for using roles which are as atomic / indivisible as possible, e.g. as provided by the [HEM-RM 2011] Figure 6: Role decomposition of Distribution System Operator (DSO) Figure 7: Role decomposition of Energy Supplier

57 The Conceptual Model 6.1 Relationship between the domains of the conceptual model and the European harmonized electricity market role model The electrical energy system is currently undergoing a paradigm shift, that has been affected by a change from the classical centralistic and top down energy production value chain "Generation", "Transmission", "Distribution" and "Consumption" to a more decentralized system, in which the participants change their roles dynamically and interact cooperatively. In the future decentralized energy systems, distributed energy resources and prosumers (i.e. electricity producing consumers) will play an increasingly important role. The development of the concepts and architectures for a European Smart Grid is not a straightforward task, because there are various concepts and architectures, representing individual stakeholders viewpoints. In conceptualizing the paradigm shift from the current situation to future situation, both situations are described below: The current situation could best be described as: Supply follows demand, One-way energy flow in the grid: bulk generation => transmission => distribution => consumption, Capacity in distribution networks is dimensioned on peak (copper plate), resulting in (almost) no network congestion, Capacity required in the lower voltage range is predictable, since it is only based on energy usage. The future situation could best be described as: Demand follows supply, due to the deployment of renewables, which are intermittent in nature. Electrification of society in order to meet objectives, which will lead to a further growth of electricity demand. Two way energy flow in the grid: consumers will also produce (e.g. by means of a photovoltaic cells, micro combined heat and power installations, etc.) and supply their surplus power to the grid. A future grid will need to support: o Multiple producing consumers, that will aggregate their electrical surplus to a Virtual Power Plant. o Electrical cars, in such a way that the grid won't fail when they want to charge simultaneously or use their batteries for energy storage to use in situations with high consumption or high production. o The integration of all kinds of distributed energy resources (wind, solar, storage ) A grid which will have to fulfill these requirements, not only by expanding grid capacity (which might become very costly due to the expected increase of peaks), but also by implementing smartness via Information and Communication Technologies (ICT) solutions, in a way that it will fully support current and future market processes. Furthermore a future grid will need the Smart Grid functions, described in the EG1 report of the CEN/CENELEC/ETSI Joint Working Group. In the future energy system very different dynamics within the grid will be faced, resulting from the expected continued proliferation of distributed (renewable) energy resources, whose timing of participation and 12

58 behavior is difficult to predict. These increased dynamics will require a much more flexible (and intelligent) approach towards the management of electricity supply and demand. Furthermore, the future situation should also allow for new market models and let all kinds of customers participate in the trade of electricity. Flexibility, thus, will be key. Where until today in the current supply follows demand model, flexibility was offered in bulk generation, in the future in the demand follows supply model the flexibility must be equally offered on both sides (generation (centralized and decentralized) and consumption (e.g. demand side management)). Therefore the ICT infrastructure and ICT solutions, which enable the required flexibility on demand and supply sides in a fully interchangeable way, which become a key component of the smart grid and therefore will be part of the smart grid eco system. This chapter defines the conceptual model of the European smart grid. This conceptual model should be regarded as the initial umbrella model from which all future frameworks, architectures and standards could be derived, and from which also existing standards could be (re) positioned. This conceptual model should also be able to act as a key reference point for future market models and related regulation, in order to guarantee that market models are supported by the right architectures and standards. The Reference Architecture for the Smart Grid must support several stakeholder groups in building the European Smart Grid, and each stakeholder today holds a different perspective on the smart grid. The more and more decentralized energy production becomes, the greater the demand will be on new methods to guarantee the stable operation of the electrical part of the smart grid. The development of the future smart grid requires the collaboration of different stakeholders. The future smart grid technology is unique in that it is anchoring the integration of power system management technology and information and communication technology / operational technologies (IT/OT convergence). The conceptual model essentially seeks to serve as a common framework, thereby enabling the convergence and facilitation of the dialog between all these stakeholders, and thus make an important contribution to aligned and consistent smart grid deployment within Europe. This alignment and consistency is guaranteed by references to the Harmonized Electricity Market Role Model [HEM-RM 2011]. A common dictionary is necessary in order to enable stakeholders to talk the same language. The Conceptual Model in a sense will be this common dictionary and describe key concepts in the European smart grid. 6.2 Starting Principles Defining a European conceptual model, from which architectures and standards can be derived, requires explicit starting principles, to be used as acceptance criteria for the Conceptual Model. These starting principles are described in this chapter. Approach Conceptual domains are a grouping of roles and actors. So roles and actors in the conceptual domains of both models can be used as a fix point for the alignment of the models. To identify the same roles and actors in the conceptual domains of both models, the European harmonized electricity market role model will be used. This alignment is based in detail on the following 5 principles, which form the basis for the development of the EU Conceptual Model (described in 6.3). 358 Principle 1: Extract business roles and system actors from the EU conceptual model The EU conceptual model is organized in conceptual domains. These conceptual domains group roles and thereby system actors which perform tasks in these roles as shown in Figure 8. This figure illustrates the meta-model used for the European conceptual model for Smart Grids. 13

59 Conceptual Domain groups part of Role is performed by performs tasks in Figure 8: Meta-model for the European conceptual model for Smart Grids Actor The approach to model the conceptual model based on business roles and related system actors ensures compatibility between market and technologies/standards. Chapter 5 provides a more detailed description of this approach Principle 2: Alignment with the European electricity market In the WGSP flexibility model, the business roles are based on the European harmonized electricity market role model, developed by ENTSO-E, ebix and EFET and defined in [HEM-RM 2011]. This ensures alignment of technologies/standards that are developed from this model with the European electricity market. The grouping of roles of the harmonized electricity market role model into the domains of the WGSP flexibility model supports initial understanding of the European electricity market (at a higher level of abstraction than the 36 roles identified in [HEM-RM 2011]). 374 Principle 3: Support central and distributed power system deployments The EU conceptual model (described in the next section) must support fully centralized, fully distributed and hybrid deployments of the power system. Energy resources connected to all levels of the grid are relevant in Smart Grids, ranging from bulk generation and industrial loads down to distributed energy resources and domestic loads. Also support for grids outside the traditional public infrastructure should be supported, as e.g. analyzed in the use cases of the workgroup on sustainable processes from the SG-CG. Examples include (non-public) grids used in local energy cooperatives, ranging from industrial areas (sea- and airports) to agricultural areas (e.g. in the greenhouse sector) Figure 9: Evolution of centralized/ decentralized power systems deployments 1 The concept of an actor is broad. E.g. actors, as identified in [SG-CG/E], roughly might be divided into system actors (devices, systems) and business actors (people, staff) (Ref. IEC TC8). When dividing domains into subdomains, then certain subdomains may not contain business actors as these subdomains may be fully defined as technology ( e.g. transmission and distribution infrastructure). 14

60 384 Principle 4: Smart Grid Coordination Group Support micro grids and a Pan European Energy Exchange System (PEEES) The objective of micro grids is to start the optimization of the grid as locally as possible, e.g. to find a balance between production and consumption, in order to avoid transmission losses and increase transmission reliability through ancillary services such as reserves Volt/VAr support, and frequency support. For other objectives to be met for micro grids see also use case WGSP PEEES are essential to realizing the large-scale energy balance between regions with a low-loss wide-area power transmission. The Pan European Energy Exchange System (PEEES), includes technologies in the transport network for low-loss wide-area power transmission systems (e. g. high-voltage direct current transmission, HVDC), better realizing the large-scale energy balance between the regions, which is essential due to the constantly changing weather situation, which has a significant influence on the power generation capacity of different regions. The PEEES is here to be understood as an abstract model for further discussions to cover the concepts for low-loss wide-area power transmission systems. As an example of this, the "Modular Development Plan of the Pan-European Transmission System 2050" of the e-highway2050 Project Consortium can be mentioned here [ENTSO-E 2012]. 400 Principle 5: Support providing flexibility in electricity supply and demand Providing flexibility in electricity supply and demand on all levels in the power system is paramount for integration of renewable energy sources in the Smart Grid. The EU conceptual model must support the use cases on providing and using flexibility. 6.3 European Conceptual Model of Smart Grids The European conceptual model of Smart Grids is defined through grouping of (European harmonized) roles and system actors, in line with the European electricity market. Figure 10 depicts the European conceptual model for the Smart Grid. The model consists of four main conceptual domains, Operations, Grid Users, Markets, and Energy Services. Each of these conceptual domains contains one or more subdomains with group roles which can be identified in the European electricity market. For this the European harmonized electricity market role model developed by ENTSO-E, ebix and EFET is used as defined in [HEM-RM 2011] and introduced in section 7. This section also provides detailed definitions of the conceptual domains of the European conceptual model for the Smart Grid and the relationship to the role model. Operations and Grid Users are conceptual domains that are directly involved in the physical processes of the power system: electricity generation, transport/distribution and electricity usage. Also, these conceptual domains include embedded intelligence (ICT) in its system actors. The Markets and Energy Services conceptual domains are defined by roles and (system) actors and their activities in trade of electricity products and services (markets), and the participation in the processes of trade and system operations representing grid users (energy services). 15

61 Flexibility Market Markets Grid Capacity Market Energy Market facilitates and coordinates trade in Operations System Operations Metering Operations Grid Operations Transmission Grids facilitates and coordinates trade by Smart Grid Connection Point trade via Energy Services Energy Trade Flexibility Trade / Balancing Grid Capacity Trade Responsibilities provides energy services to Distribution Grids... Grid Users Production, storage and consumption Bulk Generation C&I Loads Legend: Conceptual Domain Subdomain transports power from and to DER Storage Domestic Loads Electric Vehicles System Actor Figure 10: European Conceptual Model for the Smart Grid 422 Operations The Operations conceptual domain is defined by roles and actors related to the stable and safe operations of the power system; the domain ensures that the usage of the grid is within its constraints and facilitates the activities in the market. Grid Operations, System Operations and Metering Operations are identified as subdomains in the Operations conceptual domain. System actors in this domain include grid assets such as transformers, switchgear, etc. in Transmission and Distribution Grids, metering systems and control center systems. Grid Users The Grid Users conceptual domain is defined by roles and actors involved in the generation, usage and possibly storage of electricity; from bulk generation and commercial and industrial loads down to distributed energy resources, domestic loads, etc. The roles and actors in this domain use the grid to transmit and distribute power from generation to the loads. Apart from roles related to the generation, load and storage assets, the Grid Users conceptual domain includes system actors such as (customer) energy management and process control systems. Energy Services The Energy Services conceptual domain is defined by roles and actors involved in providing energy services to the Grid Users conceptual domain. These services include trading in the electricity generated, used or stored by the Grid Users conceptual domain, and ensuring that the activities in the Grid Users conceptual domain are coordinated in e.g. the system balancing mechanisms and Customer Information Systems (CIS). 16

62 Through the Energy Services conceptual domain the Grid Users conceptual domain is connected to activities such as trade and system balancing. From the Grid Users conceptual domain, flexibility in power supply and demand is provided. This flexibility is used for system balancing (through e.g. ancillary services, demand response, etc.) and trading on the market. Also roles are included which are related to trade in grid capacity (as currently is traded on the transmission level). Example (system) actors in this domain include systems for customer relationship management, and billing, trading systems, etc. I.e. the roles and actors from the Energy Services conceptual domain facilitate participation in the electricity system, by representing the Grid Users conceptual domain in operations (e.g. balance responsibility) and markets (trading). Markets The Market conceptual domain is defined by roles and actors that support the trade in electricity (e.g. on day-ahead power exchanges) and other electricity products (e.g. grid capacity, ancillary services). Sub domains which are identified in this domain are: Energy Market, Grid Capacity Market, and Flexibility Market. Activities in the Market conceptual domain are coordinated by the Operations conceptual domain to ensure the stable and safe operation of the power system. Example (system) actors in this domain are trading platforms. 6.4 Alignment This paragraph identifies and describes the required alignment with other relevant initiatives/ activities that are required for building a smart grid based on standards and common reference architectures Alignment with the EU flexibility concept In the energy transition, Europe is focusing on managing flexibility of demand and supply. This concept of flexibility is elaborated in the M/490 SG-CG/SP, resulting in several related use cases. These use cases on providing flexibility concern control/management of flexible demand & supply. Flexibility in demand and supply is provided by smart customers'. In the conceptual model as described in paragraph 6.3 this is reflected by the Grid Users domain, which provides flexibility. Parties related to grid/power system management and electricity markets may use this flexibility. The 'Flexibility Operator' (aggregation service provider) performs the operation of this flexibility. In [SG-CG/L] this use case is analyzed in the context of the European Harmonized Electricity Market Role Model (HEM- RM) which underpins the European conceptual model for Smart Grids. The Flexibility Operator relates to one of various roles in the Energy Services domain. Depending on the type of interaction with the smart customers in the use cases of SG-CG/SP, the Flexibility Operator acts in the Resource Provider, Balance Responsible Party, Balance Supplier or Grid Access Provider role from [HEM-RM 2011]. In the flexibility market, flexibility in demand and supply (interchangeable) will be traded, by services providers with balance responsibilities that have access to this (wholesale) market Alignment with NIST, SGIP, SGAC Since market models in EU and US differ, it is therefore important to derive standards that are, as much as possible, market model independent. Also the Harmonized Electricity Market Role Model as defined by ENTSO-E, ebix and EFET is currently not used in the US. Alignment therefore is created and maintained on the basis of common actor list and interactions between actors, driven from use case analysis. From this common International standards can be derived and interoperability is achieved. Therefore even if the market models and the conceptual model differ (grouping of roles and actors), the same standards may be applicable (although priorities may differ). The alignment of actor lists and interactions between actors is currently ongoing work extended into

63 Alignment with Harmonized Electricity Market Role Model The Harmonized Electricity Market Role model has been picked up for use within the SC-CG, leading to a consistent approach being taken for all future modelling exercises. As the model is already in use within ENTSO-E, this will also facilitate further cooperation/ information exchange between TSO s and DSO s, as this will be necessary for implementing smart grids which enable the energy transition (e.g. implementation of EU network codes). From discussions within the SG-CG working groups, as well in market model discussions, some new roles in this model may become necessary. Therefore r working arrangements with ENTSO-E, ebix and EFET are required in this area, in order to establish adequate version control of the Harmonized Electricity Market Role model Alignment with EU market model developments (EG3) In the EU standardization activities, the Harmonized Electricity Market Role Model (HEM-RM) is promoted as the basis for mapping responsibilities of market parties to the harmonized roles. This means that the interaction between actors, as defined by WGSP and translated to interaction between roles, can define the interaction between market parties. The Smart Grid Task Force (EG3) made recommendations to the EU commission that in the market model discussions, whatever the outcome will be, the roles and responsibilities of market parties related to the market models will be mapped onto the HEM-RM roles. In this way interaction between actors and roles can be translated to interaction between market parties. In this way it becomes clear which standards on interfaces and business services are required, and is alignment between market model development and M490 standards. 6.5 Conclusions As a conclusion from the above: The conceptual model is robust and well defined, based on roles and actors. It accommodates the flexibility concept. It bridges the 2 approaches/cultures arising from power system management and IT technology; it forms a foundation for cooperation. It accommodates alignment between SG-CG standardization activities and market model discussions. It identifies the way alignment should be reached with US (NIST, SGIP, Smart Grid Architecture Council (SGAC) from SGIP (Smart Grid Interoperability Panel, US))

64 The European Harmonized Electricity Market Role Model he text in this section is an excerpt taken from the [HEM-RM 2011] Harmonized Electricity Market Role Model, and included for informational purpose. Please refer to the original document for more detailed information on this role model. A Role Model provides a common definition of the roles and domains employed in the electricity market which enables people to use a common language in the development of information interchange. A party on the market may play several roles, for example a TSO frequently plays both the role of System Operator and the role of Imbalance Settlement Responsible. However two different roles have been defined since these roles are not always played by the same party. Even in a large organization the roles may not be played by the same business unit. Consequently it is necessary to clearly define the roles in order to be in a position to correctly use them as required. It is important to differentiate between the roles that can be found on a given marketplace and the parties that can play such roles. ENTSO-E and the associated organizations have identified a given role whenever it has been found necessary to distinguish it in an information interchange process. The model consequently identifies all the roles that intervene in the exchange of information in the electricity market. These roles define the external interfaces managed by a party for given processes. It also identifies the different domains that are necessary in the electricity market for information interchange. A domain represents a grouping of entities with common characteristics. The objective of decomposing the electricity market into a set of autonomous roles and domains is to enable the construction of business processes where the relevant role participates to satisfy a specific transaction. Business processes should be designed to satisfy the requirements of the roles and not of the parties. 7.1 Relationship between the domains of the conceptual model and the European harmonized electricity market role model Figure 11 shows the relationship between the domains of the conceptual model and the European harmonized electricity market role model. 19

65 Flexibility Market Reserve Allocator Merit Order List Responsible Markets Grid Capacity Market Capacity Coordinator Transmission Capacity Allocator Nomination Validator Energy Market Market Information Aggregator Market Operator facilitates and coordinates trade in trade via Operations System Operations System Operator Control Area Operator Control Block Operator Coordination Center Operator Imbalance Settlement Responsible Reconciliation Responsible Metering Operations Meter Administrator Meter Operator Metering Point Administrator Metered Data Aggregator Metered Data Collector Metered Data Responsible Grid Operations Grid Operator Grid Access Provider facilitates and coordinates trade by Energy Services Energy Trade Balance Supplier Block Energy Trader Reconciliation Accountable Grid Capacity Trade Capacity Trader Interconnection Trade Responsible Flexibility Trade / Balancing Responsibilities Balance Responsible Party Consumption Responsible Party Production Responsible Party Trade Responsible Party Scheduling Coordinator Resource Provider provides energy services to Grid Users Production, storage and consumption 544 Legend: Conceptual Domain Subdomain Role transports power from and to Party Connected to the Grid Consumer Producer Figure 11: Relationship between the domains of the conceptual model and the European harmonized electricity market role model Note that in the figure above, the Billing Agent role is not included in the relationship between domains of the conceptual model and the harmonized electricity market roles due to its generic nature. In [HEM-RM 2011] the Billing Agent role is not associated to any other role. 20

66 Role model role definitions The table below quotes the definitions from [HEM-RM 2011] of all the roles in the European harmonized electricity market role model. Table 1 - Role model definitions Role Description Balance Responsible Party A party that has a contract proving financial security and identifying balance responsibility with the Imbalance Settlement Responsible of the Market Balance Area entitling the party to operate in the market. This is the only role allowing a party to nominate energy on a wholesale level. Additional information: The meaning of the word balance in this context signifies that that the quantity contracted to provide or to consume must be equal to the quantity really provided or consumed. Equivalent to Program responsible party in the Netherlands. Equivalent to Balance group manager in Germany. Equivalent to market agent in Spain. Balance Supplier A party that markets the difference between actual metered energy consumption and the energy bought with firm energy contracts by the Party Connected to the Grid. In addition the Balance Supplier markets any difference with the firm energy contract (of the Party Connected to the Grid) and the metered production. Additional information: There is only one Balance Supplier for each Accounting Point. Billing Agent The party responsible for invoicing a concerned party. Block Energy Trader A party that is selling or buying energy on a firm basis (a fixed volume per market time period). Capacity Coordinator A party, acting on behalf of the System Operators involved, responsible for establishing a coordinated Offered Capacity and/or NTC and/or ATC between several Market Balance Areas. Capacity Trader Consumer A party that has a contract to participate in the Capacity Market to acquire capacity through a Transmission Capacity Allocator. NOTE The capacity may be acquired on behalf of an Interconnection Trade Responsible or for sale on secondary capacity markets. A party that consumes electricity. Additional information: This is a Type of Party Connected to the Grid. 21

67 Role Description Consumption Responsible Party A party who can be brought to rights, legally and financially, for any imbalance between energy nominated and consumed for all associated Accounting Points. Additional information: This is a type of Balance Responsible Party. Control Area Operator Responsible for : Control Block Operator Responsible for : Coordination Center Operator Responsible for : 1. The coordination of exchange programs between its related Market Balance Areas and for the exchanges between its associated Control Areas. 2. The load frequency control for its own area. 3. The coordination of the correction of time deviations. 1. The coordination of exchanges between its associated Control Blocks and the organization of the coordination of exchange programs between its related Control Areas. 2. The load frequency control within its own block and ensuring that its Control Areas respect their obligations in respect to load frequency control and time deviation. 3. The organization of the settlement and/or compensation between its Control Areas. 1. The coordination of exchange programs between its related Control Blocks and for the exchanges between its associated Coordination Center Zones. 2. Ensuring that its Control Blocks respect their obligations in respect to load frequency control. 3. Calculating the time deviation in cooperation with the associated coordination centers. 4. Carrying out the settlement and/or compensation between its Control Blocks and against the other Coordination Center Zones. Grid Access Provider Grid Operator A party responsible for providing access to the grid through an Accounting Point and its use for energy consumption or production to the Party Connected to the Grid. A party that operates one or more grids. Imbalance Settlement Responsible A party that is responsible for settlement of the difference between the contracted quantities and the realised quantities of energy products for the Balance Responsible Parties in a Market Balance Area. NOTE The Imbalance Settlement Responsible has not the responsibility to invoice. The Imbalance Settlement Responsible may delegate the invoicing responsibility to a more generic role such as a Billing Agent. 22

68 Role Description Interconnection Trade Responsible Market Information Aggregator Market Operator Meter Administrator Is a Balance Responsible Party or depends on one. He is recognised by the Nomination Validator for the nomination of already allocated capacity. Additional information: This is a type of Balance Responsible Party. A party that provides market related information that has been compiled from the figures supplied by different actors in the market. This information may also be published or distributed for general use. NOTE The Market Information Aggregator may receive information from any market participant that is relevant for publication or distribution. The unique power exchange of trades for the actual delivery of energy that receives the bids from the Balance Responsible Parties that have a contract to bid. The Market Operator determines the market energy price for the Market Balance Area after applying technical constraints from the System Operator. It may also establish the price for the reconciliation within a Metering Grid Area. A party responsible for keeping a database of meters. Meter Operator Metered Data Collector Metered Data Responsible Metered Data Aggregator Metering Point Administrator Merit Order List (MOL) Responsible Nomination Validator A party responsible for installing, maintaining, testing, certifying and decommissioning physical meters. A party responsible for meter reading and quality control of the reading. A party responsible for the establishment and validation of metered data based on the collected data received from the Metered Data Collector. The party is responsible for the history of metered data for a Metering Point. A party responsible for the establishment and qualification of metered data from the Metered Data Responsible. This data is aggregated according to a defined set of market rules. A party responsible for registering the parties linked to the metering points in a Metering Grid Area. He is also responsible for maintaining the Metering Point technical specifications. He is responsible for creating and terminating metering points. Responsible for the management of the available tenders for all Acquiring System Operators to establish the order of the reserve capacity that can be activated. Has the responsibility of ensuring that all capacity nominated is within the allowed limits and confirming all valid nominations to all involved parties. He informs the Interconnection Trade Responsible of the maximum nominated capacity allowed. Depending on market rules for a given interconnection the corresponding System Operators may appoint one Nomination Validator. 23

69 Role Description Party Connected to the Grid Producer Production Responsible Party Reconciliation Accountable Reconciliation Responsible Reserve Allocator Resource Provider Scheduling Coordinator System Operator A party that contracts for the right to consume or produce electricity at an Accounting Point. A party that produces electricity. Additional information: This is a type of Party Connected to the Grid. A party who can be brought to rights, legally and financially, for any imbalance between energy nominated and produced for all associated Accounting Points. Additional information: This is a type of Balance Responsible Party. A party that is financially accountable for the reconciled volume of energy products for a profiled Accounting Point. A party that is responsible for reconciling, within a Metering Grid Area, the volumes used in the imbalance settlement process for profiled Accounting Points and the actual metered quantities. NOTE The Reconciliation Responsible may delegate the invoicing responsibility to a more generic role such as a Billing Agent. Informs the market of reserve requirements, receives tenders against the requirements and in compliance with the prequalification criteria, determines what tenders meet requirements and assigns tenders. A role that manages a resource object and provides the schedules for it. A party that is responsible for the schedule information and its exchange on behalf of a Balance Responsible Party. For example in the Polish market a Scheduling Coordinator is responsible for information interchange for scheduling and settlement. A party that is responsible for a stable power system operation (including the organization of physical balance) through a transmission grid in a geographical area. The System Operator will also determine and be responsible for cross border capacity and exchanges. If necessary he may reduce allocated capacity to ensure operational stability. Transmission as mentioned above means the transport of electricity on the extra high or high voltage network with a view to its delivery to final customers or to distributors. Operation of transmission includes as well the tasks of system operation concerning its management of energy flows, reliability of the system and availability of all necessary system services. (Definition taken from the ENTSO-E RGCE Operation handbook Glossary). NOTE rules. additional obligations may be imposed through local market 24

70 Role Description Trade Responsible Party Transmission Capacity Allocator A party who can be brought to rights, legally and financially, for any imbalance between energy nominated and consumed for all associated Accounting Points. NOTE A power exchange without any privileged responsibilities acts as a Trade Responsible Party. Additional information: This is a type of Balance Responsible Party. Manages the allocation of transmission capacity for an Allocated Capacity Area. For explicit auctions: The Transmission Capacity Allocator manages, on behalf of the System Operators, the allocation of available transmission capacity for an Allocated capacity Area. He offers the available transmission capacity to the market, allocates the available transmission capacity to individual Capacity Traders and calculates the billing amount of already allocated capacities to the Capacity Traders

71 CEN-CENELEC-ETSI Smart Grid Coordination Group Date: 08/2014 Secretariat: CCMC SG-CG/M490/K_ SGAM usage and examples SGAM User Manual - Applying, testing & refining the Smart Grid Architecture Model (SGAM) Version 2.0 1

72 Foreword Based on the content of the M/490 EU mandate in its phase 1 ( ), the general scope of work on standardization of the Smart Grid might be considered as follows: CEN, CENELEC, and ETSI are requested to develop a framework to enable European Standardization Organizations to perform continuous standard enhancement and development in the field of Smart Grids, while maintaining transverse consistency and promoting continuous innovation. In the light of the discussions held in late 2012 between the EC Reference Group (EG1) and the Smart Grid Coordination Group (SG-CG), the need to iterate the EC Mandate M/490 was considered and agreed by both sides. As a main objective of the mandate phase 2, the SG-CG wishes to implement the methodology developed in phase 1, which set the foundations for managing the continuous engineering and deployment of standards to ensure a real end-to-end interoperability for all generic use cases, explicitly including security. A further refinement of the methodology will be used for the set of consistent standards [SG-CG/G] (under item 3.1 and 3.2 of M/490). The work is based on [SG-CG/C] and [SG-CG/E]. The final report is due on September 1st, 2014, based on version v1.0 provided at the end of 2013 for commenting within the SG-CG. A set of documents addresses this objective: The main report, which is a summary of different tools, elements and methodologies developed by the different working groups of the Smart Grid Coordination Group [SG-CG/F], and additional separate reports detailing specific issues of the working group Methodology and New Applications : The conceptual model and its relation to market models for Smart Grids [SG-CG/J] SGAM User Manual - Applying, testing & refining the Concepts, Elements and Tools for the Smart Grid Architecture Model (SGAM) [SG-CG/K] (this document) An overview of the main concepts of flexibility management [SG-CG/L] For this report: One of the key objectives of phase 2 of the mandate was to demonstrate the application of the SGAM methodology developed in phase 1, validating it by reference to use cases, systems and communications, and testing it by consideration of new use cases. In this way, the SGAM can be seen to represent the foundations for managing the continuous engineering and deployment of standards for all generic use cases, explicitly including security, and helping to ensure real end-to-end interoperability 32 2

73 Table of contents... Page Foreword 2 1. Executive summary References 6 3. Terms and definitions Symbols and abbreviations SGAM: Smart Grids Architecture Model description Introduction SGAM Smart Grid Plane SGAM interoperability layers SGAM framework SGAM levels of abstraction The SGAM and use cases Overview Use case analysis with SGAM Classification of use case design scope Relation of use case design scope to SGAM analysis pattern Relation of use case template with SGAM analysis pattern Relation of security requirements with SGAM layer abstraction Use case checklist Use case repository Mappings using the SGAM Mapping of a system breakdown on SGAM Mapping systems on SGAM - Principles Role mapping Analysis of communication networks using SGAM Description Communication network type breakdown Mapping of communication network type over the SGAM Data modelling with the SGAM Examples showing the use of the SGAM Introduction Example #1: Monitoring of the distribution grid (SG-CG WGSP-0600) Example #1.1: Monitoring inside the distribution grid (Business Use Case) Example #1.2: Monitoring inside the distribution grid (Device/system use case) Example #1.1.1: Detailing the secondary use case Access Control Example #1.1.2: Monitor system interruptions and report to regulator Further example use cases to test the SGAM

74 Overview High level use case WGSP-2135 Inter-CEMS energy trading Primary use case description WGSP Description Implications: WGSP Primary use case description WGSP Description Implications: WGSP Consideration of use cases against the SGAM Implications of above analysis for the SGAM Conclusions of the work to date Appendix A Detailed use case descriptions Appendix B Detailed mapping of WGSP-2136 to SGAM Appendix C Detailed mapping of WGSP-2137 to SGAM List of figures Figure 1: Smart Grid Plane Domains & zones of SGAM Figure 2: SGAM Smart Grid Architecture Model Figure 3: Exemplary categorization of different abstraction levels per SGAM layer (SGAM analysis pattern) Figure 4: Interrelations of elements in an exemplary SGAM model Figure 5: Classification of use case design scope Figure 6: Use case structure (based on SM-CG) Figure 7: Relation of design-scope use case classifications with SGAM analysis pattern Figure 8: Relation of use case templates with SGAM analysis pattern Figure 9: Mapping of fields in the use case templates to SGAM analysis pattern - example Figure 10: High level security requirements mapped on SGAM analysis patterns Figure 11: Detailed security requirements (examples) mapped to SGAM analysis patterns Figure 12 - Exemplary mapping of system usage on the SGAM plane Figure 13: Mapping principles of systems over the SGAM planes Figure 14: IEC Smart Grid mapping tool Figure 15: Mapping of Harmonized Role Model to SGAM Figure 16 - Mapping of communication networks on SGAM Figure 17 - Data modeling and harmonization work mapping Figure 18: Overview of examples presented Figure 19: Mapping of the use case "Monitoring of the distribution grid" Figure 20: Primary use cases for Monitoring the distribution grid Figure 21: Mapping of Monitoring inside the distribution grid on SGAM plane Figure 22: SGAM analysis for Monitoring inside the distribution grid

75 Figure 23: SGAM Analysis of Role-based Access Control Figure 24: SGAM Analysis Monitoring system interruptions and report to regulator Figure 1: Mapping of WGSP-2136 to the SGAM Component Layer Figure 2: Mapping of WGSP-2136 to the SGAM Communication Layer Figure 3: Mapping of WGSP-2136 to the SGAM Information Layer Figure 4: Mapping of WGSP-2137 to the SGAM Component Layer Figure 5: Mapping of WGSP-2137 to the SGAM Communication Layer Figure 6: Mapping of WGSP-2137 to the SGAM Information Layer List of tables Table 1: SGAM domains Table 2: SGAM zones Table 3: SGAM layers Table 4: Types of use cases Table 5: Use case checklist Table 6: Advantages of a use case repository Table 7: Smart Grids - list of the main systems History of document Number Date Content V1.0 18/12/2013 For publication and review by the BTs and TCs. V /06/2014 Integration of comments, basis for F2F meeting of WG Method on 16th of June 2014 V /06/2014 After F2F meeting V /06/2014 Cleaned version for editors V /07/2014 Working version of editors (dj, js, he) V /08/2014 Fine-tuning V1.9.3 V1.9.4 Language check Semi-final version within WG Method V Final for distribution to the SG-CG, commenting phase Main changes in this version 131 5

76 Executive summary This report seeks to present a user manual demonstrating the application of the SGAM methodology developed in phase 1, validating it by reference to use cases, systems and communications, and testing it by considering new use cases in order to identify whether any adaptations are required to the SGAM. The SGAM is also related to systems and communications in order to show its application and value as a methodology. At a general and strategic level, the user manual presented in this report confirms the value of the SGAM and the approach to mapping of use cases against the SGAM, illustrating how use cases can be considered and incorporated within the present SGAM framework. The analysis shows that the SGAM is a powerful, useful and robust tool. It also demonstrates the need for ready access to the use case repository and to the templates and examples of use case descriptions and shows the desirability of ready access to the detailed mapping tools used in presentation of the SGAM. The new high-level use cases selected for consideration deal with the co-ordination of distributed generation and loads at neighborhood level based upon peer-to-peer communication between several Central Energy Management Systems and brokerage within a multi-agent system. The choice of such a leading edge use case was dictated by the desire to test the SGAM to the limits. When the SGAM was applied to the selected new use cases, it was also clear that there is no lack of European standards for these two use cases. The main challenge presented by the possibility of peer-topeer communications as envisaged relates to the market, industry, legal and regulatory framework for such activity. Member States and others wishing to develop the concept at national level are still exploring what arrangements would be required, and it may be necessary to review this preliminary conclusion in the light of such national use cases. 2. References Smart Grid Coordination Group Phase 1 Documents [SG-CG/A] [SG-CG/B] [SG-CG/C] [SG-CG/D] [SG-CG/E] SG-CG/M490/A Framework for Smart Grid Standardization SG-CG/M490/B_ Smart Grid First set of standards SG-CG/M490/C_ Smart Grid Reference Architecture SG-CG/M490/D_ Smart Grid Information Security SG-CG/M490/E_ Smart Grid Use Case Management Process 161 Smart Grid Coordination Group Phase 2 Documents [SG-CG/F] [SG-CG/G] [SG-CG/H] [SG-CG/I] [SG-CG/J] [SG-CG/K] [SG-CG/L] SG-CG/M490/F_ Overview of SG-CG Methodologies SG-CG/M490/G_ Smart Grid Set of standards SG-CG/M490/H_ Smart Grid Information Security SG-CG/M490/I_ Smart Grid Interoperability SG-CG/M490/J_ General Market Model Development SG-CG/M490/K_ SGAM usage and examples (this document) SG-CG/M490/L_ Flexibility Management Other references made in this report [Cockburn] "Writing Effective Use Cases", Alistair Cockburn, Addison-Wesley, 2001 [DPIA template] Data Protection Impact Assessment Template 6

77 [EN 50438] Requirements for micro-generating plants to be connected in parallel with public low-voltage distribution networks [EN ] Requirements for the connection of a generating plant to a distribution system - Part 1: Connection to a LV distribution system and above 16A (Draft) [EN ] Requirements for the connection of a generating plant to a distribution system - Part 2: Connection to a MV distribution system [EnWG 52] Energy Industry Act (Germany) [GWAC:2008] GridWise Interoperability Context-Setting Framework (March 2008), GridWise Architecture Council, online: [IEC ] Telecontrol equipment and systems - Part 5-101: Transmission protocols; Companion standard for basic telecontrol tasks [IEC ] Telecontrol equipment and systems - Part 5-104: Transmission protocols - Network access for IEC using standard transport profiles [IEC 61131] Programmable controllers [IEC 61158] Industrial communication networks - Fieldbus specifications [IEC ] Wind turbines - Part 25-2: Communications for monitoring and control of wind power plants - Information models [IEC ] Wind turbines - Part 25-3: Communications for monitoring and control of wind power plants - Information exchange models [IEC ] Wind turbines - Part 25-4: Communications for monitoring and control of wind power plants - Mapping to communication profile [IEC 61499] Function blocks [IEC 61698] Datasheets [IEC ] Industrial communication networks - Profiles - Part 1: Fieldbus profiles [IEC 61850] Communication networks and systems for power utility automation, [IEC ] Communication networks and systems for power utility automation - Part 7-4: Basic communication structure - Compatible logical node classes and data classes [IEC ] Communication networks and systems for power utility automation - Part 7-410: Basic communication structure - Hydroelectric power plants - Communication for monitoring and control [IEC ] Communication networks and systems for power utility automation - Part 7-420: Basic communication structure - Distributed energy resources logical nodes [IEC ] Communication networks and systems for power utility automation - Part 8-1: Specific communication service mapping (SCSM) - Mappings to MMS (ISO and ISO ) and to ISO/IEC [IEC ] Part 8-2, Web service mapping [IEC ] Part 90, IEC , Object models for schedules [IEC ] Part 90-11, Methodologies for modeling of logics for IEC based applications [IEC ] Part 90-15, Hierarchical DER system model [IEC ] part 90-2, Using IEC for SS-CC communication [IEC ] IEC/TR , Communication networks and systems for power utility automation - Part 90-7: Object models for power converters in distributed energy resources (DER) systems [IEC ] Part 90-9, Object Models for Batteries 7

78 [IEC 61968] Application integration at electric utilities - System interfaces for distribution management [IEC ] Application integration at electric utilities - System interfaces for distribution management - Part 100: Implementation Profiles [IEC 61970] Energy management system application program interface (EMS-API) [IEC 62056] Electricity metering data exchange - The DLMS/COSEM suite [IEC 62264:2003] IEC 62262, Enterprise-control system integration [IEC ] Enterprise system integration - Part 1: Models and terminology [IEC ] IEC/TS , Power systems management and associated information exchange - Data and communications security - Part 3: Communication network and system security - Profiles including TCP/IP [IEC ] IEC/TS , Power systems management and associated information exchange - Data and communication security - Part 4: Profiles including MMS [IEC ] IEC/TS , Power systems management and associated information exchange - Data and communication security - Part 6: Security for IEC [IEC ] IEC/TS , Power systems management and associated information exchange - Data and communications security - Part 8: Role-based access control [IEC/TR 62357:2003] IEC/TR 62357, Power system control and associated communications - Reference architecture for object models, services and protocols, 2003 [IEC/TR 62357:2012] Power systems management and associated information exchange - Part 1: Reference architecture [IEC ] "Use case methodology Part 2: Definition of the templates for use cases, actor list and requirements list", CDV, 2013 [IEC ] Use case methodology - Part 3: Definition of use case template artefacts into an XML serialized format [IEC 62746] System-Schnittstelle zwischen Kunden-Energiemanagementsystemen und Energieversorgungsmanagementsystemen [IEC 8/1356/NP] "Specific application of method & tools for defining Part 1 Generic smart grid requirements", NP, 2014 [IEC PAS 62559:2008] IEC PAS 62559: , IntelliGrid Methodology for Developing Requirements for Energy Systems, 2008 [ISO 27001] ISO/IEC 27001, Information technology - Security techniques - Information security management systems - Requirements [Jonkers 2010] TOGAF 9 and ArchiMate 1.0 White paper, The Open Group 2010 refer also to and [NIST:2009] NIST Framework and Roadmap for Smart Grid Interoperability, Interoperability Standards Release 1.0 (2009), Office of the National Coordinator for Smart Grid Interoperability, National Institute of Standards and Technology, U.S. Department of Commerce. [NIST IR-7628] Guidelines for Smart Grid Cyber Security, [R&TTE] Radio and Telecommunications Terminal Equipment (R&TTE) 2014/53/EU (previous version 1999/5/EC ). [WGSP-0600, 2136, 2137] Use cases, refer to [SG-CG/E] 8

79 Terms and definitions Refer to [SG-CG/F] 4. Symbols and abbreviations AC AES AMI AS BACS BNetzA BRP BT BUC CA CapEx CEM CEMS CEN CENELEC CFC CIM COSEM CRL CSP DER DMS DSO EC EDM EMG EMS ETSI EV FACTS FEP FLIR FTP GUC HRM HES HL-UC HTTP HTTPS HV/MV HVAC HVDC HW/SW IEC IEEE IETF IP LDAP LV MDM MID Altering Current Advanced Encryption Standard Advanced Metering Infrastructure Building Automation and Control System German Federal Network Agency Balance Responsible Party Technical Board Business Use Case Certification Authority Capacity Expansion Customer Energy Management Customer Energy Management System Comité Européen de Normalisation Comité Européen de Normalisation Electrotechnique Continuous Function Chart Common Information Model Companion Specification Energy Metering Certificate revocation list Concentrated Solar Power Distributed Energy Resources Distribution Management System Distribution System Operator European Commission Energy Data Management Energy Management Gateway Energy Management System European Telecommunications Standard Institude electric vehicle Flexible Altering Current Transmission System Features, Events and Processes Forward looking infrared File Transfer Protocol Generic Use Case Harmonized Role Model Hypertext Editing System High Level Use Cases Hypertext Transfer Protocol Hypertext Transfer Protocol Secure High Voltage / Medium Voltage Heating, Ventilation and Air Conditioning High-Voltage Direct Current Hardware/ Software International Electrotechnical Commission Institute of Electrical and Electronics Engineers Internet Engineering Task Force Internet Protocol Lightweight Directory Access Protocol Low Voltage Meter Data Management Measuring instruments directive (EC) 9

80 MMS Manufacturing Messaging Specification MV Medium Voltage NIST National Institute of Standards and Technology NNAP Network Access Point OCSP Online Certificate Status Protocol OMS Outage Management System OpEx Operation Expenses OSI Open Systems Interconnect PAS Publicly Available Specification PKI Public Key Infrastructure PUC Primary Use Case QoS Quality of Service RBAC Role Based Access Conrol RDF Resource Description Framework RTU Remote Terminal Unit PV Photovoltaic SAIDI System Average Interruption Duration Index SAIFI System Average Interruption Frequency Index SCADA Supervisory Control and Data Acquisition SGAM Smart Grid Architecture Model SG-CG Smart Grid Coordination Group SG-CG/Meth SG-CG "Methodology and New Applications" Working Group SG-CG/SP SG-CG "Sustainable Process" Working Group (in phase 1) SGIS Smart Grid Information Security SIP Session Initiation Protocol SOAP Simple Object Access Protocol SP Sustainable Processes SSH Secure Shell TC Technical Committee TCP Transmission Control Protocol TLS Transport Layer Security TOGAF The Open Group Architecture Framework UC Use Case UDP User Datagram Protocol UML Unified Modeling Language VAr Unit of reactive power VPN Virtual Private Network VPP Virtual Power Plant WAMS Wide Area Monitoring protection and control Systems WAN Wide Area Network WG Working Groups XML Extensible Markup Language 5. SGAM: Smart Grids Architecture Model description 5.1 Introduction The Smart Grid Architecture Model (SGAM) [SG-CG/C] is a reference model to analyse and visualise smart grid use cases in a technology-neutral manner. Furthermore, it supports comparison of different approaches to Smart Grid solutions so that differences and commonalities between various paradigms, roadmaps, and viewpoints can be identified. By supporting the principles of universality, localization, consistency, flexibility and interoperability, it also provides a systematic approach to cope with the complexity of smart grids, allowing a representation of the current state of implementations in the electrical grid as well as the evolution to future smart grid scenarios. The SGAM builds on proven approaches from power systems as well as interdisciplinary fields like systems engineering and combines them in a simple but comprehensive model. The work on the SGAM is specifically based on significant existing material such as the NIST Conceptual Model [NIST 2009], the GridWise 10

81 Architecture Council Stack interoperability categories [GWAC 2008], the IntelliGrid Methodology [IEC PAS 62559: ], the European Conceptual Model and architecture standards like TOGAF and Archimate [Jonkers 2010, refer also to and ]. The SGAM can be used in standardization and more widely: to enable a structured analysis of Smart Grid use cases, to visualize and compare different approaches to Smart Grid architectures, paradigms, roadmaps and viewpoints, to provide a guide to analyze potential implementation scenarios, to ensure a common understanding between different stakeholders, to identify standards and standardization gaps, to visualize the scope of Smart Grid projects, and in summary, to cope with the complexity of Smart Grids. It is important to qualify the main purpose of the SGAM as follows: the SGAM does not necessarily improve a proven architecture for a single domain or zone but shows it full strength modeling interactions between domains & zones, the SGAM supports the derivation of system requirements but does not replace a detailed requirements specification, the SGAM does not replace a detailed development specification, the SGAM focuses on the architecture and does not model in detail the power system in the process zone, e.g. effects of harmonics, voltage sags etc., the SGAM does not replace detailed specifications on safety regulations or operational conditions. The SGAM is outlined in detail in the remaining part of this section. 5.2 SGAM Smart Grid Plane Power system management distinguishes between electrical process and information management. These viewpoints can be partitioned into the physical domains of the electrical energy conversion chain and the hierarchical zones for management of the electrical process (refer to [IEC :2012, IEC 62264:2003]). The Smart Grid Plane spans in one dimension the complete electrical energy conversion chain, partitioned into five domains: (Bulk) Generation, Transmission, Distribution, DER and Customer Premises. And in the other dimension the hierarchical levels of power system management, partitioned into six zones: Process, Field, Station, Operation, Enterprise and Market. This smart grid plane enables the representation of the zones in which power system management interactions between domains or inside a single domain take place. 11

82 Information Management Power System Equipment & Energy Conversion Market Enterprise Operation 403 Generation Transmission Distribution Domains DER Customer Premises Process Field Station Zones Figure 1: Smart Grid Plane Domains & zones of SGAM The domains are physically related to the electrical grid ((Bulk-) Generation, Transmission, Distribution, DER, Customer Premises) and they are arranged according to the electrical energy conversion chain. The conceptual domains Operations and Market 1 are part of the information management and represent specific hierarchical zones. The Smart Grid Plane covers the complete electrical energy conversion chain. This includes the domains listed in Table Table 1: SGAM domains Domain Description (Bulk) Generation Transmission Distribution DER Customer Premises Representing generation of electrical energy in bulk quantities typically connected to the transmission system, such as by fossil, nuclear and hydro power plants, off-shore wind farms, large scale solar power plant (i.e. PV, CSP). Representing the infrastructure which transports electricity over long distances. Representing the infrastructure which distributes electricity to customers. Representing distributed electrical resources directly connected to the public distribution grid, applying small-scale power generation and consumption technologies (typically in the range of 3 kw to 10,000 kw). These distributed electrical resources may be directly controlled by a DSO or Balance Responsible Party (BRP). Hosting both end users of electricity and also local producers of electricity. The premises include industrial, commercial and home facilities (e.g. chemical plants, airports, harbors, shopping centers, homes). Also generation in form of e.g. photovoltaic generation, electric vehicles storage, batteries, micro turbines Although the domains DER and Customer Premises can include generation, the domains are separated from each other. The DER domain includes any kind of distributed energy resources or related processes, having 1 Refer to the conceptual model explained in [SG-CG/F] and more detailed in [SG-CG/J] 12

83 as primary business goals the objective of contributing to the electricity grid as production and/or storage and/or any types of ancillary services. The Customer Premises domain on the other hand includes any kind of processes not having the primary business objective of contributing to the electricity grid (but using the grid as one energy source), such as home management processes, or building or industry management processes, or e-mobility systems. The SGAM zones represent the hierarchical levels of power system management [IEC :2012]. These zones reflect a hierarchical model that considers the concept of aggregation and functional separation in power system management. The basic idea of this hierarchical model is laid down in the Purdue Reference Model for computer-integrated manufacturing that was adopted by the IEC standard for enterprise-control system integration [IEC :2003]. This model was also applied to power system management. This is described in IEC Reference architecture for object models services [IEC/TR 62357:2003, IEC/TR :2012]. The concept of aggregation considers multiple aspects in power system management: Data aggregation data from the field zone is usually aggregated or concentrated in the station zone in order to reduce the amount of data to be communicated and processed in the operation zone Spatial aggregation from distinct location to wider area (e.g. HV/MV power system equipment is usually arranged in bays, with several bays forming a substation; multiple DER form a plant station, and DER meters in customer premises are aggregated by concentrators for a neighborhood) In addition to aggregation, the partitioning in zones follows the concept of functional separation. Different functions are assigned to specific zones. The reason for this assignment is typically the specific nature of functions, but also reflects user philosophies. Real-time functions are typically in the field and station zones (protection, phasor-measurement, automation ). Functions that cover an area, multiple substations or plants, or city districts are usually located in the operation zone (e.g. wide area monitoring, generation scheduling, load management, balancing, area power system supervision and control, meter data management ). The SGAM zones are described in Table Zone Description Table 2: SGAM zones Process Field Station Operation Enterprise Including the physical, chemical or spatial transformations of energy (electricity, solar, heat, water, wind ) and the physical equipment directly involved (e.g. generators, transformers, circuit breakers, overhead lines, cables, electrical loads, any kind of sensors and actuators which are part or directly connected to the process, ). Including equipment to protect, control and monitor the process of the power system, e.g. protection relays, bay controller, any kind of intelligent electronic devices which acquire and use process data from the power system. Representing the areal aggregation level for field level, e.g. for data concentration, functional aggregation, substation automation, local SCADA systems, plant supervision Hosting power system control operation in the respective domain, e.g. distribution management systems (DMS), energy management systems (EMS) in generation and transmission systems, microgrid management systems, virtual power plant management systems (aggregating several DER), electric vehicle (EV) fleet charging management systems. Including commercial and organizational processes, services and infrastructures for enterprises (utilities, service providers, energy traders ), e.g. asset management, logistics, work force management, staff training, customer relation management, billing and procurement 13

84 Zone Market Description Reflecting the market operations possible along the energy conversion chain, e.g. energy trading, retail market In general, organizations can have actors in several domains and zones. The areas of the activity of these actors can be shown in the smart grid plane. E.g. for the business area of a transmission utility it is likely that the utility covers all segments of the transmission domain, from process to market, whereas a service provider offering weather forecast information for distribution system and DER operators could be located to the market zone interacting with the operation zone in the distribution and DER domains. 5.3 SGAM interoperability layers For interoperability between systems or components, the SGAM consists of five layers representing business objectives and processes, functions, information exchange and models, communication protocols and components. These five interoperability layers represent an abstract and condensed version of the interoperability categories introduced by the GridWise Architecture Council [GWAC2008]. 450 Layer Description Table 3: SGAM layers Business Function Information Communication Component The business layer represents the business view on the information exchange related to smart grids. SGAM can be used to map regulatory and economic (market) structures (using harmonized roles and responsibilities) and policies, business models and use cases, business portfolios (products & services) of market parties involved. Also business capabilities, use cases and business processes can be represented in this layer. The function layer describes system use cases, functions and services including their relationships from an architectural viewpoint. The functions are represented independent from actors and physical implementations in applications, systems and components. The functions are derived by extracting the use case functionality that is independent from actors. The information layer describes the information that is being used and exchanged between functions, services and components. It contains information objects and the underlying canonical data models. These information objects and canonical data models represent the common semantics for functions and services in order to allow an interoperable information exchange via communication means. The emphasis of the communication layer is to describe protocols and mechanisms for the interoperable exchange of information between components in the context of the underlying use case, function or service and related information objects or data models. The emphasis of the component layer is the physical distribution of all participating components in the smart grid context. This includes system & device actors, power system equipment (typically located at process and field level), protection and telecontrol devices, network infrastructure (wired / wireless communication connections, routers, switches, servers) and any kind of computers Each layer covers the whole smart grid plane, which is spanned by electrical domains and information management zones. 14

85 SGAM framework The SGAM framework is established by merging the concept of the interoperability layers with the previous introduced smart grid plane. This merging results in a model that spans three dimensions: SGAM domains Zones Interoperability layers The complete three-dimensional representation of SGAM is depicted in Figure Figure 2: SGAM Smart Grid Architecture Model Using the SGAM, Smart Grid use cases can be visualized and detailed and mapped to the layers of the model to test if a use case is supported by existing standards or to identify gaps in standardization. A use case analysis with the SGAM is based on the use case description. The different fields in the use case template provide the information for the analysis, e.g. the field Domain(s)/Zone(s) specifies directly how the use case maps onto the Smart Grid Plane. Furthermore, the actor list in the use case description provides - depending on the type of the actor - information on the roles involved to model the business layer in SGAM or information on the systems and devices involved to model the component layer. Use case descriptions vary in their level of abstraction as well as in design scope as described in detail in chapter Thus, analysis with SGAM also varies as described in the following section. 5.5 SGAM levels of abstraction This section provides an overview for each interoperability layer in the SGAM on the level of abstraction on which an SGAM analysis can be applied. These SGAM analysis patterns are intended to provide guidance on how to model with the SGAM on a level of abstraction chosen, starting from a concept up to the detailed level required for implementation. For each layer Figure 3 depicts some steps (examples) of successive model refinements which may assist in defining interoperability requirements. 15

86 The interpretation of the levels of abstraction is in general different for each layer and in Figure 3 there is not necessarily any relationship between the descriptions in different layers for the same level of abstraction Figure 3: Exemplary categorization of different abstraction levels per SGAM layer (SGAM analysis pattern) 6 The SGAM and use cases 6.1 Overview The SGAM analysis patterns can also support the writing of use case descriptions, by providing sufficient information needed for a SGAM analysis at the chosen level of detail. For example, on the business layer we can start with a use case concept (e.g. the concept of demand and generation flexibility for technical and commercial operations as described in [SG-CG/E]). This concept can be augmented by identifying the roles and their responsibilities on the business layer (e.g. customer, supplier and aggregator). Based on a high level use case the system-of-systems involved (e.g. distribution system, marketplaces and smart buildings) can also be defined on the component layer. Additionally, abstract classifications on the information layer (e.g. price signals, incentives, control signals and measurements) and communication layer (e.g. real-time or non-real-time requirements) are possible. However, to derive the next level of detail we need further information from the use case description. For example, for the business layer the use case should also outline the business models including policies and regulations for the roles involved. Subsequently, the business services and processes can be specified, based on a step-by-step analysis. The other layers from function to component provide more a technical view of system use cases. The use case concept can be detailed on the function layer by defining function groups, functions and their internal behavior e.g. as flow charts. Similarly, on the information and communication layer we can derive further details by identifying the information & communication flows between the function groups and provide references to standards that could be applied (see [SG-CG/B] for examples). This gives a first indication which standards are relevant for the particular use case and which experts need to be involved in the detailed analysis of the use case. In the next step the experts define the information objects exchanged on the information layer and the communication services required on the communication layer. By identifying 16

87 these details for the use case under discussion we derive profiles for the information and communication layers for the particular use case. Subsequently, by harmonizing the results from several use case descriptions we can derive more complete profile descriptions. This detailing is followed by the definition of the information syntax and the mapping on protocols for the information and communication layers respectively. On the component layer we can identify the systems involved and in the following step of detailing the devices also. The SGAM framework and the analysis pattern presented are not only valid for standardization activities but can be used in general as a methodology for Smart Grid projects. Hence, although it is beyond the scope of the SG-CG we indicate in Figure 3 that the detailed level of abstraction can also include products on the component layer and a business case on the business layer for the stakeholders concerned. Figure 4 shows an example some relations between different elements in an free style model that is classified according to SGAM layers for an abstraction on device level. class SGAM Concepts 0.2 Business Layer Role 1 Role 2 Busi ness Process X Service1 Service2 Service3 Function Layer Function 1A Function 1B Interface 1 Function 2 Interface 2 Function 3 Information Layer Information Object 1 Information Object 2 Information Object 3 Communication Layer Communication Service 1 Communication Service 2 Component Layer Device 1 Device Figure 4: Interrelations of elements in an exemplary SGAM model 17

88 Use case analysis with SGAM Classification of use case design scope Use cases are a well-proven approach in systems engineering and used worldwide to derive a common understanding for Smart Grids. Despite (or because of) the large set of use cases available in different databases, the level of granularity differs widely in these use case descriptions. We use a simple classification for the design and scope of use cases to map the different types of use cases to the SGAM analysis pattern introduced in the previous section. We differentiate between use case concepts (or highlevel use cases), business use cases and device/system use cases. Use case concepts describe a general idea by defining the roles involved and sketching their responsibilities but not the underlying business models or processes. The target audience is system engineers, business developers, regulators and key experts in standardization having a very good overview on the whole Smart Grid landscape. Conceptual business requirements are refined in one or several business use cases written by business architects or regulators which describe them within an enterprise scope (i.e. the operation of businesses) and the interaction between different roles, e.g. to contract or negotiate services. In the next step of refinement the technical view is added by specifying one or multiple device/system use cases to realize the goal of a business use case. For these technical use cases we can define the device/system boundaries. Requirements for HW/SW engineers describe the interactions between the system(s) and external actors (i.e. other systems/devices). The following figure as well as following table clarifies the use case classification for the design scope in further detail. We would note that this classification of the use case design scope is complementary to the level of abstraction of the use case description outlined in [SG-CG/H]. Each use case type can be described additionally with different levels of abstraction. As outlined in [Cockburn], the key difference between the classification of design scope and the level of abstraction for use case descriptions is that the design scope defines the boundary box of the use case, i.e. what is in?, what is out? for the system under design. the level of abstraction refers to the details in describing the objective of the use case Figure 5: Classification of use case design scope 18

89 Because use case descriptions support various tasks, the granularity, type and content of the use case description vary widely. In general a use case describes the functions of a system and related information exchange, mainly in a technology-neutral way (depending on the level of detail). It identifies participating actors that for instance can be other systems or human actors which are linked to the particular use case. In the following, various use case types are classified highlighting different views and task of the respective use cases, e.g.: Level of detail (see Figure 6 below): for brainstorming / collection (cluster, high level use cases, conceptual description), engineering or testing; View of the use case: Business (business use case) or technical (system use case) 2 ; Users of the use case: Project (Individual use cases), technology group (specialized use cases), standardization (generic use cases) Geographical view: national, regional or international use cases Figure 6: Use case structure (based on SM-CG) Therefore the following list describes those different characteristics of use cases : 562 Types of use cases Conceptual description / Use case concept / User stories Table 4: Types of use cases Description A conceptual description describes a general idea or concept, provides an overview or background for a cluster of use cases and does not use necessarily the use case template. The conceptual description reflects the iterative work of describing different use cases, analyzing them, detailing them further and linking them to architectures, actors and systems. It may defines the roles involved and sketches their responsibilities (possibly with alternatives, incl. their security impact for the use case) but not the underlying business model or process. EXAMPLE: flexibility concept. 2 or even political / legislative use cases might be possible. 19

90 Types of use cases Use Case cluster High level use case Business use case 3 System use case 4 (Technical or device use case) Primary use case Scenarios (in the template) Steps (in the template) Secondary use case Specialized use case Generic use case (GUC) Description A use case cluster represents a group of use cases. EXAMPLE: Smart Charging A high-level use case (HL-UC) describes the general idea of a function together with generic actors. The HL-UC can be realized in different ways, so the HL-UC cannot be mapped to a specific system or architecture. Example: Fault Location, Isolation, Restoration (FLIR) in general. Business Use Cases describe business processes that the actors of a given system must and may execute. These processes are derived from roles which have been previously identified and defined (-> Business Layer of SGAM) [based on IEC 8/1356/NP]. There is no technical view. System Use Cases describe the Smart Grid functions required to enable / facilitate the business processes described in Business Use Cases. Their purpose is to detail the execution of those processes from an information system perspective (-> Function Layer of SGAM) [based on IEC 8/1356/NP]. Here device or system boundaries can be defined and interactions between the system(s) and external actors (i.e. other systems/devices) to fulfil a goal for the actor(s) can be described. A primary use case (PUC) is a use case implemented in a specific system characterized by a defined boundary (i.e. it can be mapped on a defined architecture). This means that a higher-level abstract use case might be broken down into one or more implementation possibilities, called specializations. These use cases can be mapped to a proposed architecture (SGAM). EXAMPLE: Different FLIR use cases implementing the basic functionality within a central or decentralized architecture or which are related to different network topologies. Scenarios define different routes within one UC according to different trigger signals (within the template). EXAMPLE: Scenarios describing normal, alternative or error sequences Steps are used to describe activities within a scenario in a sequential order (refer to the step-by-step analysis of the use case template). A secondary use case is used to describe core functionalities that are used by multiple PUCs. A specialized use case is a UC, which is already describing specific technologies like a specific protocol (e.g. FLIR with a protocol defined by IEC or flexibility use cases within a house using one or more home automation standards). Use cases will be called generic when their description is broadly accepted in standardization and not project or technology specific. They should address the various possible approaches and answer the request for use case harmonization, which means that duplicate use cases should be avoided. The GUC can be used for further work inside standardization (e.g. mapping to architecture, development of standards or test use cases). GUC might be described on a high or more detailed level implying different 3 Depending on the level of detail and purpose of the use case this might be a conceptual description, a user story, a high level use case 4 Depending on the level of detail and purpose of the use case this might be a generic, specialized, individual, primary, or secondary use case 20

91 563 Types of use cases Individual use case Test use cases Description systems design scope. In real projects, a company might subsequently combine generic use cases, developing them further and including their own individual, company-specific use cases that belong to its knowledge base and its business cases. Test use cases are developed based on the use cases in order to test interoperability, functions and processes Relation of use case design scope to SGAM analysis pattern We introduced in the previous sections the SGAM analysis pattern and a classification for the use case design scope. Figure 7 shows how most of the concepts can roughly relate to each other Figure 7: Relation of design-scope use case classifications with SGAM analysis pattern Use Case Concepts (or High-level Use Cases) describe the conceptual model of a use case. This may include information on all SGAM layers at a high level of abstraction. Business Use Cases and Device/System Use Cases can be used to detail the use case concept. Business use cases describe the SGAM business layer. Based on the roles involved and their responsibilities, relevant policies and regulations as well as business models should be identified. In a further step of detailing, the business service(s) and process(es) should be described. The technical view of the use case is provided in the system use case description, including details on the function, information, communication and component layer of SGAM on different levels of abstraction. Details on products and business cases are excluded from the use case description as depicted in the figure Relation of use case template with SGAM analysis pattern Use case templates provide a uniform way to document use case descriptions. Based on IEC PAS Intelligrid Methodology for developing Requirements for Energy Systems, the SG-CG/SP ("Sustainable Processes" WG) provided a use case template in the three versions short, general and detailed as examples. The short 21

92 version included only a small number of fields and provides simple way to document use cases. The general version included e.g. additional fields on the relation to other use cases, the viewpoint and scope & objective. Later, the detailed version included a step-by-step analysis by which exchanged information and requirements can be identified. The use case template is also explained in detail [IEC ], which also allows the definition of further versions of the template on individual demand. However, it is recommended that the definitions for the use of the fields in the template are followed. These use case templates with different level of detail fit to the SGAM analysis pattern as depicted in Figure 8. Selected fields of the templates are listed in the figure. A use case description should provide enough information in these fields to describe the relevant level of abstraction for the SGAM layer(s). Additional fields for the management of the use case apply to all three templates and are added at the bottom of the figure Figure 8: Relation of use case templates with SGAM analysis pattern The short template can be used to document use case concepts. Most of the information is provided in the narrative of the use case supported by diagrams. Actors and roles can be extracted from the narrative. Furthermore, the use case can be mapped on the SGAM Smart Grid Plane to identify affected domains and zones. The general and detailed templates can be used for both, business as well as system use cases. However, the two viewpoints should not be mixed in a single use case description; two separate documents should be created and linked to each other and the related use case concept. The business or technical orientation of the use case description can be defined in the field viewpoint. For a business use case, actors are specified as roles as opposed to technical use case where actors are devices and/or systems. The fields on objective and scope should provide further information on system boundaries that, projected on all layers, may provide a reference for definition of interfaces and standards supporting the use case. 22

93 The detailed template includes a step-by-step analysis that is necessary to derive a detailed understanding of the use case. For the business layer the step-by-step analysis can be used to define the related business process(es) for the business use cases. For system use cases the step-by-step analysis provides details of the information exchanged, requirements at the communication layer, and non-functional requirements. Business Function Roles & Responsibilities, e.g. energy supplier View point Actors (roles) Policies/ Regulations/ Business Models, e.g. law on energy industry (business Use Case Concept, or Function Groups e.g. Monitoring, Flexibility e.g. SCADA technical) Step-by-step Business Services & Processes, analysis e.g. change of supplier (business) Obje ctive Narrative of Use Case (short/complete) Functions, e.g. Data acquisition The field in the use case description should specify SGAM Business layers Case, on different level of abstraction. e.g. return-on-investment Internal behavior/ control flow, e.g. flow charts, state machine Information Communication Component Narrative of high-level use case Abstract classification, e.g. measurement, price signal Domains/ zones Abstract classification, e.g. real-time / non real-time System-of-systems, e.g. Distribution System Information flows with reference to standards, e.g. IEC , CIM Scope Communication flows with reference to standards, e.g. IEC Systems, e.g. Substation Automation System Step-bystep analysis (technical) Information Objects, e.g. MMXU (Logical Nodes) Communication Services, e.g. Reporting, Control (ACSI) Devices, Actors (system/devices) e.g. protection relay Information Exchanged Information syntax, e.g. XML Schema, RDF Requirements Protocol Mapping, e.g. MMS, Web Services Products, e.g. SIPROTEC Concept High Level of Abstraction Low Implementation Figure 9: Mapping of fields in the use case templates to SGAM analysis pattern 5 - example The mapping of some fields from the use case templates to SGAM analysis pattern is shown in Figure 9 depicting how information contained in use case descriptions can help to define interoperability requirements at each interoperability layer. Only those fields from the templates which provide information for the SGAM analysis are shown. These fields should specify SGAM layers on different levels of abstraction. 6.3 Relation of security requirements with SGAM layer abstraction As depicted in the figure below, high level security requirements based on use cases have to be defined. These high level security requirements are based on a determination of the risk level and lead to the required security level. This approach is part of the SGIS concept [SG-CG/D]. 5 Please, note that this actor definition refers to the use case template [IEC ] and is slightly different from the actor / role definition used with the meta-model described in [SG-CG/J]. 23

94 Figure 10: High level security requirements mapped on SGAM analysis patterns The next figure provides a more detailed overview about the steps necessary to determine the security requirements. Going from the upper left to the lower right the security requirements become more detailed. Starting from functional requirements describing the requested security functionality required to protect the assets (integrity, authentication, confidentiality), these requirements get more detailed in terms of selected mechanisms to address the functional requirements by specific security measures. These measures relate to technical implementation security requirements (e.g. AES 128 bit for encryption, application of attribute certificates for role-based access control) but also to procedural security requirements necessary to operate the technical security measures (e.g. key updates, association of roles and rights for role-based access control). 24

95 Figure 11: Detailed security requirements (examples) mapped to SGAM analysis patterns 6.4 Use case checklist The following checklist should assist the authors of use cases in writing complete and good use case descriptions 6. Subsequently, the information in the different fields of the use case description is used to specify the details for the SGAM layers. Table 5: Use case checklist Use case field Description (acc. IEC ) Name of use case Is it an active-verb goal phrase, i.e. it refers to the activity of the Use Case itself using Verb + description? EXAMPLE: Measure power Domain(s) & zone(s) Does the description define domains & zones of SGAM? Scope Does the use case description define the system boundary? Narrative of use case (short/complete) Is it clear what functions are needed to specify SGAM function layer? Which legal requirements have to be considered? 6 refer also to [Cockburn] 25

96 Use case field Description (acc. IEC ) Actors Is the list of actors consistent in type and with viewpoint, i.e. on the same SGAM layer (e.g. roles for business use cases or system/devices for component layer)? Are the actors defined in relationship to the (business) roles / responsibilities they are aimed to support?? Ensure that for business use cases the roles are based on the roles in the Conceptual Model or the Harmonized Role Model to ensure EU-wide applicability. For standardization purposes it is recommended that actor or role definitions do not force a combination of multiple in a single party. Grouped actors or roles should be used only for simplification, when commonly used (e.g. DSO). Relation to other use cases Does the use case relate to higher or lower level use cases, e.g. use case concept or business use case? Is there a consistent relationship of refinement (specialization) between roles and actors? Viewpoint Is the description of the use case on the same SGAM layer (e.g. business or technical)? Step by step analysis (for detailed use case description) Information exchanged Is it clear what information is being passed in each step? Column specifies SGAM information layer. Is there a relation with a standard data model? Requirements Does the step-by-step analysis specify the applicable requirements (configuration, QoS, data management, privacy, security, etc.)? For example, Quality of Service (QoS) requirements for the SGAM communication layer. Threat & risk analysis The selection of security and privacy requirements should be based on a threat and risk analysis. The SGIS concept (security) and EG2 DPIA template (privacy) offer a mechanism to perform this selection. Resulting requirements can be linked in the template to information objects or to the step-by-step analysis Use case repository Although it is possible to describe use cases in a word processing format, establishing a use case repository will provide many advantages for a standardization organization when the methodology is introduced on a broader scale. 26

97 642 Table 6: Advantages of a use case repository Advantages Description Administration Considering the different iterative working steps from draft via discussion to a validated use case, there is a need for a tool support: e.g. the tracking of changes or contributing authors, discussions, etc. The latest use cases and related data should always be available in the database. Collaborative platform Search functions / Transparency Harmonization of use cases Voting / Validation of use cases Different templates Analysis of use cases Link to other use cases Further engineering / export functions As previously noted the use cases should enable an exchange of basic ideas across the different sectors and stakeholders of the industry, different TC s or even different organization. Such an exchange needs a collaborative platform, which increases the transparency of the design and the common development of new systems. It will be easier to find an appropriate use case. Duplication of use cases can be minimized by using a repository for the whole community. Therefore transparency is increased, when use cases, related discussions, and the development process are visible for the community. The repository provides pre-defined content for some fields like actors or domain / zones. This will be useful for the use case author, but also aligns different use cases with each other as they use the same terms. Validated use cases are fundamental, enabling the evolution of new standards in the different TCs. The repository supports the process of validation. The complete template is complex and designed for a detailed analysis. Especially at the start, a use case repository provides easier short templates. Without rewriting these short templates, they can be extended in a repository. Further fields and cells can be added according to the needs of the users and the phase of the design process. Some fields of the use case template and some features of the use case repository support the analysis of use cases: filter functions, e.g. according to a specific actor, specific reports out of the database, gathering information from various use cases, e.g. the information exchanged between different actors in order to defined the message load or common requirements. Additionally use cases can be sorted according to the classification fields: prioritisation, maturity, etc. In a repository it is easier to link the use case to other use cases and to administrate / report these links (use case networks, clusters, interrelations). The repository provides export functionalities, including a link to UML for further detailed engineering, reusing the developed use case (IEC ). 27

98 Status of the use case The repository should support a work flow and the current status of a use case indicating e.g. if the use case is validated, under discussion or in editing mode IEC introduces on short term a use case repository for the international standardization community. A prototype of a use cases repository had been developed in phase 1 of the M/490. This repository still is available under: Link: (please use Browsers Chrome or Firefox) User with Read-only rights Name: LookatMe Password: LookatMe It contains the Generic Use Cases which had been evaluated and developed by WGSP in phase 1 [SG- CG/E]. 7 Mappings using the SGAM 7.1 Mapping of a system breakdown on SGAM 7 In the scope of this document, a system is a typical industry arrangement of components and systems, based on a single architecture, serving a specific set of use cases. In the following there are the systems which are been considered in [SG-CG/G] for the Smart Grid Set of Standards, and which de facto form the set of the Smart Grid systems and can be mapped to the SGAM plane (Figure 12). The guidelines mentioned in [SG-CG/G] indicate the purpose and limits associated to system definition and completeness of the considered list. This list of systems (Table 7) is actually made of three types of systems: Domain specific systems (Generation, Transmission, Distribution, DER, Customer Premises) Function specific systems (usually crossing domain borders) (Marketplace systems, Demand flexibility systems, Smart metering systems, Weather observation and forecast systems) Other systems usually focusing on administration features (asset management, clock reference, communication management, device management, ) 668 Domain or function Table 7: Smart Grids - list of the main systems Systems Brief introduction/comments Generation Generation management system (Bulk) Generation management system (Large Renewable) Generation management system is the control centre for Bulk or Large renewable generation plant. Even if there may be some specificities for each of these, the rest of the document will mostly merge both into one system type. 7 Provided by WG SS 28

99 Domain or function Systems Smart Grid Coordination Group Brief introduction/comments Transmission Substation automation system Refer to Distribution Distribution Black-out prevention - WAMS Wide Area Monitoring Protection and control systems EMS SCADA system Flexible AC Transmission Systems FACTS Advanced DMS SCADA system (including Geographical Information system GIS and outage management system - OMS) Distribution automation systems - Feeder automation/smart reclosers system Substation automation system Real-time blackout prevention systems, usually based on measurement coming from phase measurement units The Energy Management System (EMS) is the control centre for the Transmission Grid. Today customers require an open architecture to enable easy IT integration and better support to avoid blackouts (e.g. visualization of the grid status, dynamic network stability analysis). Power Electronics is among the actuators in the power grid. Systems like HVDC and FACTS enable actual control of the power flow and can help to increase transport capacity without increasing short circuit power. The Distribution Management System (DMS) is the counterpart to the EMS and is therefore the control center for the distribution grid. In countries where outages are a frequent problem, the Outage Management System (OMS) is an important component of the DMS. Other important components are fault location and interfaces to Geographic Information Systems. Whereas automated operation and remote control is state of the art for the transmission grid, mass deployment of Distribution Automation is only recently becoming more frequent, leading to Smart Gears. Countries like the United States of America, where overhead lines are frequently used, benefit most. Advanced distribution automation concepts promote automatic self-configuration features, reducing outage times to a minimum ( self-healing grids ). Another step further is the use of distributed energy resources to create self-contained cells ( MicroGrids ). MicroGrids can help to assure energy supply in distribution grids even when the transmission grid has a blackout. Substation Automation & Protection is the backbone for a secure grid operation. During recent years serial bus communication has been introduced (IEC 61850). Security is based on protection schemes. 29

100 DER Domain or function Customer premises Transverse FACTS system Systems DER management system Electrical storage systems AMI system Metering-related back office system Demand-Response / Load management system Smart homes and buildings systems Industrial Automation systems E-mobility systems Micro-grid systems Market places (including trading Smart Grid Coordination Group Brief introduction/comments Refer to Transmission The Advanced Metering Infrastructure (AMI) system allows remote meter configuration, dynamic tariffs, power quality monitoring and load control. Advanced systems may integrate the metering infrastructure with distribution automation. (Smart Meter is a generic term for electronic meters with a communication link.) Smart Homes are houses which are equipped with a home automation system that automates and enhances living. A home automation system interconnects a variety of control products for lighting, shutters and blinds, HVAC, appliances and other devices with a common network infrastructure to enable energy-efficient, economical and reliable operation of homes with increased comfort. Building Automation and Control System (BACS) is the brain of the building. BACS includes the instrumentation, control and management technology for all building structures, plant, outdoor facilities and other equipment capable of automation. BACS consists of all the products and services required for automatic control including logic functions, controls, monitoring, optimization, operation, manual intervention and management, for the energy-efficient, economical and reliable operation of buildings Brain of the industrial plant in charge of monitoring and controlling the industrial process, and associated facilities. 30

101 Domain or function Systems Smart Grid Coordination Group Brief introduction/comments systems) Weather observation and forecast system Asset management and condition monitoring system Asset Management Systems and Condition Monitoring devices are promising tools to optimize the OpEx and CapEx spending of utilities. Condition-based maintenance, for example, allows the reduction of maintenance costs without sacrificing reliability. Furthermore they may also be used to utilize additional transport capacity due to better cooling of primary equipment, e.g. transmission lines on winter days. Administration Communication network management system Clock reference system Authentication authorization accounting system NOTE So called Administration systems can/may be implemented superseding previous operational systems. There in most of the cases re-use communication capabilities already present in the operational system. 31

102 672 Market place and Trading system Asset & Maintenance management system Weather Forecast & Observation system Bulk Generation Management system Large Renewable Generation Management system Substation automation system WAMPAC EMS SCADA system FACTS Micro-grids Generation Transmission Distribution DER Substation automation system Distribution automation system ADMS SCADA & GIS system FACTS DER management system Storage management system AMI system Metering-related Back Office system Demand/Response Load management system Smart Home & Building management system Customer premises Industry Automation system Market Enterprise Operation Station Field Process 673 Figure 12 - Exemplary mapping of system usage on the SGAM plane Mapping systems on SGAM - Principles 676 For a structured system description, each system may be mapped to the SGAM model described above. 32

103 Figure 13: Mapping principles of systems over the SGAM planes As depicted in the drawing above (Figure 13), mapping a system onto the SGAM will consist of: the definition of the set of Generic use cases the considered system can/may support. the drawing of the typical architecture and components used by this system (component layer). a list of standards to be considered for interfacing each components within this system as shown in [SG- CG/G]. The basic idea can be found also in the following example shown in Figure 14 using the SGAM plan for a more detailed breakdown to a component and device level. This mapping chart is combined with interactive lists of use cases (yellow dots) and standards (mouse-over). Similar to [SG-CG/G] the mapping tool aims to provide an overview and to guide standard users and the standard community in selecting appropriate standards. 33

104 Figure 14: IEC Smart Grid mapping tool (Source:

105 Role mapping Furthermore, for the business layer, we can map the Harmonized Role Model (HRM) to SGAM as depicted partly in Figure Figure 15: Mapping of Harmonized Role Model to SGAM 7.3 Analysis of communication networks using SGAM Description A secure, reliable and economic power supply is closely linked to a fast, efficient and dependable telecommunication services communications. A telecommunication service is any service provided by a telecommunication network through a communications system. A communications system is a collection of individual communications networks and communication end points capable of interconnection and interoperation to form an integrated whole. 8 Provided by WG SS 35

106 The planning and implementation of communications systems, needed to support the expected services mentioned above, requires the same care as the installation of the power supply systems themselves. One way to categorize the different types of telecommunications networks is by means of transmission: Wireless: communication through the air Wire line: communication through cable dedicated to telecommunications services Powerline: communication through cable designed for electric power transmission, but used for carrying data too. Wireless communications may have to comply with local or regional regulations (such as the European Directive for Radio and Telecommunications Terminal Equipment (R&TTE) 2014/53/EU (previous version 1999/5/EC ). For Smart Grid communication architecture/technology, products based on specifications from (industry) consortia (e.g. IETF, IEEE, W3C) have been deployed widely, notably in the area of IP protocols and web services. In the section below, the list of standards/specifications takes into account the ones which fulfill market requirements. [SG-CG/C], Annex F provided some detailed information on standards pertaining to Smart Grid communications. This list of standards will now be hosted in the new edition of the Set of Standards [SG- CG/G] Communication network type breakdown Depending on the Smart Grid target applications, different types of communication networks and also collections of communication networks using different transmission technologies may be selected in order to transmit and deliver Smart Grid data. The following network types could be defined for the Smart Grids: (A) Subscriber Access Network networks that provide general broadband access (including but not limited to the internet) for the customer premises (homes, building, facilities). They are usually not part of the utility infrastructure and provided by communication service providers, but can be used to provide communication service for Smart Grid systems covering the customer premises like Smart Metering and aggregated prosumers management. (B) Neighborhood Network networks at the distribution level between distribution substations and/or end users. They are composed of any number of purpose-built networks that operate at what is often viewed as the last mile or Neighborhood Network level. These networks may service metering, distribution automation, and public infrastructure for electric vehicle charging, for example. (C) AMI backhaul Network networks at the distribution level upper tier, which is a multi-services tier that integrates the various sub layer networks and provides backhaul connectivity in two ways: directly back to control centers via the WAN (defined below) or directly to primary substations to facilitate substation level distributed intelligence. It also provides peer-to-peer connectivity or hub and spoke connectivity for distributed intelligence in the distribution level

107 (D) Low-end intra-substation Network networks inside secondary substations or MV/LV transformer station. It usually connects RTUs, circuit breakers and different power quality sensors. (E) Intra-substation Network network inside a primary distribution substation or inside a transmission substation. It is involved in low latency critical functions such as tele-protection. Internally to the substation, the networks may comprise from one to three buses (system bus, process bus, and multi-services bus). (F) Inter substation Network networks that interconnect substations with each other and with control centers. These networks are wide area networks and the high end performance requirements for them can be stringent in terms of latency and burst response. In addition, these networks require very flexible scalability and due to geographic challenges they can require mixed physical media and multiple aggregation topologies. System control tier networks provide networking for SCADA, SIPS, event messaging, and remote asset monitoring telemetry traffic, as well as peer-to-peer connectivity for tele-protection and substation-level distributed intelligence. (G) Intra-Control Centre / Intra-Data Centre Network networks inside two different types of facilities in the utility: utility data centers and utility control centers. They are at the same logical tier level, but they are not the same networks, as control centers have very different requirements for connection to real time systems and for security, as compared to enterprise data centers, which do not connect to real time systems. Each type provides connectivity for systems inside the facility and connections to external networks, such as system control and utility tier networks. (H) Backbone Network inter-enterprise or campus networks, including backbone Internet network, as well as inter-control center networks. (L) Operation Backhaul Network networks that can use public or private infrastructures, mostly to support remote operation.. They usually inter-connect network devices and/or subsystems to the Operation level over a wide area (region or country). (M) Industrial Fieldbus Area Network networks that interconnect process control equipment mainly in power generation (bulk or distributed) in the scope of smart grids. (N) Home and Building integration bus Network networks that interconnect home and / or building communicating components and sub-systems to form a home or building management sub-system or system Mapping of communication network type over the SGAM Figure 16 below provides a mapping of the different Smart Grid networks to the SGAM model. NOTE where a circle is tangent to a zone, this means that the corresponding network type can support the interface with the tangent zone. 37

108 Backbone Backhaul Neighborhood/ Horizontal network Integration bus Market Enterprise Operation Station Field Process (H) Backbone network (G) Intra-centre integration bus (L) Operation BachhaulNetwork (C) AMI Backhaul Network (E) Intra-substation integration bus (D) Low-end intra-substation integration bus (F) Inter-substation Networks (B) Neighborhood Networks (A) Subscriber Access Network Generation Transmission Distribution DER Customer premise Figure 16 - Mapping of communication networks on SGAM (M) Industrial process integration bus (N) Home & Building integration bus Note 1: These areas are a mapping example and cannot be normative to all business models. Note 2: It is assumed that sub-networks depicted in the above figure are interconnected (where needed) to provide end-to-end connectivity to applications they support. VPNs, Gateways and firewalls could provide means to ensure network security or virtualization Data modelling with the SGAM Because of the increasing need of many Smart Grid stakeholders to deploy solutions offering a semantic level of interoperability, data modeling appears as the cornerstone and foundation of the Smart grid framework. In addition data modeling seems much more stable than communication technologies, which makes this foundation even more important. Currently the IEC framework relies on 3 main pillars, as far as data modeling is concerned, represented in Figure 17. The same figure represents also the 3 harmonization work items (i.e. the definition of unified shared semantic sub-areas, or formal transformation rules) which need to be performed in order to allow an easy bridging of these semantic domains: Harmonization between CIM 9 and IEC 61850, mostly to seamlessly connect the field to operation and enterprise level Harmonization between CIM and COSEM 10, mostly to seamlessly interconnect electricity supply and grid operation, Harmonization between COSEM and IEC 61850, where smart metering may co-habit with Power Utility Automation systems. 9 CIM Common Information Model, IEC 61968, IEC COSEM Companion Specification for Energy Metering, IEC

109 Market CIM data model Enterprise 1 CIM/IEC harmonisation 1 2 Operation Station 2 CIM/COSEM harmonisation IEC data model 3 Field 3 COSEM/IEC harmonisation Process COSEM data model (smart metering) 809 Generation Transmission Distribution DER Customer premise Figure 17 - Data modeling and harmonization work mapping 8 Examples showing the use of the SGAM 8.1 Introduction With the help of an example we like to validate the SGAM Methodology and justify the following key points: The SGAM analysis pattern provides a valuable scheme to analysis, visualize and compare Smart Grid use cases from high-level to detailed specifications. A Use Case Concept with its short template is a simple way to document general ideas in an easy manner. It provides abstract information on all SGAM layers, allows alternatives and leaves room for the experts to specify the details. The mapping of the use case to the Smart Grid plane is a simple way to compare, cluster/group and harmonize several use cases. In the following sub-sections we discuss use cases related to Monitoring on very different levels of abstraction. We will start with a high-level use case taken from the previous work done in [SG-CG/E] and analyze it as a use case concept on all SGAM layers in an abstract manner. Further detailing will be done for selected, more detailed use cases and different views business as well as technical / system. Figure 18 shows an overview of the different examples outlined in the following sections, where each description provides information on the related SGAM layers with the defined level of abstraction. 39

110 Figure 18: Overview of examples presented

111 Example #1: Monitoring of the distribution grid (SG-CG WGSP-0600) WGSP-0600 use case description is used as an example of the Use Case Concept / High-level Use Case. Several sources for monitoring data and different roles are involved, e.g. sensors, meters, DERs, CEMSs. A mapping of the use case to the SGAM Smart Grid Plane plus involved market roles is depicted in Figure 20. uc SGAM Use Case Analysis - Monitoring the distribution grid DSO (Distribution System Operator) Producer (DER) Aggregator (from Simplified Role Model) (from Simplified Role Model) (from Simplified Role Model) Monitoring of the distribution grid (from Grid related use cases) Consumer Meter Operator (from Simplified Role Model) (from Simplified Role Model) Figure 19: Mapping of the use case "Monitoring of the distribution grid" 41

112 To reach the next level of detail primary use cases needs to be defined Primary use cases Monitoring inside the distribution grid Monitoring of DERs by the DSO 42

113 uc SGAM Use Case Analysis - Monitoring the distribution grid Producer (DER) DSO (Distribution (from Simplified Role Model) Aggregator (from System Simplified Operator) Role Model) (from Simplified Role Model) Monitoring of the distribution grid Monitoring inside the distribution grid Monitoring of DERs... (from SGAM Use Case Analysis) (from Distribution) (from Cross-domain: Distribution<->DER) (from Grid related use cases) Consumer Meter Operator (from Simplified Role (from Model) Simplified Role Model) Figure 20: Primary use cases for Monitoring the distribution grid 8.3 Example #1.1: Monitoring inside the distribution grid (Business Use Case) Roles & Responsibilities Policies/ Regulation/ Business Models e.g. law on energy industry Use case includes a role with a clear responsibility. According to HRM the following role is a grouped role (refer to [SG-CG/J]) From EG1: Distribution System Operator (DSO): according to the Article 2.6 of the Directive: a natural or legal person responsible for operating, ensuring the maintenance of and, if necessary, developing the distribution system in a given area and, where applicable, its interconnections with other systems and for ensuring the long-term ability of the system to meet reasonable demands for the distribution of electricity. Moreover, the DSO is responsible for regional grid access and grid stability, integration of renewables at the distribution level and regional load balancing. Monitoring information is the basis for several other use cases, e.g. FLISR, Volt/VAr control. These use cases ensure the stable operation of the distribution grid and improve performance indexes like SAIDI (System Average Interruption Duration Index) and SAIFI (System Average Interruption Frequency Index). 43

114 The business value of this use case has to be evaluated together with the use cases it enables. Security requirements: Regulative, e.g.: NERC CIP; Information Security Management: ISO 27001/02/19; from guidelines: NIST IR 7628, BDEW White Paper) 848 uc SGAM Use Case Analysis - Monitoring inside the distribution grid DSO (Distribution (from System Simplified Operator) Role Model) Monitoring inside the distribution grid (from Distribution) Figure 21: Mapping of Monitoring inside the distribution grid on SGAM plane 8.4 Example #1.2: Monitoring inside the distribution grid (Device/system use case) A rich monitoring functionality is the prerequisite to determine the state and performance of the distribution grid. Monitoring has to provide: Measurements of the grid at field level, Data concentration and access control at the station level, SCADA system to process, visualize, archive etc. the monitoring information. Data to be collected are e.g. voltage, current, frequency, phase angle, active and reactive power, and state of the control elements. These data need different monitoring approaches depending on their time horizons. A measurement of these quantities could be time-critical and partially need high sample rates. Further measurements are sent only when they exceed thresholds or every time a state change occurs. The task is to optimize data collection,finding a compromise between getting precise enough system states and not overloading the monitoring network. The monitoring protocols have to support all timescales with high reliability. All information collected should be stored in an archive for further processing. 44

115 Figure 22: SGAM analysis for Monitoring inside the distribution grid 8.5 Example #1.1.1: Detailing the secondary use case Access Control Access control as depicted as secondary use case in Figure 22 is often required for the operation of critical infrastructures. This is being requested by regulation and also by standards and guidelines addressing Smart Grid as mentioned in the business use case description in Section 8.3 Example #1.1: Monitoring inside the distribution grid (Business Use Case). In the following, SGAM is used to identify the detailed requirements to support Role-Based Access Control (RBAC) by mapping a technical solution to the SGAM function, information, communication and component layers. 45

116 a) Function Layer b) Information Layer c) Communication Layer d) Component Layer Figure 23: SGAM Analysis of Role-based Access Control Based on the requirements stemming from the business layer in Section 0, the functional layer reflects the functional security requirements for role-based access control related to dedicated zones and domains. Through mapping to different zones, one can already distinguish between local and remote access. The function layer comprises access control to components but also command execution authentication and authorization control as functional requirements. Functional requirements are typically related to an existing functional architecture during the design of an appropriate security architecture addressing discovered potential security risks (e.g. according to a risk assessment based on use cases). The SGAM analysis for the information and communication layers shows the application of [IEC ] in the context of Smart Grid systems applying protocols like IEC or IEC It has been 46

117 chosen here to provide an example of the application of SGAM in the context of identifying security requirements as well as mapping special solutions to these requirements. IEC addresses the integration of role-based access control to ease the burden of access management in power systems. It enables verification of authorization before command execution, e.g. in substation automation in terms of who is authorized to perform a specific switching command. This information can be required e.g. for auditing purposes. The roles 11 are bound to different credentials as defined in [IEC ]. The standard distinguishes between: Public Key (Identity) certificate with included role information; attribute certificate bound to an identity certificate; software token (HMAC-protected structure, Kerberos like). The standard IEC describes merely the token providing the role information as well as a set of mandatory roles (and associated rights): VIEWER; OPERATOR; ENGINEER; INSTALLER; SECADM (Security Administrator); SECAUD (Security Auditor); RBACMNT (Role-based Access Management). This list of roles and associated rights can be extended with own specific roles and rights information. The predefined list above is intended for interoperability between different components. It is expected that all enhancements are installed on the entities involved, to facilitate interoperability. The information layer requires RBAC credential specification and also mapping of entities to roles. As stated, IEC provides predefined roles and associated rights. Nevertheless, these role definitions and rights associations can be enhanced according to deployment needs. On the communication layer, roles are transmitted bound to credentials within IEC protocols. IEC defines the structure of the RBAC token and also guidance how to transmit this token as part of utilized protocols. One example is the application of X.509 attribute certificates bound to X.509 Public Key certificates. The communication layer in this example includes the following protocols: IEC protected through IEC /4: Here TLS is used to protect the communication on transport layer. Within TLS X.509 certificates are used to support mutual authentication. The X.509 certificates may be enhanced directly with role information allowing for RBAC. Alternatively an attribute certificate can be bound to the X.509 ID certificate to enable a short-term binding. SOAP (Simple Object Access Protocol) over HTTPS: Engineering using web services transported over HTTPS, which is protected by TLS. Here again, X.509 certificates may be used for mutual authentication and thus also allow for realizing RBAC based on mechanisms described in IEC LDAP (Lightweight Directory Access Protocol): Protocol used to access directory services to retrieve certificates. May be used using TLS. OCSP (Online Certificate Status Protocol): Protocol to retrieve fresh revocation information for single certificates. Avoids storing certificate revocation list (CRLs) on single field devices 11 The understanding of roles in this standard is similar as described in [SG-CG/J], but these roles are not related to the HRM. Here they are related to different responsibilities and access rights as explained. 47

118 CRL retrieval: Protocols used to request a CRL from a Certification Authority (CA). These protocols may be FTP, SSH, or HTTP. Unsecure protocols should be protected e.g. by using an underlying security protocol like TLS. The CRL is protected by itself, as it is signed by the CA. The component layer comprises additional components for credential handling like the generation or revocation of X.509 key material. This task is commonly performed by a Public Key Infrastructure (PKI). The additional components needed here comprise a Certification Authority issuing the X.509 certificates including the role information and also a repository for querying the RBAC information. A component is also needed for storing revocation information for the case when a RBAC credential is revoked before its validity period has ended. As shown above, IEC can be used to support RBAC for the discussed use case and in general for Smart Grid Systems. Nevertheless, regarding IEC there are also gaps, which can be identified: for interoperability reasons a mandatory profile for RBAC support is necessary. The standard currently defines three different profiles, without requiring concrete support for at least one. This would be necessary to ensure interoperability and avoid a full implementation of this standard; transport profiles also for other protocols than TCP/IP (e.g. application for UDP/IP or even Ethernet based communication) may be outlined. The current standard only takes TLS as concrete example for application. Nevertheless, there are other standards utilizing X.509 certificates for authentication on transport but also on (OSI) application layer. They may leverage the approach of enhancing either the X.509 public key certificate with the role information (as an extension) or by providing an attribute certificate containing the role information for a holder of a dedicated X.509 public key certificate. 8.6 Example #1.1.2: Monitor system interruptions and report to regulator As outlined in the previous sections the Monitoring use case supports a wide range of other use cases. For the short and general descriptions of the Monitoring use case it was not necessarily required to define how the monitoring data is used. This allows us to consolidate a set of monitoring use cases into a single harmonized description. However, to derive a primary use case description providing all information on all levels of details as depicted in [Cockburn], we have to define the goal of the use case precisely. Hence, we outline in this section a specialized use case that monitors system interruptions in the distribution grid and reports them to the regulator. The use case was chosen because measures for reliability are reported for many years in various countries. Thus, the required information for the use case description is based on existing sources and not derived completely new. Regulatory rules differ from country to country including also the guidelines for reporting system interruptions. In the following we focus on the regulations in Germany without any intention beyond demonstrating the SGAM methodology. As defined in Germany in the law of energy industry EnWG 52, system operators including DSOs have the obligation to report system interruptions on a yearly basis to the German Federal Network Agency (Bundesnetzagentur (BNetzA)). Furthermore, the German Federal Network Agency has the right to specify formal guidelines for reporting 12. Business View: 963 Business Process e.g. change of supplier BNetzA has the right to define the guidelines for reporting Two types of reporting are defined: o Web form for manual input o XML-based report using web services 12 As specified on the website of the German Federal Network Agency (in German only): ssicherheit/stromnetze/stromnetze-node.html 48

119 Technical View: Functions e.g. Data acquisition Semantic information model profiles e.g. MMXU (Logical Nodes) Communication Services e.g. Reporting, Control (ACSI) Devices e.g. protection relay Functions in control center include e.g. Data acquisition Archiving Reporting to regulatory body Basic data set which has to be reported for each interruption include e.g. Start (date, time) Duration (minutes) Type of the interruption (e.g. planned, unplanned) Reason for interruption (e.g. force majeure) Communication services for submitting the report include e.g. Start/close/abort transaction Send network data Report interruptions The control center can be detailed including e.g. the following components Communication Front End Database Web client Figure 24 depicts the SGAM analysis for this use case with a special focus on the interaction between components of the DSO and the regulator. 49

120 e) Function Layer f) Information Layer g) Communication Layer h) Component Layer 971 Figure 24: SGAM Analysis Monitoring system interruptions and report to regulator

121 According to Figure 3 SGAM Analysis Pattern, the function, information and communication layer can be further detailed to specify flow charts, the information syntax and the communication protocols, respectively. The following provides an example for the lowest level of detail. Flow charts e.g. CFC BNetzA defines flow charts for reporting system interruptions Following excerpt is provided as example: Information syntax e.g. XML Schema, RDF BNetzA uses WSDL to provide the service description for reporting system interruptions with web services (which is available online 13 ) Following excerpt is provided as example:

122 Protocol Mapping e.g. MMS, Web Services BNetzA provides definitions for SOAP messages of each communication service Following excerpt is provided as example In summary, this section outlines a SGAM analysis from a use case concept to a detailed description on all layers. It shows how different use case descriptions provide information for the SGAM layers with different level of abstraction. The SGAM analysis pattern depicted in Figure 3 can be used as guideline to derive high quality descriptions of use cases providing information on all interoperability layers of the SGAM framework. 9 Further example use cases to test the SGAM 9.1 Overview The following use case, which had been considered in the Sustainable Processes workgroup and was already in the use case repository, has been identified and is proposed as suitable for this purpose. It relates to the internal automation function of the customer role for optimizations according to the preferences of the customer, based on signals from outside and internal flexibilities. In this example, a demand response approach uses variable tariffs to motivate the customer to shift consumption in a different time horizon (i.e. load shifting). On customer side the signals are automatically evaluated according to preset customer preferences like cost optimization or CO2 savings and appropriate functions of one or more connected devices are initiated. 9.2 High level use case WGSP-2135 Inter-CEMS energy trading Co-ordination of distributed generation and loads at neighborhood level based upon peer-to-peer communication between several Central Energy Management Systems, and brokerage within a multi-agent system Within this high level use case, two primary use cases can be identified: - The first primary use case (WGSP-2136) describes how flexibility is offered to other neighborhood CEMSs. An example of such a scenario would be peer-to-peer co-ordination of local energy trading involving extra PV energy (not used in-house) that can be stored or used by other homes in the neighborhood. - The second primary use case (WGSP-2137) describes how flexibility is requested from other neighborhood CEMSs. An example of such a scenario would be peer-to-peer co-ordination for voltage control i.e. how distributed generation resources can be utilized for voltage stability control purposes based on distributed intelligence. The following architecture has been used as a basis in considering these use cases. 52

123 Energy Management / Providing Flexibility (M490) Actor A Energy management gateway (EMG) CEM Smart Device* Market communication Smart Grid Connection Point Actor B Functional metering reference architecture according the SM-CG (TR50572) Smart Metering gateway (LNAP ) Smart meter functionality Simple external consumer display M441 architecture * e.g. HBES device, smart appliances, storage, generator, domestic charger for EV, complex display Note that the actors in the above architectural diagram are functional entities, which means that some of them may be part of the same physical device (e.g. CEM functionality may be part of a smart device, the smart meter might also encompass the smart metering gateway and CEM, etc.) The interfaces between the entities shown in the diagram are the subject of current standardization activities overseen by the Smart Grid Co-ordination Group, with those involving the AMI delegated to the Smart Meter Co-ordination Group. 9.3 Primary use case description WGSP Description To illustrate the first primary use case WGSP-2136, the agent of the PV house may offer its energy (as a proposal) while the broker agents of the other homes evaluate the proposal knowing their own upcoming loading schedule, the habits of the house, the storage capacity, its own generation capacity and other relevant information. Accepting the energy offer would lead to a load increase and effectively a temporary switch of energy provider in the homes that accepted the energy offer. Hence, the energy produced by the PV would be locally absorbed. Various schemes of energy allocation within the neighborhood can be thought of, leading to different required billing approaches. This dynamic matching may result in nothing being perceived at the distribution substation, no load increment, no injection increment Implications: WGSP-2136 Considering the selected use case WGSP-2136 more deeply, it is evident that this peer-to-peer clearing activity is only worthwhile in practice if suitable commercial and regulatory arrangements are in place. It has to be cheaper for the community to act together in this way than if the dwellings concerned engaged individually in offering their own flexibility to the grid at whatever price their supplier/utility was offering. Thus the dwelling with its own generation would have to get a better price by making it available to the local community than the price that would be obtained if the power were exported to the wider grid; similarly the customers in that community needing electricity would have to get it at a better price than the retail price available from their supplier. A number of approaches are possible to achieve this, and all would probably require changes to the industry model operating in the member state concerned. However, one way is that the community could in effect act as a group customer, aggregating energy requirements / pooling generation resources, and entering into a supply (possibly wholesale?) contract with their chosen supplier for the balance of the community s needs. The community coordinator would keep a list of community energy resources up-to-date and indicate available resources and communicating community energy offers/needs to each energy management gateway (EMG). Customers would continue to be metered individually, but a community system of (dynamic) allocation would exist in parallel, with direct transactions set-up between different EMGs (e.g. via the internet). This need not involve the community coordinator. However the coordinator would take information 53

124 from the various CEMSs on the outcome of the transactions and divide costs and benefits according to whatever methodology they might mutually agree. For the latter to work, the community agreement would need to be registered with the supplier. Registration would entitle community members to receive a higher price (or other benefit) for locally produced and consumed energy than the normal export price, since the export price would normally take account of the distribution costs associated with injection of energy into the grid. Similarly members consuming locally produced power would receive a discount on the distribution element of the normal retail tariff to reflect their local consumption. NOTE this is simpler to achieve if all members of the community are customers of the same supplier. A community coordinator (specific to the community or an Energy Service Provider acting on behalf of the community) could receive an aggregated bill on behalf of all members based on these special community prices and then allocate costs/income accordingly. Or the supplier, acting as the agent of the community and following the community's allocation rules in the registered agreement, could carry out the task. NOTE A direct peer-to-peer agreement between two individual parties seems unlikely to be able to be implemented without someone playing a coordinating role, serving as a community repository or acting as an aggregator on behalf of the community, and for this reason, the community coordinator is seen as a separate actor, even if the role is undertaken by one of the users in the community. In terms of information flows, there would be a need to manage the aggregation and allocation process. This would require communications between individual community members (or more precisely the energy management gateways of the premises concerned) and the community coordinator, and potentially peer-topeer communications between CEMSs via their energy management gateways also. Since this use case is primarily concerned with achieving the optimal commercial outcome for the community, the coordinator would also communicate with the community s supplier, with the coordinator acting as either a community aggregator or a quasi-customer and dealing with the supplier for any surplus energy made available to the wider grid. Since the coordinator is in effect acting as a customer, communications with the supplier can be seen in the same way as when an individual customer is providing flexibility. 9.4 Primary use case description WGSP Description To illustrate the second primary use case WGSP-2137, consider a radial distribution network with distributed generation resources (producers). The producers can be used to support voltage by injection of power at the connection node. Each producer is monitored and controlled by a broker agent, which can detect the voltage violation. Each agent can behave as a broker to engage the other agents (and in practice their generators) in the voltage regulation. Note that each agent is capable of broker behavior, so this structure is not rigid. Each producer can contribute depending on its current operating conditions and electrical position in the network. Via his CEMS, the broker agent requests flexibility and, based on the current information and offers received from the other agents, decides a dispatch strategy. In this use case, the broker agent is considered to be a part of the CEM and includes local monitoring and control capabilities as well as algorithms for brokerage including accounting. Since this use case describes communication between multiple CEMS, each CEM is assigned a number / an IP address Implications: WGSP-2137 In WGSP-2137, there is in effect a community of producers who are prepared to inject power as required by the local distribution company. This community may be virtual, rather than geographically delineated as in WGSP-2136, but in common with WGSP-2136, the list of individual premises involved in the process would probably be registered in some way, in this instance with the distribution company. While the need for power injection could be communicated to the producers in the community by the distribution company, this use case envisages an automatic process based on monitoring of the system by individual producers and peerto-peer communications between them to determine optimal dispatching on a collective basis. 54

125 Since the purpose is to stabilize voltage within the wider distribution grid, no special community tariff arrangements would be required. Individual producers would be recompensed via the usual export tariffs for their part in the collective resolution of the need for injection. In common with WGSP-2136, peer-to-peer communication would be required, together with the existence of a community coordinator who would manage the community response in accordance with locally determined rules. In terms of information flows at the local level, there would be a similar need for communications between individual community members (or rather the energy management gateways of the premises concerned) and the community coordinator, and potentially peer-to-peer communications between energy management gateways also. However since the use case is primarily concerned with achieving the optimal response by the community to a distribution problem, the coordinator would in this instance communicate with the distribution system operator. Again the coordinator is in effect acting as a customer, and communications from the distribution company can be seen as an emergency response use case. NOTE More detailed descriptions of the above use cases in terms of the typical steps involved in offering and requesting flexibility are given in Appendix A of the present document. 9.5 Consideration of use cases against the SGAM Domains and Zones Looking at the SGAM framework, we have seen that the activity envisaged in the selected use cases both involve peer-to-peer communications between CEMSs within a community. In the case of WGSP-2136, the community would be at the most local level, within a few dwellings or buildings within a neighborhood. That community of CEMs would manage their own flexibility as far as possible independently of the distribution system, acting as a kind of local clearing house for flexibility. The wider smart grid would only see the net result of that local activity if there were any residual flexibility needs or offerings after the local community had managed their individual flexibility in the way they had agreed upon, e.g. by having made optimum use of their local generation resources. Thus in SGAM terms the peer-to-peer activity for WGSP-2136 is essentially localized to the DER and Customer Premises domains and the Process zone, with communications feeding back to the supplier (for billing purposes. The relevant communications would be via the energy management gateway or smart meter gateway. Given that the supplier will be receiving data and perhaps also managing the allocation process, communications would most probably make use of the protocols already defined for demand and production (generation) flexibility systems and in particular aggregated prosumers management systems. In the case of WGSP-2137, the need for injection would be evident within the distribution domain and field zone, and as noted earlier, there would be some interaction between these zones and the peer-to-peer activity described. These communications would most probably make use of the protocols already defined for distributed power quality control systems. 55

126 Appendices B & C of the current document illustrate the detailed mapping of each of the use cases using the format adopted in the First Set of Standards work for the component, communication, information and function layers. This mapping is essentially the same as that for aggregated prosumers management systems and distributed power quality control systems, with the addition of a peer-to-peer element. 9.6 Implications of above analysis for the SGAM The above analysis does not indicate that peer-to-peer communications as envisaged in the two use cases considered necessitate modification of the SGAM. Peer-to-peer communications can follow whatever protocols may be agreed upon locally. However in the activity envisaged in WGSP-2136, residual flexibility arrangements (after local optimization) would need to be managed with the supplier/utility. Such communications would thus most probably make use of the protocols already defined for aggregated prosumers management systems. Indeed in overall terms WGSP-2136 can be seen as a refinement of the existing flexibility use case, with the addition of the peer-to-peer element. Similarly, in the case of WGSP-2137, communications with the distribution domain would most probably make use of the protocols already defined for distributed power quality control systems. 9.7 Conclusions of the work to date At a general and strategic level, the above analysis shows the value of the SGAM and the approach to mapping of use cases against the SGAM. It demonstrates how new use cases can be considered and incorporated within the present SGAM framework, using the tools developed by the SG-CG. It also shows how potential standardization gaps resulting from a new use case can be identified. This should be of value to future smart grid-related work by Technical Committees. The analysis also shows that as use cases become more detailed, they increasingly reflect national and industry circumstances. However detailed use cases can be readily fitted into the SGAM methodology and framework. The value of the methodology is that it provides Member States, Technical Committees and others with a common approach and analytical language for such activity. The analysis of the new use cases demonstrates is that there is no lack of European standards for the two use cases considered. The main challenge presented by the possibility of peer-to-peer communications as envisaged relates to the market, industry, legal and regulatory framework for such activity. Member States and others wishing to develop the concept at national level are exploring what arrangements would be required, and it may be necessary to review this preliminary conclusion in the light of such national use cases. Finally the work demonstrates the need for ready access to the use case repository and to the templates and examples of use case descriptions, such as those shown in Appendix A below. This is necessary if those with potential new or more detailed use cases are to be able to check the relationship of such use cases to what has already been developed and to integrate them with previous work. The work also shows the desirability of ready access to the detailed mapping tools used in presentation of the SGAM, as illustrated in Appendices B & C of the current document. 56

127 Appendix A Detailed use case descriptions 1164 WGSP-2136: Inter-CEM flexibility offerings Scenario Name Primary Actor Triggering Event Pre-Condition Post-Condition Inter-CEM flexibility offering CEM-1 CEM_1 is (made) aware of one or more potential flexible loads / production CEM_1 is configured to create flexibility offerings CEM_1 is configured for inter- CEM communication CEM_xyz is aware that flexibility has been assigned The potential flexible load does not fall into a constraint set by the end-user 1165 Typical steps Step No. Event Name of Process/ Activity Description of Process/ Activity Information Producer (Actor) Information Receiver (Actor) Information Exchanged 1 CEM_1 is (made) aware of one or more potential flexible loads / production Send flexibility offer CEM_1 creates flexibility offering and sends this to connected neighborhood CEM s CEM_1 CEM_2-n Flexibility Offer 2 Neighborhood CEM s receive the flexibility offer Reply to flexibility offer Neighborhood CEM s reply, indicating the conditions under which they are willing to accept the flexibility offer CEM_2-n CEM_1 Flexibility Offer Reply 3 CEM_1 receives reply from interested neighborhood CEM s Assign flexibility CEM_1 determines the winners, the final amount of power for each and sends an assignment to the winning neighborhood CEM s CEM_1 CEM_xyz Flexibility Offer Assignment

128 1167 WGSP-2137: Inter-CEM flexibility request Scenario Name Primary Actor Triggering Event Pre-Condition Post- Condition Inter-CEM flexibility request CEM_1 CEM_1 is (made) aware of a flexibility need CEM_1 is configured to request flexibility CEM_1 is configured for inter-cem communication The potential flexible load does not fall into a constraint set by the end-user CEM_xyz is aware that flexibility has been assigned 1168 Typical steps Step No. Event Name of Process/ Activity Description of Process/ Activity Service Information Producer (Actor) Information Receiver (Actor) Information Exchanged 1 CEM_1 is (made) aware of a flexibility need Send flexibility request CEM_1 creates a flexibility request and sends this to connected neighborhood CEM s CEM_1 CEM_2-n Flexibility Request 2 Neighborhood CEM s receive the flexibility request Reply to flexibility request Neighborhood CEM s reply, indicating the conditions under which they are willing to provide flexibility CEM_2-n CEM_1 Flexibility Request Reply 3 CEM_1 receives reply from offering neighborhood CEM s Assign flexibility CEM_1 determines the winners, the final amount of power for each and sends an assignment to the winning neighborhood CEM s CEM_1 CEM_xyz Flexibility Request Assignment

129 1171 Information exchanged Name of Information Exchanged Description of Information Exchanged Flexibility Offer Flexibility Offer Reply Contains information on how much flexibility is the CEM willing to buy, what is the local impact and which is the sensitivity index value) Flexibility Offer Assignment Flexibility Request Flexibility Request Reply Contains information on how much flexibility is the CEM willing to offer, what is the local impact and which is the sensitivity index value) Flexibility Request Assignment

130 Appendix B Detailed mapping of WGSP-2136 to SGAM The following diagrams illustrate possible mapping of WGSP-2136 at the component, communication and information layers Figure 1: Mapping of WGSP-2136 to the SGAM Component Layer

131 Figure 2: Mapping of WGSP-2136 to the SGAM Communication Layer

132 Figure 3: Mapping of WGSP-2136 to the SGAM Information Layer

133 Appendix C Detailed mapping of WGSP-2137 to SGAM The following diagrams illustrate possible mapping of WGSP-2137 at the component, communication and information layers Figure 4: Mapping of WGSP-2137 to the SGAM Component Layer 63

134 Figure 5: Mapping of WGSP-2137 to the SGAM Communication Layer

135 Figure 6: Mapping of WGSP-2137 to the SGAM Information Layer

136 CEN-CENELEC-ETSI Smart Grid Coordination Group Date: 08/2014 Secretariat: CCMC SG-CG/M490/L_ Flexibility Management Overview of the main concepts of flexibility management Version 2.0 1

137 Foreword Based on the content of the M/490 EU Mandate in its phase 1 ( ), the general scope of work on standardization of the Smart Grid might be considered as follows: CEN, CENELEC, and ETSI are requested to develop a framework to enable European Standardization Organizations to perform continuous standard enhancement and development in the field of Smart Grids, while maintaining transverse consistency and promote continuous innovation. In the light of the discussions held between the EC Reference (EG1) Group and the Smart Grid Coordination Group (SG-CG), the need to iterate the EC Mandate M/490 was considered and agreed by both sides. As a main objective of the mandate phase 2, the SG-CG wishes to implement the developed methodology, which set up the foundations for managing the continuous engineering and deployment of standards to ensure a real end-to-end interoperability for all generic use cases explicitly including security. A further refinement of the methodology will be used for the set of consistent standards [SG-CG/G] (under item 3.1 and 3.2 of M/490). The work is based on [SG-CG/C] and [SG-CG/E]. The final report is due on September 1 st, 2014, based on the version v1.0 provided end of 2013 for commenting within the SG-CG. A set of documents is addressing this objective: The main report as a summary of different tools, elements and methodologies developed by the different working groups of the Smart Grid Coordination Group [SG-CG/F], and additional separate reports detailing specific issues of the working group Methodology and New Applications : The conceptual model and its relation to market models for Smart Grids [SG-CG/J] SGAM User Manual - Applying, testing & refining the Concepts, Elements and Tools for the Smart Grid Architecture Model (SGAM) [SG-CG/K] Overview of the main concepts of flexibility management [SG-CG/L] (this document) 26 2

138 Table of contents Foreword 2 1 References Terms and Definitions Symbols and abbreviations Introduction Background / Challenges EU-wide uniform implementation of flexibility management Scope and purpose of this document Structure of this document Flexibility in demand and supply in Smart Grids What is flexibility? Providers of Flexibility How is it provided? Demand Side Management Demand Response Explicit provisioning of flexibility to the market Flexibility Management Applications Areas Introduction How flexibility is used System operations Grid Operations Energy Trade Use cases Technical use cases Commercial use cases Market Implementation Considerations Introduction Roles, rights, expectations and responsibilities: Parties connected to the grid (e.g. consumers) Roles and responsibilities: Flexibility Operator Architecture Recommendations Introduction Smart Grid Connection Point (SGCP) Flexibility functional architecture Auto registration of participating devices and customers Auto registration CEM to flexibility operator Auto registration smart devices to CEM or to SGCP Relation between the flexibility operator and the European harmonized electricity market role model Page 3

139 Communication of price signals, tariffs and other economic incentives Explicit trade in flexibility in demand and/or supply Direct control of demand and/or supply Traffic light concept Recommendations on standardization and regulation Introduction Implementation of flexibility operator market role Relationship between standards and codes for the Traffic Light Concept Moving towards a 'smarter energy' future Recommendations from commercial / grid area Open issues still under discussion Considerations of technical limitations in the grid Many concepts for commercial use cases still remain under R&D Further key considerations relating to system stability and political framework Recommended flexibility management case studies for further study List of Figures Figure 1: Two way flow of flexibility (SOURCE: [THINK]) Figure 2: Flow of Flexibility plotted on Conceptual Model from Providing to Using Flexibility Figure 3: Categorization of Flexibility Sources (adopted from [THINK]) Figure 4: Interactions to provide / address flexibility of grid users Figure 5: Use of flexibility on different time scales Figure 6: Application areas of flexible demand, storage and generation Figure 7:Commercial and technical flexibility use cases in the grid and market area Figure 8:Flexibility operator gathering flexibilities from different customers and sells them to the endusers of flexibility (grid / system operators, commercial entities, etc.) Figure 9: Flexibility functional architecture Figure 10: Mapping of flexibility functional architecture on SGAM Figure 11: Notation used in analysis of relation between flexibility operator and [HEM-RM] Figure 12: Economic incentives in the flexibility use cases in relation to [HEM-RM] Figure 13: Explicit trade in flexibility in relation to [HEM-RM] Figure 14: Direct control of demand and/or supply use case in relation to [HEM-RM] Figure 15: Traffic Light Concept Figure 16 Traffic light concept and use cases List of Tables Table 1: Use cases for the Traffic Light Concept in relation with the tasks of a grid operator Table 2: Flexibility management case studies

140 104 History of document V1.0 18/12/2013 For publication and review by the BTs and TCs. V /06/2014 Integration of comments, basis for F2F meeting of WG Method on 16th of June 2014 V /06/2014 Cleaned version for editors V /08/2014 Fine tuning V1.9.3 V1.9.4 Language check Semi-final version within WG Method V Final for distribution to the SG-CG, commenting phase Main changes in this version

141 References Smart Grid Coordination Group Phase 1 Documents [SG-CG/A] [SG-CG/B] [SG-CG/C] [SG-CG/D] [SG-CG/E] SG-CG/M490/A_Framework for Smart Grid Standardization SG-CG/M490/B_ Smart Grid First set of standards SG-CG/M490/C_ Smart Grid Reference Architecture (this document) SG-CG/M490/D_Smart Grid Information Security SG-CG/M490/E_Smart Grid Use Case Management Process 116 Smart Grid Coordination Group Phase 2 Documents [SG-CG/F] [SG-CG/G] [SG-CG/H] [SG-CG/I] [SG-CG/J] [SG-CG/K] [SG-CG/L] SG-CG/M490/F_Overview of SG-CG Methodologies SG-CG/M490/G_Smart Grid Set of standards SG-CG/M490/H_ Smart Grid Information Security SG-CG/M490/I_Smart Grid Interoperability SG-CG/M490/J_General Market Model Development SG-CG/M490/K_SGAM usage and examples SG-CG/M490/L_ Flexibility Management (this document) Other references made in this Annex [ADDRESS-1] ADDRESS Project, Active Distribution network with full integration of Demand and distributed energy RESourceS, [ADDRESS-2] ADDRESS, The ADDRESS Project: Developing Active Demand in Smart Power Systems integrating Renewables, Régine Belhomme, Ramon Cerero, Giovanni Valtorta and Philippe Eyrolles, IEEE General Meeting, Detroit, USA, July 2011 [CEER 13] CEER, public consultation document, Regulatory and Market Aspects of Demand- Side Flexibility, November 2013 [CEN-CLC-ETSI TR 50572:2011] Functional reference architecture for communications in smart metering systems tml [E-ENERGY] R&D Project E-Energy, ENNET ENNET-0018 Use cases, refer to [SG-CG/E] [ENTSO-E 2012] Modular Development Plan of the Pan-European Transmission System 2050 of the e-highway2050 Project Consortium [EURELECTRIC] EURELECTRIC Views on Demand-Side Participation, Brussels, 2011 [[HEM-RM 2011] The Harmonized Electricity Market Role Model (December 2011), ENTSO-E, online: [IEV ] International Electrotechnical Vocabulary [IEC IEV Electropedia] International Electrotechnical Vocabulary, Electropedia: reference

142 [MIRABEL] [SEC 13] [THINK] [WGSP-xxxx] Smart Grid Coordination Group MIRABEL, Micro-Request-Based Aggregation, Forecasting and Scheduling of Energy Demand, Supply and Distribution Smart Energy Collective, An introduction to the Universal Smart Energy Framework, version 1.0, 2013 FP7 project Think, Topic 11 Final Report, Shift, Not Drift: Towards Active Demand Response and Beyond, June 2013 Use cases, refer to [SG-CG/E] Terms and Definitions NOTE some of the terms below are also defined in the main body of the report. In case some differences exist, the definition of the main body of the report should prevail. Customer Energy Manager (CEM) The internal automation function of the customer role for optimizations according to the preferences of the customer, based on signals from outside and internal flexibilities. EXAMPLE A demand response approach uses variable tariffs to motivate the customer to shift consumption in a different time horizon (i.e. load shifting). On customer side the signals are automatically evaluated according to the preset customer preferences like cost optimization or CO2 savings and appropriate actions of one or more connected devices are initiated. Demand Response (DR) A concept describing an incentivizing of customers by costs, ecological information or others in order to initiate a change in their consumption or feed-in pattern ( bottom-up approach = Customer decides). Alternative Defined in [IEV ] as: action resulting from management of the electricity demand in response to supply conditions. Demand Side Management (DSM) Measures taken by market roles (e.g. utilities, aggregator) controlling electricity demand as measure for operating the grid ( Top-down approach ). Alternative. Defined in [IEV ] as: process that is intended to influence the quantity or patterns of use of electric energy consumed by end-use customers. Flexibility On an individual level, flexibility is the modification of generation injection and/or consumption patterns in reaction to an external signal (price signal or activation) in order to provide a service within the energy system. The parameters used to characterize flexibility in electricity include: the amount of power modulation, the duration, the rate of change, the response time, the location etc. [SOURCE: Eurelectric, Jan 2014]. Flexibility offer (short: Flex-offer) Offer issued by roles connected to the grid and providing flexibility profiles in a fine-grained manner dynamically scheduled in near real-time, e.g. in case when the energy production from renewable energy sources deviates from the forecasted production of the energy system [SG-CG/E] 187 NOTE Flexibility offer starts a negotiation process. 7

143 Flexibility operator A bundle of roles from [HEM-RM 2011] which links the role party connected to the grid and its possibility to provide flexibilities to the conceptual domains energy services and operations; generic role that could be taken by many stakeholders, such as an Energy Service Company (ESCO) or an energy supplier. [Adapted from [SGCG/Sustainable Processes] to match the terminology in the Conceptual Model]. Smart Grid Connection Point (SGCP) Borderline between the area of grid and markets towards the role customer (e.g. households, building, industry). [SG-CG/E] Traffic Light Concept A concept in which different grid states are defined, in order to define market models and processes which are state dependent. On one hand a concept which describes the relation between the use of flexibilities on the grid side (red phase) and the market side (green phase) and the interrelation between both (yellow phase), on the other hand a use case which evaluate the grid status (red, yellow, green) and provides the information towards the relevant market roles. Intelligent Load Shedding A modified Load Shedding process where the selection of loads, which have to be disconnected, can be selected in a finer granularity using advanced control possibilities of the connected loads based on communication infrastructures. Load Shedding The process of deliberately disconnecting preselected loads from a power system in response to an abnormal condition in order to maintain the integrity of the remainder of the system [SOURCE: IEC IEV Electropedia: reference ]. Market An open platform operated by a market operator trading energy and power on requests of market participants placing orders and offers, where accepted offers are decided in a clearing process, usually by the market operator. EXAMPLES Energy, balancing power / energy, capacities or in general ancillary services. Microgrid A low-voltage and/or medium-voltage grid equipped with additional installations aggregating and managing largely autonomously its own supply- and demand-side resources, optionally also in case of islanding Symbols and abbreviations AD BDEW BRP BT CCMC Active Demand German Association of Energy and Water Industries Balancing Responsible Party Technical Board (CENELEC) CEN-CENELEC Management Centre 8

144 CEM Customer Energy Management CEN Comité Européen de Normalisation CENELEC Comité Européen de Normalisation Electrotechnique CHP Combined Heat and Power CNE Comisión Nacional de Energia (Spanish regulator, new) CNMC Comisión Nacional de los Mercados y la Competencia (Spanish regulator, new) DER Distributed Energy Resources DR Demand Response DSF Demand Side Flexibility DSL Digital Subscriber Line DSM Demand Side Management DSO Distribution System Operator EC European Commission EEX European Energy Exchange EG Expert Group EG3 EU Smart Grid Task Force Expert Group 3 EPEX European Power Exchange ESCO Energy Service Company ETSI European Telecommunications Standard Institute EU European Union EV Electric Vehicle FLIR Isolation and Restoration FO Flexibility Operator HBES Home and Building Electronic Systems HEM-RM Harmonized Electricity Market Role Model HES Head End System ICT Information and Communication Technologies IEEE Institute of Electrical and Electronics Engineers LNAP Local Network Access Point MDM Meter Data Management MG Microgrid NNAP Neighborhood Network Access Point SGAM Smart Grid Architecture Model SG-CG Smart Grid Coordination Group SG-CG/SP SG-CG Sustainable Processes SGCP Smart Grid Connection Point SM Smart Meter SM-CG Smart Meters Coordination Group SME Small and Medium Sized Enterprise 9

145 SO TC TLC TSO USGF VAr VPP VVO WACC WG WGSP 4 Introduction System Operator Technical Committee Traffic Light Concept Transmission System Operator Universal Smart Grid Framework Unit of Reactive Power Virtual Power Plant Volt/Var Optimization Weighted Average Cost of Capital Working Group Smart Grid Coordination Group Working Group Sustainable Processes (Phase 1 of the M/490) Background / Challenges Climate change, growing populations and electrification of energy use, cost efficiency and many other factors are requiring policy makers, engineers and researchers to rethink the power system. Tomorrow s energy system will need to accommodate and support generators with stochastic output, distributed energy resources and new loads such as electric vehicle chargers, electric heat pumps, etc. In this new era, keeping the balance between demand and supply, as well as using transmission and distribution capacity as economically as possible without overloading and blackouts are major challenges. This transition calls for a paradigm shift. Not only may a two way flow of power be introduced because of decentralized generation, but also a two way flow of flexibility is required as is shown in Figure 1. Generation Demand Past Centralized Dispatchable Predictable Flow of Flexibility Inelastic Future Generation Decentralized Less Dispatchable Less Predictable Flow of Flexibility Flow of Flexibility Demand More elastic Figure 1: Two way flow of flexibility (SOURCE: [THINK]) One piece in this puzzle is the intelligent management of flexible (distributed) supply and demand or flexibility management or in other words: the integration of these new users of the power system into power markets, scheme s for balancing and protection, etc. 10

146 EU-wide uniform implementation of flexibility management An EU-wide uniform implementation of flexibility management (one EU wide flexibility market) urgently requires well defined mechanisms. The realization of the EU 20/20/20 objectives drive towards large scale integration of DER in the grid and energy system, and subsequently large scale DER integration in the grid drives towards the need of managing flexibility. In addition to the existing, further regulation, standards and interoperability profiles are urgently required to support the mechanisms for demand side flexibility management. 4.3 Scope and purpose of this document Flexibility management covers the Flexibility Concept and Traffic Light Concept which are analyzed in [SG- CG/E]. This annex builds on this work and complements it with the work from [SG-CG/C] on Smart Grid architectures and recent developments on this subject from leading European institutions and research efforts. Moreover it is the aim to in the remaining timeframe of the Methodology and New Applications Work Group further develop standardization recommendation as well as recommendations to organizational / regulatory issues identified from this work. Based on the analysis of the use cases received during the collection period in the previous iteration of M/490 and the subsequent development of the generic use cases (see [SG-CG/E]) it was decided to introduce clusters of use cases by means of conceptual descriptions. This annex provides an overview and background to the main concepts related to flexibility management. It also provides first suggestions for functional architectures that are required to detail the generic use cases. 4.4 Structure of this document Flexibility management in this annex is considered to cover a range of methods and practices to leverage the flexibility of demand, DER, storage, etc. in order to optimize the efficiency of the power system, integrate renewables, etc. Section 5 further elaborates on where flexibility originates from and how it is provided. Section 6 further details the areas of application of the flexibility provided, i.e. what usages it has. In relation to conceptual model introduced in [SG-CG/F][SG-CG/J], the flows of flexibility considered are illustrated in Figure 2. This figure shows how grid users provide flexibility with their flexible production, storage and consumption units. Section 7 provides analysis of how the use of flexibility can be organized / implemented in market structures. 11

147 Figure 2: Flow of Flexibility plotted on Conceptual Model from Providing to Using Flexibility Finally section 8 provides recommendations on an architecture level and section 9 gives recommendations pertaining to the standardization of flexibility management as well as related regulation Flexibility in demand and supply in Smart Grids 5.1 What is flexibility? The flexibility in demand and supply in the context of Smart Grids considered in this annex covers the changes in consumption/injection of electrical power from/to the power system from their current/normal patterns in response to certain signals, either voluntarily or mandatory. This follows the definition of active demand response from [THINK], but is extended to 1) also cover flexibility from e.g. distributed generators and 2) to include cases where providing a response is mandatory. 5.2 Providers of Flexibility As introduced in section 5, traditionally, the providers of flexibility in the power system are the centralized power plants. They ramp up or down their generation, following demand. With the decentralization of generation, introduction of renewable power sources, and new loads being integrated into the power system (e.g. heat pumps, electric vehicles), there is a need to source flexibility from elsewhere. 12

148 Flexibility can be sourced from a range of generators, storage and demand. Both on supply as on demand side, flexibility can be provided. On the demand side flexibility is provided by industrial, business and residential customers, directly or via a flexibility operator/ aggregation service provider (for residential customers). This flexibility can be characterized according to Figure 3. This figure shows a progression in the extent to which an energy resource can be controlled. It is an adaption of a figure in [THINK] to extend it to cover also generation and with freely controllable equipment (e.g. distributed generators with the main purpose of generating electricity which aren t bounded by other processes). Controllable with bounds Non-buffered Non-shiftable Non-curtailable Uncontrollable Curtailable Shiftable Buffered Freely controllable Figure 3: Categorization of Flexibility Sources (adopted from [THINK]) How is it provided? Flexibility management covers a variety of mechanisms as is shown in Figure 4. It ranges from direct control of resources to price reactions. Flexibility management encompasses at least: Demand Response (DR), Demand Side Management (DSM) and explicit provisioning of flexibility to the market. In the following section, some definitions around providing and using flexibility management are formulated. For more details, please refer to the literature listed in the section 1. Smart Grid Connection Point Control Signals Price Signals, Tariffs, Incentives Flexibility Offers Information: status, forecasts, metering,... Using Flexibility Providing Flexibility Grid Users Production, storage and consumption Figure 4: Interactions to provide / address flexibility of grid users The concepts described in these definitions are elements of flexibility management where both the grid/market and the customer can take the initiative to use or offer flexible demand, generation or storage. See also section 6 which indicates how these signals relate to the parties interacted with and section 8.2 for further details on the concept of the Smart Grid Connection Point. 13

149 Demand Side Management As defined by [EURELECTRIC]: Demand Side Management (DSM) or Load Management has been used by the [mainly still vertically integrated as opposed to unbundled] power industry over the last thirty years with the aim to reduce energy consumption and improve overall electricity usage efficiency through the implementation of policies and methods that control electricity demand. Demand Side Management (DSM) is usually a task for power companies / utilities to reduce or remove peak load, hence defer the installations of new capacities and distribution facilities. The commonly used methods by utilities for demand side management are: combination of high efficiency generation units, peak-load shaving, load shifting, and operating practices facilitating efficient usage of electricity, etc. DSM is therefore characterized by a topdown approach: the utility decides to implement measures on the demand side to increase its efficiency Demand Response As defined in [THINK]: Changes in electric usage implemented directly or indirectly by end-use customers/prosumers from their current/normal consumption/injection patterns in response to certain signals. As defined in [EURELECTRIC] Demand Response (DR), on the contrary, implies a bottom-up approach: customers becomes active in managing their consumption in order to achieve efficiency gains and thus reap monetary/economic benefits. Demand Response (DR) can be defined as the changes in electric usage by end-use customers from their normal consumption patterns in response to changes in the price of electricity over time. Further, DR can be also defined as the incentive payments designed to induce lower electricity use at times of high wholesale market prices or when system reliability is jeopardized. DR includes all intentional modifications to consumption patterns of electricity of end use customers that are intended to alter the timing, level of instantaneous demand, or the total electricity consumption. DR aims to reduce electricity consumption in times of high energy cost or network constraints by allowing customers to respond to price or quantity signals Explicit provisioning of flexibility to the market As defined in [MIRABEL]: The flexibility [offering] concept assumes that parties connected to the grid produce offerings of flexibility in load and (distributed) generation. Thereby, so-called flex-offers are issued indicating these power profile flexibilities, e.g. shifting in time or changing the energy amount. In the flex-offer approach, consumers and producers directly specify their demand and supply power profile flexibility in a finegrained manner (household and SME 1 level). Flex-offers are dynamically scheduled in near real-time, e.g. in case when the energy production from renewable energy sources, such as wind turbines, deviates from the forecasted production of the energy system. 6 Flexibility Management Applications Areas 6.1 Introduction The areas in which flexibility management can be applied or in other words the use of flexible resources can occur over different time horizons (from milliseconds to years). This is shown in Figure 5. 1 Small and Medium-sized Enterprise 14

150 Figure 5: Use of flexibility on different time scales (Source: based on use cases from Energinet.dk and [SG-CG/E]) The sections below provide an overview of these areas. 6.2 How flexibility is used The application areas where flexibility in supply and demand provide value can roughly be divided into two main clusters of use cases: use of flexible demand, storage and generation in commercial and technical use cases; see also Figure 6. The technical use cases can be further subdivided into use cases related to system and grid operations Figure 6: Application areas of flexible demand, storage and generation These application areas are further detailed below System operations The application area of system operations concerns the use of flexibility in order to ensure stable operation of the power system as a whole; i.e. on the level of entire grids or market balance / control areas. The applications identified are: 15

151 System balancing ensuring frequency stability, preventing deviation between measured and scheduled inter-control-area power exchange, etc. System restoration and black start using flexibility in energy resources for orderly restoration of the power system after e.g. a black out Grid Operations Grid operations is an area where flexibility allows for local optimizations in power grids. The applications identified are: Local network constraint management ensuring grid capacity isn t exceeded (on different voltage levels) and that voltages remain within the statutory limits. Voltage / VAr optimization optimization of voltage profiles and power flows; see also use case WGSP-0200 from [SG-CG/E]. Network restoration using flexibility in energy resources for orderly restoration Power flow stabilization reducing the variation in power flow across (network) assets to increase asset lifetime Energy Trade In the area of trade in energy as a commodity, flexibility can be used to optimize trading portfolios and reduce balancing cost resulting from deviations between scheduled and actual inflow/off-take. Market / portfolio balancing reducing the difference between scheduled and measured/actual inflow/off-take of market participants. Energy market participation participation of any (aggregated) flexible resources in energy markets (on time scales varying from e.g. minute-ahead to day-ahead). 6.3 Use cases In this section, a number of the use cases offered by stakeholders market and/or grid s use of flexibility will be explored in more detail. It must be noted that further developments and harmonization is required in this area in relation to new, emerging market models. Nevertheless, the following use cases have been provided as a base to start from and encase consideration of the standardization effort required in order to support emerging future market models. The intension of this section is not to artificially limit the range of such models and the possible solutions within them. In general it may be differentiated between two major blocks on the grid and market side: 16

152 Figure 7:Commercial and technical flexibility use cases in the grid and market area Technical use cases The primary task of these use cases is to stabilize the grid in the given limits for power quality. The following key actions are suggested under these use cases, reflecting different sections within the discussed Traffic Light Concept (refer to chapter 8.6). Use Cases: 1. The Distribution System Operator (DSO) sends a control request for stability reasons (e.g. emergency signals, load shedding, need for reactive power, requesting more or less generation). 2. DSO receives information from e.g. the Smart Meter with 3 information regarding power quality, outage, etc. 3. DSO providing e.g. a correction (price, control) for market price signals in case of local grid overload (congestion management). 4. Or in case of emergency the DSO sends direct command signal according to legislation or contractual situation. 5. The DSO is the actor / market role for the technical use cases within the operation block. 6. Those technical demand response control functions might be used by other high level use cases like Microgrids (MG) or Volt/VAr Optimization (VVO), please refer to the respective generic use cases. 2 Generic use cases (e.g. DR/DSM) are providing flexibility and offer the basic functionality for both, technical and commercial flexibility. There will be "higher level" use cases dedicated to either technical or commercial. 3 Discussions, if the information must be anonymous due to privacy considerations or if e.g. local geographical information are required. 17

153 Commercial use cases It is worth emphasizing that the general premise employed here is that the application of commercial flexibility use cases can be differentiated. The general instances in which commercial flexibility use cases are likely to be relevant to include: Energy and balancing power Selling, buying, trading energy (whole sale markets) based on prices in a liberalized market environment Balancing (after market closure) Existing or new markets Existing energy markets: several use cases suggest the use of additional flexibility which has to be gathered in order to participate in existing markets (primary, secondary, tertiary markets, intra-day, day-ahead ) New markets are suggested for real time corrections, e.g. within a balancing area Market Implementation Considerations 7.1 Introduction Sections 5 and 6 above provide conceptualizations of flexibility management how flexibility in demand, generation and storage can be provided and used. This section provides an overview of considerations pertaining to implementing these concepts into market structures. This has to be taken into account in standardization of flexibility management techniques. 7.2 Roles, rights, expectations and responsibilities: Parties connected to the grid (e.g. consumers) In order to enable an affordable future energy system, demand side participation is essential for success. Customer/ parties connected to the grid need to be empowered and rewarded for delivering flexibility. They will have the right to sell their flexibility in all markets. However this should lead to product definition of flexibility with a guaranteed firmness, which will be required by the system operation for balancing purposes and by the DSO for grid constraints management purposes 4. In order to become a recognized market participant, the parties connected to the grid will also require additional information and information exchange from market parties and DSO s. This information exchange should be implemented via standards. 7.3 Roles and responsibilities: Flexibility Operator In this section the flexibility operator will be explored, with relevant potential use cases noted which might interact with a range of possible market models. It should be emphasized that potential market models and regulation continue to be developed in this area, and it is not the role of standardization to define these. In particular the output from the European Commission s Smart Grid Task Force Expert Group 3 (EG3) is likely to have an important impact on the emerging regulation, use cases or standards relating to the role of the flexibility operator. Therefore, use cases should be revisited, iterated and updated as the output from this group with respect a market model for Smart Grids is finalized. 4 Based on EG3 report on flexibility, chapter 1. 18

154 The role of the flexibility operator is a bundled role that pools the small flexibilities of customers / network users (e.g. from CEMs) in order to make use of them in the grid or on energy markets Figure 8:Flexibility operator gathering flexibilities from different customers and sells them to the end-users of flexibility (grid / system operators, commercial entities, etc.) The concept of the flexibility operator, often referred to as aggregator, seems to be widely accepted, although the name and its detailed tasks are varying. Its basic responsibility is to act as an intermediary between a supplier of flexibility (e.g. Producer or Consumer) and a user of flexibility (e.g. Grid Operator). This responsibility might be carried out by existing bundled roles in the energy market, like energy suppliers with variable prices, aggregators, Virtual Power Plant (VPP), energy servicing company, agent, etc. 2 types of flexibility operators can be defined: A flexibility operator with (own) BRP responsibility A flexibility operator without own BRP responsibility The importance of the balance responsibility role of the energy system is well understood, as it plays a crucial role in maintaining system stability and security of supply. The introduction of customers as market participants, possibly represented by aggregators operating the customers flexibility, should not jeopardize this. Therefore it will be essential that customer related metering data, which is delivered to existing and new market parties, uniquely corresponds with data required by the balance responsibility roles in the market (no gaps or overlaps). This may lead to further differentiation in measuring metering data. It is worth emphasizing that the flexibility operator defines their own optimization strategy making use of the flexibilities offered to them on the one hand and on the other hand participating in new or existing balancing power markets and energy services on the other hand. As such different levels / strategies of the flexibility concept can be considered. 19

155 Architecture Recommendations 8.1 Introduction The previous sections conceptualize the flexibility management scope. This section reiterates a number of concepts and recommendations on this conceptualization as expressed in [SG-CG/E]. This section is intended as an indication of the status quo and a stepping-stone for further work in this area. 8.2 Smart Grid Connection Point (SGCP) In this conceptual model, the Smart Grid Connection Point (SGCP) defines the physical and logical borderline / interface from the customer to the network/market or from the network/market to the customer considering small scale generation, storage or demand. The SGCP can be implemented by one or more separate interfaces (e.g. Smart Metering Gateway to an external actor). The SGCP can be used as an abstraction that will help to reduce the complexity in the description of the interactions between different "domains" such as grid/market and "resources" in a general meaning (DER or customer premise) or between providing flexibility and using flexibility. The different physical or informational "flows" that pass through the SGCP depend on the services defined between market/grid and the customer. In that respect the SGCP can be regarded also as service access points of the services delivered on the SGCP. The definition of these are dependent on different functionalities, which should be standardized taking into account as far as possible that there might be different regulations as well as market models as defined by the respective authorities for these functionalities. In the following the flexibility concept concentrates on the generic functionalities for this interface based on use cases that were received in the use case selection period and consequent discussions in the SG-CG. For a flexibility operator or a balancing responsible party (BRP), the demand or generation flexibility of the SGCP just represents positive or negative control power. In order to define these flexibilities, the supported use cases at a specific SGCP can be used within an auto registration process (refer to chapter 8.4). 8.3 Flexibility functional architecture Most use cases are describing the DR/DSM together with automation functions on the customer side, here called the Customer Energy Manager or CEM. Through the work undertaken here it appears that a fairly harmonized view on a functional architecture in the evaluated use cases is evident. The picture below represents a possible generic functional architecture example for the flexibility use cases. Here, the CEM provides the flexibility of connected smart devices, through the energy management gateway, while the smart meter and the simple external consumer display provide a number of functionalities that are described in more details in work of the Smart Meters Coordination Group (SM-CG). The energy management gateway communicates with the metering channel and the smart metering through the Smart Metering Gateway. The gateways in this architecture split different networks (Wide Area Network, Neighborhood Area Network and Local Area Network) and may be, as further described below, integrated with other functional entities. 20

156 Energy management / Providing flexibility (M/490) Actor A Energy management gateway (EMG) CEM Smart device* Grid/market communication Smart Grid Connection Point Actor B MDM HES NNAP Smart metering gateway (LNAP ) Smart meter functionality Simple external consumer display Metering channel M/441 architecture e.g. HBES device, smart appliances, storage, generator, domestic charger for EV, complex display Actor A and Actor B can be understood as backend system Figure 9: Flexibility functional architecture Note that the actors in the above architecture are functional / logical entities, which means that some of them may be part of the same physical device (e.g. CEM functionality may be part of a smart device, the smart meter might also encompass the smart metering gateway and CEM, etc.). Note that the communication path between the smart metering gateway and energy management gateway is optional (as are all communication path is in this architecture). In the aforementioned case, the information exchange between the metering channel and energy management channel will take place between Actor A and Actor B. The external actors A and B, identified in this functional architecture represent (bundle of) roles that communicate through the Smart Grid Connection Point. Examples of these roles are a meter data collector, meter operator, aggregator, supplier, flexibility operator, etc. The actual role of actor A or B depends on the local market organization in a member state and competition. In the scope of this report, actor A is defined as the external actor communicating with the energy management gateway while actor B is defined as the external actor communicating with the smart metering gateway. Functionalities of Head End System (HES), Neighborhood Network Access Point (NNAP), Local Network Access Point (LNAP), smart metering and the simple external consumer display are described in more details in the functional metering reference architecture according to SM-CG [CEN-CLC-ETSI TR 50572:2011]. The communication in the metering channel (going via Meter Data Management (MDM), HES and NNAP) is not described in detail in the use cases of the flexibility cluster since, in these use cases, their function is to pass through the information sent between smart metering gateway and actor B. Although the NNAP and LNAP can include intelligence to locally and independently implemented Smart Grid services and applications, their service in the current flexibility use cases is to pass through the information. This functional architecture can be mapped in the following way on the Smart Grid Architecture Model (SGAM) as defined in [SG-CG/C] Phase 1, [SG-CG/K] [SG-CG/F] Phase 2. 21

157 Smart Grid Architecture Model (SGAM) * e.g. HBES device, smart appliances, storage, generator, domestic charger for EV, complex display M/441 architecture Actor B MDM HES NNAP Smart metering gateway (SMG) Smart meter functionality Simple ext.cons. display Grid/Market communication Actor A Energy management gateway (EMG) CEM Smart device* Energy management / Providing flexibility (M/490) Smart Grid Connection Point Process Field Station Operation Enterprise Market Generation Transm. Distribution DER Customer Premise Figure 10: Mapping of flexibility functional architecture on SGAM 8.4 Auto registration of participating devices and customers Auto registration CEM to flexibility operator Subsequently the suggestion of the Smart Grid connection point which is defined by criteria and as it is expected that there are millions of these SGCPs, several use cases suggest that there should be an automatic registration procedure and partly a kind of plug & play functionality for the technical registration and connection of all smart customers to their flexibility operators or other relevant market roles like DSO, energy supplier or energy services companies. New Smart Grid market roles like an aggregator, which collects small energy flexibilities, need low transaction costs in order to achieve a valid business case. Use cases and standardization with automatic functionalities like auto-registration are a possibility for lowering these transaction costs (e.g. by reducing the engineering connection effort). Similar to other ICT systems (e.g. registration of DSL connection) with auto registration, the CEM will provide and receive information to/from Grid / Market. This information may include supported functionalities given the related contracts or technological possibilities (e.g. load shifting, reduction of generation or provision of reactive power). Further information exchange during auto registration may include: contract details (legal/billing relevance), power ratings, available status information, geographical information, security information like credentials and authentication, time synchronization and others. Relevant contract details are to be dealt with in advance of auto registration. 22