D7.2 ICT Requirements specifications v3 - CORDIScordis.europa.eu/.../5/.../001-D72ICTRequirementsspecificationsv30.pdf · EUTC, FIR, ORANGE, GRENOBLE INP, IBE, SWP, SYNELIXIS, TID,

FINSENY D7.2 ICT Requirements specifications v3.0

Page 1 (335)

FI.ICT-2011-285135 FINSENY

D.7.2 v3.0 Final ICT Requirements specifications

Contractual Date of Delivery to the CEC: Month 15 (29.06.2012)

Actual Date of Delivery to the CEC: Month 17 (23.08.2012)

Author(s): Martin N. Wagner Neumann

Participant(s): ATOS, NSNG, SIEMENS, BAUM, EDF, ESB, ENG, EON, EAB, EDD, EUTC, FIR, ORANGE, GRENOBLE INP, IBE, SWP, SYNELIXIS, TID, VTT, TSSG

Work package: WP 7: Consolidation

Estimated person months: 20

Security: PU = Public

Nature: R (R = Report, P = Prototype, D = Demonstrator, O = Other)

Version: 3.0

Total number of pages: 335

Abstract: The aim of the project FINSENY is to evaluate advanced smart energy scenarios and use cases in five different areas of the smart energy landscape (Distribution Networks, Microgrids, smart buildings, electric mobility and electronic marketplace for energy). The latter scenarios have to use extensively the generic enablers that will be implemented by the Future Internet Core Platform (FIWARE project), in order to plan for attractive pilots.

The first step was the specification of the scenarios and use cases which has been implemented in the dedicated Work packages (WP2-WP6). The second step was the identification of the ICT requirements described in Internal Reports by WP2-WP6.

This deliverable documents the overall ICT Requirements specifications once the final set of consolidated ICT requirements was finished. For the final consolidation the FI-PPP AB requirement templates and methodology was followed. Once finished the final version of the ICT requirements will be updated, inserted and/or refined at the FusionForge site of FIWARE and discussed in the AB.

The introduction of D7.2 documents the changes between the first and the final consolidated requirements from FINSENY.

FINSENY D7.2 ICT Requirements specifications v3.0

Page 2 (335)

Keyword list:

FI-PPP, FINSENY, Future Internet, FI-WARE, Smart Energy Grid (SEG), Distribution Network, Use Case, ICT Requirements, Functional ICT Architecture, Microgrid, Smart Buildings, Electrical Vehicles, Electronic Marketplace for energy

Disclaimer: Not applicable.

FINSENY D7.2 ICT Requirements specifications

Page 3 (335)

Executive Summary Future Internet technologies will play a critical role in the development of Smart Energy infrastructures by enabling new functionality while reducing costs. And these new features are the result of the analysis of scenarios and requirements that support them; therefore one of the most relevant objectives for the FINSENY project is to identify, describe, consolidate and share the ICT requirements of Smart Energy Systems from the view point of the use of the Future Internet core platform services and infrastructure that is being designed in the FI-WARE project, activities that are consolidated by WP 7 – Consolidation. The objective for the WP7 – Consolidation is the collection of the results from the scenario work packages (WP 2- 6), the consolidation of the ICT requirements and trial candidates and the organization of the interaction with the other FI-PPP use case projects, FI-WARE as well as INFINITY. Consequently, the activities performed until now in order to document the ICT requirements available in this deliverable can be summarized as follows: • 1st Step: Specification of the FINSENY scenarios and Use Cases performed by WP2 to WP6.

• 2nd Step: Derive and Specify the ICT Requirements related to the Use Cases and describe them as Internal Reports for the WP7.

• 3rd Step: Consolidate the ICT Requirements and send them to the Architecture Board.

• 4th Step: Develop ICT architecture based on common and domain specific enablers; identify final set of ICT requirements for the FINSENY scenarios performed by WP2 to WP6.

• 5th Step: Final consolidation of the ICT Requirements and update the back-log entries in the FI-PPP tools.

• 6th Step: Separation of generic and specific ICT Requirements to upload only new generic ICT Requirements to the AB.

• 7th Step: Development of D7.2 – ICT Requirements specifications and identification of Domain Specific Enablers (DSE) candidates to report them to WP8.

The current version of the document (D7.2), completed the consolidation (e.g. filters, eliminates duplicates, improves descriptions, etc.) of requirements produced individually in Work Packages 2 to 6 focused in the specifications of the ICT requirements. The document is composed of the following sections: • Summary of the methodology and templates used during the process.

• Summary Section for the Use Cases identified by WPs 2 to 6.

• Templates (filled) used to consolidate and report the final version of the


Page 4 (335)

Summary of ICT Requirements Specifications

• Templates (filled) used to consolidate and report the final version of the Annex I – Detailed ICT Requirements Specifications.

It is important to highlight that during the first phase of the scenario specification, the latter were conceived from the viewpoint of the final users of each and every energy landscape areas handled in FINSENY (see below the WP short descriptions). Therefore the ICT requirements at the first stage capture only general aspects related to ICT already organized in different functional categories. For the second stage, the scenarios refined the requirements in order to decompose them in a way that incorporates the use of FI-WARE chapters and enablers. Therefore the initial requirements were elaborated in an iterative process, interacting with FI-WARE through the AB and using the FusionForge tool that has been released in September 2011. Furthermore, the second stage of consolidation includes the arrangement of the requirements as generic or specific to ensure upload and upgrade only generic ICT Requirements to the AB and report the specific ICT requirements to WP8 to finalize the development of the requirements to experiment and study the feasibility of them once grouped as Domain Specific Enablers (DSE). A short description of the WPs that contribute with the Use Cases and the ICT Requirements in this deliverable is: • WP2 defines the ICT solutions for reliable and efficient operation of future Smart Distribution

Networks taking into account large share of Decentralized Energy Resource services and flexibility of the grid.

• WP3 identifies the ICT solutions to efficiently monitor and control Microgrids and their interconnection to the overlay grid.

• WP4 addresses ICT solutions for intelligent energy management for buildings and the interfaces to relevant market players.

• WP5 considers the necessary ICT infrastructure to support large scale charging of plug-in electrical vehicles.

• WP6 studies ICT solutions for a future electronic market place for energy and the interfaces to the various market players.

The most relevant updates from D7.1 First set of ICT Requirements to the AB (M7) and D7.2 ICT Requirements specification (M16) are summarized as follows: • The description of the methodology is only a summary in D7.2

• The scenarios of the Use Case Work Packages (UC WPs) were summarized.

• Only Back Log template is used to consolidate and report the ICT requirements in D7.2

• ICT Requirements were organized and reported in different sections taking into account if they are generic or specific according to the scenario WPs.

• A summary of the Domain specific requirements (DSR) table identified and reported to WP8 was included in the document.


Page 5 (335)

Authors

Partner Name Phone / Fax / e-mail

ATOS ATOS Martin N. Wagner Phone: +34 91 214 8227 e-mail: martin.2.wagner@atosresearch .eu

NSN NSN Werner Mohr Phone: +49 172 8224826 e-mail: [email protected]

SIEMENS Kolja Eger Phone: +49 89 636 42215 e-mail: [email protected] Jürgen Götz Phone: +49 89 636 40733 e-mail: [email protected] Rainer Sauerwein Phone: +49 8152 4385 e-mail: [email protected]

ENG Massimiliano Nigrelli Phone: +39 328 8834988 Fax : +39 06 83074408 e-mail: [email protected]

FIR Jonas Fluhr Phone: +49 241 47705 508 e-mail: [email protected]

GRENOBLE INP Didier Boeda Phone: +33 (4) 76 82 63 61 e-mail: [email protected]

Thales Communications Lionel Besson Phone: +33 1 46 13 24 90 e-mail: Lionel [email protected]

TID Lionel Besson Phone: +34 914832756 Mobil : +34 639818789 e-mail: [email protected]

VTT Henryka Jormakka Phone: + 358 40 511 6275 Fax: +358 20 722 7028 e-mail: [email protected] Timo Kyntäjä Phone: +358 40 178 3487 e-mail: [email protected]


Page 6 (335)

Table of Contents

1. Glossary of Terms.................................. ..................................................... 9

2. Introduction ...................................... ........................................................... 9

3. Design principles ................................. ..................................................... 12

4. Overview of the FINSENY Methodology ............... ................................... 13

4.1 Methodology fundaments .......................................................................................................... 13 4.1.1 IntelliGrid Methodology for Developing Requirements for Energy Systems ................... 13

4.1.1.1 Objectives of this Specification ............................................................................. 13 4.1.1.2 Scope of the Specification ..................................................................................... 14

4.1.2 Recommendations for the Description and Management of Use Cases for Smart Grids .. 14 4.2 Management of ICT Requirements ........................................................................................... 15

4.2.1 Functional Requirements .................................................................................................. 15 4.2.2 Non-Functional Requirements .......................................................................................... 15 4.2.3 Prioritize ICT Requirements ............................................................................................. 16

4.3 Consolidation Criteria ............................................................................................................... 16 4.3.1 Categorize and Consolidation ICT Requirements ............................................................. 16

4.3.1.1 Categorization ........................................................................................................ 16 4.3.1.2 Consolidation ......................................................................................................... 16

4.3.2 CEN/CENELEC, ETSI: M/490, Smart Grid Coordination Group .................................... 17 4.3.2.1 Schema of the Reference Architecture ................................................................... 18 4.3.2.2 Business Layer ....................................................................................................... 20

4.3.3 Security ............................................................................................................................. 21 4.3.4 Specification of ICT Requirements ................................................................................... 21

5. Summary of 1st Interaction with FI-PPP AB ......... .................................. 23

5.1 Summary of WP2 to WP6 Use Cases ........................................................................................ 23 5.1.1 WP2 – Distribution Network ............................................................................................ 23 5.1.2 WP3 - Regional -/ Microgrid ............................................................................................ 23 5.1.3 WP4 – Smart Buildings ..................................................................................................... 24 5.1.4 WP5 – Electric Mobility ................................................................................................... 25 5.1.5 WP6 – Electronic Market Place for Energy ...................................................................... 26

5.2 Feedback from FI-PPP .............................................................................................................. 27 5.3 Summary of Feedback from FI-PPP .......................................................................................... 43

6. Summary of ICT Requirements Specifications ........ .............................. 44

6.1 Generic ICT Requirements ........................................................................................................ 45 6.2 Specific ICT Requirements ....................................................................................................... 85

7. Security Requirements ............................. .............................................. 102

8. Conclusions ....................................... ..................................................... 107

9. Terms and Abbreviations ........................... ............................................ 108

10. References ........................................ ....................................................... 110

11. Annex I – Detailed ICT Requirements Specifications .......................... 111

11.1 Platform related ICT Requirements ......................................................................................... 111 11.1.1 Business Layer ................................................................................................................ 111 11.1.2 Function Layer ................................................................................................................ 147 11.1.3 Information Layer ........................................................................................................... 193 11.1.4 Communication Layer ..................................................................................................... 212 11.1.5 Component Layer ............................................................................................................ 241

11.2 Domain Specific ICT Requirements ........................................................................................ 248


Page 7 (335)

11.2.1 Business Layer ................................................................................................................ 248 11.2.2 Function Layer ................................................................................................................ 255 11.2.3 Information Layer ........................................................................................................... 274 11.2.4 Communication Layer ..................................................................................................... 297 11.2.5 Component Layer ............................................................................................................ 304

12. Annex II – Detailed Security ICT Requirements ..... .............................. 306

13. Annex III - Summary of Specific ICT Requirements to WP8 ................ 319


Page 8 (335)

List of Figures Figure 1: FINSENY Work Packages .......................................................................................................... 11 Figure 2: Requirement elicitation Methodology in FINSENY ................................................................... 13 Figure 3: Smart Grid Coordination Group with its 4 Working Groups (WG) ............................................ 18 Figure 4: SGAM Representation Scheme................................................................................................... 20 Figure 5: Layers of SGAM framework (Source: draft report WG-RA) ..................................................... 21

Index of Tables Table 1: Current Status of ICT Requirements submitted to AB .............................................................. 42 Table 2: Status of ICT Requirements submitted to AB ............................................................................ 43 Table 3: ICT Requirements submitted by WP .......................................................................................... 43 Table 10: Specific ICT Requirements to WP8 ........................................................................................ 335


Page 9 (335)

1. Glossary of Terms The glossary of terms used in this deliverable can be found in the public document Glossary Terms v2.2.doc also available at http://www.fi-ppp-finseny.eu/. Specific terms and abbreviations used in this deliverable can be found in Chapter Terms and Abbreviations.

2. Introduction Deliverable D7.1 - First set of consolidated ICT requirements to the AB documents the methodology and templates used to consolidate the ICT Requirements compiled from the different scenarios and provided to the Architecture Board.

And Deliverable D7.2 – ICT requirements specifications documents the complete process focused on identification, consolidation, classification and report of the ICT requirements. Moreover, the objective for the deliverable is to document the specifications of relevant ICT Requirements provided by scenario WPs (2-6) by analysing and evaluating the ICT requirements described in the Internal Reports prepared by the Use Cases WPs and reports the results as an evolution of the first set of ICT.

To meet the objective for the deliverable D7.2 WP2 to WP7 performed the following activities executed sequentially:

• 1st Step: Specification of the FINSENY scenarios and Use Cases performed by WP2 to WP6. This step has identified in each of the Work packages 2 to 6, relevant scenarios in the Smart Energy domain that will make extensive use of the Future Internet. These scenarios were conceived from the smart energy landscape insights perspective, analysing the stakeholders and use cases that are relevant in the smart energy domain. The results are documented on the DX.1 deliverables of the above Work packages.

• 2nd Step: Derive and Specify the ICT Requirements related to the Use Cases and describe them as Internal Reports performed by WP2 to WP6. These Internal Reports gather the 1st set of ICT requirements gathered by the FINSENY project. The process is based on the previously specified scenarios and use cases that are presented in the project deliverables DX.1.

The Internal reports include an analysis of the defined Reference Scenarios and the outlaying Building Blocks were performed, producing different requirements that are categorized and described.

• 3rd Step: Consolidate the ICT Requirements and send them to the Architecture Board performed by WP7. Initially, The FINSENY Project developed its own template to register and manage the ICT Requirements, but as soon as the FI-PPP AB Backlog Template was available, the information was registered and consolidated working only with this template. The subsequent activities were directed to consolidate the ICT Requirements by grouping them first based on a division in two main categories:

o General and component requirements: contains mainly subcategories that are common to many ICT systems, e.g. interoperability, scalability, reliability, availability, physical media, future-proof system, and environmental requirements. To properly manage the sub-categories a categories layers list were prepared to group them.

o Functional and technical requirements: lists subcategories from more functional point of ICT systems: Performance, QoS, service orientation, management, usability, and security.

o Smart Grid Architecture Model (SGAM) layers: list of stages to classify the level of impact of the ICT requirements, these layers are: Function/Service, Information, Communication and Component Layers.

Finally, teams were identified to strengthen the requirements according to their characteristics and to finally integrate the results into a single template. This allowed the staff to meet the reporting needs for the ICT requirements defined by the AB.

• 4th Step: Final specifications of the FINSENY scenarios performed by WP2 to WP6.


Page 10 (335)

This Internal Reports collect the final version of the ICT requirements gathered by the scenario WPs. The process is based in a revision of the initial ICT requirements, the feedback received from the FI-PPP AB and the exhaustive analysis performed to develop of Use Cases for Trial Experimentation.

• 5th Step: Final consolidation of the ICT Requirements and update the back-log entries in the Architecture Board Tools. D7.2 - ICT requirements specifications. Once developed and analysed the Use Cases by Work Packages, more information was available to make more accuracy the identified ICT Requirements. This additional data were used to update the currently registered information in the Fusion Forge Tool of the FI-PPP AB and to register additional ICT requirements identified during the final consolidation.

• 6th Step: Separation of generic and specific ICT Requirements to upload only new ICT Requirements to the AB. Taking into account the lesson learned during the 1st consolidation process and need to identify those ICT Requirements that can be classified as domain specific requirements (DSR), UC WP’s reported the ICT Requirements with an initial organization in generic and specific.

The FINSENY partners agreed to only submit to consideration of the FI-PPP AB those ICT Requirements classified as generic to avoid additional workload when an ICT Requirement is known as specific to a FINSENY domain.

• 7th Step: Identification of Domain Specific Enablers (DSE) when possible and report them to WP8. Domain Specific Requirements (DSR) identified in the previous step were analysed and developed as Domain Specific Enablers (DSE) to support the work performed by WP8 to:

o Detail experimentation lab requirements o Study the feasibility of DSE o Define Trial Sites

The requirements themselves are documented in more detail in two separate Excel-Files; one for generic ICT Requirements and another for specific ICT Requirements, the generic ones were used to report the ICT Requirements to the Architecture Board.

Tools and templates are useful to support the requirements engineering process; therefore once the Architecture Board provides their template (called Backlog) to receive the ICT Requirements, all ICT Requirements were translated to the new template and all UC WP’s agreed to use it.

The consolidation process of the found requirements made obvious that many requirements can be derived from more than one use case and that it is crucial to find the right level of detail. Important questions were asked throughout the consolidation phase, the most relevant ones at this stage were those concerning particularity and generality of the recorded requirements. The most important task was to classify the requirements eliminating duplicates, inconsistencies and common related ICT areas in which the requirements could lie.

Work on this topic is just in the early stages and has to be continued.

In order to create generic and specific ICT enablers, the identified requirements, need to be broken down to a lower level of granularity and consolidation efforts need to be enforced. At the same time, new requirements might appear during future discussions.

Finally, a brief description of each WP will allow understanding more clearly the scope and complexity of the consolidation process carried out (see Figure 1: FINSENY Work Packages): • WP2 defines the ICT solutions for reliable and efficient operation of future Smart Distribution

Networks taking into account large share of Decentralized Energy Resource services and flexibility of the grid.

• WP3 identifies the ICT solutions to efficiently monitor and control Microgrids and their interconnection to the larger grid.

• WP4 addresses ICT solutions for intelligent energy management for buildings and the interfaces to relevant market players.

• WP5 considers the necessary ICT infrastructure to support large scale charging of plug-in electrical vehicles.

• WP6 studies ICT solutions for a future electronic market place for energy and the interfaces to the various market players.


Page 11 (335)

Figure 1: FINSENY Work Packages

The vertical Work Packages cover the five scenarios which gain most from the use of ICT in the future Smart Energy landscape. Each Work Package follows a similar methodology in building the specific scenarios from various building blocks (Use Cases) identifying prominent ICT requirements, describing possible solutions and subsequently scenario specific trial plans.

The transversal Work Packages deal with topics that are relevant for several or all scenarios consolidate the results from the different scenarios and provide the contact points to other projects: • WP1 is the instrument to ensure coherence of the technical, business and market related activities of

the project by providing the technology frame work for the scenarios, examining the research landscape, standardization, regulation and evaluating major cross-cutting topics (i.e. Security). It is also responsible for the dissemination and exploitation of the project results.

• WP7 consolidates the requirements from the scenarios and identifies the common enablers together with the technology platform and the other usage area projects. It will further select and describe the trials for the second phase based on the input from the vertical WPs and WP8. A continuous interaction with the vertical WPs will assure a coordinated approach and consistent functional ICT architectures. This will be organized by the Project Management Team (PMT) and the Technical Manager (TM).

• WP8 is in charge of the identification and definition of domain specific enablers and the demonstration of their feasibility towards large scale experimentation as planned in Phase 2. It will ensure that the domain specific enablers cover the requirements of all investigated scenarios which are not covered by any generic enablers.

• WP9 is responsible for the overall project management.

This final work is based on existing knowledge on the selected Building Blocks (Use Cases), the interaction with the definition of the Functional ICT architecture and the resulting ICT Requirements covers all ICT aspects of DNs as each building block is considered individually and for example aspects concerning the parallel processing of the building blocks were considered.

The ICT requirements were used for the definition of common and domain specific enablers within FI-WARE and FINSENY and it is expected that they are also contributed to the on-going European Smart Grid standardization activities (CEN/CENELEC/ETSI Smart Grid Coordination Group) for the definition of standardized functions and protocols for the Smart Grid.


Page 12 (335)

3. Design principles ICT requirements from UC WPs have been categorized in two groups, as described in the FINSENY white paper1, of ICT requirements which are design principles and performance requirements and a second group which contains functional requirements. The latter have been further detailed in this deliverable.

The prominent Smart Energy design principles which are listed hereafter will be used to guide the future systems: • Openness to new service providers and business models. • Flexibility to incorporate new customers (generation and consumption) as well as mobile loads. • Decentralisation of control to support distributed generation and consumption. • Introduction of autonomous energy cells (e.g. Microgrids, Smart Buildings). • Security and safety mechanisms on all customer, system and service levels. • Automation of critical control processes. • High reliability and availability of all systems and services. • Cost efficiency. They can be translated into design principles for supporting the future ICT infrastructures. A selective set of ICT and future internet design principles is: • Open (and standardised) Interfaces guarantee the compatibility and extensibility of the System.

• Simplicity limits system complexity and improves maintainability.

• Flexibility allows for adaptability and loosely coupled systems.

• Scalability ensures that the system continues to function under changes in e.g. volume or size without affecting its performance.

• Modularity promotes vertical encapsulation of functions.

• Maintainability and Upgradability lead to suitable manageable and sustainable designs.

• Security & Privacy by Design comprises the complete system development process.

• Support of Heterogeneity is a major design principle.

• Reasonable Dimensioning to optimise cost-efficiency without compromising overall performance.

• Robustness ensures systems to survive failures.

• Locality guides the design of self-healing and robust logical systems.

• Encapsulation/Isolation of faults supports the concept of Locality.

• Auto-configuration supports the concept of Plug & Play.

• Quality of Service (QoS) classes guarantees well-defined performance metrics.

• The Decentralisation of Control Structures supports scalability, performance and locality.

• The Decentralisation of Processing demands for distributed data storage and processing units, and may introduce hierarchies.

• End-to-end Connectivity ensures that a network provides a general transport service that is transparent to applications.

• The Networks of Networks principle supports the decomposition into a collection of autonomous networked sub-systems.

For example the following IR3.1 ICT requirements are design principles: • Scalability • R&A for the systems • R&A for the communications • Modularity of hardware devices • Modularity of software devices • … 1http://www.fi-ppp-finseny.eu/wp-

content/uploads/2012/05/FINSENY_VisionMissionStrategy_April_2012_newLogo.pdf


Page 13 (335)

4. Overview of the FINSENY Methodology The FINSENY Project developed its own methodology to extract and analyse the ICT Requirements from the Use Cases but the FINSENY Methodology has taken into account the many related documents but most important was IntelliGrid Methodology for Developing Requirements for Energy Systems with Recommendations for the Description and Management of Use Cases for Smart Grids as a document validator of the results to be achieved. Consequently the next two sections below summarize the foundations of these documents.

Figure 2: Requirement elicitation Methodology in FINSENY

4.1 Methodology fundaments

4.1.1 IntelliGrid Methodology for Developing Requirements for Energy Systems

4.1.1.1 Objectives of this Specification

As defined by the IEC, the scope of IEC TC8 is to “prepare and coordinate, in co-operation with other TC/SCs, the development of international standards and other deliverables with emphasis on overall system aspects of electricity supply systems and an acceptable balance between cost and quality for the users of electrical energy. Electricity supply system encompasses transmission and distribution networks and connected user installations (generators and loads) with their network interfaces.”

IEC TC8 is therefore developing this Publicly Available Specification (PAS) with the following objectives:

• To develop a standard methodology for determining and defining user requirements in a consistent and comprehensive manner. Standards often address only the technical issues that are included in technical specifications; however, it is just as vital to develop standards to assist users to clearly and comprehensively define their requirements.

• To clarify the distinction between “user requirements” (the “what” as needed by power system experts) and “technical specifications” (the “how” as technical descriptions of systems, applications, and information flows to meet the “what”). Currently this distinction is an “invisible line” so that often the “what” and the “how” are mixed together – with technology-oriented project engineers jumping directly to the “how” without fully exploring the “what” with the power system experts.

• To emphasize the critical need to determine all user requirements first, before any commitments are made on “how” to meet those requirements. Because automation and control systems are so complex and are becoming increasingly so, if all requirements are not clearly defined first, then the premature design of systems can block or seriously hinder meeting those requirements that were not initially recognized.

• To provide a means for testing the systems once implemented to ensure that the user requirements are truly met, regardless of what standards and technologies are ultimately incorporated by the vendors.


Page 14 (335)

4.1.1.2 Scope of the Specification

This Publicly Available Specification (PAS) defines a methodology for power system domain experts to determine and describe their user requirements for automation systems, based on their utility business needs. This methodology was originally developed as part of the IntelliGrid Architecture developed by the Electrical Power Research Institute (EPRI), as a means to implement the “IntelliGrid vision” of the automated, self-healing, and efficient power system of the future.

4.1.2 Recommendations for the Description and Management of Use Cases for Smart Grids Deutsche Kommission Elektrotechnik Elektronik Informationstechnik (DKE)

This document take into account the complexity of the smart grid especially because of the variety of actors and systems and details recommendations to develop use case descriptions that could be used to create a common understanding and for the development and identification of interfaces and data models. From the point of view of DKE, the identification of needs for standardization play a decisive role in addition to the objectives stated above.

In this context, use case descriptions are to be established for various target groups, such as companies in the energy industry, IT manufacturers, equipment manufacturers, standardization organizations, legislators, and companies from other sectors than the energy industry.

In order to master the challenges associated with the compilation and management of use cases, it is recommended that the process is structured by implementing of the following measures:

• Use of conventions: Guidelines, for example, of naming conventions and particular UML diagrams for the presentation of graphics.

• Limitation to the essentials: Avoidance of redundancies, for example, and reduction to relevant information only.

• Use of familiar/proven methods/approaches: Relying, for example, on familiar/proven modelling languages such as UML.

• Tool support: Use of software tools to reduce manual work, especially for quality and consistency assurance.

Requirements for technical process support

Additionally the document describes the method to assist the activities of use case identification, processing and by information technology to ensure rapid and consistent processing and demand-driven management and analysis facilities. A technical solution should therefore cover these functions of identification and processing, management and use.

• Functional requirements

The technical solution should enable recording of the text of the use cases, structured in accordance with the extended IEC/PAS 62559 [6] template. Apart from the text, integration of graphical representations (e.g. UML diagrams) at the locations provided in the template should also be possible.

• Non-functional requirements

Together with the requirements stated in the previous section, non-functional requirements which have an effect on the handling of the system and on its behaviour are also to be taken into account.

The support tool should be easy to use and intuitively understandable, and should only require a shallow learning curve, as the aim is to give as many people as possible the opportunity to contribute their ideas to the standardization work.

Furthermore, cultural and political requirements are to be taken into account; the Enterprise Architect tool, for example, is used for IEC standards 61968/61970, which makes it advisable to provide an export function to this tool or aim for an implementation using it. With regard to the contribution of the use cases to be compiled with the tool, multilingual support is also desirable as it could lead not only to greater use of the use cases compiled but also to a larger group of users for use case compilation and import.


Page 15 (335)

4.2 Management of ICT Requirements

A goal is a high-level objective that the Use Case under consideration should achieve. In turn, an ICT requirement is a description of a system service or constraint needed by a Use Case to achieve a goal. So, an ICT requirement specifies how a goal should be accomplished by a proposed system.

Besides the services and the quality restrictions that a system should provide, an ICT requirements also should include the application domain information and the organizational context where the system will be applied. From this point of view, we can identify three types of requirements: functional, non-functional and organizational requirements. It is important to distinguish the types of requirements since they have different characteristics and therefore, by means of this distinction, we can choose the adequate methods and techniques that should be used during ICT Requirements process.

The traditional approaches used in software development are driven by functional requirements and their focus is on achieving the desired functionality of the system. However, a broader view of software development is one that goes beyond the description of system functionalities, also including organizational and non-functional requirements in a requirements specification.

4.2.1 Functional Requirements Functional requirements (FRs) capture the intended behaviour of the system in terms of services, tasks or functions the system is required to perform. This kind of requirement is generally specified by means of inputs, processing, outputs, controls, exceptions and entities. The more common techniques for specifying functional requirements are: use cases, scenarios, data flow diagrams and state transition diagrams. Currently, use case is the most used practice to capture and represent functional requirements, especially in object-oriented software development.

A use case describes a set of interactions between actors and the system necessary to deliver the service that satisfies the user goal. It also includes possible alternative sequences that may satisfy the goal, as well as sequences that may lead to failure in completing the service because of exceptional behaviour, error handling, etc.

4.2.2 Non-Functional Requirements Non-functional requirements (NFRs) are requirements that impose restrictions on the product being developed (product requirements), on the development process (process requirements), or they specify external constrains that the product/process must meet (external requirements). These constraints usually narrow the choices for constructing a solution to the problem. The distinction between functional and non-functional requirements may cause confusion. Some NFRs characteristics are used to distinguish them from functional requirements: • NFRs are focused on how the software must perform something instead of focused on what the

software must do. • NFRs “cross-cut” software functionality. • NFRs express constraints or conditions that need to be satisfied by functional requirements and/or

design solutions. • Different from functional requirements that can fail or succeed, NFRs rarely can be completely met:

their satisfying is accomplished within acceptable limits. Most approaches to systematically deal with non-functional requirements focus on specific NFRs such as security and performance. In turn, the NFR Framework can be applied to a variety of non-functional requirements. In this approach, NFRs are treated as soft goals to be satisfied by means of operationalization’s (operations, data representations, architectural decisions, etc.).

Although non-functional requirements are crucial for system development success, they are seldom analysed and, even when they are considered, they are generally poorly documented:

1. They are often stated in requirements specifications just as abstract, vague and informal declarations such as: “the system should have good security, performance, confidentiality, usability”. This kind of declaration makes it difficult to analyse and to verify how to meet the non-functional requirement. Moreover, it may be ambiguous since different interpretations about the real meaning of the NFR are possible. For those reasons, we advocate that abstract declarations of NFRs need to be broken down into smaller components and then converted into operationalization’s that together contribute for achieving these NFRs.

2. Normally, non-functional requirements are not documented in a specific artefact. On the contrary, they are declared repeatedly in each functional artefact affected by them. This fact contradicts the


Page 16 (335)

separation of concerns principle and, consequently, the requirements comprehension, evolution and reuse are damaged.

4.2.3 Prioritize ICT Requirements In most cases, the Use Case Projects will be unable to implement all of the ICT requirements due to lack of time, resources, or developing changes in the goals of the project. Therefore, the purpose of this data is to prioritize the ICT requirements so that the FI-WARE can choose which ICT requirements are relevant and in what order. Thus, the categorization of the ICT Requirements is crucial for prioritization.

The available prioritization methods are flexible and can be as simple as unstructured deliberation between the Use Case WP but for the FI-PPP related projects the Architecture Board defines the prioritization values as follows:

• MUST - Features that absolutely have to be done are categorized as “Must”. If any of these features are not done, the project will be considered a failure.

• SHOULD - Features that are important to the success of the project, but are not absolute musts (they have a workaround or will not cause the project to fail) are categorized as “Should”.

• COULD - Features that are nice to have but are not core features are categorized as “Could”. • WON’T - Features that are not going to be implemented this time are marked as “Won’t”.

Therefore the FINSENY project decided to handle 2 different priorities, one related to the priority of the ICT Requirements to the project itself and the other one that will depends on the feedback to be received from FI-WARE project.

4.3 Consolidation Criteria

The previous section described the work done by the Use Case Work Packages to generate their use cases and the required ICT requirements to ensure the deployment of the Use Cases. Consequently, the next task was to consolidate these requirements in order to ensure a coherent vision of the needs of all use cases related to the project.

4.3.1 Categorize and Consolidation ICT Requirements

4.3.1.1 Categorization

Firstly, it is necessary to identify among the requirements their category, consequently an initial list of categories were suggested that had to be extended depending on the ICT requirements that were identified and documented. The result was a list of category values that includes values related to the perception of the UC about the scope of use case and technical requirements specifications.

The next step was to identify a structure of categories for grouping the categories defined by the UC. Consequently several methods were analysed and FINSENY decided to use the Scheme detailed in the Reference Architecture of the Smart Grid Coordination Group (see Figure 4: SGAM Representation Scheme). A specific section of this chapter is devoted to detail the Schema and the Category Layer used for categorization purposes.

Finally, the original categories were grouped according to Layer Categories.

4.3.1.2 Consolidation

The first step of the consolidation process for the ICT requirements was identifying those requirements that are common. A requirement is common if it was identified in more than one Use Case. For this purpose an analysis of the functional and non-functional descriptions and the original category of each of the requirements were performed.

The second step was to review the common ICT Requirements to identify overlapping or overriding of the requirements. The result was a list of requirements in terms of their impact on different use cases that allows cohesion in the description of the resulting requirements.

An additional purpose of this step was to classify the requirements as essential, non-essential, system level, software level, or as architectural constraints; therefore an initially assigned priority could be reconsidered and re-evaluated.


Page 17 (335)

But it should also be noted that consolidate requirements must use a common reference model that allows categorizing and grouping these requirements in order to ensure that they are consolidated according to the same levels of influence (layers).

Therefore, before starting the final ICT requirements consolidation process, an evaluation of the Open Source best practices and the Reference Architecture Working Group of the Smart Grid Coordination group were performed to define the relations related to classification and categorization process.

Taking into account the scope of this document, the following summarizes the activities and findings related to the Reference Architecture Working Group of the Smart Grid Coordination group.

4.3.2 CEN/CENELEC, ETSI: M/490, Smart Grid Coordination G roup The EU Standardisation Mandate M/490 2 or the “Standardisation Mandate to European Standardisation Organisations (ESO) to support European Smart Grid deployment” is part of the initiatives to archive the 20/20/20-goals set. In detail the goal are set to accomplish greenhouse gas emission of at least 20% compared to 1990, to provide at least 20% of the energy consumption from renewable energy resources and reduce primary energy use by 20% by higher energy efficiency. As a result of this effort the mandate’s scope focuses on the analysis of standards and their suitability for an “electricity network that can efficiently integrate the behaviour and actions of all users – generators, consumers and those that do both – in order to ensure economically efficient, sustainable power system with low losses and high levels of quality and security of supply and safety.” (Quote Mandate M/490) which describes a so called Smart Grid. Therefore standards, existing and yet to be created, are analysed for their consistency, interoperability and integration of current and future technologies including computer and communication technologies, electrical infrastructure while maintaining flexibility to cope with and integrate future developments. While the interface to building, industry, appliances and home automation are included, the standards in these objects are neither analysed nor included. The targets are summarized in three categories: 1. A technical reference architecture which reflects the necessary information and data flows between

domains and is flexible enough to integrate further systems and subsystems. 2. A set of consistent standards supporting the information exchange via communication protocols and

data models while integrating all users into the electric system and its operations. 3. Development of sustainable processes and collaborative tools supporting the interoperability, security

and privacy considerations. These should also support gap analysis and ensure future developments and updates of the two mentioned categories above.

Also important is the fact that the Smart Grid Coordination Group does not create or substitute existing Technical Committees (TC). The Groups role is not only to address the identified tasks but also implement management systems in which Smart Grid requirement can be implemented into the existing standardisation while maintaining interoperability and flexibility for future changes.

http://ec.europa.eu/energy/gas_electricity/smartgrids/doc/2011_03_01_mandate_m490_en.pdf


Page 18 (335)

Figure 3: Smart Grid Coordination Group with its 4 Working Groups (WG)

CEN/CENELEC/ETSI accepted the mandate and for analysis the Smart Grid Coordination Group (SG CG) was created based on the former Joint Working Group Smart Grid (JWG-SG) 3. This group created four groups separating the analysis into four main fields (Figure 1): 1. Working Group First Set of Standards (WG FSS) 2. Working Group Sustainable Processes (WG SP) 3. Working Group Reference Architecture (WG RA) 4. Working Group Information Security (WG IS) The reporting line is ensured by an interim and a second, final report to the EU Commission. Each of the Working Groups creates their own report while maintaining communication exchange with the other Working Groups. For FINSENY the work of the Smart Grid Coordination Group and its Working Groups is especially important as the standardisation aspects are widely covered: From the detailed review of the WG FSS and detailed listings of the concerned standards to the development of new standardisation tools like Use Cases up to the big picture of an overall reference architecture. The Reference Architecture Working Group of the Smart Grid Coordination group, jointly established by ETSI, CEN, and CENELEC in response to the M/490 mandate, has the goal to define the Technical Reference Architecture of Smart Grids, “a technical reference architecture which will represent the functional information data flows between the main domains and integrate much systems and subsystems architecture.” This reference architecture has been provided in March 2012 (Interim Report) and the final Technical Report by end of 2012. A conceptual model was ready by the end of 2011.

4.3.2.1 Schema of the Reference Architecture

The Reference Architecture Working Group discuss currently a proposal for a universal model for Smart Grid architectures – called at the moment Smart Grid Architecture Model (SGMA) – taking into account the following requirements:

• Being consistent with M490 conceptual model • Being able to represent the views of different stakeholders in an universal way • Providing an abstract view on Smart Grid specific structures (domains, scope, layers) • Being able to represent the current situation and map future concepts (migration)

3 ftp://ftp.cencenelec.eu/CENELEC/Smartgrid/SmartGridFinalReport.pdf


Page 19 (335)

• Shall be consistent with interoperability categories and with the OSI layer concept

The Smart Grid Architecture Model (SGAM) layers concept can be used as tool for validating smart grid use cases in respect to existing information and communication standards. It can be used for identifying gaps for those circumstances in that a use case is not able to cover all layers or if related components (required to fulfil intended services/functions of a use case) cannot be connected via appropriate physical, communication and information standards under consideration of functional / non-functional requirements. It can also be used to design new smart grid use cases, to study the distribution of functions and their impact on components, information and communication.

In order to validate that existing Smart Grid architectures that can be represented by SGAM layers, the Reference Architecture Working Group mapped it with the ETSI, IEC SG3 Mapping Chart and TC57 Architectures with the following results:

• All representations are similar, the TC57 representation is mostly a flattened version of the layered concept

• New representation concept adds level perspective • Most of IEC SG3 chart is mapped on Component Layer • Communication and Information Layers can be filled by specified standards • Applications in field, station should be specified • New representation concept adds domain perspective

The Function/Information/Communication/Component (FICC) Layers allows to represent existing smart grid architectures in a universal way by taking into account the current and future smart grid scenarios and also migration paths, therefore it ensures the validation of smart grid use cases in respect to standards’ support and integrates the outcome of the M490 WGs “Sustainable Processes”, “First set of standards” and “Security”. The SGAM schema is based upon a representation into 3 axes (see Figure 4: SGAM Representation Scheme):

1. Domains (i.e. generation, transmission, distribution, …) 2. Levels of scope (i.e. process, field, station, …) 3. The following 4 layers:

• Function Layer • Information Layer

• Communication Layer • Component Layer


Page 20 (335)

Figure 4: SGAM Representation Scheme

4.3.2.2 Business Layer

But the categorization of ICT Requirements requires taking into account an additional layer: the Business Layer. During the process of categorization and classification of ICT requirements was obvious that many of them could not be directly related to the four levels identified and described above. These requirements even though they had a technology component, represented not only technological needs, also detailing needs that can be considered business. Then the categorization of ICT Requirements requires taking into account an additional layer: the Business Layer (see: Figure 5: Layers of SGAM framework (Source: draft report WG-RA)).

The SOA Reference Architecture (SOA RA) recognizes the promise of SOA and the challenges in the past in the ability to change the business processes as market changes and therefore introduces a specific layer for business processes and flows. The layer is called the Business Process Layer and allows externalization of the business process flow in a separate layer in the architecture and thus has a better chance to rapidly change as the market condition changes.

The Business Process Layer covers process representation and composition, and provides building blocks for aggregating loosely-coupled services as a sequencing process aligned with business goals. Data flow and control flow are used to enable interactions between services and business processes. The interaction may exist within an enterprise or across multiple enterprises.

The Business Process Layer leverages the Function Layer to compose and choreograph services and to coordinate business processes to fulfil customer requirements.

In more detail, the Business Process Layer performs three-dimensional process-level handling: top-down, bottom-up, and horizontal. From the top-down direction, this layer provides facilities to decompose business requirements into tasks comprising activity flows, each being realized by existing business processes, services, and service components. From the bottom-up direction, the layer provides facilities to compose existing business processes, services, and service components into new business processes. From the horizontal direction, the layer provides services-oriented collaboration control between business processes, services, and service components.

Consequently the layer structure used for classification, categorization and consolidation proposes must not only be aligned with the SGAM framework but also must include the Business Layers too. Therefore the layers (Figure 5: Layers of SGAM framework (Source: draft report WG-RA) are defined as: • Business Layer: Represents the business process representation and composition, and provides

building blocks for aggregating loosely-coupled services as a sequencing process aligned with business goals. Data flow and control flow are used to enable interactions between services and business processes

• Function Layer: Represents logical functions or applications independent from physical implementations

• Information Layer : Represents information objects or data models required to fulfil functions and to be exchanged by communication

• Communication Layer: Represents protocols and mechanisms for the exchange of information between components

• Component Layer: Represents physical devices which host functions, information and communication means


Page 21 (335)

Generation

TransmissionDistribution

DERCustomerPremise

Process

Field

Station

Operation

Enterprise

Market

Domains

Zones

Component Layer

Communication Layer

Information Layer

Function Layer

ProtocolProtocol

Data ModelData Model

Outline of Usecase

Subfunctions

Business Layer

Business ObjectivesPolit. / Regulat.. Framework

InteroperabilityDimension

Figure 5: Layers of SGAM framework (Source: draft report WG-RA)

The SGAM framework is in alignment not only with the EU efforts in the Smart Grid context but also with the most relevant Reference Architectures available today. Moreover, these layers allow defining a category level that is consistent with the methodologies and the work done by different teams in a worldwide scope.

For FINSENY the Working Group Reference Architecture is especially relevant as the SGAM model is a guideline and methodology for the FINSENY Use Case analysis identifying the prominent functional Use Case building blocks and ICT enablers.

Additionally, the SGAM framework is used in FINSENY for classification and categorization to ensure a compressive and coherent consolidation of ICT Requirements.

4.3.3 Security IT Security Requirements describe functional and non-functional requirements that need to be satisfied in order to achieve the security attributes of an IT system. Security requirements can be formulated on different abstraction levels. At the highest abstraction level they basically just reflect security objectives.

Consequently, by including a Security Layer to manage security requirements the consolidation process is now able to accurately adapt itself to the current state of the practice of software and ICT requirements integration.

Therefore the Security Layer represents any ITC element (Function/Service, Information, Communication & Component) required to protect it from unauthorized access, use, disclosure, disruption, modification, perusal, inspection, recording or destruction.

4.3.4 Specification of ICT Requirements For the scope of the D7.2 ICT Requirements specifications a specification is defined as "a detailed description of needs to be satisfied by the development of external or internal resources". Its purpose is to present a clear, accurate and full description of the project needs and therefore enable propositions of solution to meet those needs.


Page 22 (335)

A good specification should:

• State the requirement specification completely, clearly, concisely, logically and unambiguously • Focus on outcomes not how they are to be met. • Contain enough information for potential developers to decide and cost the goods or services they will

offer. • Permit offered goods or services to be evaluated against defined criteria by examination, trial, test or

documentation. • State the criteria for acceptance by examination, trial, test or documentation. • Contain only the essential features or characteristics of the requirement. • Provide equal opportunity for all potential suppliers to offer a product or service which meets the

requirements and which may incorporate alternative technical solutions.

A good specification should not:

• Over-specify requirements • Contain features that directly or indirectly discriminate in favour of, or against, any supplier, product,

process or source

The final specifications of the requirements are developed in this document using the format defined by FI-PPP AB and called Back-Log template in order to ensure that the following information is included in the descriptions:

• Scope: Provides a context for the requirement within the project.

• Goal & Rationale: These are usually laid out point by point so it is very clear what the requirement needs to do.

• Inputs (only for Domain Specific Requirements): this field defines what inputs are needed by the system.

• Outputs (only for Domain Specific Requirements): Systems have to produce an output in one form or another. This section will describe the expected form of outputs.

• Processing requirements (only for Domain Specific Requirements): Between Input and Output there needs to be some processing going on. This part of the requirement specification describes the processing to be carried out.

• Important validation details.


Page 23 (335)

5. Summary of 1st Interaction with FI-PPP AB

5.1 Summary of WP2 to WP6 Use Cases

D7.1 First set of Consolidated ICT Requirements to AB delivered on October 2011 and available on the web portal of the FINSENY Project (http://www.fi-ppp-finseny.eu ) includes a detailed description of the WP2 to WP6 Use Cases. Therefore the following sections only include summarized information of the WP UCs.

5.1.1 WP2 – Distribution Network All smart grid solutions rely on the Distribution Network so this must be seen as a key enabler for any future improvement in efficiency, safety and sustainability of the energy supply. However, any improvement in the Distribution Network will be very expensive because its size is huge, including thousands of primary substations, hundreds of thousands of secondary substations, tens of millions of grid user connections in each European Country.

WP2 Use Case Summary

• Mobile Work Force Management (MWFM): It covers the ability for field crews to have access to work orders in the field. The main issue about this UC is to use pervasive means of communication options especially in case of disturbance of regular communication.

• Fault Location, Isolation and Service Restoration (FLIR) : This building block (UC) describes the procedures after a fault until the service is restored. It includes the identification of a fault, determining its location, isolating the faulty section and reconfiguring the grid to re-energize these sections as quickly as possible.

• MV DAC from utility control Centre (MVDAC) : Data Acquisition and Control of real and non-real time information of MV electrical network from the utility control Centre. The differences from the already deployed HV or VHV DAC are the size of the network (more than 100 times bigger) and the location of the controllable elements which are closest to the customers.

• SG Energy Control of Power Inverter (SGEC): This use case describes the interactions, mechanisms and the interfaces of power inverters in context of a smart grid. Power consumption from the grid as well as power infield into the grid is considered.

• Dynamic Control of Active Components (DCAC): This building block (UC) covers the dynamic control (performed automatically) of distributed active network components on substation level with the goal to ensure stable and energy efficient network operation.

5.1.2 WP3 - Regional -/ Microgrid The Microgrid scenario has been chosen as an important and visionary electricity grid scenario to analyse ICT requirements. Microgrids are essentially a substructure of the global grid and comprise local low-voltage and even medium-voltage distribution systems with distributed energy resources and storage devices in order to satisfy the demands of energy consumers. Such systems can be operated in a semi-autonomous way, if interconnected to the grid, or in an autonomous way (islanding mode), if disconnected from the main grid.

WP3 Use Case Summary • Business Use Cases

o Microgrid Operator sells and buys energy on the external markets o Microgrid Operator sells Balancing and Ancillary Services o Microgrid provides Islanding Mode

• Control & Management Use Cases

o Balancing supply and demand on different time-scales o Demand-side management o Supply-side management o Black Start in Islanding mode o Auto-configuration o Long-term Planning of Microgrid Infrastructure Design and Upgrading


Page 24 (335)

5.1.3 WP4 – Smart Buildings This Work Package aims to define the scope of the smart buildings domain, analysing different buildings typologies (smart homes, residential buildings, office buildings, data centres and hotels, also called scenarios in the context of this document) as holistic systems that encompass all the physical components of the building. For this analysis use cases were defined which deal with energy-related functions of the building which need the support of ICT systems. Use cases across the different scenarios defined share a set of common external actors, namely external and internal environment, organizations such as energy service companies or facility staff, and external entities such as electric utilities or the micro grid where the building might be inserted; while other actors are specific for each scenario.

WP4 Use Cases Summary • Home Domain Use Cases

o Display the global energy consumption and costs using data from Smart Meter and Metering Operator

o Display the global and per appliance energy consumption and costs, either realized and/or forecasted

o Warn the consumer if the available total power (in the home) is not sufficient to run a Smart Appliance

o Direct load control o Dynamic pricing of electricity o Emergency Load reduction o Handle dynamic power cap o Optimize energy in a home equipped with smart appliances and smart generation and storage

• Residential Buildings Use Cases

o Display Energy Consumption o Provide Emergency Lighting o Provide Graceful Elevator Shutdown o Store Electricity Locally o Store Hot Water Locally o Centrally Heat Water for Private Uses o Provide Communal Hot Water o Optimize Lighting o Optimize Indoor Climate Control

• Office / Public Building Use Cases

o Check energy use o Check acute alerts o Allow Real-time DR events in the service centre o Check DR period in the office room o Energy coaching o Check benchmarking in districts

• Data Centre Use Cases

o Optimize the data centre air conditioning o Optimize the free-cooling in the data centres o Optimize server power usage o Manages business continuity o Optimizes power workload maintaining a high quality of services (QoS) o Choose between multiple service classes in function of the workloads priority

• Hotel Use Cases

o Execute strategy o Define Energy KPIs o Monitor KPIs


Page 25 (335)

o Set Prices o Request load switch o Shed load o Generate energy locally o Store Energy o Request energy from the net

5.1.4 WP5 – Electric Mobility The introduction of electric vehicles (EV) will require major changes to be made in electricity networks, as predictions suggest that the charging of electric car batteries will be the biggest load on future networks. Meeting the new demands depends on the introduction of new ICT technology in both the energy grid and the vehicles as well as the connection of the vehicles to the grid in real time. The interaction of EV with the power grid and transport infrastructure needs new innovative services and comes along with significant functional and non-functional ICT requirements. These requirements are to be satisfied with generic and specific enabling technologies.

Therefore a typical set of building blocks for electric mobility should be defined, investigating the interests of a wide range of stakeholders and the likely evolution of their requirements in the coming years as market conditions evolve.

ICT Requirements were be derived from the building blocks that are required from Smart Grids to support the loads that electric vehicles will generate and to balance these loads with the generating ability of renewable energy sources. Additionally, requirements on business models enabling revenue sharing should be defined and detailed requirements for billing and charging systems and security and authentication systems should be compiled.

WP5 Use Cases Summary

• Use Case Short Trip: The short trip use cases reflect usage of EV for trips within a range of full battery (typically < 150km). The trip destinations are therefore “nearby”, e.g. the place of work, shopping places or places of leisure activities (typically workdays evening or the weekend).

• Charge Point Accessibility: Functions described herein are derived from 5 different mobility scenarios for medium-ranged distance (< 350 km) trips identified to be important for future electric mobility. All five scenarios are briefly described in the next section.

• Use Case Long Trip: The basic premises of the Long Trip use cases (ucLT) are that the owner/driver of an electric vehicle will:

o make long distance journey o need to recharge multiple times o encounter such roaming issues as availability of charge points and payment options

• Use Case Grid Operational: While energy suppliers (retailers) can benefit from an extension of their market, grid operators Denial of service (DoS) might be faced with serious problems as to overload situations with parallel charging processes of many electric vehicles (EV). In general terms, DSOs need controlled charge mechanisms). To support those mechanisms and to prevent harmful situations, DSOs might apply the following principles:

o Scenario A: prediction of charge loads – to prepare for stress situations o Scenario B: optimized charge scheduling – to charge EVs without exceeding the capacity of the

local power grid

• Use Case Value Added Services: This section also assumes that the following electro-mobility key enablers are all in-place and are embedded in national infrastructures. Building on this core set of key enablers, this section tries to identify a number of spin-off value added products and services. It is also assumed that electric vehicles can relatively easily be equipped with these new interactive features and services.


Page 26 (335)

Key enablers include:

o Future electric vehicles will have a high speed wireless internet connection so that the driver / user can receive information on charging stations.

o Future electric vehicles will have a smart device like an iOS, Android, Windows Mobile, QNX, TomTom, Garmin etc. so that the driver / user can visualise maps to closest charging points.

o Future electric vehicles will have embedded geo-location & GPS / Galileo technology so that the driver / user can dynamically plot routes to closest free charging points.

o Data roaming tariffs will be transparent across Europe and wider countries so that the driver / user can confidently move between states / countries.

o Energy roaming tariffs will be transparent across Europe and wider countries so that the driver / user can confidently move between states / countries.

5.1.5 WP6 – Electronic Market Place for Energy The high level scenario for an Electronic Market Place for Energy (eMarket4E) arises from the considerations related to evolution of the electricity market due to de-regulation and the transformation of the old electricity grid into a smart grid. In this perspective, a particular attention is for end consumers which now might also produce energy (so called “prosumer”) (e.g., by means of solar panels on the roofs of residential houses or micro-generation plants) and need to be integrated as active elements in the electricity grid.

Anyway, a large variety of actors take part to the Market Place, each having specific needs. In particular, the actors want to boost their business processes by primarily accomplish fruitful transactions. They will deal with various types of assets that can be found in the smart energy market: financial transactions, physical energy capacity commercialization, information services, etc.

The low level scenarios developed in the Electronic Market Place for Energy scenario are grouped together in three clusters (so called “business Cases”):

• Information and final user contracts about energy use - tackles the need of providing to the user the ability to get detailed information about his energy use via different means using the internet in a reliable way as well as to empower the final customer with tools to configure his electricity contract online.

• Demand Side Management include a scenario that shows how the final customer is able to get discounts on his electricity bill if he allows the grid users to send signals to his home or premise, in order to flat the Demand curve.

• Energy Trading that represents one of the fundamental pieces of the eMarket4E, it brings together the different actors (grid users, grid operators, providers and customers) of the energy value chain with a particular focus on the involvement of the final energy Customer and Prosumer that at the moment do not have Internet based eMarket4E services for trading.

WP6 Use Cases Summary

• Detailed Consumption Information • Transparency in the Green Market • Colour Ethical Bid • Energy Contract Brokering • Information about Energy Generation Sources: Being Green • Flatten Demand Curve • Incentive Based Green Market • Trading for the Good of All • Trading flexible capacity • Energy Markets for Neighbourhoods • Supplier Side Local trading


Page 27 (335)

5.2 Feedback from FI-PPP

Once registered the ICT requirements for their evaluation by the Architecture Board as generic or specific, WP7 and the Technical Team followed up the comments and suggestions issued by AB and reported them to the WPs with the aim to ensure maintain updated the requirements and to include the decisions in subsequent improvements of ICT Requirements in FINSENY. The following table contains a summary of the historical movement requirements associated FusionForge registered.

Fusion Forge Nro.

Name Submitted by

Status Assigned to

Prio- rity

Messages

326 FINSENY EPIC Data Bus

Microgrid FINSENY (FINSENY_wp3)

Needs revision by Issuer

Microgrid FINSENY (wp3)

3 Date: 2011-12-11 07:01 The Issuer needs to provide more detail in the description of the requested functionality Date: 2011-12-11 07:01 In particular, what he is required when referring to QoS

1100 FINSENY Theme Connectivity from FINSENY project

Distribution Network FINSENY (FINSENY_wp2)


Distribution Network FINSENY (wp2)

3 Date: 2012-05-18 16:45 Explanation missing!

1101 FINSENY EPIC Connectivity Infrastructure




3 Date: 2012-03-27 21:07 In the framework of I2ND, the work package concentrates on a controlled network operator environment. QoS will be supported in the framework of 3GPP System Architecture Evolution (http://en.wikipedia.org/wiki/System_Architecture_Evolution) especially the Evolved Packet Core (EPC) with a prototype implementation by Fraunhofer FOKUS – OpenEPC. Peer-to-peer applications will be supported as an Over-the-top application with restricted access to the network infrastructure – either as an overlay with no access or through currently defined APIs. A full access to the network infrastructure will not be given to third party providers or Over-the-top providers. It will be defined by contracts. We need more details. End-to-end QoS and SLA management is currently in the discussion with the ETICS project (https://www.ict-etics.eu/). Please check the latest deliverable of the architecture. Comments and requests are highly welcome. Date: 2012-03-27 21:07 In a very first review, the requested functionality will be covered by one or more Generic Enablers in FI-WARE. Nevertheless, the request will be further analysed by members of the FI-WARE team to confirm this initial response. This may require


Page 28 (335)

Fusion Forge Nro.

Name Submitted by

Status Assigned to

Prio- rity

Messages

further interaction with you so, please, stay tuned. Members of the FI-WARE development team will also double-check that there are Features entries in the FI-WARE Backlog that cover the requested functionality. Date: 2012-03-22 22:52 Hans, can you provide a comment to this requirement, possibly asking the Issuer to provide more details if necessary, thanks. BR (PG)

1102 FINSENY EPIC Connectivity Services




3 Date: 2012-03-26 14:52 additional comment: What you might request for can be seen as part of a service. In this case, the primary contact for a user is probably being a service provider, which then in turn will enable it using e.g. the S3C or the NetIC GE. Date: 2012-03-26 14:20 Not really clear what exactly is requested, please specify in more detail. Some info on what NetIC currently is planning to offer: a user of NetIC can request a path or a virtual network with certain QoS parameters (limitations and details depending on the NetIC instantiation and the underlying network). Once provided, the path or virtual network can be used, by the requesting user itself or other users connected to this path or virtual network. For more details on the preliminary architecture, please check https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.I2ND.NetIC. If you believe there are still specific features that need to be included in NetIC GE, please provide us further details on it by updating this ticket. Date: 2012-03-22 22:50 Klaus, can you provide a comment on the requirement, possibly asking for more details to the Issuer if necessary, thanks. BR (PG)

1103 FINSENY EPIC Connectivity QoS




3 Date: 2012-03-27 21:19 In the framework of I2ND, the work package concentrates on a controlled network operator environment. QoS can be negotiated on a certain level from services and applications which are based on sensor data, Telco and Web environment, and from Over-the-top service (in a restricted manor). Please check the latest deliverable of the architecture. Comments and requests are highly welcome. Date: 2012-03-27 21:19 In a very first review, the requested functionality will be covered by one or more Generic Enablers in FI-WARE. Nevertheless, the request will be further analysed by


Page 29 (335)

Fusion Forge Nro.

Name Submitted by

Status Assigned to

Prio- rity

Messages

members of the FI-WARE team to confirm this initial response. This may require further interaction with you so, please, stay tuned. Members of the FI-WARE development team will also double-check that there are Features entries in the FI-WARE Backlog that cover the requested functionality. Date: 2012-03-22 22:49 Hans, can you comment the requirement, possibly asking the Issuer to send more information if necessary, thanks. BR (PG)

1104 FINSENY EPIC Remote Upgrades

DSE FINSENY (FINSENY_wp8)

Under Evaluation by FI-WARE

Alex Glikson (glikson)

3 Date: 2012-05-16 12:37 Could someone from the Cloud chapter care about this request? Date: 2012-04-15 18:12 This ticket seems to be more cloud related; as Torsten have already advanced in previous comments Date: 2011-11-30 19:05 USDL will provide means to specify software update channels. However, it's a matter of the Cloud chapter to realize the upgrading. Date: 2011-11-30 19:05 The requested functionality has been evaluated and considered relevant. Therefore, a number of related Epics and Features will soon be added to the FI-WARE Backlog.

1106 FINSENY EPIC SLA Management Performance Management

E-Mobility FINSENY (FINSENY_wp5)


Kay Haensge (haensgekay)

3 Date: 2012-07-02 16:05NetIC expects requests which can be translated in measurable (e.g. used bandwidth on a link or flow) or settable (e.g. routing table entries, bandwidth reservations) parameters. Negotiation of SLAs and translation into the described requests is seen to be done by S3C. Date: 2012-06-08 12:58 Topic should be double checked by Net_IC and is forwarded to Net_IC. Date: 2012-04-02 15:43 Trying to understand what is the impact on Cloud... Please, provide more specific requirements in terms of KPIs and SLOs that need to be monitored and enforced. Date: 2012-01-17 21:09 Please set status.


Page 30 (335)

Fusion Forge Nro.

Name Submitted by

Status Assigned to

Prio- rity

Messages

1107 FINSENY Theme SLA Management

E-Mobility FINSENY (FINSENY_wp5)


Kay Haensge (haensgekay)

3 Date: 2012-07-02 16:07 NetIC expects requests which can be translated in measurable (e.g. used bandwidth on a link or flow) or settable (e.g. routing table entries, bandwidth reservations) parameters. Negotiation of SLAs and translation into the described requests is seen to be done by S3C. Date: 2012-06-08 13:00 Topic should be double checked by Net_IC and is forwarded to Net_IC. Date: 2012-04-02 15:41 From Cloud perspective, it is not clear what is meant by SLA. What are the specific SLOs that are required? Changing status to "Needs Revision by Issuer", before we can decide on impact on IaaS capabilities. Date: 2012-01-17 21:10 Please adapt status.

1108 FINSENY Theme Auto-configuration



Dénes Bisztray (bisztray)

3 Date: 2012-05-17 13:31 When the underlying EPICs are clarified, only then can I decide if the Theme as a whole is supported. Date: 2012-01-09 13:29 This theme includes currently the following epics: - 1109 Epic FINSENY.EPIC.Autoconfiguration.Addressing - 1110 Epic FINSENY.EPIC.Autoconfiguration.DeviceDescription - 1111 Epic FINSENY.EPIC.Autoconfiguration.RegistrationAndLookUp - 1112 Epic FINSENY.EPIC.Autoconfiguration.Discovery - 1113 Epic FINSENY.EPIC.Autoconfiguration.AccessControl - 1114 Epic FINSENY.EPIC.Autoconfiguration.MappingTool Hence, it is not only about registration at a registry but also about addressing, device description, discovery and look-up as well as secure and trusted access. Date: 2011-12-14 15:53 This is more like a requirement from the device then an actual feature request towards IoT SE. Basically we require the device to register itself towards the gateway or backend. Then it gets a name, and goes into the registry.


Page 31 (335)

Fusion Forge Nro.

Name Submitted by

Status Assigned to

Prio- rity

Messages

1109 FINSENY EPIC Auto-configuration Addressing


Accepted for inclusion in FI-WARE Backlog


3 Date: 2012-06-08 13:06 Feature should be already implemented in DNLA and UPNP. Please double check with the specification - http://www.dlna.org/consumer-home, http://www.upnp.org/ or contact the IoT-chapter. Date: 2012-02-06 17:00 The requested functionality has been evaluated and considered relevant. Therefore, a number of related Epics and Features will soon be added to the FI-WARE Backlog. Date: 2011-12-14 09:56 This should be supported however was not considered yet.

1110 FINSENY EPIC Auto-configuration Device Description




3 Date: 2012-05-17 11:13 The common information model for describing device capabilities is a goal of Fi-Ware as well. Currently, the candidates are XML-based. However we are not considering IEC 61970/61968 or SCL of IEC 61850-6. Can you please clarify if this ticket requests simply to have a common information model, or specifically those standards? Date: 2011-12-14 15:53 This is supported by Resource Management.

1111 FINSENY EPIC Auto-configuration Registration And Look Up


Already Covered by Baseline Asset


3 Date: 2012-05-17 11:25 This EPIC covers several areas. Fi-Ware IoT does not deal with the software on the devices which means the device manufacturer is responsible for sending the device capabilities to the IoT Gateway or Backend. So this part is out of scope. However, when these capabilities and control function descriptions arrive on the gateway or backend, they are stored and can be discovered by applications. Cumulocity from NSN definitely supports this scenario. Date: 2011-12-14 15:54 This should be covered by the Resource Management task.


Page 32 (335)

Fusion Forge Nro.

Name Submitted by

Status Assigned to

Prio- rity

Messages

1112 FINSENY EPIC Auto-configuration Discovery




3 Date: 2012-05-17 11:31 I would like to ask for some clarification. 1) The device connects to the network; however running "a discovery protocol where it advertises its services to control points" seems similar to EPIC.FINSENY.Autoconfiguration.RegistrationAndLookUp. What is the difference? 2) I'm not sure what exactly the control points are. I mean if they have a repository with the devices, then they don't need a discovery protocol to discover the devices already managed by them. Such a discovery protocol would be needed by the applications using these control points. Date: 2011-12-14 15:55 This is a generic discovery service. Thus it is supported by the Resource Management task.

1113 FINSENY EPIC Auto-configuration Access Control




3 Date: 2012-02-09 12:21 The requested functionality will be supported by FI-WARE and is already described in the FI-WARE Backlog. For more information you may visit the FI-WARE Product Vision and the concrete entries in the FI-WARE backlog referred in the comments linked to this ticket. In addition, please monitor progress of activities, particularly GE specifications, to confirm that all your needs are covered. Date: 2012-02-09 12:21 As we understand the requirement, the access rights component in IoT Data Handling (apply XACML policy rules) should fulfil the functionality Date: 2011-12-14 15:55 I wonder if the Data Access Policy supports this scenario. Which GE is responsible for this on the backend?

1114 FINSENY EPIC Auto-configuration Mapping Tool




3 Date: 2012-05-17 11:43 Just to clarify, this mapping tool what we are talking about is a tool for the engineering phase that helps creating protocol or data adapters for the IoT system? Date: 2012-03-13 15:38 Yes, I agree that "mapping tool should support the domain-expert during an engineering phase in harmonizing and aligning the different information models." To answer where this component/mechanism should be: I think, this is the interoperability issues for meta-data description and can be handled via a separate component that can include (semi-) automated mechanism or interface for manual mapping between different models and FI-Ware's base information model. Then, we can see it as a back-end component that are components can refer to it.


Page 33 (335)

Fusion Forge Nro.

Name Submitted by

Status Assigned to

Prio- rity

Messages

Date: 2012-01-09 14:04 Information models are highly domain-specific. Even in the smart energy domain we have to cope with different information models (e.g. IEC 61850 and IEC 61970 /CIM). These are based e.g. on XML schema or OWL. The mapping tool should support the domain-expert during an engineering phase in harmonizing and aligning the different information models. The tool should be easy to use requiring in the best case only limited knowledge on ontologies etc. Hence, looking at the comment from Payam it seems that we have the same understanding about the scope of this epic. Date: 2011-12-15 12:42 meant to write an interesting feature... Date: 2011-12-15 12:41 This is an interesting features; but reading the description it is not clear to me on what level the mapping is done; Interfaces? Data and meta-data descriptions? Or Protocol mapping in communications? I will take an assumption that Mapping tool will map different data and resource descriptions in this context. Currently in FI-Ware, IoT we have two or three main information models that are included in different assets. Those that are based on OGC SWE (e.g. SensorML) - serialized in XML format- and those that use IoT-A information model (i.e. IoT-A resource, entity and service models) and use RDF or OMA-NGSA based descriptions in other serializations. Now the question is if we can use a tool to provide this mapping? My understanding is that at the schema level this should be done manually by experts to see how different features than be mapped/related to each other - and maybe provide upper-level ontology to related them- Then how the tool can help us with this; does it provide automation? Or will provide an interface to make the process easier? In this respect, we need to clarify the role of this epic. Date: 2011-12-14 15:56 This is the semantic mediator as far as I understand, either in the backend or the gateway.


Page 34 (335)

Fusion Forge Nro.

Name Submitted by

Status Assigned to

Prio- rity

Messages

1115 FINSENY Epic Transactional Mechanisms

WP6:eMarketplace4Energy FINSENY (FINSENY_wp6)


Pablo Arozarena (pablo)

3 Date: 2012-02-07 17:55 In a highly distributed (cloud) environment such as FI-WARE, it is essential to assure the transactional properties (ACID properties as described already). If, for example, several parties negotiate energy products on a marketplace (enabled by a certain FI-WARE component), it needs to be ensured that only one consumer can buy the same energy product which is traded on the market. At the same time, the energy product can only be traded successfully in case the payment service (enabled by another FI-WARE component) terminates successfully; otherwise the deal needs to be discarded and the product can be traded again. What we expect is a cross FI-ware GEs transactional mechanisms (maybe in the form of APIs) in order to ensure ACID properties in using different GEs as already described before. Date: 2012-01-18 11:52 The Issuer needs to provide more detail in the description of the requested functionality Date: 2012-01-18 11:52 It is not clear to me what is exactly expected from FI-WARE. Date: 2012-01-17 21:13 Please set status.

1118 FINSENY THEME Database System

Consolidation FINSENY (FINSENY_wp7)


Carlos Ralli Ucendo (ralli)

3 Date: 2012-05-31 06:01 Additional improvements. This entry is similar to another one uploaded by FINSENY. Date: 2011-12-11 10:40 In a very first review, the requested functionality will be covered by one or more Generic Enablers in FI-WARE. Nevertheless, the request will be further analysed by members of the FI-WARE team to confirm this initial response. This may require further interaction with you so, please, stay tuned. Members of the FI-WARE development team will also double-check that there are Features entries in the FI-WARE Backlog that cover the requested functionality.


Page 35 (335)

Fusion Forge Nro.

Name Submitted by

Status Assigned to

Prio- rity

Messages

1119 FINSENY EPIC Device Database



Consolidation FINSENY (wp7)

3 Date: 2012-06-08 13:50 It should be also checked by the ID management – security chapter! IDs are not exclusively assigned to human beings – processes and devices might be covered too. Date: 2012-05-18 11:58 Sender: Consolidation FINSEN Y Any device that generates information required for management proposes or that could be updated/upgraded remotely must be authenticated before the data can be accepted or the firmware updated; therefore a centralized database will all devices and regional databases are required. Identification of devices must be stores for authentication proposes. Identification of devices like Meters, Charging Points, Intelligent Sensors, etc. requires definition and development of guidelines to ensure unique identification, e.g. Serial Number+Manufacturer+Region. Date: 2012-03-22 22:20 Dear Colleague, can you specify what are the devices you are targeting in your requirement (smartphones, PCs, sensor nodes, etc.), and what kind of identification data you would expect to have available. Thanks and BR. (PG)

1121 FINSENY EPIC Distributed Databases



Carlos Ralli Ucendo (ralli)

3 Date: 2012-05-31 06:17 Minor changes were made to the backlog entry. Date: 2011-12-11 07:30 In a very first review, the requested functionality will be covered by one or more Generic Enablers in FI-WARE. Nevertheless, the request will be further analysed by members of the FI-WARE team. Date: 2011-12-11 07:30 I believe that applications may program the CEP so that context information is directed to different target components of the application based on type of data and devices that generate the information. Each of these target destinations could store context information on its own database system. The CEP GE team is assigned this ticket but I guess it will probably be transitioned to an "Already Covered by Baseline Asset" status.

1122 FINSENY EPIC Customers Profile


Open TID FIWARE Developer (tiddeveloper)

3 Date: 2012-06-01 10:35 Good morning, Can you provide more details regarding what you mean by this request. Also can you provide reference information as to the "legal framework of EU countries". Regards Grant


Page 36 (335)

Fusion Forge Nro.

Name Submitted by

Status Assigned to

Prio- rity

Messages

1124 FINSENY STORY SmartGrid Data




3 Date: 2012-02-09 10:44 We understand that the requested functionality will be supported in FI-WARE because it is already supported in one of the products adopted as baseline for building the reference implementation. Please check description of the provided FI-WARE Feature and monitor progress of activities, particularly GE specifications, to confirm that all your needs are covered. Date: 2012-02-09 10:44 In IoT Data handling we expect to deliver micro-database component to store data at device level or gateway level if these two are able to host the component of course. This is not for all statistical data but for data available for real-time services which could be deleted and not store for a long time Date: 2011-12-14 15:57 The Instantaneous and Real-time data component within the Local Storage GE.

1125 FINSENY EPIC Security Intrusion Detection

Lionel Besson FINSENY (FINSENY_lionelb)


Daniel GIDOIN (gidoin)

3 Date: 2012-06-19 22:27 I agree, It is necessary to use a Distributed Intrusion Detection System (DShield) but today the provision of the service is out of scope of the Security Monitoring GE. Date: 2012-04-16 13:56 Snort is a good IDS, but I'm unaware in which way we can coordinate / exchange between the different instances, in order to have some distributed IDS Date: 2012-03-29 11:17 I suggests to use the Snort® IDS, an open source network intrusion prevention and detection system (IDS/IPS) developed by Sourcefire combining signature, protocol, and anomaly-based inspection. Date: 2012-03-29 11:17 The requested functionality has been evaluated and considered relevant. Therefore, a number of related Epics and Features will soon be added to the FI-WARE Backlog.

1427 FINSENY EPIC Data confidentiality

Consolidation FINSENY (finseny_wp7)


Nathalie DUBUS (dubusn)

3

1428 FINSENY EPIC Data Integrity




3 Date: 2012-03-26 10:17 Should be covered by XACML mechanisms and anonymous mechanisms but no assets are available for encryption at device level


Page 37 (335)

Fusion Forge Nro.

Name Submitted by

Status Assigned to

Prio- rity

Messages

1429 FINSENY EPIC Data Management and Storage




3 Date: 2012-03-26 10:22 Would be covered by IoT Data handling assets (collect data from sensors, could be stored locally or at Gateway level) and data will be pushed to backend to be stored by Data & Context management assets (Big Data, Mongo DB, etc...)

1430 FINSENY EPIC Data management Performance




3 Date: 2012-03-26 10:25 Would be covered by assets in Cloud chapter, Data and Context Management chapter and IoT chapter to collect all information, store them locally or in the cloud with assets related to data management (big data, CEP, etc...)

1431 FINSENY EPIC Database System




3 Date: 2012-03-26 10:37 covered by local micro database (IoT chapter), Pub/Sub broker or Big Data assets (Data & Context Management)

1432 FINSENY EPIC Common Data Models




3 Date: 2012-03-26 10:18 We expect to use NGSI-10 for meta data and be able to include all data models in the same container

1433 FINSENY EPIC Data Backup and Recovery




3 Date: 2012-05-17 12:43 The description is a bit vague. What level are we talking about? Device, backend or gateway? And even then the software that runs on the device/gateway should be backed up, or applications that run on the devices/gateways harnessing their capabilities? What about measurements?

1434 FINSENY EPIC Distributed Processing




3 Date: 2012-03-26 10:34 Should be supported by CEP assets, to apply local rules and then decide of some actions

1435 FINSENY EPIC Persistent Data Storage




3 Date: 2012-03-26 08:01 Should be assumed by local micro-database at the gateway level. Could also be available in future smart devices


Page 38 (335)

Fusion Forge Nro.

Name Submitted by

Status Assigned to

Prio- rity

Messages

1436 FINSENY EPIC Data Bus Management




3 Date: 2012-06-22 15:46 Please, provide more details (the link to the wiki is broken, and the details here are not clear). Date: 2012-05-20 17:19 I believe this is a storage component and not context/data subscription itself. The storage shall be subscribed either to the publish/subscribe GE or to the data and context providers directly. Date: 2012-05-17 12:44 I'm not sure who assigned this to Boris, but it seems right that this EPIC is related to the DCM chapter. Hence, I change FI-WARE chapter from IoT to DCM.

1438 FINSENY Theme Data Bus Management


Open Boris Moltchanov (boris)

3

1439 FINSENY EPIC Data Bus integration




3 Date: 2012-03-22 22:45 Dear Colleague, the requirement seems not perfectly explained: do you consider at what level (nodes into ad hoc networks, networking connectivity with the FI-WARE platform, etc.)? Please provide more details on the requirements in order to correctly understand what should be supported by the FI-WARE GEs, thanks. BR (PG) Date: 2012-03-13 14:46 Seems to be an I2ND topic.

1450 FINSENY Feature Dedicated or shared transport infrastructure for connected devices

Distribution Network Finseny (finseny_wp2)



3 Date: 2012-05-17 12:55 I'm sorry, but the description seems very domain specific. Can you elaborate on what is exactly the communication technology layer, or at least what can be its counterpart in Fi-Ware IoT? And what are exactly the useful links that should be utilised? I am not sure this is an Internet of Things capability.


Page 39 (335)

Fusion Forge Nro.

Name Submitted by

Status Assigned to

Prio- rity

Messages

1451 FINSENY Theme Time synchronization of the connected devices




3 Date: 2012-06-08 14:45 This is a well solved problem. Please check out: http://www.ntp.org/rfc.html. Ticket should be closed, I2ND support not necessary! Date: 2012-05-17 13:25 Further specification is needed, could you give concrete examples? Complex Event Processing is both present at DCM and IoT level, device actuation is present in IoT.

1543 FINSENY EPIC High priority asynchronous messages




3 Date: 2012-06-08 14:47 Topic might be covered in S3C as long the traffic is managed and controlled in an operator environment. In this case S3C is able to support you. More details are required. Date: 2012-03-23 17:33 Hi Pierangelo, we are clarifying the point in the moment, will update this response soon. BR Holger Elias Date: 2012-03-22 22:34 Dear Colleague, do you consider this request associated to I2ND GEs or to IoT ones? Could you please explicit this point for better understanding of the requirement, thanks. BR (PG)

1583 FINSENY THEME Deploy Apps On Smart Grid Devices

E-Mobility FINSENY (finseny_wp5)


E-Mobility FINSENY (wp5)

3 Date: 2012-05-17 09:29 Fi-Ware IoT deals with generic devices. We indeed plan to have software/firmware update functionalities using OMA DM via ETSI M2M. Smart Grid devices however are domain specific, and Fi-Ware IoT try to focus on generic enablers. Hence, we do not provide anything Smart Grid specific. Also the description mentioned grouping of updates. The grouping of updates seems to be a requirement towards the application using the Fi-Ware system, not the requirement of the Fi-Ware itself. Date: 2012-05-11 17:36 deployment will not be supported by the Apps and Services chapter. Date: 2012-02-29 12:25 Provide means to modularly manage groups of functionalities (via "Apps") of plenty, distributed smart grid devices.


Page 40 (335)

Fusion Forge Nro.

Name Submitted by

Status Assigned to

Prio- rity

Messages

1584 FINSENY EPIC Remote Initialization



E-Mobility FINSENY (wp5)

3 Date: 2012-05-17 13:10 What is the exact scope of this EPIC? Is it about the gateway being capable of issuing updates on the devices or about the devices receiving these updates? Is it about a firmware or software update, or activation of pre-existing functionalities on the device or runtime deployment of software components on the device? it is usable not only configuring some parameters remotely, but also to choose the actual functionality flexibly depending on the actual place and environment where the device is used (e.g. smart meter). Date: 2012-05-11 17:38 Deployment and management of runtime infrastructure will not be supported by the Apps/Services framework.

1585 FINSENY EPIC Store and Management of Apps for smart grid devices


Open Nobody (None)

3 Date: 2012-05-11 17:40 The apps/services chapter will not support deployment of apps. This is the responsibility of the service provider using services from the Cloud/IoT/IND chapters.

1616 FINSENY Theme Electronic Market Place

WP6:eMarketplace4Energy FINSENY (finseny_wp6)


Andreas Klein (klein)

3 Date: 2012-05-22 18:10 We should talk about the specific requirements as soon as possible. Date: 2012-05-17 10:35 This ticket is clearly a backend component, and not only out of scope for internet of things, but also domain specific. Please consider reallocating this to the APPS chapter.

1618 FINSENY EPIC Efficient and secure service access and provision



WP6:eMarketplace4Energy FINSENY (wp6)

3 Date: 2012-05-17 13:12 Does this EPIC mean that IoT uses and thus exposes some kind of standard protocol (which is already covered by IoT asset), or there should be one standard it should support but not listed in this EPIC? Date: 2012-03-15 21:52 Note that there seem to be some overlap with the Efficient Web Services GE proposed by FI-Content (http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIContent.Epic.EfficientWebServices) that is in the first OpenCall. It would be interesting to explore to what degree this aspect is already covered or new aspects need to be covered.


Page 41 (335)

Fusion Forge Nro.

Name Submitted by

Status Assigned to

Prio- rity

Messages

1619 FINSENY EPIC Billing and Payment Mechanism



Torsten Leidig (leidig)

3 Date: 2012-05-22 18:12 Interface to billing systems is part of the business model engine which will start development in September. We should start to discuss the requirements according to FINSENEY asap. Date: 2012-05-17 10:32 Billing and Payment Mechanisms are clearly out of scope for Fi-Ware Internet of Things. Please consider reallocating this ticket to the APPS chapter.

1620 FINSENY EPIC High portability applications for fixed and mobile services targeted to the final customer



WP6:eMarketplace4Energy FINSENY (wp6)

3 Date: 2012-05-17 10:46 The EPIC description is a bit vague. What kind of operating system or devices are needed to be supported? Can you please precisely list the needed protocols/operating systems?

1663 FINSENY EPIC Real time system to monitor the available kind of energy for the energy-retailers

Consensus Building FINSENY (finseny_wp1)


Torsten Leidig (leidig)

3 Date: 2012-05-22 18:14 We currently discuss how the availability of services and resources are handled at the marketplace and business model engine. It would be nice to go into deeper discussions of the FINSENY use case requirements to guide the interface specifications. Date: 2012-05-17 13:28 This is clearly out of scope for Internet of Things, this is rather an Application/Services Ecosystem EPIC. I suggest transferring it to that chapter.

1664 FINSENY EPIC Web Service-enabled technologies for electricity network management


Open Consensus Building FINSENY (wp1)

3 Date: 2012-06-22 16:07 Cloud services *are* going to provide Restful interface, which can be invoked without human intervention. Are there any other requirements from the cloud infrastructure that you can envision?


Page 42 (335)

Fusion Forge Nro.

Name Submitted by

Status Assigned to

Prio- rity

Messages

1665 FINSENY Theme Security Management


Open Robert Seidl (seidl)

3

Table 1: Current Status of ICT Requirements submitted to AB


Page 43 (335)

5.3 Summary of Feedback from FI-PPP

The following summary was taken from the FussionForge Web Page (https://forge.fi-ware.eu/my/) on June 30, 2012. It shows the results for the 47 trackers submitted by the FINSENY Project. The first table shows the current status of the ICT Requirements submitted by the Technical Team to the FI-PPP Architecture Board (AB) (see details of the requirements submitted in Table 1: Current Status of ICT Requirements submitted to AB):

Status Quantity Accepted for inclusion in FI-WARE Backlog 5 Already Covered by Baseline Asset 6 Needs revision by Issuer 25 Open 5 Under Evaluation by FI-WARE 6

Table 2: Status of ICT Requirements submitted to AB Taking into account that the FINSENY Project organized a Technical Team with representatives from all WPs and assigned “caretakers” to ensure registration of the consolidated ICT Requirements identified during the 1st cycle of consolidations, next table shows a summary of the ICT Requirements submitted to the AB by WP

Work Package Quantity WP1 – Consensus Building and Impact Creation 3 WP2 – Distribution Network 7 WP3 – Regional- / Microgrid 8 WP4 – Smart Buildings 1 WP5 – Electric Mobility 5 WP6 – Electronic Market Place for Energy 5 WP7 - Consolidation 16 WP8 – Domain Specific Enablers and Experimentation 2

Table 3: ICT Requirements submitted by WP Additional information regarding the current status of the ICT requirements submitted to the FI-PPP Architecture Board is available in Table 1: Current Status of ICT Requirements submitted to AB.


Page 44 (335)

6. Summary of ICT Requirements Specifications

For consolidation proposes the ICT Requirements were grouped taking into account their relation with the SGAM Layers and their sphere of influence in the following layers: • Business Layer • Function Layer • Information • Communication • Component An additional organization of the ICT requirements were done using the classification defined by the AB and related to the complexity of the requirement: Theme, Epic, Feature and Story; being “Theme” the most generic/less complex and “Story” the most detailed/complex. This grouping ensures “father-son” relationship view of ICT requirements by preventing the consolidation discard those that are not generic enough to consolidate.

The following tables show a summary of the specifications for the final version of the ICT Requirements after consolidation. A complete description of ICT requirements is available in Annex I – Detailed ICT Requirements.

The following tables (and the detailed specification) with the ICT requirements have been organized firstly according to whether they were considered by the UC WPs relevant to the FI-WARE platform (generic), including those identified as generic by the AB, or as specific (domain specific). Additionally, within each group was assessed complexity of the ICT requirements according to the layers developed in the model SGAM.


Page 45 (335)

6.1 Generic ICT Requirements

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Bus

ines

s

TH

EM

E

SLA Management The SLAs for usage of ICT services between different market players in the energy sector must be able to be managed flexibly.

FINSENY (WP5)

Pen

ding

MU

ST

In order to reflect different levels of QoS on a business level, a variety of SLAs will be needed. The usage of different SLAs must be supported by a SLA Management environment. Any SLA management strategy comprises the negotiation of the contract (that must be abdicable) before run-time as well as the monitoring of its fulfillment during run-time. More precisely, eight functions are required: SLA Template Creation (including basic schema with QoS parameters) SLA Template Publication and Discovery SLA Negotiation between providers and consumer of services SLA Optimization SLA Monitoring (Audit) SLA Evaluation (Audit, eventually penalties for interrupted services) SLA Re-Negotiation SLA Accounting

10/0

5/20

12

Bus

ines

s

TH

EM

E

Data management DN operation involves handling (processing, analyzing, semantically classifying and accessing) large volumes of data that partially have to be stored for later use (e.g. billing, planning, historical analysis, regulation). The data must be kept consistent and synchronized with other systems within seconds. Data consistency has to be executed by DMS/SCADA system

FINSENY (WP2)

Pen

ding

MU

ST

Management of large volumes of data can pose a performance or data organization problem. Requires good data management Not required data have to be deleted after short time Data bursts have to be supported Organizational and system boundaries have to be considered in the design (format, types, naming, access rights)

14/0

5/20

12


Page 46 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Bus

ines

s

TH

EM

E Data Bus

Management Using multiple databases for different types of data requires communication channels for integration and interpretation of the information.

FINSENY (All)

Pen

ding

MU

ST

The large amount of information must be storage taking into account the context of the data. To make decision more than one type of data must be available.

07/0

2/20

12

Bus

ines

s

TH

EM

E

Device Management All devices must be managed to ensure a continue control and supervision of their interaction with the systems.

FINSENY (All)

Pen

ding

MU

ST

Features: A device or sub-system should be able to describe its capabilities to other entities. A description file is provided by the device and is expressed e.g. in XML. The description file contains information about the device, e.g. its logical devices, functional units and services. The description of the service includes a list of commands and its parameters as well as a list of variables to describe the state of the service at run time. A common information model for describing the capabilities of the device is needed and has to be standardized, e.g. based on IEC 61970/61968 or SCL of IEC 61850-6. Expected issue: Standardization of object models for capability description for a large set of devices and properties.

14/1

1/20

11

Bus

ines

s

TH

EM

E Quality of Service Every network (or network part)

should be able to manage differentiated services through the management of priority levels.

FINSENY (All)

Alre

ady

cove

red

Sho

uld

Every network (or network part) should be able to manage differentiated services through the management of priority levels.

20/0

7/20

11

Bus

ines

s

TH

EM

E

Performance Management

Performance management ensures that SLA is being met in an effective and efficient manner. Performance management can focus on the performance of any ICT component of the Grid.

FINSENY (All)

Pen

ding

MU

ST

Performance management ensures that SLA is being met in an effective and efficient manner. Performance management can focus on the performance of any ICT component of the Grid.

05/1

2/20

11


Page 47 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Bus

ines

s

TH

EM

E

Derivation of flexible energy prices / Calculation

Provides a real time energy price in order to allow the EV-user or an aggregator to decide whether charging is reasonable.

FINSENY (WP5)

Pen

ding

MU

ST

Energy providers need to be able to dynamically derive energy prices for the next hours. This requires precise forecasts of the availability of energy, as well as of the expected demand. Dynamic prices are then a means to balance the energy need and to avoid potentially expensive peaks of the demand. The complex derivation of energy prices depends on temperature, energy market prices, SOC (state of charge) and mobility needs of all customers (anonym). The calculation must consider grid capacity and calculate combinations of mobility offers which can be time-graded.

10/0

5/20

12

Bus

ines

s

TH

EM

E

Electronic Market Place

The services that will be provided at the eMarket4E will have to comply with: Ease of learning, memorable, maintenance, natural interaction and user satisfaction. This refers to the service interaction design in one side (service provider) and on the other by the artifacts provided at the platform side to mash up and produce services.

FINSENY (All)

Pen

ding

Mus

t

The services that will be provided at the eMarket4E will have to comply with: Ease of learning, memorable, maintenance, natural interaction and user satisfaction. This refers to the service interaction design in one side (service provider) and on the other by the artifacts provided at the platform side to mash up and produce services.

21/1

2/20

11

Bus

ines

s

TH

EM

E

Future-proof system design requirements

The interfaces should be open for future-proof system design wrt to modularity, standardization, maintainability and HW/SW upgradeability

FINSENY (WP2)

Pen

ding

MU

ST

Future-proof system design requires modularity, maintainability, upgradeability of hardware, firmware and software as well as long time sourcing. Expected issues: Long time sourcing in contradiction to open market development and semiconductor/parts life-cycle. 14

/05/

2012


Page 48 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Bus

ines

s

TH

EM

E

Interfaces (differentiate between user interfaces and other interfaces)

The interfaces for all users should be easy-understandable and user-friendly.

FINSENY (All)

Pen

ding

Mus

t

The interfaces for all users should be easy-understandable and user-friendly.

22/0

8/20

11

Bus

ines

s

TH

EM

E

Marketplace services

The services that will be provided at the eMarket4E will have to comply with: Ease of learning, memorable, maintenance, natural interaction and user satisfaction. This refers to the service interaction design in one side (service provider) and on the other by the artifacts provided at the platform side to mash up and produce services. This requires also matching algorithms for finding appropriate contracts while keeping prices low or for finding appropriate offers to solve a grid issue

FINSENY (WP6)

Pen

ding

MU

ST

The services that will be provided at the eMarket4E will have to comply with: Ease of learning, memorable, maintenance, natural interaction and user satisfaction. This refers to the service interaction design in one side (service provider) and on the other by the artifacts provided at the platform side to mash up and produce services. An electronic marketplace needs to be available that facilitates the management, negotiation and closing of energy contracts.as well as to facilitate management, collection and selection of grid issues and issue solution (offers).The service will hold user energy information in detail. And it has to feature the capability of personalizing the interface depending on the context and preferences of the users.

24/0

5/20

12

Bus

ines

s

TH

EM

E Monitoring of EVSE Provide information in order to take

measures for grid stability. FINSENY (WP5)

Pen

ding

MU

ST

Measurement results must be observed to ensure grid stability.

10/0

5/20

12

Bus

ines

s

TH

EM

E

Payment methods/ possibilities at EVSE

Consumers should be able to pay by a payment method of their choice EC, Visa Card, PayPal, …

FINSENY (WP5)

Pen

ding

CO

ULD

EV-users may want to choose a payment method that they are comfortable with at an EVSE. There are lots of possible payment methods. The implementation of each payment method can be adapted from existing payment systems.

10/0

5/20

12


Page 49 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Bus

ines

s

EP

IC

Agnostic on the HAN technology

To have a technology reliable, durable, and able to integrate seamlessly with numerous different devices, standards and other technologies.

FINSENY (WP6)

Pen

ding

SH

OU

LD To be defined

21/0

5/20

12

Bus

ines

s

EP

IC

Scalability of Marketplace services

Marketplace Services should be offered in a scalable way which allows scaling the number of users and transactions easily.

FINSENY (WP6)

Pen

ding

SH

OU

LD The Marketplace Services should be offered in a scalable way,

as it is expected that the amount of users and thus transactions will increase.

24/0

5/20

12

Bus

ines

s

EP

IC

Virtual Network Operator

Provide a means where multiple service providers can all independently operate and dynamically provision the same physical telecoms infrastructure

FINSENY (All)

Pen

ding

SH

OU

LD

In general, current regional and national networks are operated by a single service provider. 3rd party operators are increasingly using virtualization technologies to provide new services. A future internet will see 100's of virtual operators operating dynamically inside the same physical network infrastructure where bandwidth and network services can dynamically scale in real time to customer requirements. This means that future networks will need to Open Up and expose control API's to 100's of various virtual service providers and software applications and agitate the combined real-time requirements into a single physical network provisioning system or a Virtual Network Operator. This will enable any new smart-grid use-case, service or application to organically grow without the high capital cost barrier to entry. In the case of the WP5 ICT-DCM, this capability will enable Smart Grid operators to directly control and scale the telecoms network in response to its real-time requirements as opposed to investing high capital costs in niche point-to-point networks.

10/0

5/20

12

Bus

ine

ss

EP

IC

Derivation of energy prices

Energy providers need to be able to dynamically derive energy prices for

FINSENY (All) P

endi

ng

Cou

ld Energy providers need to be able to dynamically derive energy

prices for the next hours. This requires precise forecasts of the 22/0

9/20 11


Page 50 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

the next hours. This requires precise forecasts of the availability of energy, as well as of the expected demand. Dynamic prices are then a means to balance the energy need and to avoid potentially expensive peaks of the demand.

availability of energy, as well as of the expected demand. Dynamic prices are then a means to balance the energy need and to avoid potentially expensive peaks of the demand.

Bus

ines

s

EP

IC

Connectivity Infrastructure

The connectivity is based on the infrastructure established for all devices and systems utilizing communication. Infrastructure includes aspects from technology, architecture and topology of the connectivity function (communication network). Infrastructures enable different means to provide the connectivity services and the quality of the service for different communication requirements. Finally, the infrastructure ownership and operational models (dedicated/public/shared) will impact SG actors and stakeholders, caused by different physical network media classes.

FINSENY (WP2/WP3/WP4/WP5)

Pen

ding

MU

ST

The network infrastructure should feature numerous levels of Classes of Service to support SLAs, e.g. the best being guaranteed QoS, the worst being best effort QoS. The network infrastructure should also feature a fully meshed architecture to support advanced peer-to-peer multimedia service applications. Aggregation nodes for various access protocols and technologies need to be supported in a ubiquitous and pervasive connectivity function. The network infrastructure should therefore build on a combination of advanced wireless and fixed architectures. Support of dynamic provision of Ethernet / IP bandwidth for on demand services is required, so that e.g. high definition uni-cast electro-mobility video services will be supported. Wireless coverage is essential, e.g. in order to dynamically receive information on a Journey with an EV. Non-blocking advanced virtualization technologies are necessary to enable many virtual electro-mobility network operators on the same physical telecoms network and allow for dynamically scaled bandwidth and connectivity services with respect to real-time customer requirements. In case of coverage problems during communication / transaction, different communication channels/media with seamless handover shall be enabled. (e.g. when an EV´s moving and channel is disturbed)

17/1

1/20

11


Page 51 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Bus

ines

s

EP

IC

Availability of Public Charge Points

Public charge points are available to all as many people as possible.

FINSENY (WP5)

Pen

ding

Mus

t

Public charge points are available to all as many people as possible.

09/0

6/20

11

Bus

ines

s

EP

IC

Billing and Payment Mechanism

The Billing and Payment Systems allows manage the information required by the user to make a transaction

FINSENY (All)

Pen

ding

Mus

t

The Billing and Payment Systems allows manage the information required by the user to make a transaction

22/0

9/20

11

Bus

ines

s

EP

IC

QoS Classes For each type of data transport (e.g. information, control, monitoring) a suitable connectivity service with the required QoS class can be reserved.

FINSENY (WP3)

Pen

ding

MU

ST

From a FINSENY’s use case analysis a set of six QoS classes were identified. They have to support the main tasks of control, monitoring and management.

14/0

5/20

12


Page 52 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Bus

ines

s

EP

IC

Performance Management for SLA Monitoring

Performance management is an essential element for the Future Internet. It must be implemented at different architectural levels to guarantee for reliable and expected KPIs e.g., network, data center and component level KPIs.

FINSENY (All)

Pen

ding

MU

ST

Performance management for SLA Monitoring includes supervision of KPIs which result from the contents of the SLA agreement and which have to be met in order to fulfill the negotiated SLA. Key components like data aggregation nodes or cloud computing resources must be monitored according to performance parameters agreed by an SLA e.g., a real time application like tele control is featured because a delay in the communications has similar effects than a lost. Performance management is not limited to component level scope, but must also be applied to higher level KPIs like service reliability or service respond time. Additionally, control mechanisms have to be implemented to tune performance parameters where appropriate. If performance cannot be met due to a lack of resources or if performance parameters are close to be failed these control mechanisms have to issue a warning to the SLA provider.

09/1

1/20

11

Bus

ines

s

EP

IC

Easy-to Understand Interface

The user interfaces of all systems facing final consumers should be easy-understandable, user-friendly. Intuitive and show all data the users need but not more than necessary.

FINSENY (WP6)

Pen

ding

SH

OU

LD The interfaces for all users should be easy-understandable and

user-friendly. If not, users would not use the advanced systems.

24/0

5/20

12

Bus

ines

s

EP

IC

Energy Management System

To receive home data by a metering system installed within the final user home (to measure consumed and/or produced energy)

FINSENY (WP6)

Pen

ding

MU

ST

A metering system installed within the final user home and it will be used to measure energy consumed and/or produced

18/0

5/20

12


Page 53 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Bus

ines

s

EP

IC

E-Roaming Agreement Management

Energy roaming (E-roaming) agreement management is comprised of all functions conducted in checking whether two or more energy roaming partners have an agreement.

FINSENY (WP5)

Pen

ding

MU

ST

E-roaming, partners involved in the roaming process need to be able to identify/check if an agreement is valid between them at the moment it is activated. If an EV-user connects to EVSE of a particular EVSE-operator that operator needs to check whether the connected EPS is a roaming partner of the EV-user and/or EMSP, respectively i.e., checking if charged energy can be billed over the EV-user’s home EPS. Therefore, the involved EMSP receives the EVSE-operator’s EPS information and checks if a roaming contract between the EV-user and that EPS exists. If there is an active roaming contract, settlement and billing functions could be performed using the EV-users home EPS.

10/0

5/20

12

Bus

ines

s

EP

IC

Flexibility in the creation of new services interfaces/interaction framework

The final user services have to be designed following the design interaction methodology

FINSENY (WP6)

Pen

ding

MU

ST

Diverse preferences and abilities of the customers should be taken into account when designing the service interaction of eMarket4E services.

18/0

5/20

12

Bus

ines

s

EP

IC

Responsivity Provide a means whereby future regional telecoms networks can be dynamically re-configured and modified in fractions of a second.

FINSENY (WP5)

Pen

ding

SH

OU

LD

Current internet services are quite static and do not changed very often. In addition, the applications running over the network have no relationship or control to the services being provided. A future internet will enable dynamic service provisioning where the network will be directly responsive to the real-time to the demands of an application. This means that future network architectures must be able to reconfigure themselves at the packet level or in millisecond or micro-second time-frames, much faster than the current control systems.

10/0

5/20

12


Page 54 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Bus

ines

s

FE

AT

UR

E

Transactional mechanisms - Market Place

For the Electronic Marketplace for Energy in the FINSENY project, transactional mechanisms are required to perform critical operations in a consistent way. Actions like buying or selling energy and stipulating or closing contracts have to be supported by possibly distributed ICT transactional mechanisms with transactional guarantees.

FINSENY (All)

Pen

ding

MU

ST

For the Electronic Marketplace for Energy in the FINSENY project, transactional mechanisms are required to perform some critical operations such as payments, contracts establishment/closing, and exchange of goods on the electronic market platform. A transaction is a logical unit of work which starts with the begin operation and finishes with either the commit or the abort operation. In a transaction, between start and the commit or abort operations, data requests are executed (on behalf of the transaction). A data request is an operation that manipulates a data object in such a way that it either reads or modifies the values stored in the data object. Classic transactions are bracketed by key control operations as Begin-Transaction, Commit-Transaction and Abort-Transaction. Each transaction must respect all the ACID properties: Atomic - either all operations of a transaction happen or none; Consistency - a transaction is a transformation from one correct state to another correct one; Isolation - even if many transactions may be executed concurrently, they do not interfere with the other ones; Durability - once a transaction is finalized, it will remain so. If a transaction is aborted (also known as rollback operation), all effects of the data managed on behalf of transaction are discarded. A Declarative Transaction Model is needed to manage a transaction lifecycle. With a Declarative Transaction Model the framework itself manages the starting and stopping (i.e. Begin, Commit or Abort) of the transaction. Developers only need to tell the framework when to roll back the transaction on application exception and configure the transaction through configuration parameters.

14/1

1/20

11


Page 55 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Bus

ines

s

FE

AT

UR

E Legally binding

electronic contracts Legal conditions which allow to electronically closing binding contracts without direct human interaction.

FINSENY (WP6)

Pen

ding

MU

ST

The legal conditions need to allow to electronically close binding contracts, even if they are closed automatically, e.g., by means of intelligent agents.

24/0

5/20

12

Bus

ines

s

FE

AT

UR

E Standardized

energy contract A standard for energy contracts and energy contract offerings need to be available in order to facilitate trading between all actors and to develop tools such as Web-based electronic marketplaces.

FINSENY (WP6)

Pen

ding

SH

OU

LD .A standard for energy (shifting) contracts and energy (shifting)

contract offerings need to be available in order to facilitate trading between all actors and to develop tools such as Web-based electronic marketplaces.

24/0

5/20

12

Bus

ines

s

FE

AT

UR

E Info communication

system for the Final Users

Al the services provided by the eMarket4E have to be available by web

FINSENY (WP6)

Pen

ding

MU

ST

A WEB portal that allows the final user, through a smart phone or a PC, to choose between different energy retailer in order to get at best, technically and economically, its energetic needs.

23/0

5/20

12

Bus

ines

s

FE

AT

UR

E

Production/ Consumption information available in near real time

To have services which provide energy production/consumption information in near real time to the energy customers/prosumer

FINSENY (WP6)

Pen

ding

MU

ST

Real time communication amongst the actors may lead to improved peak demand management as consumers are able to view energy prices in time, and sequentially assess the best time to buy/consume energy. A prosumer will not only have to evaluate which is the best time in the day to sell/consume electricity but also whether to self-consume or store the energy being produced. Nearly real time production/consumption information is needed to improve peak demand management, view energy prices in time, and sequentially assess the best time to buy/consume energy

24/0

5/20

12


Page 56 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Fun

ctio

n

TH

EM

E Supervisory control Lightweight, non-application-specific

control layer for non-safety- critical control of building entities

FINSENY (WP4)

Pen

ding

Mus

t

Service-level control for dynamically configured sets of building entities, derived from simple exclusion or sequence rules and matched to generic models of these entities

30/0

6/20

12

Fun

ctio

n

TH

EM

E

User Profile Providing a combined user profile bundling a charging profile, customer profile and further information about a user.

FINSENY (WP5)

Pen

ding

SH

OU

LD

Each E-mobility provider may create a user profile which contains information about the EV-user. The information in the user profile may consist of a customer profile, charging profile or sensitive user information like a unique user ID. Already saved preferences reduce the time the EV-user needs to set up necessary data for charging, identification, authentication, authorization or other services like most favorite radio stations. The stored data can be used for ancillary services (cf. Android or Facebook apps using standardized stored user data to prevent the user entering his personal data for each app separately).

10/0

5/20

12

Fun

ctio

n

TH

EM

E

Interoperability on Communications Technology (CT) layer

Interoperability on - North-bound CT I/Fs between DSO, Aggregators and VPPs wrt intra and inter-company communication - Standardized South-bound I/Fs wrt SG-devices communication

FINSENY (WP2)

Pen

ding

MU

ST

Features: UC functionality relies on interoperable communication network architecture from the sensor/actor devices via the IEDs, RTUs, aggregation and transport nodes to the server infrastructure and between server sites including switching/routing functionality on communication system protocol layers 2, 3 and 4 (link, network, transport). (LAN-switching, IP (MPLS)-routing and flow control). Standards framework as agreed in ETSI, IEEE, IETF for basic interworking. Namely Ethernet, TDM and serial Interface interoperability as well as their appropriate transport and routing layers, incl. secure transport, i.e. authenticated and encrypted message transfer. Expected issues: Definition of failsafe mechanisms to overcome limited distortion of interoperability

14/0

5/20

12


Page 57 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Fun

ctio

n

TH

EM

E EVSE Information

Service Provide an information service that informs an EV-user about EVSE nearby or at the destination.

FINSENY (WP5)

Pen

ding

SH

OU

LD The EVSE information service informs an EV-user about EVSE

nearby or at the destination.

10/0

5/20

12

Fun

ctio

n

EP

IC

Availability/Reliability of forecast in demand/production

To have an ICT system able to guarantee a high level of availability and Reliability of forecast in Energy demand/production for the Market Place.

FINSENY (WP6)

Pen

ding

SH

OU

LD The Availability of the forecast services have to be high,

otherwise energy shortage may happen.

21/0

5/20

12

Fun

ctio

n

EP

IC

Aggregate EVs to virtual power plants

Interface for V2G-Operator to administer, monitor and control many EVs at same time.

FINSENY (WP5)

Pen

ding

SH

OU

LD A certain amount of EVs is aggregated to a virtual power plant

to use economies of scale. A single EV does not have an impact on the grid stability. A certain amount of EVs is necessary to get a storage capacity to control the grid.

10/0

5/20

12

Fun

ctio

n

EP

IC

Electricity Network management

In order to provide Emarket4E services, we need of an infrastructure and services for monitoring, supervisory control and operation of electrical networks.

FINSENY (WP6)

Pen

ding

MU

ST

Services for monitoring, supervisory control and operation of electrical networks need to be in place.

18/0

5/20

12

Fun

ctio

n

EP

IC

Energy Monitoring To have smart device and smart metering for gathering all the needed date from the user premises

FINSENY (WP6)

Pen

ding

MU

ST

Mechanisms for delivering data related to the energy consumption and/or production within a Smart House need to be in place for planning, procuring and selling activities. Besides Smart Meters, devices need to be intelligent and to be able to communicate. 18

/05/

2012


Page 58 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Fun

ctio

n

EP

IC

Connectivity Services

Connectivity Services have to be available for all devices and sub-systems to support all kind of data transports inside FINSENY's grid architectures. For this purpose, these services have to fulfill connectivity requirements depending on the different challenges of the data transport.


Pen

ding

MU

ST

The network infrastructure should feature numerous levels of Classes of Service to support SLAs, e.g. the best being guaranteed QoS, the worst being best effort QoS. The network infrastructure should also feature a fully meshed architecture to support advanced peer-to-peer multimedia service applications. Aggregation nodes for various access protocols and technologies need to be supported in a ubiquitous and pervasive connectivity function. The network infrastructure should therefore build on a combination of advanced wireless and fixed architectures. Support of dynamic provision of Ethernet / IP bandwidth for on demand services is required, so that e.g. high definition uni-cast electro-mobility video services will be supported. Wireless coverage is essential, e.g. in order to dynamically receive information on a Journey with an EV. Non-blocking advanced virtualization technologies are necessary to enable many virtual electro-mobility network operators on the same physical telecoms network and allow for dynamically scaled bandwidth and connectivity services with respect to real-time customer requirements. In case of coverage problems during communication / transaction, different communication channels/media with seamless handover shall be enabled. (e.g. when an EV´s moving and channel is disturbed)

14/0

5/20

12


Page 59 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Fun

ctio

n

EP

IC

Reliability and availability on Communications Technology (CT) layer

Reliability of CT layer I/Fs towards Aggregator, VPP or DSO and SG-devices.

FINSENY (WP2)

Pen

ding

MU

ST

Features: Insuring reliability and defining a suitable availability of CT operations towards Aggregator, VPP or DSO processes, applications, databases and the SG-devices. Ensuring appropriate transport and routing layer reliability for communication functions require: - Considering communication equipment lifetime expectation (acceptable FIT-rate of nodes and I/Fs) - Suitable time to repair - Communication equipment protection to meet availability requirement (parallel nodes) - Path layer protection to meet availability requirement (multi-homing, route-redundancy) Expected issues: High cost threat for redundant paths

14/0

5/20

12

Fun

ctio

n

EP

IC

Reliability of the system

To guarantee the reliability of the system in term of response time performance

FINSENY (WP6)

Pen

ding

SH

OU

LD It is very important to guarantee the reliability of the system in

terms of response time performance, as users would not use the systems otherwise.

24/0

5/20

12

Fun

ctio

n

EP

IC

User Management Providing a mean that allows the E-Mobility provider to manage and maintain customer profiles and storage of user profiles.

FINSENY (WP5)

Pen

ding

MU

ST

There are different kinds of user profiles that can be stored on Servers. User Management opens the possibility to create, maintain, search, modify and delete user profiles. For example a user management system may help structure certain kinds of user profiles for accounting processes. 10

/05/

2012

Fun

ctio

n

EP

IC

Identifiers In order to provide individual services and to allow for E-Roaming, several different ways of identification are needed, such as an End User in front of an EVSE via a Unique ID.

FINSENY (WP5)

Pen

ding

MU

ST

The identifier must be unique for each user.

10/0

5/20

12


Page 60 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Fun

ctio

n

EP

IC

Identification medium

Provide a medium which enables the possibility of the Identification of a EV-user through RFID, Smartcard, Keypad, etc.

FINSENY (WP5)

Pen

ding

MU

ST

There are different kinds of identification mediums like Wireless LAN, Bluetooth, GSM/UMTS, Power Line Communication, Keypad, Near Field Communication, … Each identification medium needs protocols and at least two compatible end devices on each side of the connection (in this case between the EVSE and the electric vehicle). 10

/05/

2012

Fun

ctio

n

EP

IC

Quality of Service for Connectivity

Quality of Service (QoS) of connectivity functions is defined here as an agreed set of properties, which a specific Connectivity Function has to provide after negotiation and agreement with the information-layer (on behalf of the component and function/service-layers, according to the FICC-layers in the SGAM concept of SGCG). QoS can have many properties, in focus here are Latency, Bandwidth – Throughput / Good put, Delay and Jitter, Prioritization and Packet Loss. An agreed set of QoS parameters from the before (a Class of Service; CoS) may be the basis for a Service Level Agreement (SLA) to be fulfilled and monitored by the Connectivity Function. An example for energy related communication QoS is given in IEC61850-90-4. Pls. see inserted diagram.


Pen

ding

MU

ST

On functional or service layer information/data needs to be exchanged between devices, sub-systems, control centers or management systems. Depending on the desired functionality, but not necessarily on the max. Communication capabilities of the devices, corresponding connectivity quality needs to be insured. - Therefore the desired connectivity functionality needs to be described and classified first. IEC 61850-5 describes already requirements for Electricity Transport and Distribution Systems and large parts of Microgrid functionality as well as Distributed Energy Resources (DER). In other areas like Building or EV charging systems or new Aggregation functions, new Future Internet Technologies have to fulfill specific application-area and use case specific QoS connectivity requirements. - Individual and repeating sets of QoS requirements can secondly be grouped in Service Level Agreements (SLA) on QoS. In this QoS description, connectivity parameters concerning quantitative settings for Latency, Bandwidth – Throughput / Good put, Delay and Jitter, Prioritization and Packet Loss need to be specified. - SLAs need third to be communicated to the connectivity layer and acknowledged by it.

17/1

1/20

11


Page 61 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Depending on the locally available Connectivity Function capabilities, SLA requests need to be acknowledged rejected or alternative proposals need to be negotiated with consequences to the desired functionality. In FI-Ware there is the IaaS Data Center Resource Management mentioned to support this. - A forth aspect for the Connectivity QoS Function is the supervision of achieved performance for certain SLAs. Typically QoS related SLAs will be static, by interface selection and according setting of communication equipment. Especially depending on Access Communication (wired or wireless) Network capabilities, time variable assignment of QoS needs to be considered. Therefore a QoS related (management) communication interface between the function layer and the communication layer is required in parallel. The table 8 from IEC 61850-90-4 shows exemplary derived SLAs for typical electricity grid functions as described in IEC 61850-5.

Fun

ctio

n

EP

IC

Real Time Data and Service management

We need applications able to process data and to manage services in real time

FINSENY (WP6)

Pen

ding

SH

OU

LD The requirement takes on board the fact that in the future real

time tariff schemes will have to be handled by the Market place service.

18/0

5/20

12

Fun

ctio

n

EP

IC

Request / Response Request/Response service for a single information of monitoring and / or control

FINSENY (WP3)

New

WP

3 R

equi

rem

ent

MU

ST

A request/response service is a service based on a client request to get or set one data attribute and initiates a response from the server, either with the value of this attribute or with the information on the successful or unsuccessful setting of the attribute. 24

/05/

2012


Page 62 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Fun

ctio

n

EP

IC

Web-Service-enabled technologies for electricity network management

Services for monitoring, supervisory control and operation of electrical networks need to be in place. The network infrastructure should feature open web-service APIs so that electro mobility cloud services and marketplace services can simultaneously query and reserve both network and cloud services without any human intervention.

FINSENY (All)

Pen

ding

Mus

t

Services for monitoring, supervisory control and operation of electrical networks need to be in place. The network infrastructure should feature open web-service APIs so that electro mobility cloud services and marketplace services can simultaneously query and reserve both network and cloud services without any human intervention.

24/0

8/20

11

Fun

ctio

n

EP

IC

Decision Making and signaling energy commands

Manage DSM signals to reduce the power consumption in customer homes. The user has access to a DMS application on the internet and can choose from the DSM offerings.

FINSENY (WP6)

Pen

ding

MU

ST

The service that may lie on the Grid User side or in the cloud needs to know the user contract and the installed capabilities. According to the latter processing capabilities are key to decide how to signal the shape demand commends.

18/0

5/20

12

Fun

ctio

n

EP

IC

Derivation of flexible E-Roaming prices / Calculation

Providing a calculation of E-Roaming prices could also be necessary to allow transparent roaming costs.

FINSENY (WP5)

Pen

ding

SH

OU

LD Costs that occur because of roaming need to be specified and

calculated to ensure a proper billing and make a choice between different roaming partners possible.

10/0

5/20

12

Fun

ctio

n

EP

IC

Electricity Price signal hourly – daily

Fixing and managing the Price .The main price to be dealt with are: Energy Price derived from auctions (for who participate to Energy Trading) (prices and quantity exchanged) Final Energy Prices- Tariff (Price/kW to be pay from the final customers) (Defined from the Energy Retails. It

FINSENY (WP6)

Pen

ding

MU

ST

The final user should know the price of the electricity in order to incentive or disincentive the consumption of the energy depending on the price. This interface must be as much detailed as possible covering final price per minute, incentives, contra-incentives, etc. The final price of the electricity for customers’ needs to be updated hourly-daily in order to take decisions on the scheduling of the consumption of the energy by the BEMS or the final user.

21/0

5/20

12


Page 63 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

derives from the business model and pricing model followed. ) The price has to be notified/shown to all market stakeholders according their roles in the electronic market place.

Fun

ctio

n

EP

IC

End users Interface End users shall be able to access a set of functionalities including visualization of energy consumption metering

FINSENY (All)

Pen

ding

MU

ST

End users shall be able to access a set of functionalities including visualization of energy consumption metering.

28/1

2/20

11

Fun

ctio

n

EP

IC EVSE Price Service Provide an information service that

informs an EV-user about the energy price at EVSE nearby or at the destination.

FINSENY (WP5)

Pen

ding

CO

ULD

The EVSE price service informs an EV-user about the energy prices at EVSE nearby.

10/0

5/20

12

Fun

ctio

n

EP

IC

HMI at comfort EVSE

End users shall be able to access a set of functionalities including visualization of energy consumption metering and resulting energy costs. Electric Vehicle Users (EV-users) need to specify preferences such as the Charge Time Frame and the Minimum Battery State Of Charge (BSOC). Instead of simple techniques ("End-users Interface / HMI - EVSE"), this could be done more sophisticated and automatically, e.g., with user-friendly agent technology which could be integrated into a navigation system. The end user may be informed about

FINSENY (WP5)

Pen

ding

CO

ULD

End users shall be able to access a set of functionalities including visualization of energy consumption metering, state of charge, Battery State Of Charge … through user-friendly agent technology. A bunch of additional information, settings and services may be available for users at an advanced EVSE HMI.

10/0

5/20

12


Page 64 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

availability of certain tariffs at the EVSE.

Fun

ctio

n

FE

AT

UR

E Efficient and secure

service access and provision

The Ability of generating contracts on the fly over the internet will need to be reliable by employing standard protocols and interfaces from the users. Security access has to be provided also following usual

FINSENY (WP6)

Pen

ding

SH

OU

LD

The Ability of generating contracts on the fly over the internet will need to be reliable by employing standard protocols and interfaces for the users. Security access has to be provided also following usual

18/0

5/20

12

Fun

ctio

n

FE

AT

UR

E

Standardized grid issues and solutions descriptions

To facilitate automated treatment of such energy grid situations and of grid issue situations and to develop tools such as Web-based electronic marketplaces, e.g., in an electronic market place.

FINSENY (WP6)

Pen

ding

SH

OU

LD

A standard for grid issue descriptions need to be available in order to facilitate automated treatment of such situations, e.g., in an electronic market place. A standard for grid issue solutions and grid issue solution offerings needs to be defined in order to facilitate an automated treatment of grid issue situations and to develop tools such as Web-based electronic marketplaces.

24/0

5/20

12

Fun

ctio

n

FE

AT

UR

E Billing to customer Each customer gets a bill for the

charged energy. FINSENY (WP5)

Pen

ding

Sho

uld

The layout and content of bills needs to be specified. The generation of customer bills can be done via standard "billing" IT Systems. For a huge amount of cleared EV-users a Trusted Third Party could make billing easier and more efficient.

10/0

5/20

12

Fun

ctio

n

FE

AT

UR

E

Accounting (Roaming: Rating, Clearing, Billing, Settlement; Bill to customer)

Charging at any EVSE must be accountable to the EV-user charging his EV.

FINSENY (WP5)

Pen

ding

Mus

t

In case of Roaming Rating, Clearing, Billing and Settlement are processes which make accounting for a high amount of charging processes easier. If a customer is charging at his/her E-mobility providers own EVSE, the accounting only consists of an E-mobility internal process.

10/0

5/20

12


Page 65 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Fun

ctio

n

FE

AT

UR

E Control mechanisms

for Smart Home Standard mechanisms are required in order to assure the interoperability

FINSENY (WP6)

Pen

ding

MU

ST

Standardized mechanisms to control the energy consumption and production in Smart Homes from the outside need to be in place. This includes in particular communication interfaces and a protocol for information exchange.

18/0

5/20

12

Fun

ctio

n

FE

AT

UR

E User preferences

and agreements interfaces

The BEMS must provide an user interface for the user to manage their electric consumption preferences

FINSENY (WP6)

Pen

ding

MU

ST

The BEMS must provide an user interface for the user to manage their electric consumption preferences

21/0

5/20

12

Fun

ctio

n

FE

AT

UR

E Data gathering at

building/local level in real time

We need to gather the data (energy consumptions/production, etc.) at home/building level in real time, In order to process them for providing the emarket4E services.

FINSENY (WP6)

Pen

ding

MU

ST

The data in local/building/Community level have to be gathered in real time.

21/0

5/20

12

Fun

ctio

n

FE

AT

UR

E

Identification Medium supporting E-Roaming

The identification through identifiers must be possible with roaming clients as well as own customers. A standardized identification medium is necessary.

FINSENY (WP5)

Pen

ding

MU

ST

There are different kinds of identification mediums like Wireless LAN, Bluetooth, GSM/UMTS, Power Line Communication, Keypad, Near Field Communication, … Each identification medium needs protocols and at least two compatible end devices on each side of the connection (in this case between the EVSE and the EV). For roaming all roaming partners need to standardize the identification medium to make identification, regardless of the end points and EVs involved in the charging process, possible.

10/0

5/20

12


Page 66 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Fun

ctio

n

FE

AT

UR

E

QoS Service Class 1A

Safety critical for control FINSENY (WP3)

New

WP

3 R

equi

rem

ent

MU

ST

Priority: highest Latency: < 10 -100 ms Data occurrence: spontaneous (as reaction on failure in energy system) Bandwidth / Data volume: <1500 Byte Communication: Unicast/multicast Redundancy: needed for communication

14/0

5/20

12

Fun

ctio

n

FE

AT

UR

E QoS Service Class

1B Safety critical for monitoring FINSENY

(WP3)

New

WP

3 R

equi

rem

ent

MU

ST

Priority: highest Latency: < 10 -100 ms Data occurrence: spontaneous (on failure in energy system) Bandwidth / Data volume: <1500 Byte Communication: Unicast Redundancy: needed for communication

14/0

5/20

12

Fun

ctio

n

FE

AT

UR

E

QoS Service Class 2A

Operational critical for control FINSENY (WP3)

New

WP

3 R

equi

rem

ent

MU

ST

Priority: medium Latency: < 1s Data occurrence: spontaneous (on request of operator or action from SCADA) Bandwidth / Data volume: <1500 Byte Communication: Unicast Redundancy: redundancy in energy system (multiple devices can provide a similar service)

14/0

5/20

12

Fun

ctio

n

FE

AT

UR

E

QoS Service Class 2B

Operational critical for monitoring FINSENY (WP3)

New

WP

3 R

equi

rem

ent

MU

ST

Priority: medium Latency: < 1s Data occurrence: periodically Bandwidth / Data volume: <100 kbps Communication: Unicast Redundancy: redundancy in energy system (multiple devices can provide a similar service)

14/0

5/20

12


Page 67 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Fun

ctio

n

FE

AT

UR

E QoS Service Class

3 Communication Network Control for Management

FINSENY (WP3)

New

WP

3 R

equi

rem

ent

MU

ST

Priority: high Latency: < 100ms Data occurrence: spontaneous and periodically Bandwidth / Data volume: <100 kbps Communication: Unicast/Multicast Redundancy: needed for communication 14

/05/

2012

Fun

ctio

n

FE

AT

UR

E QoS Service Class

4 Best effort/Background traffic for Management

FINSENY (WP3)

New

WP

3 R

equi

rem

ent

MU

ST

Priority: low Latency: best effort Data occurrence: spontaneous and periodically Bandwidth / Data volume: best effort Communication: Unicast Redundancy: no 14

/05/

2012

Fun

ctio

n

FE

AT

UR

E Real time system to

monitor the available kind of energy for the energy retailers

FINSENY (WP6)

Pen

ding

SH

OU

LD A SW WEB-based system that allow the energy retailers to

give users the kind of requested energy together at all the necessary market information

18/0

5/20

12

Fun

ctio

n

FE

AT

UR

E

Ease of use of the eMarket4E services

The user applications have to follow the service interaction design roles in order to assure a better involvement of the final user

FINSENY (WP6)

Pen

ding

MU

ST

The services that will be provided at the eMarket4E will have to comply with: Ease of learning, memorability, maintainability, natural interaction and user satisfaction. This refers to the service interaction design in one side (service provider) and on the other by the artifacts provided at the platform side to mash up and produce services. 18

/05/

2012

Fun

ctio

n

FE

AT

UR

E HMI for desktop

browsers End users shall be able to access a set of functionalities including visualization of energy consumption metering and resulting energy costs.

FINSENY (WP5)

Pen

ding

MU

ST


10/0

5/20

12


Page 68 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Fun

ctio

n

FE

AT

UR

E

HMI for smartphones

End users shall be able to access a set of functionalities including visualization of energy consumption metering and resulting energy costs.

FINSENY (WP5)

Pen

ding

MU

ST


10/0

5/20

12

Fun

ctio

n

FE

AT

UR

E HMI in EVs End users shall be able to access a

set of functionalities including visualization of energy consumption metering and resulting energy costs.

FINSENY (WP5)

Pen

ding

MU

ST


10/0

5/20

12

Fun

ctio

n

FE

AT

UR

E

Network API's Provide a single interface to manage an entire national infrastructure

FINSENY (WP5)

Pen

ding

CO

ULD

For vehicles that are used in different Use Case categories, FI-Ware and or Smart Grid applications will need to directly control the network and dynamically reconfigure network services in real time depending on EV data-requirements as they dynamically travel around a city / region. Ideally the network API's should also be built on REST web services technology to enable the SG and Future Internet apps to talk directly to the network.

10/0

5/20

12

Info

rmat

ion

TH

EM

E

Algorithms to support forecast of mobility needs, power demand, etc.

Provide a forecast of grid loads which is calculated through algorithms in the cloud and broadcasted through a communication interface.

FINSENY (WP5)

Pen

ding

MU

ST

In the past grid loads were mainly based on experienced data. The recent changes of the grid into a smart grid and the high amount of unpredictable renewable energies makes the prediction based on experienced data impossible. The forecast of grid loads needs to be calculated by algorithms to allow real time energy demand and supply data. The introduction of EVs makes the prediction of energy prices and demand even more complicated. The complex calculations must be done in the cloud and broadcasted for all clients that rely on real time grid data.

10/0

5/20

12


Page 69 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Info

rmat

ion

TH

EM

E

Support of intelligent algorithm deployment

In a smart-(dis-)charging scenario, a new (near) optimal schedule needs to be calculated whenever certain parameters change. For example, it is necessary to mediate between dimensions (mobility demand, power grid demand, generation capability, battery capability).

FINSENY (WP5)

Pen

ding

MU

ST

Each EV has different characteristics as well as every user has different mobility demands. The optimal charging schedule must be based on a lot of parameters like mobility demand, power grid demand, generation capability, battery capability, energy prices, charging time frame ... Algorithms help to find a heuristic optimized schedule. EV-users may set up settings to influence the charging behavior of their EV. Energy providers or E-mobility providers may sell charging priority to their customers.

10/0

5/20

12

Info

rmat

ion

EP

IC

Auction Processing Processing all the bids and demands of Energy according the defined auction rules and models, in order to determine the exchanged quantities of energy at different prices for all the auction participants.

FINSENY (WP6)

Pen

ding

SH

OU

LD We need an automated system able to process all the bids and

demands according the defined auction rules and models, in order to determine the exchanged quantities of energy at different prices for all the auction participants.

03/0

2/20

12

Info

rmat

ion

EP

IC

Common data models

Definition of common data models (CDM) per type of sensor/appliance. In order to perform energy optimization on behalf of the consumer, home appliances must be modeled in a common way so that the intelligence in the system is able to monitor them, know control capabilities, programming capabilities and have at any moment information on the reachability of the device.

FINSENY (All)

Pen

ding

Mus

t

Definition of common data models (CDM) per type of sensor/appliance. In order to perform energy optimization on behalf of the consumer, home appliances must be modeled in a common way so that the intelligence in the system is able to monitor them, know control capabilities, programming capabilities and have at any moment information on the reachability of the device.

07/0

2/20

12


Page 70 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Info

rmat

ion

EP

IC

Mapping Tool for Information Models

To cope with different information models a flexible easy-to-use mapping tool is needed to map data points from different information models onto each other.

FINSENY (All)

Und

er E

valu

atio

n by

FI-

WA

RE

Cou

ld

Monitoring and control are two basic functionalities of control centers (e.g. in a Microgrid). The Control Center communicates with a large set of different devices from different domains (e.g. from intelligent loads to large wind turbines). Today a large number of different standards exist and it is very likely that this will also be true in the future. To ensure interoperability between different standards with different information models the standards have to be harmonized. A flexible mapping tool is needed to map monitoring and control data points from different information models onto each other. E.g. the mapping tool should be designed to minimize the manual input and mapping information should be re-usable.

14/1

1/20

11

Info

rmat

ion

EP

IC

Data Base System Large amounts of data need to be collected, stored and made available.

FINSENY (All)

Pen

ding

MU

ST

Many repositories to store all the information (measurements, profiles, EV, SMs, etc.) gathered from the devices must be available. Large amounts of data are to be saved on databases. Context management is key to classify information of various devices well identified. 28

/12/

2011

Info

rmat

ion

EP

IC

Data management and storage

We need method/technologies to collect, store and made available large amounts of data.

FINSENY (WP6)

Pen

ding

MU

ST

Large amounts of data need to be collected, stored and made available.

24/0

5/20

12

Info

rmat

ion

EP

IC

Data integrity The data to be sent and received have to be reliable in term of truthfulness and timing. It shall be possible to ensure the integrity of the communicated data (during the data transfer as well as stored data) and to verify whether

FINSENY (All)

Pen

ding

Mus

t

The data to be sent and received have to be reliable in term of truthfulness and timing. It shall be possible to ensure the integrity of the communicated data (during the data transfer as well as stored data) and to verify whether the data hasn’t been tampered. In particular for all payment scenarios, data integrity has to be ensured.

07/0

2/20

12


Page 71 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

the data hasn’t been tampered.

Info

rmat

ion

EP

IC

Data management Performance

Computing resources must be highly scalable in order to process, storage and evaluate data in order to allow for grid integration services. Data Integrity must be ensured

FINSENY (All)

Pen

ding

Cou

ld

Computing resources must be highly scalable in order to process, storage and evaluate data in order to allow for grid integration services. Data Integrity must be ensured

07/0

2/20

12

Info

rmat

ion

EP

IC

Distributed Databases

To provide storage systems for large amount of information, distributed database system (local, regional, etc.) are required.

FINSENY (All)

Pen

ding

MU

ST

A distributed database systems are required to provide storage system(s) for context information taking into account the type of data and the devices that generate de information.

28/1

2/20

11

Info

rmat

ion

EP

IC

Device Database Identification of devices must be stores for authentication proposes.

FINSENY (WP3/WP4)

Und

er E

valu

atio

n

MU

ST

Features: A device or sub-system should be able to describe its capabilities to other entities. A description file is provided by the device and is expressed e.g. in XML. The description file contains information about the device, e.g. its logical devices, functional units and services. The description of the service includes a list of commands and its parameters as well as a list of variables to describe the state of the service at run time. A common information model for describing the capabilities of the device is needed and has to be standardized, e.g. based on IEC 61970/61968 or SCL of IEC 61850-6. Expected issue: Standardization of object models for capability description for a large set of devices and properties.

28/1

2/20

11

Info

rmat

ion

EP

IC

Packet Loss Avoidance of packet Loss for MV secondary substations

FINSENY (WP2)

Pen

ding

Sho

uld

Packet Lost defines the maximum level of errors that the application could manage for normal operation. This parameter affects more drastically to Tele control function. Expected issue: ICT solution must be designed to guarantee a low level of packet lost for the Tele control function.

14/0

5/20

12


Page 72 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Info

rmat

ion

FE

AT

UR

E

Data Base System EV

A central or local (distributed) database system is required to provide storage system(s) for context information (EV users, EVSE, environmental 3rd party). In an EVSE, also a local database may be used for charge detailed record.

FINSENY (All)

Pen

ding

Cou

ld

A central or local (distributed) database system is required to provide storage system(s) for context information (EV users, EVSE, environmental 3rd party). In an EVSE, also a local database may be used for charge detailed record.

07/0

2/20

12

Info

rmat

ion

FE

AT

UR

E Persistent data

storage Database systems must ensure availability of enough non-volatile memory (e.g. flash memory) for storing measurements, internal data, and enable future firmware and software updates.

FINSENY (All)

Pen

ding

Mus

t

Database systems must ensure availability of enough non-volatile memory (e.g. flash memory) for storing measurements, internal data, and enable future firmware and software updates.

07/0

2/20

12

Info

rmat

ion

FE

AT

UR

E Data Integrity at the

Marketplace To provide integrity to the access to the eMarket4E

FINSENY (WP6)

Pen

ding

MU

ST

The Information that is to be collected by the Marketplace has to be handled taking care of personalization and context based information.

18/0

5/20

12

Info

rmat

ion

FE

AT

UR

E Distributed

Processing Distributed processing of the data is required to balance storage and analysis of huge amount of data.

FINSENY (All)

Pen

ding

Cou

ld

For balancing supply and demand the Microgrid Control Center has to run the state analysis and define the sub-sequent actions. These tasks include power flow calculations and forecasting models.

07/0

2/20

12

Info

rmat

ion

FE

AT

UR

E

Smart Metering Data

Data from smart meters should be available in the electronic-marketplace system with a possibly low delay. This requires the respective infrastructure to communicate measurements from the individual smart meters to the

FINSENY (WP6)

Pen

ding

MU

ST

All consumers need to have Smart Meters and means to analyze/view the corresponding data in order to be precisely aware of their energy consumption. More, Microgrid Operators need to have Smart Meters and means to analyze/view the corresponding data in order to be precisely aware of e-Island energy consumption/production. 24

/05/

2012


Page 73 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

respective systems, including harmonization of the data, plausibility checks etc.

Info

rmat

ion

FE

AT

UR

E Publish / Subscribe Enables the reporting and logging of

events as soon as they will happen without the need for another request

FINSENY (WP3)

New

WP

3 R

equi

rem

ent

MU

ST

A pub/sub service is a service based on the subscription of a client for a server initiating a data message as soon as a special event happens at the server side.

24/0

5/20

12

Info

rmat

ion

ST

OR

Y

Identifiers supporting E-Roaming

Provide the possibility of the identification of an End User in front of an EVSE via a Unique ID, which may reveal the E-mobility provider of an EV-user who is a roaming customer.

FINSENY (WP5)

Pen

ding

MU

ST

The identifier must be unique for each user. It may use a certain format that draws conclusions on the country of origin or the E-mobility provider of the user. The uniqueness of each ID should not be affected by the bigger amount of user IDs because of roaming. 10

/05/

2012

Com

mun

icat

ion

TH

EM

E

Connectivity Connectivity must be insured for all devices and sub-systems to support all kind of data transports inside FINSENY's grid architectures.

FINSENY (WP2/WP3/WP4/WP5) P

endi

ng

MU

ST

Devices (e.g. DER, Network Smart Devices) or sub-systems (e.g. Home/Building Energy Management Systems) installed in or at the edge of a Smart Grid need to communicate between each other or to their hosts located in physical Control or Management Centers or with virtualized Management Systems (eventually private or public cloud-based). Therefore Connectivity functions have to be assumed ubiquitously present throughout the SG topology. Different physical implementations of connectivity functions (communication networks) shape various dimensions of available capabilities. To match and agree on specific sets of connectivity capabilities between connected devices and Control Centers or Management Systems, the following EPICs were defined. Please note that they represent only a partition of the desired capability dimensions.

14/0

5/20

12


Page 74 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Com

mun

icat

ion

TH

EM

E

Addressing When new devices (e.g. DER, Network Smart Devices) or sub-systems (e.g. Home/Building Energy Management Systems) are installed in or at the edge of a Smart Grid (e.g. a Microgrid) they automatically configure themselves (also frequently denoted as Plug & Play). This requirement focuses on IP address configuration and addressability of the device by a Control Center.

FINSENY (WP3/WP4)

Pen

ding

MU

ST

Features: This requirement describes to automatically configure the network address of the device or sub-system. To be independent on the communication network and the ownership of the network (e.g. utility-owned, commercially provided, Internet) dynamic IP addresses are used. For the auto configuration of network addresses different technologies are available (e.g. DHCP, Auto IP or NDP for IPv6). Furthermore, to increase reliability multi-homing should be possible. After auto-configuration of the network settings of the device or sub-system it is addressable locally or remotely by control centers. For flexibility the connection setup should be possible in both directions. Expected issues: NAT, Firewall configuration

14/1

1/20

11

Com

mun

icat

ion

TH

EM

E

Communication Services

Communication Services have to be available for all devices and subsystems. They support and enable data transport between devices in the grid to transfer information (e.g. based on IEC 61850) to each other.

FINSENY (WP3)

New

WP

3 R

equi

rem

ent

MU

ST

Communication Services deal with the interoperability between a variety of devices in the distribution grid, e.g. between substations, IEDs and meters. The services hereby describe the transport of information (as described in IEC 61850 data model) between intelligent electronic devices. These services may be e.g. get, set, report, operate etc. and are mainly described in IEC 61850-7-2.

24/0

5/20

12

Com

mun

icat

ion

TH

EM

E

Interoperable ICT interfaces of EVSE

EVSE must be able to communicate with back-ends to transmit certain charging or accounting parameters (in particular for intelligent charging). Even more important is a standardized interface to EVs in order to provide basic info on a screen in the EV.

FINSENY (WP5)

Pen

ding

MU

ST

In order to enable ICT on end points, end points need to be interoperable with each other. This allows for example the communication with ICT between EVSEs and EVs.

10/0

5/20

12


Page 75 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Com

mun

icat

ion

TH

EM

E

Time Synchronization

To achieve network wide synchronization of control tasks on different time-ranges and scalability up to hundreds of systems, while being robust to topology changes and failures, a time-based synchronization method by utilizing concepts of e.g. time-stamping and skew compensation with linear regression is needed.

FINSENY (WP2/WP3)

Sta

te o

f the

art

MU

ST

For clock synchronization protocols like PTP (IEEE1588) and NTP have to be used. To achieve network wide synchronization of control tasks on different time-ranges and scalability up to hundreds of systems, while being robust to topology changes and failures, a time-based synchronization method by utilizing concepts of e.g. time-stamping and skew compensation with linear regression is needed. Features: Establish time synchronization with precision up to 10ms - Re-Sync mechanism - Security Means - Interoperability of the IT-System on North-bound IT I/Fs. (Wrt processes, applications and databases in the sense of CIM/IEC61968, GID/IEC61970, GIS and Interactions) founded on available standards and extensions. - I7 Interoperability on standardized South-bound IT I/Fs as IEC61850, IEC60870 used for control and measurement purposes of SG-devices, DER, DG, Storage and SGEC devices. Should not stand in contradiction to already existing IEC61850 definitions. Expected issues: Deterministic of the communication network Information model interoperability

16/0

5/20

12


Page 76 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Com

mun

icat

ion

EP

IC

Dedicated or Shared Transport Infrastructure

Control from an Aggregator, VPP or DSO needs appropriate transport network capacity, which may be supplied by a dedicated operator on an exclusive or shared basis

FINSENY (WP2)

Pen

ding

MU

ST

South-bound IT (Server) I/Fs need to connect via suitable transport links towards the SG-device locations (e.g. Sub-Stations) Transport links may be realized via: - Optical Fibers, operating WDM, SDH/PDH, Ethernet/LAN, - 3GPP-defined cellular wireless (2G/GPRS 3G/UMTS 4G/LTE) - WIMAX or Microwave private radio network - Powerline based PLC/BPL (Powerline/Broadband Powerline Communication) - Commercial DSL-lines based on ADSL, VDSL or SHDSL

14/0

5/20

12

Com

mun

icat

ion

EP

IC

Connection Monitoring

Monitoring of end-to-end connection parameters (online/offline, latency, bandwidth, etc.) to remote devices

FINSENY (WP3)

Pen

ding

SH

OU

LD

The Communication Network Monitoring component monitors the connection status to all devices managed by the MGCC. This information includes parameters like online/offline, latency, jitter and bandwidth. This information is offered to other components in the MGCC, e.g. warnings about disconnection. 16

/05/

2012

Com

mun

icat

ion

EP

IC

Communication protocols

A precondition for communication protocol for communication between end points (EV, EVSE) and own Back-end (Cloud) is a well-defined stack of communication protocols which enables IT services.

FINSENY (WP5)

Pen

ding

MU

ST

A communication protocol is a formal description and implementation of a digital message format and communication rules. Interoperable ICT needs communication protocols to communicate with each other. Standardized communication protocols allow different ICT to be compatible with each other. 10

/05/

2012

Com

mun

icat

ion

EP

IC

Data Bus Communication

The data bus should provide different communication services (e.g. request/response, publish/subscribe, transactions). Furthermore, it should support different levels of Quality of Service because different applications have different demands, e.g. w.r.t. latency,

FINSENY (All)

Pen

ding

Cou

ld

The data bus should provide different communication services (e.g. request/response, publish/subscribe, transactions). Furthermore, it should support different levels of Quality of Service because different applications have different demands, e.g. w.r.t. latency, frequency of data exchange, quality or time synchronization. 22

/09/

2011


Page 77 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

frequency of data exchange, quality or time synchronization.

Com

mun

icat

ion

EP

IC

Data Bus integration The data bus must provide different communication services (e.g. request/response, publish/subscribe, transactions) storage in different databases.

FINSENY (All)

Pen

ding

MU

ST

The data bus must support different levels of Quality of Service taking into account that different applications have different demands, e.g. w.r.t. latency, frequency of data exchange, quality or time synchronization.

07/0

2/20

12

Com

mun

icat

ion

EP

IC

Device registration for remote monitoring and control

When new devices (e.g. DER, Network Smart Devices) or sub-systems (e.g. Home/Building Energy Management Systems) are installed in or at the edge of the Smart Grid (e.g. Microgrid) they automatically configure themselves (also frequently denoted as Plug & Play). This requirement focuses on the registration of the device or sub-system at a registry which is operated e.g. as part of control center (e.g. the Microgrid Control Center).

FINSENY (WP3)

Und

er E

valu

atio

n by

FI-

WA

RE

MU

ST

Features: After connecting to the network, the device or sub-system connects to a registry where it publishes the description of its capabilities and services with respect to monitoring and control. The registry could be central or distributed. Furthermore, access rights are defined based on contractual agreements which define the level of monitoring and control of the device or sub-system from control center. This registry provides lookup services with rich-query functions for a control center to discover devices with the needed properties or capabilities.

14/1

1/20

11

Com

mun

icat

ion

EP

IC

Interoperable ICT interfaces of EVSE at (semi-)public places

The interoperability of ICT at EVSE is particular important at public places. It is the base for E-Roaming as well as further intelligent charging services.

FINSENY (WP5)

Pen

ding

MU

ST

Especially at public places, EVSE and EVs must be able to operate using ICT. Interoperable ICT enables IT based services for EV-users, E-mobility providers and grid stabilization.

10/0

5/20

12


Page 78 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Com

mun

icat

ion

EP

IC

IP mobility "Pushing” data to the worker handset whatever the telecommunication medium the worker is currently using.

FINSENY (WP2)

Pen

ding

SH

OU

LD

From the Dispatch System point of view, the communication system must be able to “push” data to the worker handset whatever the telecommunication medium the worker is currently using, even if its IP address has changed.

14/0

5/20

12

Com

mun

icat

ion

EP

IC

IPV6 a must for IOT (Customer BEMS and related devices)

It is needed Internet (IPv6) for the BEMS

FINSENY (WP6)

Pen

ding

MU

ST

The BEMS would have to be uniquely identified at the customer premises and in some cases the devices included in energy efficiency services.

18/0

5/20

12

Com

mun

icat

ion

EP

IC

Latency The communication infrastructure must offer a guarantee on the maximal round trip time for messages (from the application on the originator device to the destination device and back)

FINSENY (WP2)

Pen

ding

MU

ST

For time critical events the communication infrastructure must offer a guarantee on the maximal round trip time for messages.

14/0

5/20

12

Com

mun

icat

ion

EP

IC

Secure communication between smart grid and operator

Use of standard security mechanism for the communications

FINSENY (WP6)

Pen

ding

MU

ST

The events and information interchanged between the different eMarket4E actors must be certified by the originator before being taken into account, so that faked events may be dismissed.

21/0

5/20

12


Page 79 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Com

mun

icat

ion

EP

IC

TCP/IP protocol FINSENY (WP6)

Pen

ding

MU

ST

TCP/IP, the most important protocol, is the one used for communications. TCP/IP protocol must be supported between the different actors in the eMarket4E

24/0

5/20

12

Com

mun

icat

ion

FE

AT

UR

E

Speed of communication to the eMarket4E services

Speed of communication is needed to make more automatic the trading process, to involve prosumers and to incentive renewable energy sources.

FINSENY (WP6)

Pen

ding

MU

ST

eMarket4E services will require SOTA internet connectivity speeds. In this case speeds starting at 800 Kbps should be provided.

18/0

5/20

12

Com

mun

icat

ion

FE

AT

UR

E

Reliable data transport over heterogeneous networks

Different Communication Service Providers (CSP) are maybe involved in a single data transaction. End-2-End QoS has to be assured over CSP boundaries including identification of Location of Failure.

FINSENY (All)

Pen

ding

Cou

ld

Different Communication Service Providers (CSPs) are maybe involved in a single data transaction. End-2-End QoS has to be assured over CSP boundaries including identification of Location of Failure.

22/0

9/20

11

Com

mun

icat

ion

FE

AT

UR

E

Communication protocols supporting E-Roaming

A precondition for communication between end points (EV, EVSE) and own Back-end (Cloud) as well as between back-end and back-end of roaming partners is a communication protocol which also enables standardized roaming services. In analogy to mobile networks a Charge Data Record (CDR) contains information about the charging

FINSENY (WP5)

Pen

ding

MU

ST

Interoperable ICT needs communication protocols to communicate with each other. Standardized communication protocols allow different ICT to be compatible with each other. An Open Charge Communication Protocol (OCCP) is in development which enables roaming.

10/0

5/20

12


Page 80 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

process. Certificates and signatures for measuring purposes and ID transfer help with the verification of transferred data.

Com

mun

icat

ion

FE

AT

UR

E

Communication interface to EVSE

Provide a communication interface for communication between EVSE or the back-end and an EV-user.

FINSENY (WP5)

Pen

ding

MU

ST

Communication interfaces enable user to machine and machine to machine communication. It allows transfer of data into the cloud as well as a communication interface for user to EVSE and user to back-end communication.

10/0

5/20

12

Com

mun

icat

ion

FE

AT

UR

E

Communication QoS for V2G

The guaranteed quality level (Best) Different Intermediate Levels (Intermediate) [No Quality Level (No - Best Effort)]; also for VAS, such as educating/training videos for inexperienced EV-users, instead printed manuals/handbooks in the car; real-time mapping services.

FINSENY (WP5)

Pen

ding

SH

OU

LD

For vehicles that are used in different Use Case categories, Fi-Ware and or Smart Grids applications will need to directly control the QoS levels / SLA's of the various SG services. WP5 trials will need a range of CoS levels ranging from guaranteed QoS with low bandwidth levels, guaranteed QoS with high bandwidth levels, and also best effort traffic.

10/0

5/20

12

Com

mun

icat

ion

FE

AT

UR

E

Backup of communication links

Backup solution should be provided for the communication links. Interfaces enabling communication should operate also at the time when the DSO grid is down. Exception can be a LV PLC link.

FINSENY (WP2)

Pen

ding

CO

ULD

Features: Interfaces to different physical media. Back up network for communication between elements. Expected issues: Increased cost of the system.

14/0

5/20

12


Page 81 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Com

mun

icat

ion

FE

AT

UR

E

Device discovery in a Local Area Network

When new devices are installed in a Smart Building or data center they automatically configure themselves (also frequently denoted as Plug & Play). This requirement focuses on discovery mechanisms in the LAN of the building.

FINSENY (WP4)

Und

er E

valu

atio

n

MU

ST

Features: After connecting to the network, the device runs a discovery protocol where it advertises its services to control points. Furthermore, the protocol offers search functions for control points to find devices of interest. Expected issues: no difficult configuration yet ensure secure & trusted access

14/1

1/20

11

Com

mun

icat

ion

FE

AT

UR

E

High priority asynchronous messages (related to CoS or QoS - feature or Story)

In case of alarms, e.g. in conjunction with power inverters, the according asynchronous messages must be transported very fast to the controller, as alarms normally reflects a very soon loss of energy production. In order to further guarantee the stability of the smart grid, therefore, this information must be transported with highest priority or via reserved communication channels. Without time-synchronization just the priority of the (asynchronous) telegram can be used to reduce the latency from submitting the message until receiving it.

FINSENY (WP2)

Alre

ady

cove

red

MU

ST

Establish prioritized communication channels Fast priority routing mechanisms Security Means Interoperability of the IT-System on North-bound IT I/Fs. (Wrt processes, applications and databases in the sense of CIM/IEC61968, GID/IEC61970, GIS and Interactions) founded on available standards and extensions. Interoperability on standardized South-bound IT I/Fs as IEC61850, IEC60870, DNP3 used for control and alarm purposes of SG-devices, DER, DG, Storage and SGEC devices. Expected issues: Reservation of communication channels (hidden to the user) Fast Priority routing Information model interoperability

20/0

8/20

11


Page 82 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Com

mun

icat

ion

FE

AT

UR

E

Interoperable ICT interfaces of EVSE at (semi-)public places supporting E-Roaming

Provide the possibility of varying energy suppliers at one EVSE at a public EVSE.

FINSENY (WP5)

Pen

ding

MU

ST

EVSEs and EVs must be able to operate using ICT even if the EVSE is operated by a foreign E-mobility provider. Interoperable ICT enables IT based roaming services for EV-users, E-mobility providers and grid stabilization.

10/0

5/20

12

Com

mun

icat

ion

FE

AT

UR

E

Need of GSM/GPRS/HSDPA systems for mobile approach

In order to deploy mobile application we need to be supported by GSM/GPRS/HSDPA systems communication

FINSENY (WP6)

Pen

ding

SH

OU

LD

the realization of the nomadic dream for the transactions in the energy market operations: anywhere, anytime, safely

21/0

5/20

12

Com

pone

nt

EP

IC

Interoperability of Public Charge Points with EV (ICT and Electrical)

The charging point supports various models of electric vehicles.

FINSENY (All)

Pen

ding

Mus

t


09/0

6/20

11

Com

pone

nt

EP

IC

Device discovery When new devices (e.g. DER, Network Smart Devices) or sub-systems (e.g. Home/Building Energy Management Systems) are installed in or at the edge of the Smart Grid (e.g. Microgrid) they should get automatically configured (by a generalization of classical Plug & Play mechanisms). This requirement focuses on the discovery of the

FINSENY (WP4)

Pen

ding

MU

ST

As per classical mechanisms, a new device can broadcast its identity on the network to which it gets connected and this message is intercepted by registry services or agents. This first configuration stage then leads to the registration stage

30/0

6/20

12


Page 83 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

device or sub-system by the system to which it gets connected.

Com

pone

nt

FE

AT

UR

E

Servers array for a cloud computing for high speed data processing and running services

A large amounts of data need to be collected and processed in high speed mode through an appropriate infrastructure.

FINSENY (WP6)

Pen

ding

MU

ST

In the Smart Grids energy trading (kind, quantity & price) , where fast processing of large volumes of data is mandatory for securities and other transactions, the world's best response performance and throughput at the millisecond level is a necessity. In addition, a large number of prosumers have a growing need for the real-time analysis of conditions to strengthen their risk management and monitoring capabilities. The high-speed and large-volume data processing solution provides just the right solution for a wide range of prosumer needs. A large amounts of data need to be collected and processed in high speed mode through an appropriate infrastructure. For this reason cloud infrastructure services seems to be the right answer

24/0

5/20

12

Com

pone

nt

FE

AT

UR

E

Registry Services The device registry offers internally in the MGCC different communication services (i.e. REQ/RESP as well as PUB/SUB) over the ESB for other components to provide look-ups.

FINSENY (WP3)

New

WP

3 R

equi

rem

ent

SH

OU

LD

The device registry offers different communication services over the ESB to provide look-up results to other components. These services are request/response as well as subscribe/notification. In the case of subscribe/notification a component can subscribe on changes about a specific query. The registry will notify the component to return updated query results.

16/0

5/20

12

Com

pone

nt

FE

AT

UR

E

Remote Upgrades Remote software upgrades of the charging infrastructure (e.g. pool of charging stations), single charging stations, substations and other grid devices and in the self-configuration case also of sensors and other involved devices.

FINSENY (All)

Pen

ding

MU

ST

Required software upgrades of the charging infrastructure (e.g. pool of charging stations) and single charging station shall be possible remotely. Furthermore remote software updates of substation and other grid devices shall be also possible. In the self-configuration case the remote software upgrade of sensors and other devices is also required. 11

/11/

2011


Page 84 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Com

pone

nt

FE

AT

UR

E

Deploy Apps on Smart Grid Devices

Provide means to modularly manage groups of functionalities (via "Apps") of plenty, distributed smart grid devices.

FINSENY (All)

Pen

ding

MU

ST

The smart grid relies more and more on distributed elements (smart grid devices) that are computing and communicating with each other and with control centers. Apart from hardware elements, these distributed elements are able to provide different functions over time. The functionality, once initialized can be changed via updates or upgrades. In order to allow these updates/upgrades, security issues are to be considered.

10/0

5/20

12

Com

pone

nt

FE

AT

UR

E

High Demand for Computing Resources

For some use cases, it is necessary to provide high performance computing resources for calculation and simulation models in the Microgrid Control Centre including real-time processing.

FINSENY (WP3)

Und

er e

valu

atio

n by

FI-

WA

RE

MU

ST

Extension of FIWARE.Epic.Cloud.PaaS.PaaSScaling for cloud architecture used for the Microgrid Control Centre component. Some operations of the Microgrid Control Centre require higher computing resources than during normal management operations. Therefore the hosting environment should provide means providing computing resources for high demanding tasks. One example is switching to islanding mode in order to quickly check availability of electrical resources in case islanding of the Microgrid is required. Also for long-term planning it may be necessary to provide high performance processing for large-scale planning and simulation. In order to optimize power flow in case of switching to islanding mode, high demand for computing resources for calculation and simulation models in Microgrid Control Centre is required. In order to optimize power flow in case of switching to connected mode, medium processing demand for adaptation to electrical parameters in Overlay Grid is required.

31/0

5/30

12


Page 85 (335)

6.2 Specific ICT Requirements

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Bus

ines

s

TH

EM

E

Control Capability For control functionalities of the Microgrid Control Centre guaranteed performance: deterministic processing time including real-time processing is required

FINSENY (WP3)

New

WP

3 re

quire

men

t

MU

ST

Microgrid control system performs fast, coordinated, synchronized control actions, therefore the maximum delay added by processing should be guaranteed. It may be achieved by processing distribution, resource reservation, performance scaling etc. For control actions real-time constraints for processing should be met. 31

/05/

3012

Bus

ines

s

TH

EM

E Monitoring & Control

Services Monitoring and Control Services are needed to get status information from and control signals to the devices in a reliable and timely manner

FINSENY (WP3)

New

WP

3 R

equi

rem

ent

MU

ST

Monitoring and Control Services have to be defined to get status information from and control signals to the devices in a reliable and timely manner

16/0

5/20

12

Bus

ines

s

EP

IC

Energy Forecast To foresee energy consumption and production at different level (Home, Building, neighborhoods, city etc.) The consumption/production forecast has to cover from short to long time

FINSENY (WP6)

Pen

ding

SH

OU

LD More accurate forecasting of the Energy consumption and

production in a more granular way will be able to support the energy stakeholders to take decisions for Energy trading, for grid load management, for Energy use ( e.g. : in house)

03/0

2/20

12

Bus

ines

s

EP

IC

Processing capabilities at the Marketplace

The Service at the marketplace will have to implement complex operations between the data that will be collected from the Grid users and operators So high level of processing capabilities are needed

FINSENY (WP6)

Pen

ding

MU

ST

The Service at the marketplace will have to implement complex operations between the data that will be collected from the Grid users and operators

18/0

5/20

12


Page 86 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Bus

ines

s

EP

IC

Store and Management of Apps for smart grid devices

Provide access to a huge amount of applications (app store) packaged with the possibility to easily deploy them and manage them on all operated devices.

FINSENY (WP5)

Pen

ding

SH

OU

LD

The app store does not provide the possibility to "buy" new apps, but also methods deploy these Apps on a bunch of gadgets and therewith functionally administer the devices. Different players would have own accounts for their profile and therefore can only "reconfigure" the functionality of their devices (high security requirements!). 10

/05/

2012

Bus

ines

s

FE

AT

UR

E Forecasting of

production/consumption hourly –daily- monthly- yearly

Services able to provide reliable forecasts of od energy production are required and use at user premise in order to plan the energy consumption and to participate to energy trading market.

FINSENY (WP6)

Pen

ding

SH

OU

LD

The users should be able to Know the next/future consumption/production of energy hourly, daily and monthly. Reliable forecasts of energy demand are needed for planning generation and consumption.

21/0

5/20

12

Bus

ines

s

ST

OR

Y Standardized

energy information data

Format for information exchange has to be standardized

FINSENY (WP6)

Pen

ding

SH

OU

LD A standard for energy information and analytic results needs to

be available in order to facilitate the transactions and additional services offered in marketplace as well as energy information analytics for the smart city.

24/0

5/20

12

Fun

ctio

n

TH

EM

E Contract information To manage contract information FINSENY

(WP6)

Pen

ding

MU

ST

Contract information need to be updated daily in order to take decisions on the scheduling of the consumption of the energy by the BEMS or the final user.

21/0

5/20

12

Fun

ctio

n

TH

EM

E

Discovery and identification of non-network-connected entities

Extension of device configuration mechanisms to physical entities that do not have a network interface

FINSENY (WP4)

Pen

ding

SH

OU

LD Sensors may play the role of a network interface for physical

entities that do not have a network interface (e.g. legacy appliances in a building) : these entities can get discovered, identified and registered through sensors in a way similar to what is done for regular networked devices using plus & play mechanisms

30/0

6/20

12


Page 87 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Fun

ctio

n

EP

IC

Transactional mechanisms

For a series of applications in the FINSENY project, transactional mechanisms are required to perform critical operations throughout a distributed system in a consistent and reliable way. Actions like contract management, buying or selling energy, auxiliary service offers and management operations have to be supported by distributed ICT transactional mechanisms with transactional guarantees.

FINSENY (WP3)

NE

W W

P3

requ

irem

ent

MU

ST

A transaction is a logical unit of work coordinating distributed data and process (service) handling. Transactions usually start with a begin operation and finishes with either the commit or the abort (rollback) operation. Between start of, the commit or abort operation, data operations and process coordination activities are executed. Classic transactions are bracketed by key control operations as Begin-Transaction, Commit-Transaction and Abort-Transaction. Each transaction must respect all the ACID properties: Atomic, Consistency, Isolation and Durability. Enhanced transaction mechanisms have to control the operations and outcome of multiple applications or services. For this they include a coordination and correlation manager. It is useful to define transaction services for short term and long term transactions.

14/0

5/20

12

Fun

ctio

n

EP

IC

Rating system A rating system should be available that facilitates a possibly objective assessment of all marketplace actors. Such a system should be objective, easy to understand, comprehensible and follow state-of-the-art concepts.

FINSENY (WP6)

Pen

ding

SH

OU

LD

A rating system is available that facilitates a possibly objective assessment of all marketplace actors. This enables the prosumers to consider them prior to transactions in order to enhance the prosumers risk management analysis. The rating system could be similar to well-known systems which are in use on websites such as amazon or eBay. 23

/05/

2012

Fun

ctio

n

EP

IC

Control Apps A control center can remotely install control applications on other devices

FINSENY (WP3)

NE

W W

P3

Req

uire

men

t

CO

ULD

Similar to the requirement in FINSENY.EPIC.Modularity.ExecutionContainer code can be deployed at a device. This should also enable to remotely install control apps which have access to the control API of the device. 16

/05/

2012


Page 88 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Fun

ctio

n

EP

IC

Network Cell synchronization

A synchronization protocol is needed to synchronize different networks in terms of frequency, phase and voltage

FINSENY (WP3)

New

WP

3 re

quire

men

t

SH

OU

LD

The protocol provides a control algorithm in order to synchronize different networks with different phase, frequency and / or voltage. When implying more than two networks, the protocol can be peer-to-peer based, but the master/slave solution is used in the other cases. Fast and reliable control loops are used to ensure that the synchronization is achieved correctly

31/0

5/20

12

Fun

ctio

n

EP

IC

Interoperability of Building energy management system with the grid (distribution network or Microgrid)

Standard interface between the grid and the building energy management system should allow the exchange of upward monitoring and downward control information between the two

FINSENY (WP4)

Pen

ding

SH

OU

LD

The technologies that can support such a dialogue are extremely diverse. At the most elementary level it is a form of Inter-Process Communication (IPC) between the grid and the building components and, as such, all the following are possible: • SOAP web services • REST web services • semantic web • custom socket-level protocol (low level but reliable and widely deployed). • structured data exchanges (e.g. following an XML, JSON or ASN.1 serialization)

30/0

6/20

12


Page 89 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Fun

ctio

n

EP

IC

Electricity Price signal hourly – daily

Fixing and managing the Price .The main price to be dealt with are: Energy Price derived from auctions (for who participate to Energy Trading) (prices and quantity exchanged) Final Energy Prices- Tariff (Price/kW to be pay from the final customers) (Defined from the Energy Retails. It derives from the business model and pricing model followed.) The price has to be notified / shown to all market stakeholders according their roles in the electronic market place.

FINSENY (WP6)

Pen

ding

MU

ST

The final user should know the price of the electricity in order to incentive or disincentive the consumption of the energy depending on the price. This interface must be as much detailed as possible covering final price per minute, incentives, contra-incentives, etc. The final prices of the electricity for customers need to be updated hourly-daily in order to take decisions on the scheduling of the consumption of the energy by the BEMS or the final user.

21/0

5/20

12

Fun

ctio

n

EP

IC

Operate Operate (or cancel) control value also at a specific point in time (time activated operate)

FINSENY (WP3)

NE

W W

P3

Req

uire

men

t

MU

ST

Service is specified in detail in IEC61850 ACSI

16/0

5/20

12

Fun

ctio

n

EP

IC

Select before operate

Select a control point before sending an operate command. This locks the control point and control sequences can be realized.

FINSENY (WP3)

NE

W W

P3

Req

uire

men

t

CO

ULD


16/0

5/20

12


Page 90 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Fun

ctio

n

EP

IC

Control Apps A control center can remotely install control applications on other devices

FINSENY (WP3)

NE

W W

P3

Req

uire

men

t

CO

ULD

Similar to the requirement in FINSENY.EPIC.Modularity.ExecutionContainer code can be deployed at a device. This should also enable to remotely install control apps which have access to the control API of the device. 16

/05/

2012

Fun

ctio

n

EP

IC

Logging Service The control center can specify logging options at remote device/systems and can query log files afterwards.

FINSENY (WP3)

NE

W W

P3

Req

uire

men

t

CO

ULD

Logging service is specified in detail in IEC61850 ACSI

16/0

5/20

12

Fun

ctio

n

EP

IC

Transaction Services


FINSENY (WP3)

NE

W W

P3

requ

irem

ent

MU

ST

A transaction is a logical unit of work coordinating distributed data and process (service) handling. Transactions usually start with a begin operation and finishes with either the commit or the abort (rollback) operation. Between the start of the commit or abort operation, data operations and process coordination activities are executed. Classic transactions are bracketed by key control operations as Begin-Transaction, Commit-Transaction and Abort-Transaction. Each transaction must respect all the ACID properties: Atomic, Consistency, Isolation and Durability. Enhanced transaction mechanisms have to control the operations and outcome of multiple applications or services. For this they include a coordination and correlation manager. It is useful to define transaction services for short term and long term transactions.

14/0

5/20

12


Page 91 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Fun

ctio

n

FE

AT

UR

E Control of EV

(charging signals) EVSE and EVs must be ready in order to start the power transfer any time.

FINSENY (WP5)

Dom

ain

Spe

cific

MU

ST

EVSE should get charging signals which enable or disable charging at the specific charging outlet of an EVSE. This helps stabilizing the grid and makes intelligent charging possible.

10/0

5/20

12

Fun

ctio

n

FE

AT

UR

E Energy source

information hourly – daily: generation, price, source …

The energy source information of the electricity need to be updated hourly-daily in order to take decisions on the scheduling of the consumption of the energy by the BEMS or the final user.

FINSENY (WP6)

Pen

ding

MU

ST

The energy source information of the electricity need to be updated hourly-daily in order to take decisions on the scheduling of the consumption of the energy by the BEMS or the final user.

21/0

5/20

12

Fun

ctio

n

FE

AT

UR

E Forecast of grid load

and energy demand Services able to provide reliable forecasts of grid load and energy demand are required in order to plan energy generation and consumption.

FINSENY (WP6)

Pen

ding

SH

OU

LD Reliable forecasts of grid load and energy demand are needed

for planning generation and consumption.

18/0

5/20

12

Fun

ctio

n

FE

AT

UR

E Power limits

information For the user to get detailed information of the consumption and to reduce it using a DMS application choosing what it offers.

FINSENY (WP6)

Pen

ding

MU

ST

The information about the power limit in the electric contracts needs to be updated daily in order to take decisions on the scheduling of the consumption of the energy by the BEMS or the final user.

21/0

5/20

12

Fun

ctio

n

FE

AT

UR

E High portability

applications for fixed and mobile services targeted to the final customer

The applications for the services about the eMarket4E have to function properly on the widest possible range of devices, whether they are fixed or mobile, with different operating systems.

FINSENY (WP6)

Pen

ding

MU

ST

The applications for the services about the eMarket4E have to function properly on the widest possible range of devices, whether they are fixed or mobile, with different operating systems.

18/0

5/20

12


Page 92 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Fun

ctio

n

ST

OR

Y Accounting for V2G

usage V2G usage must be accounted properly to ensure that an EV-user is paid for his reinserted energy.

FINSENY (WP5)

Pen

ding

MU

ST

Consumed and inserted power is multiplied via amounts (rating), and compared (clearing), and finally billed to the customer (potentially "cash back" for customer).

10/0

5/20

12

Info

rmat

ion

EP

IC

Conditional Control A series of control operation have to be executed under certain conditions. A control service should be available which allows to define the conditions on atomic and task level

FINSENY (WP3)

New

WP

3 R

equi

rem

ent

MU

ST

Almost any complex control task will require conditional control: the ability to direct the flow of execution based on a condition. The simplest forms are dealing with IF-THEN-ELSE statements. Conditional control services should be defined on atomic and task level.

14/0

5/20

12

Info

rmat

ion

EP

IC

Create control set Switch from one set of setting values to another one

FINSENY (WP3)

NE

W W

P3

Req

uire

men

t

SH

OU

LD Service is specified in detail in IEC61850 ACSI

16/0

5/20

12

Info

rmat

ion

EP

IC

Creation of data set Create a data set as a collection of data of several objects

FINSENY (WP3)

New

WP

3 R

equi

rem

ent

SH

OU

LD Service that creates an ordered group of data or data attributes

organized as a single collection for the convenience of the client. Thus, it is avoided that each data or data attribute has to be requested in a single message, the data set values can be requested in a single message which saves bandwidth consumption.

24/0

5/20

12


Page 93 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Info

rmat

ion

EP

IC

Customers Profile EV

The customer profile is needed to allow transparent use of charging infrastructure at (foreign) EVSE. For example, the E-Mobility provider needs to know at which (foreign) charging stations his customer is allowed to charge. This information will be stored in the customer’s profile. A high number of other parameters will be stored related the customers profiles.

FINSENY (WP5)

Pen

ding

MU

ST

Customers profile data must be storage and available taking into account the legal framework of the EU countries.

10/0

5/20

12

Info

rmat

ion

EP

IC

Operate Operate (or cancel) control value also at a specific point in time (time activated operate)

FINSENY (WP3)

NE

W W

P3

Req

uire

men

t

MU

ST


16/0

5/20

12

Info

rmat

ion

EP

IC

Create control set Switch from one set of setting values to another one

FINSENY (WP3)

NE

W W

P3

Req

uire

men

t

SH

OU

LD Service is specified in detail in IEC61850 ACSI

16/0

5/20

12

Info

rmat

ion

EP

IC

Conditional Control A series of control operation have to be executed under certain conditions. A control service should be available which allows to define the conditions on atomic and task level

FINSENY (WP3)

New

WP

3 R

equi

rem

ent

MU

ST


14/0

5/20

12


Page 94 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Info

rmat

ion

EP

IC

Control Capability For control functionalities of the Microgrid Control Centre guaranteed performance: deterministic processing time including real-time processing is required

FINSENY (WP3)

New

WP

3 re

quire

men

t

MU

ST

Microgrid control system performs fast, coordinated, synchronized control actions, therefore the maximum delay added by processing should be guaranteed. It may be achieved by processing distribution, resource reservation, performance scaling etc. For control actions real-time constraints for processing should be met.

31/0

5/30

12

Info

rmat

ion

FE

AT

UR

E Request / Response

for data set Request/Response for data set FINSENY

(WP3)

New

WP

3 R

equi

rem

ent

SH

OU

LD This is a collection of data for the request / response service.

24/0

5/20

12

Info

rmat

ion

ST

OR

Y Storage of User

profile User profiles must be stored in consideration of the design principles (security, data integrity ...).

FINSENY (WP5)

Pen

ding

MU

ST

User profile data must be stored on servers in the cloud to be able to gain access from any end points or back-end that is connected to the cloud.

10/0

5/20

12

Info

rmat

ion

ST

OR

Y Tariffing signals and

profiles To provide tariff signals updated daily and to have user profiling day by day updated

FINSENY (WP6)

Pen

ding

MU

ST

Tariffing signals and user profiles need to be updated daily in order to take decisions on the scheduling of the consumption of the energy by the BEMS or the final user.

21/0

5/20

12

Info

rmat

ion

ST

OR

Y

User Software Agent System

To use Autonomous SW entity this observes and stores the final user energy buying habits. Then it acts upon request and directs its activity towards achieving best goals.

FINSENY (WP6)

Pen

ding

MU

ST

Autonomous SW entity which observes and stores the final user energy buying habits. Then it acts upon request and directs its activity towards achieving best goals.

18/0

5/20

12


Page 95 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Info

rmat

ion

ST

OR

Y Charging Profile The EV-user needs the possibility to

configure preferences like time, amount of charged energy and charging costs.

FINSENY (WP5)

Pen

ding

SH

OU

LD Each time an EV-user is charging at an EVSE, a charging

profile may be helpful to pre-select charging specific settings.

10/0

5/20

12

Info

rmat

ion

ST

OR

Y

Analysis of (huge amounts of) data

The analysis of data is processed in the cloud ("Big data"). There is only a minimal calculation effort for end points like EVs or EVSE.

FINSENY (WP5)

Pen

ding

MU

ST

The analysis of data stored in databases can be done in the cloud. The computing capacity in the cloud is ideal for all kinds of algorithms and calculations needed for a proper data analysis. For example the analysis of energy demand and supply is a data analysis that is important to forecast energy prices.

10/0

5/20

12

Info

rmat

ion

ST

OR

Y Time Data

Exchange Exchange in short periods of time for large amounts of data collected and processed in high speed mode.

FINSENY (All)

Pen

ding

MU

ST

The exchange of information related to pricing, demand, available energy, etc. Must be done in real time for regional databases and many times daily with centralized systems.

28/1

2/20

11

Info

rmat

ion

ST

OR

Y

Distributed Data processing at local/community level

A Distributed Data processing at local/community level is needed in order to assure a greater scalability of the services. More it can enable to process and provide services at local level reducing the timing to delivery

FINSENY (WP6)

Pen

ding

MU

ST

At local /community level it is necessary a distributed data processing.

23/0

5/20

12

Info

rmat

ion

ST

OR

Y Metering at EVSE Metering different parameters

(power, reactive power, current, temperature, voltage …) is necessary for monitoring of EVSE.

FINSENY (WP5)

Pen

ding

MU

ST

Measurement at EVSE is possible likewise smart metering. Parameters as power, reactive power, current, temperature, voltage …need to be collected for a proper monitoring of an EVSE.

10/0

5/20

12


Page 96 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Info

rmat

ion

ST

OR

Y

Metering at grid nodes and transfer of data to back-end

Provide available grid load information for management purposes. EVSE (or E-mobility providers) need to have the required intelligence to act according to the received data.

FINSENY (WP5)

Pen

ding

MU

ST

Dynamic grid load information ("Forecast of grid loads") need to be distributed automatically (push) or made available (pull) to charge station providers. In order to facilitate charge station technologies to work with different grid operators, the respective exchange protocols and data formats should be universal. 10

/05/

2012

Info

rmat

ion

ST

OR

Y Set Configuration Set configuration parameter in field

device FINSENY (WP3)

New

WP

3 R

equi

rem

ent

MU

ST

A service for setting data for configuration purpose.

24/0

5/20

12

Info

rmat

ion

ST

OR

Y internal

Communication Services

Information transport between sub-devices inside a device

FINSENY (WP3)

New

WP

3 R

equi

rem

ent

MU

ST

Internal communication means services to exchange information between components inside or nearby to an IED (e.g. electronic components inside a substation for measurement and control).

24/0

5/20

12

Info

rmat

ion

ST

OR

Y Publish / Subscribe

for data set Publish / Subscribe for data set FINSENY

(WP3)

New

WP

3 R

equi

rem

ent

SH

OU

LD This is a collection of data for the publish / subscribe service.

24/0

5/20

12

Info

rmat

ion

ST

OR

Y Real time data

exchange between Gateway-Server and Servers- Cloud Data center

In order to provide information to final user in near real time, we need a real time data exchange among the devices in the system.

FINSENY (WP6)

Pen

ding

MU

ST

It is strongly necessary to have a real time data exchange between Gateway-Server and Servers- Cloud Data center

21/0

5/20

12


Page 97 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Info

rmat

ion

ST

OR

Y

Scheduled actions Scheduled actions are to be used to transmit automatically a pre-defined set of data to and/or from the power site (e.g. power inverter) without sending messages for ordering that data in before. Such data could be regular status information, metering data, meteorological data, etc. If the transmission time is not deterministic a time-stamp should be part of the transmission.

FINSENY (WP2)

Pen

ding

SH

OU

LD

Features: Interoperability on standardized South-bound IT I/Fs as IEC61850, IEC60870 used for control and measurement purposes of SG-devices, DER, DG, Storage and SGEC devices. Interoperability of the IT-System on North-bound IT I/Fs. (Wrt processes, applications and databases in the sense of CIM/IEC61968, GID/IEC61970, GIS and Interactions) founded on available standards and extensions. Please note: The relevant IT-Systems to control the above mentioned devices may be hosted by Aggregators, VPPs and the DSO. Contained functions are: Time-stamped messages, Auto-cyclic messages, setting-up mechanism, and de-install mechanism. Expected issues: Bandwidth reservation Information model interoperability

14/0

5/20

12


Page 98 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Com

mun

icat

ion

EP

IC

Addressing (IPV6) Use IPV6 addressing for each device connected to the Power Grid. Once it's connected it should keep the same, fix, IPV6 address.

FINSENY (WP3)

New

WP

3 re

quire

men

t

MU

ST

Almost all Internet Service Providers still offer IPV4 as standard option. ISP feel more comfortable using dynamic address assignment, as fixe assignment is more expensive and limited scalability due to its limited addressing capabilities. This is a problem for Power Grids, where it´s mandatory to know with which equipment the Control Center is talking with. This problem will not be any more using IPV6, after auto-configuration any device would be assigned with a fixed IPv6 address belonging to the appropriate subnet, or virtual private network. One relevant point that may not be covered by IPv6 protocol as an Standard would be the limited visibility that IPs should have, for example, a customer device should always be able to reach the control center but never another customer device. Other improvements incorporated in this protocol, as multicast or mandatory security would be also profitable for the Power Grids.

31/0

5/20

12

Com

mun

icat

ion

EP

IC

Indirect connectivity Entities that do not have a native network interface should have a network presence

FINSENY (WP4)

Pen

ding

SH

OU

LD

Connectivity mediated by sensors and actuators is set up to extend the network beyond natively networked devices, providing a network identity and connectivity to all kinds of physical entities in the building domain

30/0

6/20

12


Page 99 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Com

mun

icat

ion

EP

IC

MultiVPN Monitoring, metering and control devices, communicating all with the Control Center, are the essential tasks required to manage a power grid. The signals they send are managed by different sub-systems within the control centers. Internet may provide a virtual private network for each of the subsystems, each one, with its own criteria for safety and quality of service.

FINSENY (WP3)

Dom

ain

Spe

cific

CO

ULD

This requirement describes how Internet Service Providers could supply different private networks "Power Grid" dedicated, over the same physical connection. The three essentials would be: one for remote control tasks, another for monitoring, and the third for billing metering. Each one would have its own security and QoS Requirement. For example, Remote Control and Monitoring will require low latency; meanwhile the billing meters could transit as best effort data. Although, these tasks can be solved nowadays with proprietary added routers at the terminal points or directly at the application layer. Future Internet could provide directly these value added services, even more, Virtual Private Networks could bring new paid services to final customers, for example, remote home automation, bank connections, etc. Expected issues: NAT, Firewall configuration

31/0

5/20

12

Com

mun

icat

ion

EP

IC

Network Cell synchronization

A synchronization protocol is needed to synchronize different networks in terms of frequency, phase and voltage

FINSENY (WP3)

New

WP

3 re

quire

men

t

SH

OU

LD


31/0

5/20

12

Com

mun

icat

ion

ST

OR

Y

Building data transmission availability

The user gets detailed information of the consumption in their homes, and also gets information from the utilities on the tariffs. The user can monitor home overall consumption and the BMS will be able to reduce the energy consumption at user premises.

FINSENY (WP6)

Pen

ding

MU

ST

The BEMS installed at the user premises will have to transmit data over the Internet. Always on connectivity and ADSL speeds are required and on the provider side (Marketplace) Data Mining will thus apply.

22/0

5/20

12


Page 100 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Com

mun

icat

ion

ST

OR

Y

Select before operate

Select a control point before sending an operate command. This locks the control point and control sequences can be realized.

FINSENY (WP3)

NE

W W

P3

Req

uire

men

t

CO

ULD


16/0

5/20

12

Com

mun

icat

ion

ST

OR

Y

Service discovery mechanism to set appropriate CoS for communication

A service discovery mechanism needs to be specified and implemented in order to set the communication network CoS according to the SG-devices´ communication requirements.

FINSENY (WP2)

Pen

ding

MU

ST

The service discovery mechanism is required for every service provisioning and usage.

14/0

5/20

12

Com

pone

nt

FE

AT

UR

E

Auto-configuration When new devices (e.g. DER, Network Smart Devices) or sub-systems (e.g. Home/Building Energy Management Systems) are installed in or at the edge of a Smart Grid (e.g. a Microgrid) they automatically configure themselves (also frequently denoted as Plug &Play). This theme consists of different requirements w.r.t. addressing, device description, discovery, registration and lock-up as well as secure and trusted access.

FINSENY (WP3/WP4)

Und

er E

valu

atio

n by

FI-

WA

RE

MU

ST

For details see EPIC.FINSENY.Autoconfiguration.Addressing, EPIC.FINSENY.Autoconfiguration.DeviceDescription, EPIC.FINSENY.Autoconfiguration.RegistrationAndLookUp, EPIC.FINSENY.Autoconfiguration.RegistrationAndLookUp

14/1

1/20

11


Page 101 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description

Last

m

odifi

ed

Com

pone

nt

FE

AT

UR

E Remote Initialization Provide the possibility to initialize a

newly installed smart grid device (e.g. smart meter) remotely.

FINSENY (All)

Pen

ding

Mus

t

When new smart grid devices are installed, it is usable not only configuring some parameters remotely, but also to choose the actual functionality flexibly depending on the actual place and environment where the device is used (e.g. smart meter).

10/0

5/20

12


Page 102 (335)

7. Security Requirements The objective of the Security ICT Requirements can be described as the collective processes and mechanisms by which sensitive and valuable information and services are protected from publication, tampering or collapse by unauthorized activities or untrustworthy individuals and unplanned events respectively.

Security planning for ICT involves the development of security policies (i.e., acceptable use, disaster recovery, breach notification), implementation of security controls (to include hardware, software, and personnel), risk assessment, cryptographic use and controls, and legal/ethical considerations. It is essentially the strategic view of computer security as opposed to the tactical view that an intrusion detection analyst might have.

The Security aspect of the FINSENY Project was managed by WP1 with the contributions of ICT Requirements developed by other Use Case WPs; therefore the following templates describe the specification for the Security related ICT Requirements:


Page 103 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description Last

m

odifi

ed

All

TH

EM

E

Access Before an EV-user can charge, he must be able to park its EV on the dedicated place. The access to the charging outlet of the EVSE could be restricted, e.g. via a locking mechanism. In order to overcome the locking mechanism the EVSE ICT can be used (RFID, smartcard ...).

FINSENY WP5

Pen

ding

MU

ST

EVSE must be accessible. Physical barriers should not prevent EV-users of using a certain EVSE. The charging outlet of an EVSE may be locked and only be unlocked by after identification and authentication to prevent unauthorized EV-users from charging. 10

/05/

2012

All

FE

AT

UR

E Access by

different connected devices

To enable the user to access to the market applications by different device and operative systems in order to Avoid costs for changing communication technology.

FINSENY WP6

Pen

ding

SH

OU

LD The contract negotiation and the act of

offering and buying energy surplus should be designed by following web-service API, so that different application (including web-based ones) can be developed for different devices.

24/0

5/20

12

All

EP

IC

Access Control When new devices (e.g. DER, Network Smart Devices) or sub-systems (e.g. Home/Building Energy Management Systems) are installed in or at the edge of the Smart Grid (e.g. Microgrid) they automatically configure themselves (also frequently denoted as Plug & Play). This requirement focuses on secure and trusted role-based access control of the device and its monitoring &control functions.

FINSENY WP3

Pen

ding

MU

ST

Features: The auto-configuration process should define mechanisms for role-based access including authorization and authentication.

14/1

1/20

11


Page 104 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description Last

m

odifi

ed

All

EP

IC

Authentication and access control

To have a role-based access-control system in order to assure the user rights into the marketplace

FINSENY WP6

Pen

ding

MU

ST

All transactions on the marketplace need to be authenticated and the respective users need to have appropriate rights. This requires a role-based access-control system.

24/0

5/20

12

All

TH

EM

E

Authorization The authorization of an identified and authenticated EV-user or EV should be provided to limit access to a specific EVSE only to certain customers.

FINSENY-WP5

Pen

ding

SH

OU

LD

Components shall enforce separation of duties through assigned access authorization. The user privileges should be restricted to only those that are required for each person's role, taking into account emergency cases. This reflects least privileged application. Specifically to consider is handling in emergency situations, where a user rights override option should be always implemented. This requires appropriate considerations in the general account policy definition as well as consideration of the specific situation (e.g., by using the situational information (emergency) as additional parameter for access control) This is to (also) address certain types of DoS attacks.

10/0

5/20

12

All

FE

AT

UR

E Data privacy on

energy exchange To have high-medium level of user data privacy protection.

FINSENY WP6

Pen

ding

MU

ST

The information provided concerning offering and buying energy surplus should not be used by other parties not participating directly in the eMarketplace4E.

18/0

5/20

12


Page 105 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description Last

m

odifi

ed

All

FE

AT

UR

E Data privacy on

energy home use and contract information

To provide security to the access of the user to the information of the consumption and to the contract of the DMS application.

FINSENY WP6

Pen

ding

MU

ST

The information interchanged between the user and the BEMS and between the eMarket4E and the BEMS must be certified by the originator before being taken into account. 21

/05/

2012

All

EP

IC

Data backup and recovery

Backups of critical software, applications, and data for all components of the data system should be assured.

FINSENY

Pen

ding

Mus

t

Backups of critical software, applications, and data for all components of the data system should be assured.

07/0

2/20

12

All

EP

IC

Data confidentiality

It shall be possible to ensure the confidentiality of the communicated data by cryptographic mechanisms, unless otherwise protected by alternative physical measures.

FINSENY

Pen

ding

Mus

t

It shall be possible to ensure the confidentiality of the communicated data by cryptographic mechanisms, unless otherwise protected by alternative physical measures.

07/0

2/20

12

All

TH

EM

E

Identification & Authentication

After having access, the identification and authentication of an EV-user or EV should be provided to make an authorization process possible.

FINSENY-WP5

Pen

ding

Sho

uld

The identification is enabled by using a unique ID through an appropriate identification medium. The authentication of the transferred ID is verified by a back-end server which stores the IDs. System components shall uniquely authenticate users and specific components before establishing a connection.

10/0

5/20

12

All

EP

IC

Privacy of Contract

The information provided in contract should not be used by other parties

FINSENY WP6

Pen

ding

MU

ST

The information provided in contract and offers must not be used by other parties

24/0

5/20

12


Page 106 (335)

SG

AM

FI-

WA

RE

Name Goal Source

Sta

tus

Prio

rity

Description Last

m

odifi

ed

All

FE

AT

UR

E Reliable and

deterministic signal commands

from the Marketplace

It is needed to have reliable signals commands from the marketplace in order to be able to contract trusted services.

FINSENY WP6

Pen

ding

MU

ST

This UC will need reliable and provisioning QoS, since signaling is involved between the GRID and the user BEMS. The latter signals will have to arrive reliably in order to shape the demand curve. 18

/05/

2012

All

TH

EM

E

Security. Management

Security management policy has to consider all involved cryptographic protection means, including key management infrastructure, certificate management, security policies, addressing both, technical and organizational means.

FINSENY

Pen

ding

Mus

t

Security management policy has to consider all involved cryptographic protection means, including key management infrastructure, certificate management, security policies, addressing both, technical and organizational means. 24

/08/

2011

All

EP

IC

Service Transparency at

the customer premises: Data

Access

A transparent service may allow the customer to pick the conditions which will earn them greater savings.

FINSENY WP6

Pen

ding

MU

ST

Emarket4E services will have to access information coming from various devices at the customer premises. Thus Layer 3 protocols should be supported, Access technology agnostic, compatibility with AAA services and also information appliance agnostic.

18/0

5/20

12

All

EP

IC

Logging Service Logging Service FINSENY WP3

Dom

ain

Spe

cific

NE

W W

P3

Req

uire

men

t Domain Specific Enabler based on IEC61850

16/0

5/20

12


Page 107 (335)

8. Conclusions During the definition, analysis and development phase of the final specification of requirements, the Use Case Work Packages made and initial classification of the ICT Requirements as specific to the FINSENY domains or generic for the FI-WARE Platform. This additional step performed before preparing the consolidation of requirements allowed: • Consolidate all requirements according to their area of influence as:

o Generic: to be registered and managed by FI-PPP AB, and o Specific: related to FINSENY’s domains and required to develop Domain Specific

Enablers (DSE). • Generic ICT Requirements supports the definition of additional functionalities to be developed by the

FI-WARE project. • Specific ICT Requirements allows the development of Domain Specific Enablers, their analysis and

definition of need for experimentation and trials.

As during the first consolidation of ICT Requirements, for the final ICT Requirements specifications the additional data received from the Use Case Work Packages were merged and classified according to the Smart Grid Architecture Model (SGAM) category layers to ensure a coherent consolidation. This SGAM was developed by the Reference Architecture Working Group of the Smart Grid Coordination Group of CEN/CENELEC/ESI. An additional layer “Security” was included to ensure that the security impact on the ICT Requirements was taken in consideration.

Many of the identified requirements cannot be considered specifically related to Communication and Information Technologies, but their impact on the planning and design of systems and applications is so important that, once consolidated, were included in the Services classification.

The final specifications of the Requirements were prepared using the template developed by the FI-PPP AB to ensure coherence between all FI-PPP projects.


Page 108 (335)

9. Terms and Abbreviations AB Architecture Board

ADSL Asymmetric Digital Subscriber Line

API Application Programming Interface

CoS Class of Service

CSP Communication Service Provider

CT Communication Technology

DAC Data Acquisition and Control

DB Database

DCAC Dynamic Control of Active Components

DN Distribution Network

DoS Denial of Service

DSE Domain Specific Enablers

DSL Digital Subscriber Line

DSM Demand Side Management

DSO Distribution System Operator

DSR Domain Specific Requirements

ECC Elliptic Curve Cryptography

EPRI Electrical Power Research Institute

EV Electric vehicle

EVSE Electric Vehicle Supply Equipment

FAN Field Area Network

FI Future Internet

FI Future Internet

FICC Function / Information / Communication / Component layers of the SGAM

FINSENY Future INternet for Smart ENergY

FI-PPP Future Internet Public Private Partnership

FI-WARE Future Internet Ware (Technology foundation: Future Internet Core Platform)

FLIR Fault Location, Isolation and Service Restoration

FR Functional Requirement

GPRS General Packet Radio Service

GUI Graphical User Interface

HMI Human Machine Interface

HW Hardware

IATF Information Assurance Technical Framework

ICT Information and Communication Technology

ID Identifier

IDS Intrusion Detection System

IEC International Electro technical Commission

IED Intelligent Electronic Device

IEEE Institute of Electrical and Electronics Engineers

IETF Internet Engineering Task Force

IP Internet Protocol

IS Information Security

ISO International Standardization Organization


Page 109 (335)

IT Information Technology

LAN Local Area Network

LTE Long Term Evolution

MPLS Multiprotocol Label Switching

MV Medium Voltage

MVDAC Medium Voltage Data Acquisition and Control from utility control centre

MWFM Mobile Work Force Management

NFR Non Functional Requirement

PAS Publicly Available Specification

PC Personal Computer

PDH Plesiochronous Digital Hierarchy

PLC Power Line Communication

QoS Quality of Service

R&A Reliability and Availability

RSA Rivest, Shamir, Adleman, cryptographic algorithm allowing signature and encryption

RTU Remote Terminal Unit

SDH Synchronous Digital Hierarchy

SDL (here: Microsoft) Security Development Lifecycle

SEG Smart Energy Grid

SG Smart Grid

SGAM Smart Grid Architecture Model

SGEC Smart Grid Energy Control of Power Grid

SHDSL Single-pair High-speed Digital Subscriber Line

SLA Service Level Agreement

SM Smart Meter

SW Software

TDM Time Division Multiplex

TLS Transport Layer Security

TSO Transmission System Operator

UC Use Case

UC WP Use Case Work Package

UML Unified Modelling Language

UMTS Universal Mobile Telecommunications System

WDM Wavelength Division Multiplexing

WP Work package


Page 110 (335)

10. References

• FINSENY Internal Reports: IR2.1, IR3.1, IR4.1, IR5.1 & IR6.1 • Open Security Architecture (OSA) - http://www.opensecurityarchitecture.org • Open System Interconnection - http://en.wikipedia.org/wiki/OSI_model • ISO/IEC 7498-1:1994, Information technology—Open Systems Interconnection—Basic

Reference Model: The Basic Model • ITU-T Recommendation X.200 (11/93) [ISO/IEC 7498-1:1994], Open Systems Interconnection

- Basic Reference Model. • M/490 Reference Architecture WG – 02/09/2011 – Smart Grids CG – Reference architecture

WG - © CEN-CENELEC-ETSI 2011 • Communication architecture for the Smart Grid - P Wetterwald, J Heiles, R Forbes, O Elloumi • IEC TC57 Reference Architecture –Scope and Layers – www.iectc57.ucaiug.org • Standardization and Requirements: Methodology for comparison – PlasTEP • Security Quality Requirements Engineering (SQUARE) Methodology - Nancy R. Mead, Eric D.

Hough, Theodore R. Stehney II - November 2005 • Towards a Goal-Oriented Requirements Methodology based on the Separation of Concerns

Principle - Geórgia Maria C. de Sousa and Jaelson Brelaz de Castro - Centro de Informática – Universidade Federal de Pernambuco (UFPE) - Caixa Postal 7851, CEP: 50.732-970, Recife – PE – Brasil

• Agile Methodology in Requirements Engineering – Sujoy Bose, Manish Kurhekar and Joydip Ghoshal – SETlabs Briefings Online – 2008

• PDM: A requirements methodology for software system enhancements - R. G. Mays, L. S. Orzech, W. A. Ciarfella, R. W. Phillips – IBM Systems Journal – Volume 24, Number 2

• Recommendations for the Description and Management of Use Cases for Smart Grids - DKE Deutsche Kommission Elektrotechnik Elektronik Informationstechnik – José M. Gonzalez, Jörn C. Trefke - Version of 28.02.2011

• IntelliGrid Methodology for Developing Requirements for Energy Systems - INTERNATIONAL ELECTROTECHNICAL COMMISSION - ISBN 2-8318-9525-1 - Edition 1.0 2008-0

• IEC Smart Grid Standardization Roadmap - SMB Smart Grid Strategic Group (SG3) - June 2010; Edition 1.0

• Agile Requirements Modelling - http://www.agilemodeling.com/ • Beywatch European project – ICT for energy efficient Homes and Neighbourhoods –

http://www.beywatch.eu/ • GridWise Architecture Council (GWAC) - http://www.gridwiseac.org/ • Tech team.com

http://www.teach-ict.com/as_a2_ict_new/ocr/A2_G063/331_systems_cycle/specifications/miniweb/pg3.htm

• SOA Reference Architecture Technical Standard: Business Process Layer – http://www.opengroup.org/soa/source-book/soa_refarch/busproc.htm

• Business Layers Guidelines - J.D. Meier, Alex Homer, David Hill, Jason Taylor, Prashant Bansode, Lonnie Wall, Rob Boucher Jr, Akshay Bogawat – http://apparch.codeplex.com/wikipage?title=Business%20Layer%20Guidelines&referringTitle=Guidelines&ProjectName=apparch


Page 111 (335)

11. Annex I – Detailed ICT Requirements Specifications

11.1 Platform related ICT Requirements

11.1.1 Business Layer

SGAM framework Business

Category THEME

ID THEME.FINSENY.SLA Management

Name SLA Management

Goal The SLAs for usage of ICT services between different market players in the energy sector must be able to be managed flexibly.

Version 1.0

Source FINSENY (WP5)

Source contact Jonas Fluhr

Stakeholder cf. Use cases

Scope Platform

Status Pending MoSCoW priority MUST

Relative priority cf MoSCoW

Chapter Apps, Cloud, Data, I2ND

Enabler

Description

In order to reflect different levels of QoS on a business level, a variety of SLAs will be needed. The usage of different SLAs must be supported by a SLA Management environment. Any SLA management strategy comprises the negotiation of the contract (that must be abdicable) before run-time as well as the monitoring of its fulfillment during run-time. More precisely, eight functions are required: SLA Template Creation (including basic schema with QoS parameters) SLA Template Publication and Discovery SLA Negotiation between providers and consumer of services SLA Optimization SLA Monitoring (Audit) SLA Evaluation (Audit, eventually penalties for interrupted services) SLA Re-Negotiation SLA Accounting These functions are traversed mainly sequentially. To conduct these functions, available SLA schemas and negotiations protocols could be applied (WS-Agreement, WSLA, etc.). For SLA Monitoring and Evaluation, adequate means of performance management are necessary (cf. FINSENY.EPIC.SLA Management. Performance Management. Different QoS levels (cf. FINSENY.EPIC.Connectivity.QoS) are an essential part of the data definitions in SLAs.


Page 112 (335)

Rationale

SLA Management is useful for many use cases and applications. Within FINSENY, the need for data streams and services with dynamic levels QoS have been identified. Within distributed e-business environments, the QoS have to be covered via different SLAs. Examples: 1) Assuming an electric vehicle (EV) in front of a certain EVSE, it will have the possibility to provide new grid operations (e.g. Vehicle-to-Grid (V2G) services) at a certain point of time. For some new grid operations, extremely high levels of QoS (latency, jitter and reliability) are to be applied. (This QoS comes at a certain price for which an EV should pay. An EV owner or EV aggregator will include these V2G operating costs in its market offers.) Some hours later, the EV might be excluded from V2G, due to changing personal mobility needs of its user. In this case, only intelligent charging with lower QoS is necessary. These different levels of QoS are part of SLAs between the EV aggregator and the ICT provider. They need to be monitored and evaluated during the contract period. 2) There will be offered of a variety value added services for EVs in front of charging stations and at different other positions (e.g. navigation and social network services). They will need various different SLAs.

Owner TBD

Owner contact TBD

Complexity XL

Creation Date 26/04/2012

Last modified 10/05/2012


Page 113 (335)


Category THEME

ID THEME.FINSENY.Data management Name Data management Goal DN operation involves handling (processing, analyzing, semantically

classifying and accessing) large volumes of data that partially have to be stored for later use (e.g. billing, planning, historical analysis, regulation). The data must be kept consistent and synchronized with other systems within seconds. Data consistency has to be executed by DMS/SCADA system

Version 1.0


Source contact Yvonne-Anne Pignolet

Stakeholder

Scope Platform

Status Pending

MoSCoW priority MUST

Relative priority

Chapter D/C Management Enabler Big Data Analysis Description Management of large volumes of data can pose a performance or data

organization problem. Requires good data management Not required data have to be deleted after short time Data bursts have to be supported Organizational and system boundaries have to be considered in the design (format, types, naming, access rights)

Rationale Data management is required in order to maintain operational consistency

Owner

Owner contact

Complexity XL

Creation Date



Page 114 (335)


Category THEME

ID THEME.FINSENY.Data Bus Management

Name Data Bus Management Goal Using multiple databases for different types of data requires

communication channels for integration and interpretation of the information.

Version 1.0 Source FINSENY (All) Source contact Martin Wagner

Stakeholder

Scope Platform


Relative priority

Chapter IoT Enabler IoT Communication

Description The large amount of information must be storage taking into account the context of the data. To make decision more than one type of data must be available.

Rationale Customer data, device measurements, commercial transactions and other data must be reviewed to take decisions.

Owner

Owner contact

Complexity XL




Page 115 (335)


Category THEME

ID THEME.FINSENY.Device Management Name Device Management Goal All devices must be managed to ensure a continue control and

supervision of their interaction with the systems.

Version 1.0

Source FINSENY (All) Source contact Martin Wagner

Stakeholde r

Scope Platform


Relative priority

Chapter IoT

Enabler IoT Resources Management

Description Features: A device or sub-system should be able to describe its capabilities to other entities. A description file is provided by the device and is expressed e.g. in XML. The description file contains information about the device, e.g. its logical devices, functional units and services. The description of the service includes a list of commands and its parameters as well as a list of variables to describe the state of the service at run time. A common information model for describing the capabilities of the device is needed and has to be standardized, e.g. based on IEC 61970/61968 or SCL of IEC 61850-6. Expected issue: Standardization of object models for capability description for a large set of devices and properties.

Rationale In several Smart Grid use cases it is unlikely that a static engineering process is done for the whole system (e.g. supply-side and demand-side management). The Smart Grid shows dynamics and the engineering has to be adapted to these circumstances. It has to become an online process supporting the Plug & Play feature for devices.

Owner

Owner contact

Complexity L

Creation Date 05.08.2011



Page 116 (335)


Category THEME

ID THEME.FINSENY.Quality of Service

Name Quality of Service Goal Every network (or network part) should be able to manage

differentiated services through the management of priority levels.

Version 2.0

Source FINSENY (All) Source contact Ignacio Martín Díaz de Cerio Stakeholder

Scope Platform

Status Already covered MoSCoW priority Should

Relative priority

Chapter IoT Enabler S3C

Description Every network (or network part) should be able to manage differentiated services through the management of priority levels.

Rationale In case of critical scenarios, when media are shared among multiples parties and network congestion is considered very high, it would be useful to characterize the traffic with at least two priority classes. The delivery of real time information for FLIR, DCAC and SGEC requires the timely exchange of several hundreds of bytes. For MWFM applications with maps require a suitable bandwidth to support the field workers.

Owner

Owner contact

Complexity M




Page 117 (335)


Category THEME

ID THEME.FINSENY.Performance Management

Name Performance Management Goal Performance management ensures that SLA are being met in an

effective and efficient manner. Performance management can focus on the performance of any ICT component of the Grid.

Version 1.0

Source FINSENY (All) Source contact Martin Wagner Stakeholder

Scope Platform


Relative priority

Chapter IoT Enabler Description Performance management ensures that SLA are being met in an

effective and efficient manner. Performance management can focus on the performance of any ICT component of the Grid.

Rationale One of the typical operations of MV-DAC from the utility control center use case is to switch off and switch of an electrical line that feed an area. It is very important that all ICT elements that provide the Telecontrol Function have batteries with a suitable autonomy in order to not be affected by these typical operations. As an example, the Telecontrol Function is implemented by means of a periodical polling, each 2 seconds. This period is related mainly by the latency of the physical medium. When using specific physical mediums for example geostationary satellite mediums, these periodical polling should be longer (each 3 seconds for example). The effect of this is that when a grid operator sends an order, receives the updated information in the grid control application in less than this configured period. Jitter must be controlled in any case. When an answer arrives after the periodical polling period, a communication error arises. It has the same effect than a communication lost. Any failure, even that it is solved in a short period, spent a lot of resources in both the client and the provider.

Owner

Owner contact

Complexity M


Last modified


Page 118 (335)


Category THEME

ID THEME.FINSENY.Derivation of flexible energy prices / Calculation

Name Derivation of flexible energy prices / Calculation Goal Provides a real time energy price in order to allow the EV-user or an

aggregator to decide whether charging is reasonable.

Version 1.0




Scope Platform

Status Pending



Chapter IoT; Service;

Enabler Description Energy providers need to be able to dynamically derive energy prices

for the next hours. This requires precise forecasts of the availability of energy, as well as of the expected demand. Dynamic prices are then a means to balance the energy need and to avoid potentially expensive peaks of the demand. The complex derivation of energy prices depends on temperature, energy market prices, SOC (state of charge) and mobility needs of all customers (anonym). The calculation must consider grid capacity and calculate combinations of mobility offers which can be time-graded.

Rationale

Owner TBD

Owner contact TBD

Complexity XL




Page 119 (335)


Category THEME

ID THEME.FINSENY. Electronic Market Place

Name Electronic Market Place

Goal The services that will be provided at the eMarket4E will have to comply with: Ease of learning, memorable, maintenance, natural interaction and user satisfaction. This refers to the service interaction design in one side (service provider) and on the other by the artifacts provided at the platform side to mash up and produce services.

Version 1.0

Source FINSENY (All) Source contact Pasquale Andriani

Stakeholder

Scope Platform

Status Pending

MoSCoW priority Must

Relative priority

Chapter IoT

Enable r

Description The services that will be provided at the eMarket4E will have to comply with: Ease of learning, memorable, maintenance, natural interaction and user satisfaction. This refers to the service interaction design in one side (service provider) and on the other by the artifacts provided at the platform side to mash up and produce services.

Rationale An electronic marketplace needs to be available that facilitates management, collection and selection of grid issues and issue solution (offers) as well as the management, recommendation, negotiation and closing of energy (shifting) contracts and notification services and reporting. The service also will hold user energy information in detail. And it has to feature the capability of personalizing the interface depending on the context and preferences of the users.

Owner

Owner contact

Complexity M




Page 120 (335)


Category THEME

ID THEME.FINSENY.Future-proof system design requirements

Name Future-proof system design requirements Goal The interfaces should be open for future-proof system design wrt to

modularity, standardization, maintainability and HW/SW upgradeability

Version 1.0

Source FINSENY (WP2) Source contact Timo Kyntäjä

Stakeholder

Scope Platform

Status Pending


Relative priority

Chapter I2ND Enabler CDI Description Future-proof system design requires modularity, maintainability,

upgradeability of hardware, firmware and software as well as long time sourcing. Expected issues: Long time sourcing in contradiction to open market development and semiconductor/parts life-cycle.

Rationale Functional architecture may become dependent on practically available equipment which is compliant to operational conditions

Owner

Owner contact

Complexity L

Creation Date



Page 121 (335)


Category THEME

ID THEME.FINSENY.Interfaces (differentiate between user interfaces and other interfaces)

Name Interfaces (differentiate between user interfaces and other interfaces)

Goal The interfaces for all users should be easy-understandable and user-friendly.

Version 1.0

Source FINSENY (All) Source contact Roberto del Olmo Stakeholder

Scope Platform

Statu s Pending MoSCoW priority Must

Relative priority

Chapter IoT Enabler Description The interfaces for all users should be easy-understandable and user-

friendly.

Rationale Understandable user interfaces may affect customers’ involvement.

Owner

Owner contact

Complexity M


Last modified


Page 122 (335)


Category THEME

ID THEME.FINSENY.Marketplace services

Name Marketplace services Goal The services that will be provided at the eMarket4E will have to comply

with: Ease of learning, memorable, maintenance, natural interaction and user satisfaction. This refers to the service interaction design in one side (service provider) and on the other by the artifacts provided at the platform side to mash up and produce services. This requires also matching algorithms for finding appropriate contracts while keeping prices low or for finding appropriate offers to solve a grid issue

Version 1.0

Source FINSENY (WP6) Source contact Pasquale Andriani Stakeholder

Scope Platform

Status Pending


Relative priority

Chapter APPS, SECURITY

Enabler APPS: Marketplace; SECURITY Privacy Management Description The services that will be provided at the eMarket4E will have to comply

with: Ease of learning, memorable, maintenance, natural interaction and user satisfaction. This refers to the service interaction design in one side (service provider) and on the other by the artifacts provided at the platform side to mash up and produce services. An electronic marketplace needs to be available that facilitates the management, negotiation and closing of energy contracts.as well as to facilitate management, collection and selection of grid issues and issue solution (offers).The service will hold user energy information in detail. And it has to feature the capability of personalizing the interface depending on the context and preferences of the users.

Rationale An electronic marketplace needs to be available that facilitates management, collection and selection of grid issues and issue solution (offers) as well as the management, recommendation, negotiation and closing of energy (shifting) contracts and notification services and reporting. The service also will hold user energy information in detail. And it has to feature the capability of personalizing the interface depending on the context and preferences of the users.

Owner

Owner contact

Complexity M




Page 123 (335)


Category THEME

ID THEME.FINSENY.Monitoring of EVSE

Name Monitoring of EVSE

Goal Provide information in order to take measures for grid stability. Version 1.0

Source FINSENY (WP5) Source contact Jonas Fluhr


Scope Platform



Chapter IoT; I2ND Enabler Description Measurement results must be observed to ensure grid stability.

Rationale A lack of EVSE monitoring may lead to a local grid overload which might result in a local blackout.

Owner TBD

Owner contact TBD

Complexity M




Page 124 (335)


Category THEME

ID THEME.FINSENY.Payment methods/ possibilities at EVSE

Name Payment methods/ possibilities at EVSE

Goal Consumers should be able to pay by a payment method of their choice EC, Visa Card, PayPal, …

Version 1.0



Scope Platform

Status Pending MoSCoW priority COULD

Relative prior ity cf MoSCoW

Chapter I2ND

Enabler Description EV-users may want to choose a payment method that they are

comfortable with at an EVSE. There are lots of possible payment methods. The implementation of each payment method can be adapted from existing payment systems.

Rationale Each customer should be able to choose his/her most favorite payment method.

Owner TBD

Owner contact TBD

Complexity M




Page 125 (335)


Category EPIC

ID EPIC.FINSENY.Agnostic on the HAN technology Name Agnostic on the HAN technology Goal To have a technology reliable, durable, and able to integrate

seamlessly with numerous different devices, standards and other technologies.

Version 1.0

Source FINSENY (WP6) Source contact Massimiliano Nigrelli Stakeholder

Scope Platform

Status Pending MoSCoW priority SHOULD

Relative priority

Chapter

Enabler

Description Rationale Owner

Owner contact

Complexity M


Last modif ied 21/05/2012


Page 126 (335)


Category EPIC

ID EPIC.FINSENY.Scalability of Marketplace services

Name Scalability of Marketplace services Goal Marketplace Services should be offered in a scalable way which allows

scaling the number of users and transactions easily. Version 1.0


Source contact Pasquale Andriani

Stakeholder

Scope Platform


Relative priority

Chapter CLOUD

Enabler CLOUD: DCRM+SM Description The Marketplace Services should be offered in a scalable way, as it is

expected that the amount of users and thus transactions will increase.

Rationale

Owner

Owner contact

Complexity M




Page 127 (335)


Category EPIC

ID EPIC.FINSENY.Virtual Network Operator

Name Virtual Network Operator

Goal Provide a means where multiple service providers can all independently operate and dynamically provision the same physical telecoms infrastructure

Versi on 1.0

Source FINSENY (All) Source contact Fergal Ward


Scope Platform

Status Pending

MoSCoW priority SHOULD


Chapter I2ND Enabler Description In general, current regional and national networks are operated by a

single service provider. 3rd party operators are increasingly using virtualization technologies to provide new services. A future internet will see 100's of virtual operators operating dynamically inside the same physical network infrastructure where bandwidth and network services can dynamically scale in real time to customer requirements. This means that future networks will need to Open Up and expose control API's to 100's of various virtual service providers and software applications and agitate the combined real-time requirements into a single physical network provisioning system or a Virtual Network Operator. This will enable any new smart-grid use-case, service or application to organically grow without the high capital cost barrier to entry. In the case of the WP5 ICT-DCM, this capability will enable Smart Grid operators to directly control and scale the telecoms network in response to its real-time requirements as opposed to investing high capital costs in niche point-to-point networks.

Rationale This is a new generic enabler provided by the core platform

Owner TBD

Owner contact TBD

Complexity L




Page 128 (335)


Category EPIC

ID EPIC.FINSENY.Derivation of energy prices

Name Derivation of energy prices Goal Energy providers need to be able to dynamically derive energy prices

for the next hours. This requires precise forecasts of the availability of energy, as well as of the expected demand. Dynamic prices are then a means to balance the energy need and to avoid potentially expensive peaks of the demand.

Version 1.0

Source FINSENY (All) Source contact Pasquale Andriani

Stakeholder

Scope Platform

Status Pending MoSCoW priority Could

Relative priority

Chapter IoT Enabler Description Energy providers need to be able to dynamically derive energy prices

for the next hours. This requires precise forecasts of the availability of energy, as well as of the expected demand. Dynamic prices are then a means to balance the energy need and to avoid potentially expensive peaks of the demand.

Rationale Owner

Owner contact

Complexity L


Last modified


Page 129 (335)


Category EPIC

ID EPIC.FINSENY.Connectivity Infrastructure

Name Connectivity Infrastructure Goal The connectivity is based on the infrastructure established for all

devices and systems utilizing communication. Infrastructure includes aspects from technology, architecture and topology of the connectivity function (communication network). Infrastructures enable different means to provide the connectivity services and the quality of the service for different communication requirements. Finally, the infrastructure ownership and operational models (dedicated/public/shared) will impact SG actors and stakeholders, caused by different physical network media classes.

Version 1.0

Source FINSENY (WP2/WP3/WP4/WP5)

Source contact Timo.Kyntaja

Stakeholder

Scope Platform

Status Pending


Relative priority

Chapter Apps/Services, IoT, I2ND

Enabler Related or directly involved Enablers: From Applications/Services Ecosystem & Delivery area (5.)2.8 SLA Management (5.)5.1 Multi-channel/Multi-device Access System From IoT area: (6.)2.1 IoT Communications (6.)2.2 IoT Resources Management (6.)2.4 IoT Process Automation From I2ND area: (7.)2.1 Connected Devices Interfacing (CDI) (7.)2.3 Network Information and Control (NetIC) (7.)2.4 Service, Capability, Connectivity, and Control (S3C)


Page 130 (335)

Description The network infrastructure should feature numerous levels of Classes of Service to support SLAs, e.g. the best being guaranteed QoS, the worst being best effort QoS. The network infrastructure should also feature a fully meshed architecture to support advanced peer-to-peer multimedia service applications. Aggregation nodes for various access protocols and technologies need to be supported in a ubiquitous and pervasive connectivity function. The network infrastructure should therefore build on a combination of advanced wireless and fixed architectures. Support of dynamic provision of Ethernet / IP bandwidth for on demand services is required, so that e.g. high definition uni-cast electro-mobility video services will be supported. Wireless coverage is essential, e.g. in order to dynamically receive information on a Journey with an EV. Non-blocking advanced virtualization technologies are necessary to enable many virtual electro-mobility network operators on the same physical telecoms network and allow for dynamically scaled bandwidth and connectivity services with respect to real-time customer requirements. In case of coverage problems during communication / transaction, different communication channels/media with seamless handover shall be enabled. (e.g. when an EV’s moving and channel is disturbed)

Rationale Owner

Owner contact

Complexity XL




Page 131 (335)


Category EPIC

ID EPIC.FINSENY.Availability of Public Charge Points

Name Availability of Public Charge Points

Goal Public charge points are available to all as many people as possible.

Version 1.0


Source contact

Stakeholder

Scope Platform

Status Pending MoSCoW priority Must

Relative priority

Chapter IoT

Enabler Description Public charge points are available to all as many people as possible. Rationale

Owner

Owner contact

Complexity L


Last modified


Page 132 (335)


Category EPIC

ID EPIC.FINSENY.Billing and Payment Mechanism

Name Billing and Payment Mechanism Goal The Billing and Payment Systems allows manage the information

required by the user to make a transaction

Version 1.0

Source FINSENY (All) Source contact Pasquale Andriani Stakeholder

Scope Platform


Relative priority

Chapter IoT Enabler Description The Billing and Payment Systems allows manage the information

required by the user to make a transaction

Rationale Owner

Owner contact

Complexity M


Last modified


Page 133 (335)


Category EPIC

ID EPIC.FINSENY.QoS Classes

Name QoS Classes Goal For each type of data transport (e.g. information, control, monitoring) a

suitable connectivity service with the required QoS class can be reserved.

Version 1.0

Source FINSENY (WP3) Source contact Kolja Eger Stakeholder

Scope Platform

Status Pending


Relative prio rity

Chapter I2ND Enabler Description From a FINSENY’s use case analysis a set of six QoS classes were

identified. They have to support the main tasks of control, monitoring and management.

Rationale From FINSENY use cases extensions to IEC61850-90-4 are needed Owner

Owner contact

Complexity M




Page 134 (335)


Category EPIC

ID EPIC.FINSENY.Performance Management for SLA Monitoring

Name Performance Management for SLA Monitoring

Goal Performance management is an essential element for the Future Internet. It must be implemented at different architectural levels to guarantee for reliable and expected KPIs e.g., network, data center and component level KPIs.

Version 2.0

Source FINSENY (All)

Source contact Matthias Sund


Scope Platform



Chapter Enabler SLA Management (High-Level Description, section 5.2.7) Description Performance management for SLA Monitoring includes supervision of

KPIs which result from the contents of the SLA agreement and which have to be met in order to fulfill the negotiated SLA. Key components like data aggregation nodes or cloud computing resources must be monitored according to performance parameters agreed by an SLA e.g., a real time application like telecontrol is featured because a delay in the communications has similar effects than a lost. Performance management is not limited to component level scope, but must also be applied to higher level KPIs like service reliability or service respond time. Additionally, control mechanisms have to be implemented to tune performance parameters where appropriate. If performance cannot be met due to a lack of resources or if performance parameters are close to be failed these control mechanisms have to issue a warning to the SLA provider.

Rationale One example use case is switching off an electrical line that feeds an area. This is a typical MV-DAC operation from the utility control center. It is very important that all ICT elements that provide the Telecontrol Function have batteries with a suitable autonomy in order to not be affected by these typical operations. Battery states have to be monitored in order to guarantee operation at these occasions and therefore also to guarantee battery availability. In case the battery is in an unhealthy state a warning has to be generated and communicated to the operator or SLA provider that can act accordingly in order to maintain the negotiated SLA. Other important performance parameters must also be monitored and controlled e.g., RTD has to be monitored at a higher layer since many components (physical media, NEs, etc.) interwork with each other to not exceed a certain threshold and could therefore be subject to an SLA. Some functions like telecontrol are in need of a maximum RTD which if higher than negotiated leads to operational failures.

Owner TBD

Owner contact TBD

Complexity XL



Page 135 (335)



Page 136 (335)


Category EPIC

ID EPIC.FINSENY.Easy to Understand Interface

Name Easy to Understand Interface Goal The user interfaces of all systems facing final consumers should be

easy-understandable, user-friendly. Intuitive and show all data the users need but not more than necessary.

Version 1.0


Scope Platform


Relative priority

Chapter not applicable as this is a UI requirement Enabler not applicable as this is a UI requirement Description The interfaces for all users should be easy-understandable and user-

friendly. If not, users would not use the advanced systems.

Rationale

Owner

Owner contact

Comple xity M




Page 137 (335)


Category EPIC

ID EPIC.FINSENY.Energy Management System

Name Energy Management System Goal To receive home data by a metering system installed within the final

user home (to measure consumed and/or produced energy)

Version 1.0


Scope Platform


Relative priority

Chapter CLOUD, DATA, SECURITY

Enabler CLOUD EDGE; DATA IoT Gateway Data Handling; SECURITY Identity Management

Description A metering system installed within the final user home and it will be used to measure energy consumed and/or produced

Rationale Owner

Owner contact

Complexity L




Page 138 (335)


Category EPIC

ID EPIC.FINSENY.E-Roaming Agreement Management

Name E-Roaming Agreement Management

Goal Energy roaming (E-roaming) agreement management is comprised of all functions conducted in checking whether two or more energy roaming partners have an agreement.

Version 1.0



Scope Platform


Relative priori ty cf MoSCoW

Chapter Data Enabler "Contract management" Description E-roaming, partners involved in the roaming process need to be able to

identify/check if an agreement is valid between them at the moment it is activated. If an EV-user connects to EVSE of a particular EVSE-operator that operator needs to check whether the connected EPS is a roaming partner of the EV-user and/or EMSP, respectively i.e., checking if charged energy can be billed over the EV-user’s home EPS. Therefore, the involved EMSP receives the EVSE-operator’s EPS information and checks if a roaming contract between the EV-user and that EPS exists. If there is an active roaming contract, settlement and billing functions could be performed using the EV-users home EPS.

Rationale E-roaming agreements must be checked to validate charging attempts of EV-users.

Owner TBD

Owner contact TBD

Complexity XL




Page 139 (335)


Category EPIC

ID EPIC.FINSENY.Flexibility in the creation of new services interfaces/interaction framework

Name Flexibility in the creation of new services interfaces/interaction framework

Goal The final user services have to be designed following the design interaction methodology

Version 1.0



Stakeholder

Scope Platform

Status Pending


Relative priority

Chapter not applicable as this is a UI requirement

Enabler not applicable as this is a UI requirement Description Diverse preferences and abilities of the customers should be taken into

account when designing the service interaction of eMarket4E services.

Rationale

Owner

Owner contact

Complexity L




Page 140 (335)

SGAM frame work Business

Category EPIC

ID EPIC.FINSENY.Responsivity

Name Responsivity Goal Provide a means whereby future regional telecoms networks can be

dynamically re-configured and modified in fractions of a second.

Version 1.0

Source FINSENY (WP5) Source contact Fergal Ward


Scope Platform



Chapter IoT

Enabler Description Current internet services are quite static and do not changed very

often. In addition, the applications running over the network have no relationship or control to the services being provided. A future internet will enable dynamic service provisioning where the network will be directly responsive to the real-time to the demands of an application. This means that future network architectures must be able to reconfigure themselves at the packet level or in millisecond or micro-second time-frames, much faster than the current control systems.

Rationale This is a new feature of future networks with interfaces into the core platform

Owner TBD

Owner contact TBD

Complexity M




Page 141 (335)


Category FEATURE

ID FEATURE.FINSENY.Transactional mechanisms - Market Place

Name Transactional mechanisms - Market Place

Goal For the Electronic Marketplace for Energy in the FINSENY project, transactional mechanisms are required to perform critical operations in a consistent way. Actions like buying or selling energy and stipulating or closing contracts have to be supported by possibly distributed ICT transactional mechanisms with transactional guarantees.

Version 2.0

Source FINSENY (All) Source contact Pasquale Andriani Stakeholder

Scope Platform

Status Pending MoSCoW priori ty MUST

Relative priority

Chapter Data/Context Management; Applications/Services Ecosystem

Enabler Marketplace Description For the Electronic Marketplace for Energy in the FINSENY project,

transactional mechanisms are required to perform some critical operations such as payments, contracts establishment/closing, and exchange of goods on the electronic market platform. A transaction is a logical unit of work which starts with the begin operation and finishes with either the commit or the abort operation. In a transaction, between the start and the commit or abort operations, data requests are executed (on behalf of the transaction). A data request is an operation that manipulates a data object in such a way that it either reads or modifies the values stored in the data object. Classic transactions are bracketed by key control operations as Begin-Transaction, Commit-Transaction and Abort-Transaction. Each transaction must respect all the ACID properties: Atomic - either all operations of a transaction happen or none; Consistency - a transaction is a transformation from one correct state to another correct one; Isolation - even if many transactions may be executed concurrently, they do not interfere with the other ones; Durability - once a transaction is finalized, it will remain so. If a transaction is aborted (also known as rollback operation), all effects of the data managed on behalf of transaction are discarded. A Declarative Transaction Model is needed to manage a transaction lifecycle. With a Declarative Transaction Model the framework itself manages the starting and stopping (i.e. Begin, Commit or Abort) of the transaction. Developers only need to tell the framework when to roll back the transaction on application exception and configure the transaction through configuration parameters.


Page 142 (335)

Rationale The roll-out of the charging infrastructure is an ongoing process. For that it is necessary to maintain and to upgrade the software of charging stations (pool or single). Especially with respect to the increasing number of the charging stations (and thus the complete infrastructure) software upgrades are necessary to enhance the communication between these elements and additional with the grid. Similar is the situation for the grid itself. Ongoing developments will be takes place in the future. For that it is essential to perform remote software upgrades in the substations and other grid devices to enhance and to maintain the functionality of these devices. The self-configuration aspect makes the grid more agile, reliable, available etc. For that it is necessary to have a lot of sensors in the grid and the amount of sensors should be increased. The development of the firmware of these sensors is an ongoing process and the possibility of remote software upgrades is mandatory.

Owner

Owner contact

Complexity L




Page 143 (335)


Category FEATURE

ID FEATURE.FINSENY.Legally binding electronic contracts

Name Legally binding electronic contracts

Goal Legal conditions which allow to electronically closing binding contracts without direct human interaction.

Version 1.0


Scope Platform

Status Pending MoSCoW p riority MUST

Relative priority

Chapter not applicable as this is a standardization requirement

Enabler not applicable as this is a standardization requirement Description The legal conditions need to allow to electronically close binding

contracts, even if they are closed automatically, e.g., by means of intelligent agents.

Rationale

Owner

Owner contact

Complexity M




Page 144 (335)


Category FEATURE

ID FEATURE.FINSENY.Standardized energy contract

Name Standardized energy contract Goal A standard for energy contracts and energy contract offerings need to

be available in order to facilitate trading between all actors and to develop tools such as Web-based electronic marketplaces.

Version 1.0



Stakeholder

Scope Platform

Status Pending


Relative priority

Chapter not applicable as this is a legal/standardization requirement Enabler not applicable as this is a legal/standardization requirement Description A standard for energy (shifting) contracts and energy (shifting) contract

offerings need to be available in order to facilitate trading between all actors and to develop tools such as Web-based electronic marketplaces.

Rationale Owner

Owner contact

Complexity S




Page 145 (335)


Category FEATURE

ID FEATURE.FINSENY.Info communication system for the Final Users

Name Info communication system for the Final Users Goal Al the services provided by the eMarket4E have to be available by web

Version 1.0

Source FINSENY (WP6) Source contact Pasquale Andriani

Stakeholder

Scope Platform

Status Pending


Relative priority


Enabler APPS Marketplace; SECURITY Privacy Management

Description A WEB portal that allows the final user, through a smart phone or a PC, to choose between different energy retailer in order to get at best, technically and economically, its energetic needs.

Rationale Owner

Owner contact

Complexity M




Page 146 (335)


Category FEATURE

ID FEATURE.FINSENY.Production/Consumption information available in near real time

Name Production/Consumption information available in near real time Goal To have services which provide energy production/consumption

information in near real time to the energy customers/prosumer

Version 1.0

Sourc e FINSENY (WP6) Source contact Pasquale Andriani Stakeholder

Scope Platform


Relative priority

Chapter IoT

Enabler IoT Communication, IoT Gateway device management, IoT Gateway Data Handling

Description Real time communication amongst the actors may lead to improved peak demand management as consumers are able to view energy prices in time, and sequentially assess the best time to buy/consume energy. A prosumer will not only have to evaluate which is the best time in the day to sell/consume electricity but also whether to self-consume or store the energy being produced. Nearly real time production/consumption information is needed to improve peak demand management, view energy prices in time, and sequentially assess the best time to buy/consume energy

Rationale Owner

Owner contact

Complexity M




Page 147 (335)

11.1.2 Function Layer SGAM framework Function

Category THEME

ID THEME.FINSENY.Supervisory control

Name Supervisory control

Goal Lightweight, non-application-specific control layer for non-safety- critical control of building entities

Version 1.0


Source contact Gilles Privat

Stakeholder

Scope Platform

Status Pending

MoSCoW p riority Must

Relative priority

Chapter

Enabler Description Service-level control for dynamically configured sets of building

entities, derived from simple exclusion or sequence rules and matched to generic models of these entities

Rationale

Owner

Owner contact

Complexity

Creation Date

Last modified


Page 148 (335)

SGAM framework Function

Category THEME

ID THEME.FINSENY.User Profile Name User Profile Goal Providing a combined user profile bundling a charging profile, customer

profile and further information about a user.

Version 1.0

Source FINSENY (WP5) Source contact Jonas Fluhr Stakeholder cf. Use cases

Scope Platform



Chapter IoT

Enabler Description Each E-mobility provider may create a user profile which contains

information about the EV-user. The information in the user profile may consist of a customer profile, charging profile or sensitive user information like a unique user ID. Already saved preferences reduce the time the EV-user needs to set up necessary data for charging, identification, authentication, authorization or other services like most favorite radio stations. The stored data can be used for ancillary services (cf. Android or Facebook apps using standardized stored user data to prevent the user entering his personal data for each app separately).

Rationale User profiles comfort users and contract partners each time user data is necessary for operations like accounting.

Owner TBD

Owner contac t TBD

Complexity L




Page 149 (335)


Category THEME

ID THEME.FINSENY.Interoperability on Communications Technology (CT) layer

Name Interoperability on Communications Technology (CT) layer Goal Interoperability on

- North-bound CT I/Fs between DSO, Aggregators and VPPs wrt intra and inter-company communication - Standardized South-bound I/Fs wrt SG-devices communication

Version 1.0

Source FINSENY (WP2) Source contact Timo Kyntäjä

Stakeholder

Scope Platform


Relative priority

Chapter I2ND

Enabler NETIC, CDI, S3C and DSE Description Features: UC functionality relies on interoperable communication

network architecture from the sensor/actor devices via the IEDs, RTUs, aggregation and transport nodes to the server infrastructure and between server sites including switching/routing functionality on communication system protocol layers 2, 3 and 4 (link, network, transport). (LAN-switching, IP (MPLS)-routing and flow control). Standards framework as agreed in ETSI, IEEE, IETF for basic interworking. Namely Ethernet, TDM and serial Interface interoperability as well as their appropriate transport and routing layers, incl. secure transport, i.e. authenticated and encrypted message transfer. Expected issues: Definition of failsafe mechanisms to overcome limited distortion of interoperability

Rationale Interoperability on CT layer is relevant for a standardized operation and data exchange of SGEC, DCAC, MVDAC and FLIR related information

Owner

Owner contact

Complexity M

Creation Date



Page 150 (335)


Category THEME

ID THEME.FINSENY.EVSE Information Service

Name EVSE Information Service Goal Provide an information service that informs an EV-user about EVSE

nearby or at the destination.

Version 1.0


Scope Platform


Relative priorit y cf MoSCoW

Chapter IoT Enabler Description The EVSE information service informs an EV-user about EVSE nearby

or at the destination.

Rationale An EV-user wants to know where his/her EV can be charged.

Owner TBD

Owner contact TBD

Complexity M




Page 151 (335)


Category EPIC

ID EPIC.FINSENY.Availability/Reliability of forecast in demand/production

Name Availability/Reliability of forecast in demand/production Goal To have an ICT system able to guarantee a high level of availability

and Reliability of forecast in Energy demand/production for the Market Place.

Version 1.0


Scope Platform

Status Pending MoSCoW pri ority SHOULD

Relative priority

Chapter DATA Enabler DATA: Complex Event Processing; DATA: Publish/Subscribe Broker Description The Availability of the forecast services have to be high, otherwise

energy shortage may happen.

Rationale Owner

Owner contact

Complexity L




Page 152 (335)


Category EPIC

ID EPIC.FINSENY.Aggregate EVs to virtual power plants

Name Aggregate EVs to virtual power plants

Goal Interface for V2G-Operator to administer, monitor and control many EVs at the same time.

Version 1.0



Scope Platform



Chapter IoT

Enabler Description A certain amount of EVs is aggregated to a virtual power plant to use

economies of scale. A single EV does not have an impact on the grid stability. A certain amount of EVs is necessary to get a storage capacity to control the grid.

Rationale In times of a growing amount of renewable energy sources like wind energy, energy storage capacity is becoming more important.

Owner TBD

Owner contact TBD

Complexity XL




Page 153 (335)


Category EPIC

ID EPIC.FINSENY.Electricity Network management

Name Electricity Network management

Goal In order to provide Emarket4E services, we need of an infrastructure and services for monitoring, supervisory control and operation of electrical networks.

Version 1.0


Stakeholder

Scope Platform


Relative priority

Chapter IoT, DATA

Enabler IoT Service Enablement; DATA Publish/Subscribe Broker Description Services for monitoring, supervisory control and operation of electrical

networks need to be in place.

Rationale Owner

Owner contact

Complexity L




Page 154 (335)


Category EPIC

ID EPIC.FINSENY.Energy Monitoring Name Energy Monitoring Goal To have smart device and smart metering for gathering all the needed

date from the user premises

Version 1.0


Stakeholder

Scope Platform


Relative priority

Chapter CLOUD, IoT, SECURITY

Enabler CLOUD EDGE (Cloud Proxy); IoT: IoT Communications, IoT Resources Management, IoT Data Handling; SECURITY Privacy Management

Description Mechanisms for delivering data related to the energy consumption and/or production within a Smart House need to be in place for planning, procuring and selling activities. Besides Smart Meters, devices need to be intelligent and to be able to communicate.

Ration ale

Owner

Owner contact

Complexity M




Page 155 (335)


Category EPIC

ID EPIC.FINSENY.Connectivity Services

Name Connectivity Services

Goal Connectivity Services have to be available for all devices and sub-systems to support all kind of data transports inside FINSENY's grid architectures. For this purpose, these services have to fulfill connectivity requirements depending on the different challenges of the data transport.

Version 2.0

Source FINSENY (WP2/WP3/WP4/WP5) Source contact Kolja Eger Stakeholder

Scope Platform


Relative priority

Chapter IoT, I2ND


Description The network infrastructure should feature numerous levels of Classes of Service to support SLAs, e.g. the best being guaranteed QoS, the worst being best effort QoS. The network infrastructure should also feature a fully meshed architecture to support advanced peer-to-peer multimedia service applications. Aggregation nodes for various access protocols and technologies need to be supported in a ubiquitous and pervasive connectivity function. The network infrastructure should therefore build on a combination of advanced wireless and fixed architectures. Support of dynamic provision of Ethernet / IP bandwidth for on demand services is required, so that e.g. high definition unicast electro-mobility video services will be supported. Wireless coverage is essential, e.g. in order to dynamically receive information on a Journey with an EV. Non-blocking advanced virtualization technologies are necessary to enable many virtual electro-mobility network operators on the same physical telecoms network and allow for dynamically scaled bandwidth and connectivity services with respect to real-time customer requirements. In case of coverage problems during communication / transaction, different communication channels/media with seamless handover shall be enabled. (e.g. when an EV’s moving and channel is disturbed)

Rationale


Page 156 (335)

Owner

Owner contact

Comple xity XL




Page 157 (335)


Category EPIC

ID EPIC.FINSENY.Reliability and availability on Communications Technology (CT) layer

Name Reliability and availability on Communications Technology (CT) layer Goal Reliability of CT layer I/Fs towards Aggregator, VPP or DSO and SG-

devices.

Version 1.0

Source FINSENY (WP2) Source contact Timo Kyntäjä Stakeholder

Scope Platform


Relative priority

Chapter IoT

Enabler IoT Communications Description Features: Insuring reliability and defining a suitable availability of CT

operations towards Aggregator, VPP or DSO processes, applications, databases and the SG-devices. Ensuring appropriate transport and routing layer reliability for communication functions require: - Considering communication equipment lifetime expectation (acceptable FIT-rate of nodes and I/Fs) - Suitable time to repair - Communication equipment protection to meet availability requirement (parallel nodes) - Path layer protection to meet availability requirement (multi-homing, route-redundancy) Expected issues: High cost threat for redundant paths

Rationale Defining availability figures on CT layer is relevant for ongoing operation and also related to safe grid operation

Owner

Owner contact

Complexity M

Creation Date



Page 158 (335)


Category EPIC

ID EPIC.FINSENY.Reliability of the system

Name Reliability of the system

Goal To guarantee the reliability of the system in term of response time performance

Version 1.0



Stakeholder

Scope Platform

Status Pending


Relative priority

Chapter not applicable as this is a hardware/infrastructure requirement

Enabler not applicable as this is a hardware/infrastructure requirement Description It is very important to guarantee the reliability of the system in terms of

response time performance, as users would not use the systems otherwise.

Rationale

Owner

Owner contact

Complexity L




Page 159 (335)


Category EPIC

ID EPIC.FINSENY.User Management

Name User Management Goal Providing a mean that allows the E-Mobility provider to manage and

maintain customer profiles and storage of user profiles.

Version 1.0


Scope Platform


Relat ive priority cf MoSCoW

Chapter Data

Enabler

Description There are different kinds of user profiles that can be stored on Servers. User Management opens the possibility to create, maintain, search, modify and delete user profiles. For example a user management system may help structure certain kinds of user profiles for accounting processes.

Rationale To create, maintain, search, modify and delete those profiles a User Management System is necessary for all kinds of application in the E-Mobility sector.

Owner TBD

Owner contact TBD

Complexity M




Page 160 (335)


Category EPIC

ID EPIC.FINSENY.Identifiers

Name Identifiers Goal In order to provide individual services and to allow for E-Roaming,

several different ways of identification are needed, such as an End User in front of an EVSE via a Unique ID.

Version 1.0



Scope Platform



Chapter Sec; IoT

Enabler Description The identifier must be unique for each user.

Rationale Each user needs to hold a unique ID for a proper Identification and Authentication to make ICT services like accounting possible.

Owner TBD

Owner contact TBD

Complexity M




Page 161 (335)


Category EPIC

ID EPIC.FINSENY.Identification medium

Name Identification medium

Goal Provide a medium which enables the possibility of the Identification of a EV-user through RFID, Smartcard, Keypad, etc.

Version 1.0


Scope Platform

Status Pending



Chapter I2ND

Enabler Description There are different kinds of identification mediums like Wireless LAN,

Bluetooth, GSM/UMTS, Power Line Communication, Keypad, Near Field Communication, … Each identification medium needs protocols and at least two compatible end devices on each side of the connection (in this case between the EVSE and the electric vehicle).

Rationale Identifiers need to be transferred through an identification medium in order to communicate the ID between an EVSE and an EV.

Owner TBD

Owner contact TBD

Complexity L




Page 162 (335)


Category EPIC

ID EPIC.FINSENY.Quality of Service for Connectivity Name Quality of Service for Connectivity

Goal Quality of Service (QoS) of connectivity functions is defined here as an agreed set of properties, which a specific Connectivity Function has to provide after negotiation and agreement with the information-layer (on behalf of the component and function/service-layers, according to the FICC-layers in the SGAM concept of SGCG). QoS can have many properties, in focus here are Latency, Bandwidth – Throughput / Good put, Delay and Jitter, Prioritization and Packet Loss. An agreed set of QoS parameters from the before (a Class of Service; CoS) may be the basis for a Service Level Agreement (SLA) to be fulfilled and monitored by the Connectivity Function. An example for energy related communication QoS is given in IEC61850-90-4. Pls. see inserted diagram.

Version 1.0

Source FINSENY (WP2/WP3/WP4/WP5) Source contact Timo.Kyntaja Stakeholder

Scope Platform


Relative priority




Page 163 (335)

Description On functional or service layer information/data needs to be exchanged between devices, sub-systems, control centers or management systems. Depending on the desired functionality, but not necessarily on the max. Communication capabilities of the devices, corresponding connectivity quality needs to be insured. - Therefore the desired connectivity functionality needs to be described and classified first. IEC 61850-5 describes already requirements for Electricity Transport and Distribution Systems and large parts of Microgrid functionality as well as Distributed Energy Resources (DER). In other areas like Building or EV charging systems or new Aggregation functions, new Future Internet Technologies have to fulfill specific application-area and use case specific QoS connectivity requirements. - Individual and repeating sets of QoS requirements can secondly be grouped in Service Level Agreements (SLA) on QoS. In this QoS description, connectivity parameters concerning quantitative settings for Latency, Bandwidth – Throughput / Good put, Delay and Jitter, Prioritization and Packet Loss need to be specified. - SLAs need third to be communicated to the connectivity layer and acknowledged by it. Depending on the locally available Connectivity Function capabilities, SLA requests need to be acknowledged rejected or alternative proposals need to be negotiated with consequences to the desired functionality. In FI-Ware there is the IaaS Data Center Resource Management mentioned to support this. - A forth aspect for the Connectivity QoS Function is the supervision of achieved performance for certain SLAs. Typically QoS related SLAs will be static, by interface selection and according setting of communication equipment. Especially depending on Access Communication (wired or wireless) Network capabilities, time variable assignment of QoS needs to be considered. Therefore a QoS related (management) communication interface between the function layer and the communication layer is required in parallel. The table 8 from IEC 61850-90-4 shows exemplary derived SLAs for typical electricity grid functions as described in IEC 61850-5.

Rationale QoS is a prerequisite for many use cases which rely on the Connectivity Function, i.e. communicate externally

Owner

Owner contact

Complexity XL




Page 164 (335)


Category EPIC

ID EPIC.FINSENY.Real Time Data and Service management

Name Real Time Data and Service management Goal We need applications able to process data and to manage services in

real time

Version 1.0


Source contact Pasquale Andriani Stakeholder

Scope Platform


Relative priority

Chapter APPS

Enabler APPS: Marketplace Description The requirement takes on board the fact that in the future real time

tariff schemes will have to be handled by the Market place service.

Rationale

Owner

Owner contact

Complexity L




Page 165 (335)


Category EPIC

ID EPIC.FINSENY.Request / Response

Name Request / Response

Goal Request/Response service for a single information of monitoring and / or control

Version 1.0

Source FINSENY (WP3) Source contact Jürgen Goetz Stakeholder

Scope Platform

Status New WP3 Requirement


Relative priority

Chapter I2ND

Enabler

Description A request/response service is a service based on a client request to get or set one data attribute and initiates a response from the server, either with the value of this attribute or with the information on the successful or unsuccessful setting of the attribute.

Rationale Requested for communication between a client and a server to initiate one exchange of data (monitoring and control).

Owner

Owner contact

Complexity XL




Page 166 (335)


Category EPIC

ID EPIC.FINSENY.Web-Service-enabled technologies for electricity network management

Name Web-Service-enabled technologies for electricity network management

Goal Services for monitoring, supervisory control and operation of electrical networks need to be in place. The network infrastructure should feature open web-service APIs so that electro mobility cloud services and marketplace services can simultaneously query and reserve both network and cloud services without any human intervention.

Version 1.0

Source FINSENY (All) Source contact Javier Lucio Stakeholder

Scope Platform


Relative priority

Chapter IoT Enabler Description Services for monitoring, supervisory control and operation of electrical

networks need to be in place. The network infrastructure should feature open web-service APIs so that electro mobility cloud services and marketplace services can simultaneously query and reserve both network and cloud services without any human intervention.

Rationale This requirement is essential as the scenario can only be facilitated with such mechanisms.

Owner

Owner contact

Complexity L


Last modified


Page 167 (335)


Category EPIC

ID EPIC.FINSENY.Decision Making and signaling energy commands

Name Decision Making and signaling energy commands Goal Manage DSM signals to reduce the power consumption in customer

homes. The user has access to a DMS application on the internet and can choose from the DSM offerings.

Version 1.0



Stakeholder

Scope Platform

Status Pending


Relative priority

Chapter not applicable as this is a hardware/infrastructure requirement Enabler not applicable as this is a hardware/infrastructure requirement

Description The service that may lie on the Grid User side or in the cloud needs to know the user contract and the installed capabilities. According to the latter processing capabilities are key to decide how to signal the shape demand commends.

Rationale

Owner

Owner contact

Complexity L




Page 168 (335)


Category EPIC

ID EPIC.FINSENY.Derivation of flexible E-Roaming prices / Calculation

Name Derivation of flexible E-Roaming prices / Calculation Goal Providing a calculation of E-Roaming prices could also be necessary to

allow transparent roaming costs.

Version 1.0


Scope Platform



Chapter IoT; Service

Enabler

Description Costs that occur because of roaming need to be specified and calculated to ensure a proper billing and make a choice between different roaming partners possible.

Rationale Roaming costs must be available because they may be important criteria for a customer to decide where to charge and for billing reasons.

Owner TBD

Owner contact TBD

Complexity XL




Page 169 (335)


Category EPIC

ID EPIC.FINSENY.Electricity Price signal hourly – daily Name Electricity Price signal hourly – daily Goal Fixing and managing the Price .The main price to be dealt with are:

Energy Price derived from auctions(for who participate to Energy Trading)(prices and quantity exchanged) Final Energy Prices- Tariff ( Price/kW to be pay from the final customers) ( Defined from the Energy Retails. It derives from the business model and pricing model followed. ) The price has to be notified/shown to all market stakeholders according their roles in the electronic market place.

Version 1.0

Source FINSENY (WP6) Source contac t Pasquale Andriani

Stakeholder

Scope Platform


Relative priority

Chapter not applicable as this might be considered a Domain Specific Requirement (DSR)

Enabler not applicable as this might be considered a Domain Specific Requirement (DSR)

Description The final user should know the price of the electricity in order to incentive or disincentive the consumption of the energy depending on the price. This interface must be as much detailed as possible covering final price per minute, incentives, contra-incentives, etc. The final price of the electricity for customers’ needs to be updated hourly-daily in order to take decisions on the scheduling of the consumption of the energy by the BEMS or the final user.

Ration ale

Owner

Owner contact

Complexity S




Page 170 (335)


Category EPIC

ID EPIC.FINSENY.End users Interface

Name End users Interface Goal End users shall be able to access a set of functionalities including

visualization of energy consumption metering

Version 1.0


Scope Platform


Relative priority

Chapter IoT Enabler IoT Resources Management

Description End users shall be able to access a set of functionalities including visualization of energy consumption metering.

Rationale In order to achieve the highest levels of energy efficiency, end users should have tools that allow them to define the most efficient strategy con energy consumption.

Owner

Owner contact

Complexity L




Page 171 (335)


Category EPIC

ID EPIC.FINSENY.EVSE Price Service

Name EVSE Price Service

Goal Provide an information service that informs an EV-user about the energy price at EVSE nearby or at the destination.

Version 1.0


Scope Platform

Status Pending

MoSCoW priority COULD


Chapter IoT

Enabler Description The EVSE price service informs an EV-user about the energy prices at

EVSE nearby.

Rationale An EV-user wants to know the current energy price at EVSE nearby. Owner TBD

Owner contact TBD

Complexity M




Page 172 (335)


Category EPIC

ID EPIC.FINSENY.HMI at comfort EVSE

Name HMI at comfort EVSE Goal End users shall be able to access a set of functionalities including

visualization of energy consumption metering and resulting energy costs. Electric Vehicle Users (EV-users) need to specify preferences such as the Charge Time Frame and the Minimum Battery State Of Charge (BSOC). Instead of simple techniques ("End users Interface / HMI - EVSE"), this could be done more sophisticated and automatically, e.g., with user-friendly agent technology which could be integrated into a navigation system. The end user may be informed about availability of certain tariffs at the EVSE.

Version 1.0



Scope Platform

Status Pending



Chapter IoT

Enabler Description End users shall be able to access a set of functionalities including

visualization of energy consumption metering, state of charge, Battery State Of Charge … through user-friendly agent technology. A bunch of additional information, settings and services may be available for users at an advanced EVSE HMI.

Rationale In order to achieve the highest levels of energy efficiency, end users should have tools that allow them to define the most efficient strategy of energy consumption. Users may need or want additional more specified information, settings or services at an EVSE.

Owner TBD

Owner contact TBD

Complexity L




Page 173 (335)


Category FEATURE

ID FEATURE.FINSENY.Efficient and secure service access and provision

Name Efficient and secure service access and provision

Goal The Ability of generating contracts on the fly over the internet will need to be reliable by employing standard protocols and interfaces from the users. Security access has to be provided also following usual

Version 2.0


Scope Platform

Status Pending


Relative priority

Chapter APPS, SECURITY Enabler APPS Marketplace, SECURITY Identity Management

Description The Ability of generating contracts on the fly over the internet will need to be reliable by employing standard protocols and interfaces for the users. Security access has to be provided also following usual

Rationale

Owner

Owner contact

Complexity L




Page 174 (335)


Category FEATURE

ID FEATURE.FINSENY.Standardized grid issues and solutions descriptions

Name Standardized grid issues and solutions descriptions

Goal To facilitate automated treatment of such energy grid situations and of grid issue situations and to develop tools such as Web-based electronic marketplaces, e.g., in an electronic market place.

Version 1.0


Scope Platform


Relative priority


Enabler not applicable as this is a standardization requirement

Description A standard for grid issue descriptions need to be available in order to facilitate automated treatment of such situations, e.g., in an electronic market place. A standard for grid issue solutions and grid issue solution offerings needs to be defined in order to facilitate an automated treatment of grid issue situations and to develop tools such as Web-based electronic marketplaces.

Rationale

Owner

Owner contact

Complexity S




Page 175 (335)


Category FEATURE

ID FEATURE.FINSENY.Billing to customer

Name Billing to customer

Goal Each customer gets a bill for the charged energy. Version 1.0


Scope Platform

Status Pending

MoSCoW priority Should


Chapter Data

Enabler Description The layout and content of bills needs to be specified. The generation of

customer bills can be done via standard "billing" IT Systems. For a huge amount of cleared EV-users a Trusted Third Party could make billing easier and more efficient.

Rationale Customers need clarity about the charged energy and the energy costs.

Owner TBD

Owner contact TBD

Complexity M




Page 176 (335)


Category FEATURE

ID FEATURE.FINSENY.Accounting (Roaming: Rating, Clearing, Billing, Settlement; Bill to customer)

Name Accounting (Roaming: Rating, Clearing, Billing, Settlement; Bill to customer)

Goal Charging at any EVSE must be accountable to the EV-user charging his EV.

Version 1.0



Scope Platform

Status Pending



Chapter Data; Enabler Descript ion In case of Roaming Rating, Clearing, Billing and Settlement are

processes which make accounting for a high amount of charging processes easier. If a customer is charging at his/her E-mobility providers own EVSE, the accounting only consists of an E-mobility internal process.

Rationale Each user needs to pay for the charged energy regardless of if he is a roaming or a usual customer.

Owner TBD

Owner contact TBD

Complexity XL




Page 177 (335)


Category FEATURE

ID FEATURE.FINSENY.Control mechanisms for Smart Home

Name Control mechanisms for Smart Home Goal Standard mechanisms are required in order to assure the

interoperability

Version 1.0


Scope Platform


Relative priority

Chapter IoT

Enabler IoT Communications, IoT Resources Management, IoT Data Handling

Description Standardized mechanisms to control the energy consumption and production in Smart Homes from the outside need to be in place. This includes in particular communication interfaces and a protocol for information exchange.

Rationale Owner

Owner contact

Complexity L


Last modif ied 18/05/2012


Page 178 (335)


Category FEATURE

ID FEATURE.FINSENY.User preferences and agreements interfaces

Name User preferences and agreements interfaces

Goal The BEMS must provide an user interface for the user to manage their electric consumption preferences

Version 1.0


Scope Platform

Status Pending


Relative priority

Chapter not applicable as this is a UI requirement

Enabler not applicable as this is a UI requirement Description The BEMS must provide an user interface for the user to manage their

electric consumption preferences

Rationale Owner

Owner contact

Complexity S




Page 179 (335)


Category FEATURE

ID FEATURE.FINSENY.Data gathering at building/local level in real time

Name Data gathering at building/local level in real time

Goal We need to gather the data (energy consumptions/production, etc. ) at home/building level in real time, In order to process them for providing the emarket4E services.

Version 1.0


Stakeholder

Scope Platform

Status Pending


Relative priorit y

Chapter CLOUD

Enabler CLOUD: Edge (cloud proxy)

Description The data in local/building/Community level have to be gathered in real time.

Rationale

Owner

Owner contact

Complexity L




Page 180 (335)


Category FEATURE

ID FEATURE.FINSENY.Identification Medium supporting E-Roaming

Name Identification Medium supporting E-Roaming Goal The identification through identifiers must be possible with roaming

clients as well as own customers. A standardized identification medium is necessary.

Version 1.0


Scope Platform



Chapter I2ND Enabler Description There are different kinds of identification mediums like Wireless LAN,

Bluetooth, GSM/UMTS, Power Line Communication, Keypad, Near Field Communication, … Each identification medium needs protocols and at least two compatible end devices on each side of the connection (in this case between the EVSE and the EV). For roaming all roaming partners need to standardize the identification medium to make identification, regardless of the end points and EVs involved in the charging process, possible.

Rationale Identifiers need to be transferred through an identification medium in order to communicate the ID between an EVSE and an EV. The identification medium needs to be standardized for roaming.

Owner TBD

Owner contact TBD

Complexity L




Page 181 (335)


Category FEATURE

ID FEATURE.FINSENY.QoS Service Class 1A

Name QoS Service Class 1A Goal Safety critical for control

Version 1.0

Source FINSENY (WP3) Source contact Kolja Eger

Stakeholder

Scope Platform



Relative priority

Chapter I2ND

Enabler Description Priority: highest

Latency: < 10 -100 ms Data occurrence: spontaneous (as reaction on failure in energy system) Bandwidth / Data volume: <1500 Byte Communication: Unicast/multicast Redundancy: needed for communication

Rationale Requested for e.g. FLISR, load shedding Owner

Owner contact

Complexity M




Page 182 (335)

SGAM framewor k Function

Category FEATURE

ID FEATURE.FINSENY.QoS Service Class 1B

Name QoS Service Class 1B

Goal Safety critical for monitoring

Version 1.0


Scope Platform



Relative priority

Chapter I2ND Enabler Description Priority: highest

Latency: < 10 -100 ms Data occurrence: spontaneous (on failure in energy system) Bandwidth / Data volume: <1500 Byte Communication: Unicast Redundancy: needed for communication

Rationale Requested for e.g. FLISR, load shedding

Owner

Owner contact

Complexity M




Page 183 (335)


Category FEATURE

ID FEATURE.FINSENY.QoS Service Class 2A

Name QoS Service Class 2A

Goal Operational critical for control Version 1.0


Scope Platform



Relative priority

Chapter I2ND Enabler Description Priority: medium

Latency: < 1s Data occurrence: spontaneous (on request of operator or action from SCADA) Bandwidth / Data volume: <1500 Byte Communication: Unicast Redundancy: redundancy in energy system (multiple devices can provide a similar service)

Rationale requested for e.g. Primary reserve, VoltVar Owner

Owner contact

Complexity M




Page 184 (335)


Category FEATURE

ID FEATURE.FINSENY.QoS Service Class 2B

Name QoS Service Class 2B Goal Operational critical for monitoring Version 1.0


Scope Platform



Relative priority

Chapter I2ND

Enabler

Descrip tion Priority: medium Latency: < 1s Data occurrence: periodically Bandwidth / Data volume: <100 kbps Communication: Unicast Redundancy: redundancy in energy system (multiple devices can provide a similar service)

Rationale requested for e.g. Primary reserve, VoltVar

Owner

Owner contact

Complexity M




Page 185 (335)


Category FEATURE

ID FEATURE.FINSENY.QoS Service Class 3 Name QoS Service Class 3 Goal Communication Network Control for Management

Version 1.0


Scope Platform



Relative priority

Chapter I2ND Enabler Description Priority: high

Latency: < 100ms Data occurrence: spontaneous and periodically Bandwidth / Data volume: <100 kbps Communication: Unicast/Multicast Redundancy: needed for communication

Rationale requested for e.g. Time synchronization

Owner

Owner contact

Complexity M




Page 186 (335)


Category FEATURE

ID FEATURE.FINSENY.QoS Service Class 4

Name QoS Service Class 4 Goal Best effort/Background traffic for Management Version 1.0


Scope Platform

Status New WP3 Requirement MoSCoW priority MUST

Relative priority

Chapter I2ND Enabler Description Priority: low

Latency: best effort Data occurrence: spontaneous and periodically Bandwidth / Data volume: best effort Communication: Unicast Redundancy: no

Rationale requested for e.g. Day-ahead price signals, logging, configuration

Owner

Owner contact

Complexity M




Page 187 (335)


Category FEATURE

ID FEATURE.FINSENY.Real time system to monitor the available kind of energy for the energy retailers

Name Real time system to monitor the available kind of energy for the energy retailers

Goal Version 1.0


Scope Platform


Relative priority


Enabler APPS: Marketplace; SECURITY: Identity Management

Description A SW WEB-based system that allow the energy retailers to give users the kind of requested energy together at all the necessary market information

Rationale Owner

Owner contact

Complexity L




Page 188 (335)


Category FEATURE

ID FEATURE.FINSENY.Ease of use of the eMarket4E services

Name Ease of use of the eMarket4E services Goal The user applications have to follow the service interaction design

roles in order to assure a better involvement of the final user

Version 1.0



Stakeholder

Scope Platform

Status Pending


Relative priority

Chapter not applicable as this is a UI requirement Enabler not applicable as this is a UI requirement

Description The services that will be provided at the eMarket4E will have to comply with: Ease of learning, memorability, maintainability, natural interaction and user satisfaction. This refers to the service interaction design in one side (service provider) and on the other by the artifacts provided at the platform side to mash up and produce services.

Rationale Owner

Owner contact

Complexity L




Page 189 (335)


Category FEATURE

ID FEATURE.FINSENY.HMI for desktop browsers

Name HMI for desktop browsers Goal End users shall be able to access a set of functionalities including

visualization of energy consumption metering and resulting energy costs.

Version 1.0


Source conta ct Jonas Fluhr Stakeholder cf. Use cases

Scope Platform

Status Pending



Chapter IoT

Enabler IoT Resources Management Description End users shall be able to access a set of functionalities including

visualization of energy consumption metering.

Rationale In order to achieve the highest levels of energy efficiency, end users should have tools that allow them to define the most efficient strategy of energy consumption.

Owner TBD

Owner contact TBD

Complexity L




Page 190 (335)


Category FEATURE

ID FEATURE.FINSENY.HMI for smartphones Name HMI for smartphones Goal End users shall be able to access a set of functionalities including

visualization of energy consumption metering and resulting energy costs.

Version 1.0



Scope Platform



Chapter IoT

Enabler

Description End users shall be able to access a set of functionalities including visualization of energy consumption metering.


Owner TBD

Owner contact TBD

Complexity L




Page 191 (335)


Category FEATURE

ID FEATURE.FINSENY.HMI in EVs

Name HMI in EVs

Goal End users shall be able to access a set of functionalities including visualization of energy consumption metering and resulting energy costs.

Version 1.0


Scope Platform

Status Pending



Chapter IoT

Enabler Description End users shall be able to access a set of functionalities including

visualization of energy consumption metering.


Owner TBD

Owner contact TBD

Complexity XL




Page 192 (335)


Category FEATURE

ID FEATURE.FINSENY.Network API's

Name Network API's Goal Provide a single interface to manage an entire national infrastructure Version 1.0

Source FINSENY (WP5) Source contact Fergal Ward Stakeholder cf. Use cases

Scope Platform



Chapter

Enabler Description For vehicles that are used in different Use Case categories, FI-Ware

and or Smart Grid applications will need to directly control the network and dynamically reconfigure network services in real time depending on EV data-requirements as they dynamically travel around a city / region. Ideally the network API's should also be built on REST web services technology to enable the SG and Future Internet apps to talk directly to the network.

Rationale Problem: the hardware is out in the field. In how far could the Core-Platform support here? What’s the exact ICT requirement for them? In how far it could be a generic enabler?

Owner TBD

Owner contact TBD

Comp lexity L




Page 193 (335)

11.1.3 Information Layer SGAM framework Information

Category THEME

ID THEME.FINSENY.Algorithms to support forecast of mobility needs, power demand, etc.

Name Algorithms to support forecast of mobility needs, power demand, etc.

Goal Provide a forecast of grid loads which is calculated through algorithms in the cloud and broadcasted through a communication interface.

Version 1.0


Scope Platform

Status Pending



Chapter Data; IoT

Enabler Description In the past grid loads were mainly based on experienced data. The

recent changes of the grid into a smart grid and the high amount of unpredictable renewable energies makes the prediction based on experienced data impossible. The forecast of grid loads needs to be calculated by algorithms to allow real time energy demand and supply data. The introduction of EVs makes the prediction of energy prices and demand even more complicated. The complex calculations must be done in the cloud and broadcasted for all clients that rely on real time grid data.

Rationale Real time grid load data and energy prices make V2G and intelligent charging possible. Both aspects help to stabilize the grid.

Owner TBD

Owner contact TBD

Complexity XL




Page 194 (335)

SGAM framework Information

Category THEME

ID THEME.FINSENY.Support of intelligent algorithm deployment

Name Support of intelligent algorithm deployment Goal In a smart-(dis-)charging scenario, a new (near) optimal schedule

needs to be calculated whenever certain parameters change. For example, it is necessary to mediate between dimensions (mobility demand, power grid demand, generation capability, battery capability).

Version 1.0


Scope Platform

Status Pending



Chapter Data; IoT

Enabler

Description Each EV has different characteristics as well as every user has different mobility demands. The optimal charging schedule must be based on a lot of parameters like mobility demand, power grid demand, generation capability, battery capability, energy prices, charging time frame ... Algorithms help to find a heuristic optimized schedule. EV-users may set up settings to influence the charging behavior of their EV. Energy providers or E-mobility providers may sell charging priority to their customers.

Rationale Each EV-user wants to use his/her EV regardless of the grid status. The EV-user is just interested into fulfilling his mobility demands. On the other side the energy providers need to ensure grid stability. Furthermore the EV's battery shouldn't be charged faster than necessary to prevent battery aging. An algorithm mediates between all dimensions to get the best possible charging schedule.

Owner TBD

Owner contact TBD

Complexity XL




Page 195 (335)


Category EPIC

ID EPIC.FINSENY.Auction Processing

Name Auction Processing Goal Processing all the bids and demands of Energy according the defined

auction rules and models, in order to determine the exchanged quantities of energy at different prices for all the auction participants .

Version 1.0


Stakeholder

Scope Platform

Status Pending


Relative priority

Chapter Applications/Services Ecosystem and Delivery Framework

Enabler Marketplace Description We need an automated system able to process all the bids and

demands according the defined auction rules and models, in order to determine the exchanged quantities of energy at different prices for all the auction participants.

Rationale Owner

Owner contact

Complexity


Last modified


Page 196 (335)


Category EPIC

ID EPIC.FINSENY.Common data models

Name Common data models Goal Definition of common data models (CDM) per type of sensor/appliance.

In order to perform energy optimization on behalf of the consumer, home appliances must be modeled in a common way so that the intelligence in the system is able to monitor them, know control capabilities, programming capabilities and have at any moment information on the reachability of the device.

Version 1.0


Stakeholder

Scope Platform


Relative priority

Chapter IoT Enabler Description Definition of common data models (CDM) per type of sensor/appliance.

In order to perform energy optimization on behalf of the consumer, home appliances must be modeled in a common way so that the intelligence in the system is able to monitor them, know control capabilities, programming capabilities and have at any moment information on the reachability of the device.

Rationale In order to perform energy optimization on behalf of the consumer, home appliances must be modeled in a common way so that the intelligence in the system is able to monitor them, know control capabilities, programming capabilities and have at any moment information on the reachability of the device.

Owner

Owner contact

Complexity M




Page 197 (335)


Category EPIC

ID EPIC.FINSENY.Mapping Tool for Information Models

Name Mapping Tool for Information Models Goal To cope with different information models a flexible easy-to-use

mapping tool is needed to map data points from different information models onto each other.

Version 2.0

Source FINSENY (All) Source contact Kolja Eger Stakeholder

Scope Platform

Status Under Evaluation by FI-WARE MoSCoW priority Could

Relative priority

Chapter IoT


Description Monitoring and control are two basic functionalities of control centers (e.g. in a Microgrid). The Control Center communicates with a large set of different devices from different domains (e.g. from intelligent loads to large wind turbines). Today a large number of different standards exist and it is very likely that this will also be true in the future. To ensure interoperability between different standards with different information models the standards have to be harmonized. A flexible mapping tool is needed to map monitoring and control data points from different information models onto each other. E.g. the mapping tool should be designed to minimize the manual input and mapping information should be re-usable.

Rationale Not a single standard will cover all relevant points and interoperability can only be ensured by the harmonization and mapping of standards.

Owner

Owner contact

Complexity L




Page 198 (335)


Category EPIC

ID EPIC.FINSENY.Data Base System

Name Data Base System

Goal Large amounts of data need to be collected, stored and made available.

Version 1.0


Stakeholder

Scope Platform

Status Pending


Relative priority

Chapter IoT Enabler IoT Data Management Description Many repositories to store all the information (measurements, profiles,

EV, SMs, etc.) gathered from the devices must be available. Large amounts of data are to be saved on databases. Context management is key to classify information of various devices well identified.

Rationale This is an essential requirement and the system will not work properly without it: Several means of measurements will be received for storage.

Owner

Owner contact

Complexity XL




Page 199 (335)


Category EPIC

ID EPIC.FINSENY.Data management and storage

Name Data management and storage Goal We need method/technologies to collect, store and made available

large amounts of data.

Version 1.0


Stakeholder

Scope Platform


Relative priority

Chapter CLOUD

Enabler CLOUD: Object Storage

Description Large amounts of data need to be collected, stored and made available.

Rationale Owner

Owner contact

Complexity S




Page 200 (335)


Category EPIC

ID EPIC.FINSENY.Data integrity

Name Data integrity

Goal The data to be transmitted and received have to be reliable in term of truthfulness and timing. It shall be possible to ensure the integrity of the communicated data (during the data transfer as well as stored data) and to verify whether the data hasn’t been tampered.

Version 1.0


Scope Platform

Status Pending


Relative priority

Chapter IoT

Enabler IoT Gateway Data Handling; IoT Gateway Device Management

Description The data to be transmitted and received have to be reliable in term of truthfulness and timing. It shall be possible to ensure the integrity of the communicated data (during the data transfer as well as stored data) and to verify whether the data hasn’t been tampered. In particular for all payment scenarios, data integrity has to be ensured.

Rationale This is an essential requirement and the system will not work properly without it. One challenge is that the field deployed devices are typically not suitable for traditional third party malicious code protection mechanisms. This combined with very little or no physical security means that emphasis be placed on the risk associated with these widely dispersed assets. Therefore it should be ensured that no malicious code can pass some security zones (e.g. from the utility’s NAN to HAN). Field tools represent potentially high risk also because they may be connected to numerous networks.

Owner

Owner contact

Complexity M




Page 201 (335)


Category EPIC

ID EPIC.FINSENY.Data management Performance

Name Data management Performance Goal Computing resources must be highly scalable in order to process,

storage and evaluate data in order to allow for grid integration services. Data Integrity must be ensured

Version 1.0


Scope Platform


Relative priority

Chapter IoT

Enabler

Description Computing resources must be highly scalable in order to process, storage and evaluate data in order to allow for grid integration services. Data Integrity must be ensured

Rationale This is an essential requirement and the system will not work properly without it.

Owner

Owner contact

Complexity L


Last modifie d 07/02/2012


Page 202 (335)


Category EPIC

ID EPIC.FINSENY.Distributed Databases

Name Distributed Databases Goal To provide storage systems for large amount of information, distributed

database system (local, regional, etc.) are required.

Version 1.0


Stakeholder

Scope Platform


Relative priority

Chapter IoT

Enabler IoT Data Management

Description A distributed database systems are required to provide storage system(s) for context information taking into account the type of data and the devices that generate de information.

Rationale Data has to be stored persistently in a database. The database system has to show high-performance because of the high volume of data and multiple accesses.

Owner

Owner contact

Complexity XL




Page 203 (335)


Category EPIC

ID EPIC.FINSENY.Device Database

Name Device Database Goal Identification of devices must be stores for authentication proposes. Version 2.0

Source FINSENY (WP3/WP4) Source contact Kolja Eger Stakeholder

Scope Platform

Status Under Evaluation by FI-WARE


Relative priority

Chapter IoT

Enabler IoT Resources Management Description Features: A device or sub-system should be able to describe its

capabilities to other entities. A description file is provided by the device and is expressed e.g. in XML. The description file contains information about the device, e.g. its logical devices, functional units and services. The description of the service includes a list of commands and its parameters as well as a list of variables to describe the state of the service at run time. A common information model for describing the capabilities of the device is needed and has to be standardized, e.g. based on IEC 61970/61968 or SCL of IEC 61850-6. Expected issue: Standardization of object models for capability description for a large set of devices and properties.

Rationale Any device that generates information required for management proposes or that could be updated/upgraded remotely must be authenticated before the data can be accepted or the firmware updated; therefore a centralized database will all devices and regional databases are required. Identification of devices must be stores for authentication proposes. Identification of devices like Meters, Charging Points, Intelligent Sensors, etc. requires definition and development of guidelines to ensure unique identification, e.g. Serial Number + Manufacturer + Region. In several Smart Grid use cases it is unlikely that a static engineering process is done for the whole system (e.g. supply-side and demand-side management). The Smart Grid shows dynamics and the engineering has to be adapted to these circumstances. It has to become an online process supporting the Plug & Play feature for devices.

Owner

Owner contact

Complexity L




Page 204 (335)

SGAM framewor k Information

Category EPIC

ID EPIC.FINSENY.Packet Loss

Name Packet Loss Goal Avoidance of packet Loss for MV secondary substations Version 1.0

Source FINSENY (WP2) Source contact Ignacio Martín Díaz de Cerio Stakeholder

Scope Platform

Status Pending MoSCoW priority Should

Relative priority

Chapter IoT

Enabler IoT Communications, IoT Resources Management

Description Packet Lost defines the maximum level of errors that the application could manage for normal operation. This parameter affects more drastically to Telecontrol function. Expected issue: ICT solution must be designed to guarantee a low level of packet lost for the Telecontrol function.

Rationale If packet lost is high Grid Control application becomes not so interactive as designed and safety problems could arise when switching circuit breakers

Owner

Owner contact

Complexity L

Creation Date



Page 205 (335)


Category FEATURE

ID FEATURE.FINSENY.Data Base System EV

Name Data Base System EV Goal A central or local (distributed) database system is required to provide

storage system(s) for context information (EV users, EVSE, environmental 3rd party). In an EVSE, also a local database may be used for charge detailed record.

Version 2.0


Scope Platform


Relative priority

Chapter IoT

Enabler Description A central or local (distributed) database system is required to provide

storage system(s) for context information (EV users, EVSE, environmental 3rd party). In an EVSE, also a local database may be used for charge detailed record.

Rationale Owner

Owner contact

Complexity


Last modi fied 07/02/2012


Page 206 (335)


Category FEATURE

ID FEATURE.FINSENY.Persistent data storage

Name Persistent data storage Goal Database systems must ensure availability of enough non-volatile

memory (e.g. flash memory) for storing measurements, internal data, and enable future firmware and software updates.

Version 1.0


Scope Platform


Relative priority

Chapter IoT

Enabler

Description Database systems must ensure availability of enough non-volatile memory (e.g. flash memory) for storing measurements, internal data, and enable future firmware and software updates.

Rationale Unacceptable data values must be detected in order to prevent undesirable application behavior and to notify the system of possible malfunctioned equipment.

Owner

Owner contact

Complexity XL




Page 207 (335)


Category FEATURE

ID FEATURE.FINSENY.Data Integrity at the Marketplace

Name Data Integrity at the Marketplace Goal To provide integrity to the access to the eMarket4E Version 1.0


Scope Platform


Relative priority

Chapter APPS

Enabler APPS: Marketplace

Description The Information that is to be collected by the Marketplace has to be handled taking care of personalization and context based information.

Rationale

Owner

Owner contact

Complexity M




Page 208 (335)


Category FEATURE

ID FEATURE.FINSENY.Distributed Processing

Name Distributed Processing Goal Distributed processing of the data is required to balance storage and

analysis of huge amount of data.

Version 1.0


Scope Platform


Relative priority

Chapter IoT

Enabler Descrip tion For balancing supply and demand the Microgrid Control Center has to

run the state analysis and define the sub-sequent actions. These tasks include power flow calculations and forecasting models.

Rationale To minimize processing latency the jobs could be processed in parallel and distributed across different machines. Also for forecasting, planning and revenue in the revenue distributed processing capabilities are crucial.

Owner

Owner contact

Complexity


Last modifie d 07/02/2012


Page 209 (335)


Category FEATURE

ID FEATURE.FINSENY.Smart Metering Data

Name Smart Metering Data Goal Data from smart meters should be available in the electronic-

marketplace system with a possibly low delay. This requires the respective infrastructure to communicate measurements from the individual smart meters to the respective systems, including harmonization of the data, plausibility checks etc.

Version 1.0



Stakeholder

Scope Platform


Relative priority

Chapter CLOUD, IoT, SECURITY

Enabler CLOUD EDGE; IoT Gateway Data Handling; SECURITY Identity Management

Description All consumers need to have Smart Meters and means to analyze/view the corresponding data in order to be precisely aware of their energy consumption. More, Microgrid Operators need to have Smart Meters and means to analyze/view the corresponding data in order to be precisely aware of e-Island energy consumption/production.

Rationale Owner

Owner contact

Complexity L

Creation Date



Page 210 (335)


Category FEATURE

ID FEATURE.FINSENY.Publish / Subscribe

Name Publish / Subscribe Goal Enables the reporting and logging of events as soon as they will

happen without the need for another request

Version 1.0

Source FINSENY (WP3) Source contact Jürgen Goetz

Stakeholder

Scope Platform


Relative priority

Chapter I2ND Enabler

Description A pub/sub service is a service based on the subscription of a client for a server initiating a data message as soon as a special event happens at the server side.

Rationale Requested for handling reports, events and alarms. Owner

Owner contact

Complexity XL




Page 211 (335)


Category STORY

ID STORY.FINSENY.Identifiers supporting E-Roaming

Name Identifiers supporting E-Roaming Goal Provide the possibility of the identification of an End User in front of an

EVSE via a Unique ID, which may reveal the E-mobility provider of an EV-user who is a roaming customer.

Version 1.0




Scope Platform

Status Pending



Chapter Sec; IoT

Enabler Description The identifier must be unique for each user. It may use a certain format

that draws conclusions on the country of origin or the E-mobility provider of the user. The uniqueness of each ID should not be affected by the bigger amount of user IDs because of roaming.

Rationale Each user needs to hold a unique ID for a proper Identification and Authentication in the whole roaming-connected area to make ICT services like accounting possible.

Owner TBD

Owner contact TBD

Complexity M




Page 212 (335)

11.1.4 Communication Layer SGAM framework Communication

Category THEME

ID THEME.FINSENY.Connectivity

Name Connectivity

Goal Connectivity must be insured for all devices and sub-systems to support all kind of data transports inside FINSENY's grid architectures.

Version 2.0

Source FINSENY (WP2/WP3/WP4/WP5)

Source contact Kolja Eger Stakeholder

Scope Platform


Relative priority


Enabler Connectivity Services have to be defined and managed by the communication network management. The connectivity services have to be classified according to a set of QoS parameters, like priority, latency; throughput, packet loss, etc. (see FINSENY.EPIC.Connectivity.QoS).

Description Devices (e.g. DER, Network Smart Devices) or sub-systems (e.g. Home/Building Energy Management Systems) installed in or at the edge of a Smart Grid need to communicate between each other or to their hosts located in physical Control or Management Centres or with virtualised Management Systems (eventually private or public cloud-based). Therefore Connectivity functions have to be assumed ubiquitously present throughout the SG topology. Different physical implementations of connectivity functions (communication networks) shape various dimensions of available capabilities. To match and agree on specific sets of connectivity capabilities between connected devices and Control Centres or Management Systems, the following EPICs were defined. Please note that they represent only a partition of the desired capability dimensions. Others need to be described in parallel or need to be added (e.g. performance, reliability, availability, scalability, security and environmental related).

Rationale Connectivity capabilities need to be commonly understood, agreed and controlled within the SG to support full desired functionality

Owner

Owner contact

Complexity XL




Page 213 (335)

SGAM framework Communication

Category THEME

ID THEME.FINSENY.Addressing

Name Addressing Goal When new devices (e.g. DER, Network Smart Devices) or sub-systems

(e.g. Home/Building Energy Management Systems) are installed in or at the edge of a Smart Grid (e.g. a Microgrid) they automatically configure themselves (also frequently denoted as Plug & Play). This requirement focuses on IP address configuration and addressability of the device by a Control Centre.

Version 2.0

Source FINSENY (WP3/WP4)


Scope Platform


Relative priority

Chapter I2ND; IoT

Enabler Connected Device Interfacing; IoT Communication

Description Features: This requirement describes to automatically configure the network address of the device or sub-system. To be independent on the communication network and the ownership of the network (e.g. utility-owned, commercially provided, Internet) dynamic IP addresses are used. For the auto configuration of network addresses different technologies are available (e.g. DHCP, Auto IP or NDP for IPv6). Furthermore, to increase reliability multi-homing should be possible. After auto-configuration of the network settings of the device or sub-system it is addressable locally or remotely by control centres. For flexibility the connection setup should be possible in both directions. Expected issues: NAT, Firewall configuration

Rationale Addressability is a prerequisite for all use cases which rely on communication.

Owner

Owner contact

Complexity M




Page 214 (335)


Category THEME

ID THEME.FINSENY.Communication Services

Name Communication Services Goal Communication Services have to be available for all devices and

subsystems. They support and enable data transport between devices in the grid to transfer information (e.g. based on IEC 61850) to each other.

Version 1.0


Source contact Jürgen Goetz Stakeholder

Scope Platform


Relative priority

Chapter IoT, I2ND

Enabler Description Communication Services deal with the interoperability between a

variety of devices in the distribution grid, e.g. between substations, IEDs and meters. The services hereby describe the transport of information (as described in IEC 61850 data model) between intelligent electronic devices. These services may be e.g. get, set, report, operate etc. and are mainly described in IEC 61850-7-2.

Rationale Communication services are a prerequisite for handling data of a data model describing the different devices (monitoring and control).

Owner

Owner contact

Complexity XL




Page 215 (335)


Category THEME

ID THEME.FINSENY.Interoperable ICT interfaces of EVSE

Name Interoperable ICT interfaces of EVSE Goal EVSE must be able to communicate with back-ends to transmit certain

charging or accounting parameters (in particular for intelligent charging). Even more important is a standardized interface to EVs in order to provide basic info’s on a screen in the EV.

Version 1.0


Source contact Jonas Fluhr Stakeholder cf. Use cases

Scope Platform



Chapter IoT

Enabler Description In order to enable ICT on end points, end points need to be

interoperable with each other. This allows for example the communication with ICT between EVSEs and EVs.

Rationale Interoperable ICT for EVSE reduces direct (e.g. additional hardware) or indirect (e.g. time of user) transaction costs of all concerned stakeholders.

Owner TBD

Owner contact TBD

Complexity XL




Page 216 (335)


Category THEME

ID THEME.FINSENY.Time Synchronization

Name Time Synchronization Goal To achieve network wide synchronization of control tasks on different

time-ranges and scalability up to hundreds of systems, while being robust to topology changes and failures, a time-based synchronization method by utilizing concepts of e.g. time-stamping and skew compensation with linear regression is needed.

Version 2.0


Source contact Kolja Eger

Stakeholder

Scope Platform

Status State of the art MoSCoW priority MUST

Relative priority

Chapter IoT Enabler Description For clock synchronization protocols like PTP (IEEE1588) and NTP

have to be used. To achieve network wide synchronization of control tasks on different time-ranges and scalability up to hundreds of systems, while being robust to topology changes and failures, a time-based synchronization method by utilizing concepts of e.g. time-stamping and skew compensation with linear regression is needed. Features: Establish time synchronization with precision up to 10ms - Re-Sync mechanism - Security Means - Interoperability of the IT-System on North-bound IT I/Fs. (Wrt processes, applications and databases in the sense of CIM/IEC61968, GID/IEC61970, GIS and Interactions) founded on available standards and extensions. -I7 Interoperability on standardized South-bound IT I/Fs as IEC61850, IEC60870 used for control and measurement purposes of SG-devices, DER, DG, Storage and SGEC devices. Should not stand in contradiction to already existing IEC61850 definitions. Expected issues: Deterministic of the communication network Information model interoperability


Page 217 (335)

Rationale Certain types of control applications require synchronized action sequences, on one hand for stringent and fast aligned control tasks (no jitter) or on the other for completing control tasks under upper limits of time. FLIR: In order to comply with standards (CEI, IEEE) FLIR is required to complete restoration within one minute. Since several messages have to be disseminated during the process, a delay of at most one second is acceptable. For tele-protection a delay of at most 50ms must be guaranteed. Since the voltages are much lower in the distribution network than in the transmission network, tele-protection is less important here than in transmission networks and we can omit the harsh requirement that only <50ms latency is acceptable (nice to have, but requires a large effort). MWFM: To react timely to new situations, field workers need to be notified of important events within seconds DCAC, SGEC: Control applications require fine-grained updates on state and fast delivery of commands, the typical latency requirement is one second. Some system critical components might require faster communication for network stability.

Owner

Owner contact

Complexity M




Page 218 (335)


Category EPIC

ID EPIC.FINSENY.Dedicated or Shared Transport Infrastructure

Name Dedicated or Shared Transport Infrastructure Goal Control from an Aggregator, VPP or DSO needs appropriate

transport network capacity, which may be supplied by a dedicated operator on an exclusive or shared basis

Version 1.0


Source contact Timo Kyntäjä Stakeholder

Scope Platform


Relative priority

Chapter I2ND Enabler S3C Description South-bound IT (Server) I/Fs need to connect via suitable transport

links towards the SG-device locations (e.g. Sub-Stations) Transport links may be realized via: - Optical Fibres, operating WDM, SDH/PDH, Ethernet/LAN, - 3GPP-defined cellular wireless (2G/GPRS 3G/UMTS 4G/LTE) - WIMAX or Microwave private radio network - Powerline based PLC/BPL (Powerline/Broadband Powerline Communication) - Commercial DSL-lines based on ADSL, VDSL or SHDSL

Rationale Transport infrastructure is relevant for on-going SG operation, private or dedicated networks may be purpose designed (for reliability, security)

Owner

Owner contact

Complexity S

Creation Date



Page 219 (335)


Category EPIC

ID EPIC.FINSENY.Connection Monitoring

Name Connection Monitoring Goal Monitoring of end-to-end connection parameters (online/offline,

latency, bandwidth, etc.) to remote devices

Version 1.0



Stakeholder

Scope Platform

Status Pending


Relative priority

Chapter IoT

Enabler Connectivity Management

Description The Communication Network Monitoring component monitors the connection status to all devices managed by the MGCC. This information includes parameters like online/offline, latency, jitter and bandwidth. This information is offered to other components in the MGCC, e.g. warnings about disconnection.

Rationale The current connection status has to be monitored to react on connection errors or bad network conditions. This information can help to increases the reliability of the overall system

Owner

Owner contact

Complexity L




Page 220 (335)


Category EPIC

ID EPIC.FINSENY.Communication protocols

Name Communication protocols

Goal A precondition for communication protocol for communication between end points (EV, EVSE) and own Back-end (Cloud) is a well-defined stack of communication protocols which enables IT services.

Version 1.0



Scope Platform

Status Pending



Chapter Sec; I2ND Enabler Description A communication protocol is a formal description and implementation

of a digital message format and communication rules. Interoperable ICT needs communication protocols to communicate with each other. Standardized communication protocols allow different ICT to be compatible with each other.

Rationale Without communication protocols the communication protocol between ICT devices is not possible.

Owner TBD

Owner contact TBD

Complexity L




Page 221 (335)


Category EPIC

ID EPIC.FINSENY.Data Bus Communication

Name Data Bus Communication

Goal The data bus should provide different communication services (e.g. request/response, publish/subscribe, transactions). Furthermore, it should support different levels of Quality of Service because different applications have different demands, e.g. w.r.t. latency, frequency of data exchange, quality or time synchronization.

Version 2.0



Scope Platform

Status Pending

MoSCoW priority Could

Relative priority

Chapter IoT

Enabler Description The data bus should provide different communication services (e.g.

request/response, publish/subscribe, transactions). Furthermore, it should support different levels of Quality of Service because different applications have different demands, e.g. w.r.t. latency, frequency of data exchange, quality or time synchronization.

Rationale Owner

Owner contact

Complexity


Last modified


Page 222 (335)


Category EPIC

ID EPIC.FINSENY.Data Bus integration

Name Data Bus integration Goal The data bus must provide different communication services (e.g.

request/response, publish/subscribe, transactions) storage in different databases.

Version 1.0


Source contact Martin Wagner

Stakeholder

Scope Platform

Status Pending


Relative priority

Chapter IoT

Enabler IoT Communication IoT Data Management

Description The data bus must support different levels of Quality of Service taking into account that different applications have different demands, e.g. w.r.t. latency, frequency of data exchange, quality or time synchronization.

Rationale Transforming and analysing data into useful business and operational intelligence is one of the biggest challenges. For this purpose a flexible data bus to exchange information is crucial.

Owner

Owner contact

Complexity XL




Page 223 (335)


Category EPIC

ID EPIC.FINSENY.Device registration for remote monitoring and control

Name Device registration for remote monitoring and control Goal When new devices (e.g. DER, Network Smart Devices) or sub-systems

(e.g. Home/Building Energy Management Systems) are installed in or at the edge of the Smart Grid (e.g. Microgrid) they automatically configure themselves (also frequently denoted as Plug & Play). This requirement focuses on the registration of the device or sub-system at a registry which is operated e.g. as part of control centre (e.g. the Microgrid Control Centre).

Version 2.0



Stakeholder

Scope Platform

Status Under Evaluation by FI-WARE MoSCoW priority MUST

Relative priority

Chapter IoT

Enabl er IoT Resources Management

Description Features: After connecting to the network, the device or sub-system connects to a registry where it publishes the description of its capabilities and services with respect to monitoring and control. The registry could be central or distributed. Furthermore, access rights are defined based on contractual agreements which define the level of monitoring and control of the device or sub-system from control centre. This registry provides lookup services with rich-query functions for a control centre to discover devices with the needed properties or capabilities.

Rationale In several Smart Grid use cases it is unlikely that a static engineering process is done for the whole system (e.g. supply-side and demand-side management). The Microgrid shows dynamics and the engineering has to be adapted to these circumstances. It has to become an online process supporting the Plug & Play feature for devices.

Owner

Owner contact

Complexity L


Last modi fied 14/11/2011


Page 224 (335)


Category EPIC

ID EPIC.FINSENY.Interoperable ICT interfaces of EVSE at (semi-)public places

Name Interoperable ICT interfaces of EVSE at (semi-)public places Goal The interoperability of ICT at EVSE is particular important at public places.

It is the base for E-Roaming as well as further intelligent charging services.

Version 1.0




Scope Platform

Status Pending

MoSCoW priorit y MUST


Chapter IoT

Enabler Description Especially at public places, EVSE and EVs must be able to operate using

ICT. Interoperable ICT enables IT based services for EV-users, E-mobility providers and grid stabilization.

Rationale Interoperation between EVSE and EV is necessary for all intelligent charging services to enable authentication and authorization at an ID-Server for example, in particular at public places.

Owner TBD

Owner contact TBD

Complexity XL

Creation Dat e 26/04/2012



Page 225 (335)


Category EPIC

ID EPIC.FINSENY.IP mobility

Name IP mobility Goal "Pushing” data to the worker handset whatever the telecommunication

medium the worker is currently using.

Version 1.0


Source contact Patric Coudray

Stakeholder

Scope Platform


Relative priority

Chapter IoT

Enabler IoT Communications

Description From the Dispatch System point of view, the communication system must be able to “push” data to the worker handset whatever the telecommunication medium the worker is currently using, even if its IP address has changed.

Rationale IP mobility is an issue that must be handled by the communication system Owner

Owner contact

Complexity L

Creation Date



Page 226 (335)


Page 227 (335)


Category EPIC

ID EPIC.FINSENY.IPV6 a must for IOT (Customer BEMS and related devices)

Name IPV6 a must for IOT (Customer BEMS and related devices) Goal It is needed Internet (IPv6) for the BEMS Version 1.0



Stakeholder

Scope Platform

Status Pending


Relative priority

Chapter not applicable as this is an infrastructure requirement

Enabler not applicable as this is an infrastructure requirement

Description The BEMS would have to be uniquely identified at the customer premises and in some cases the devices included in energy efficiency services.

Rationale Owner

Owner contact

Complexity S




Page 228 (335)


Category EPIC

ID EPIC.FINSENY.Latency

Name Latency Goal The communication infrastructure must offer a guarantee on the maximal

round trip time for messages (from the application on the originator device to the destination device and back)

Version 1.0


Source contact Yvonne-Anne Pignolet

Stakeholder

Scope Platform

Status Pending

MoSCoW priori ty MUST

Relative priority

Chapter IoT

Enabler IoT Communications, IoT Resources Management and DSE in case the requirement is not fulfilled by GE

Description For time critical events the communication infrastructure must offer a guarantee on the maximal round trip time for messages.

Rationale FLIR: In order to comply with standards (CEI, IEEE) FLIR is required to complete restoration within one minute. Since several messages have to be disseminated during the process, a delay of at most one second is acceptable. For tele protection a delay of at most 50ms must be guaranteed. Since the voltages are much lower in the distribution network than in the transmission network, tele protection is less important here than in transmission networks and we can omit the harsh requirement that only <50ms latency is acceptable (nice to have, but requires a large effort). MWFM: To react timely to new situations, field workers need to be notified of important events within seconds DCAC, SGEC: Control applications require fine-grained updates on state and fast delivery of commands, the typical latency requirement is one second. Some system critical components might require faster communication for network stability.

Owner

Owner contact

Complexity L

Creation Date



Page 229 (335)


Category EPIC

ID EPIC.FINSENY.Secure communication between smart grid and operator

Name Secure communication between smart grid and operator Goal Use of standard security mechanism for the communications Version 1.0



Scope Platform

Status Pending


Relative priority

Chapter not applicable as this is an infrastructure/communication requirement

Enabler not applicable as this is an infrastructure/communication requirement

Description The events and information interchanged between the different eMarket4E actors must be certified by the originator before being taken into account, so that faked events may be dismissed.

Rationale

Owner

Owner contact

Complexity M




Page 230 (335)


Category EPIC

ID EPIC.FINSENY.TCP/IP protocol

Name TCP/IP protocol Goal Version 1.0



Stakeholder

Scope Platform


Relative priority

Chapter not applicable as this is an infrastructure/communication requirement

Enabler not applicable as this is an infrastructure/communication requirement

Description TCP/IP, the most important protocol, is the one used for communications. TCP/IP protocol must be supported between the different actors in the eMarket4E

Rationale

Owner

Owner contact

Complexity XS




Page 231 (335)


Category FEATURE

ID FEATURE.FINSENY.Speed of communication to the eMarket4E services

Name Speed of communication to the eMarket4E services Goal Speed of communication is needed to make more automatic the trading

process, to involve prosumers and to incentive renewable energy sources.

Version 1.0



Scope Platform


Relative priority

Chapter not applicable as this is a WAN network/connectivity requirement

Enabler not applicable as this is a WAN network/connectivity requirement Description eMarket4E services will require SOTA internet connectivity speeds. In this

case speeds starting at 800 Kbps should be provided.

Rationale Owner

Owner contact

Complexity S




Page 232 (335)


Category FEATURE

ID FEATURE.FINSENY.Reliable data transport over heterogeneous networks

Name Reliable data transport over heterogeneous networks Goal Different Communication Service Providers (CSP) are maybe involved in

a single data transaction. End-2-End QoS has to be assured over CSP boundaries including identification of Location of Failure.

Version 1.0


Source contact

Stakeholder

Scope Platform

Status Pending

MoSCoW priority Could

Relative priority

Chapter IoT Enabler Description Different Communication Service Providers (CSP) are maybe involved in

a single data transaction. End-2-End QoS has to be assured over CSP boundaries including identification of Location of Failure.

Rationale Owner

Owner contact

Complexity L


Last modified


Page 233 (335)


Category FEATURE

ID FEATURE.FINSENY.Communication protocols supporting E-Roaming

Name Communication protocols supporting E-Roaming Goal A precondition for communication between end points (EV, EVSE) and

own Back-end (Cloud) as well as between back-end and back-end of roaming partners is a communication protocol which also enables standardized roaming services. In analogy to mobile networks a Charge Data Record (CDR) contains information about the charging process. Certificates and signatures for measuring purposes and ID transfer help with the verification of transferred data.

Version 1.0



Scope Platform



Chapter Sec; I2ND

Enabler Description Interoperable ICT needs communication protocols to communicate with

each other. Standardized communication protocols allow different ICT to be compatible with each other. An Open Charge Communication Protocol (OCCP) is in development which enables roaming.

Rationale Without communication protocols the communication protocol between ICT devices is not possible. Roaming services are more complex than usual communication between EVSE and EVs which makes communication protocols necessary to provide roaming services.

Owner TBD

Owner contact TBD

Complexity L




Page 234 (335)


Category FEATURE

ID FEATURE.FINSENY.Communication interface to EVSE

Name Communication interface to EVSE

Goal Provide a communication interface for communication between EVSE or the back-end and an EV-user.

Version 1.0




Scope Platform



Chapter IoT; Sec; I2ND

Enabler

Description Communication interfaces enable user to machine and machine to machine communication. It allows transfer of data into the cloud as well as a communication interface for user to EVSE and user to back-end communication.

Rationale Without communication interfaces and protocols a communication between user and devices as well as devices and devices is not possible.

Owner TBD

Owner contact TBD

Complexity L




Page 235 (335)


Category FEATURE

ID FEATURE.FINSENY.Communication QoS for V2G

Name Communication QoS for V2G Goal The guaranteed quality level (Best)

Different Intermediate Levels (Intermediate) [ No Quality Level (No - Best Effort) ]; also for VAS, such as educating/training videos for inexperienced EV-users, instead printed manuals/handbooks in the car; real-time mapping services (gmaps)

Version 1.0


Source contact Fergal Ward


Scope Platform



Chapter

Enabler

Description For vehicles that are used in different Use Case categories, Fi-Ware and or Smart Grids applications will need to directly control the QoS levels / SLA's of the various SG services. WP5 trials will need a range of CoS levels ranging from guaranteed QoS with low bandwidth levels, guaranteed QoS with high bandwidth levels, and also best effort traffic.

Rationale Problem: In how far could the Core-Platform support here? What’s the exact ICT requirement for them? In how far it could be a generic enabler?

Owner TBD

Owner contact TBD

Complexity M

Creatio n Date 26/04/2012



Page 236 (335)


Category FEATURE

ID FEATURE.FINSENY.Backup of communication links

Name Backup of communication links Goal Backup solution should be provided for the communication links.

Interfaces enabling communication should operate also at the time when the DSO grid is down. Exception can be a LV PLC link.

Version 1.0


Source contact Henryka Jormakka

Stakeholder

Scope Platform


Relative priority

Chapter IoT

Enabler IoT Communications

Description Features: Interfaces to different physical media. Back up network for communication between elements. Expected issues: Increased cost of the system.

Rationale The communication may be necessary for grid re-establishing. Owner

Owner contact

Complexity L

Creation Date



Page 237 (335)


Category FEATURE

ID FEATURE.FINSENY.Device discovery in a Local Area Network

Name Device discovery in a Local Area Network Goal When new devices are installed in a Smart Building or data centre they

automatically configure themselves (also frequently denoted as Plug & Play). This requirement focuses on discovery mechanisms in the LAN of the building.

Version 2.0



Scope Platform

Status Under Evaluation by FI-WARE MoSCoW priority MUST

Relative priority

Chapter IoT Enabler IoT Resources Management Description Features: After connecting to the network, the device runs a discovery

protocol where it advertises its services to control points. Furthermore, the protocol offers search functions for control points to find devices of interest. Expected issues: no difficult configuration yet ensure secure & trusted access

Rationale Devices installed by the end consumer without any installer should be plug & play. However shouldn't allow unauthorized access from neighbours, hackers … nor allow the user to hack the neighbours. If an installer is mandatory, his skills may not be in ICT but rather in electricity, energy management, etc.

Owner

Owner contact

Complexity L

Creation Date 05.08.2011



Page 238 (335)


Category FEATURE

ID FEATURE.FINSENY.High priority asynchronous messages (related to CoS or QoS - feature or Story)

Name High priority asynchronous messages (related to CoS or QoS - feature or Story)

Goal In case of alarms, e.g. in conjunction with power inverters, the according asynchronous messages must be transported very fast to the controller, as alarms normally reflects a very soon loss of energy production. In order to further guarantee the stability of the smart grid, therefore, this information must be transported with highest priority or via reserved communication channels. Without time-synchronization just the priority of the (asynchronous) telegram can be used to reduce the latency from submitting the message until receiving it.

Version 2.0


Sourc e contact Dieter Eckardt

Stakeholder

Scope Platform

Status Already covered


Relative priority

Chapter IoT Enabler IoT Resource Management Description Establish prioritized communication channels

Fast priority routing mechanisms Security Means Interoperability of the IT-System on North-bound IT I/Fs. (Wrt processes, applications and databases in the sense of CIM/IEC61968, GID/IEC61970, GIS and Interactions) founded on available standards and extensions. Interoperability on standardized South-bound IT I/Fs as IEC61850, IEC60870, DNP3 used for control and alarm purposes of SG-devices, DER, DG, Storage and SGEC devices. Expected issues: Reservation of communication channels (hidden to the user) Fast Priority routing Information model interoperability

Rationale In order to be able to stabilize the grid even in case of big energy losses as a consequence of a failure situation (e.g. within a DER) the controller must be informed immediately about the new situation. The controller then is forced to use such high priority channels in order to redirect energy to maintain stability of the grid.

Owner

Owner contact

Complexity M




Page 239 (335)


Category FEATURE

ID FEATURE.FINSENY.Interoperable ICT interfaces of EVSE at (semi-) public places supporting E-Roaming

Name Interoperable ICT interfaces of EVSE at (semi-) public places supporting E-Roaming

Goal Provide the possibility of varying energy suppliers at one EVSE at a public EVSE.

Version 1.0



Scope Platform



Chapter IoT

Enabler

Description EVSEs and EVs must be able to operate using ICT even if the EVSE is operated by a foreign E-mobility provider. Interoperable ICT enables IT based roaming services for EV-users, E-mobility providers and grid stabilization.

Rationale Interoperation between EVSE and EVs is necessary for all intelligent charging services to enable authentication and authorization at an ID-Server for example. It is even more important for automatic roaming processes.

Owner TBD

Owner contact TBD

Complexity XL




Page 240 (335)


Category FEATURE

ID FEATURE.FINSENY.Need of GSM/GPRS/HSDPA systems for mobile approach

Name Need of GSM/GPRS/HSDPA systems for mobile approach Goal In order to deploy mobile application we need to be supported by

GSM/GPRS/HSDPA systems communication

Version 1.0



Scope Platform


Relative priority

Chapter not applicable as this is an infrastructure/communication requirement Enabler not applicable as this is an infrastructure/communication requirement Description the realization of the nomadic dream for the transactions in the energy

market operations: anywhere, anytime, safely

Rationale Owner

Owner contact

Complexity M




Page 241 (335)

11.1.5 Component Layer SGAM framework Component

Category EPIC

ID EPIC.FINSENY.Interoperability of Public Charge Points with EV (ICT and Electrical)

Name Interoperability of Public Charge Points with EV (ICT and Electrical) Goal The charging point supports various models of electric vehicles.

Version 1.0



Stakeholder

Scope Platform

Status Pending


Relative priority

Chapter IoT

Enabler

Description The charging point supports various models of electric vehicles. Rationale If the charging point is not standard to any EV model, the final user must

be sure regarding the availability of charging point for his/her model.

Owner

Owner contact

Complexity L


Last modified


Page 242 (335)

SGAM framework Component

Category EPIC

ID EPIC.FINSENY.Device discovery

Name Device discovery

Goal When new devices (e.g. DER, Network Smart Devices) or sub-systems (e.g. Home/Building Energy Management Systems) are installed in or at the edge of the Smart Grid (e.g. Microgrid) they should get automatically configured (by a generalization of classical Plug & Play mechanisms). This requirement focuses on the discovery of the device or sub-system by the system to which it gets connected.

Version 2.0



Stakeholder

Scope Platform

Status Pending


Relative priority

Chapter IoT

Enabler Description As per classical mechanisms, a new device can broadcast its identity on

the network to which it gets connected and this message is intercepted by registry services or agents. This first configuration stage then leads to the registration stage

Rationale Owner

Owner contact

Complexity

Creation Date

Last modified


Page 243 (335)


Category FEATURE

ID FEATURE.FINSENY.Servers array for a cloud computing for high speed data processing and running services

Name Servers array for a cloud computing for high speed data processing and running services

Goal A large amounts of data need to be collected and processed in high speed mode through an appropriate infrastructure.

Version 1.0



Stakeholder

Scope Platform

Status Pending


Relative priority

Chapter not applicable as this is an infrastructure/storage requirement

Enabler not applicable as this is an infrastructure/storage requirement Description In the Smart Grids energy trading (kind, quantity & price) , where fast

processing of large volumes of data is mandatory for securities and other transactions, the world's best response performance and throughput at the millisecond level is a necessity. In addition, a large number of prosumers have a growing need for the real-time analysis of conditions to strengthen their risk management and monitoring capabilities. The high-speed and large-volume data processing solution provides just the right solution for a wide range of prosumer needs. A large amounts of data need to be collected and processed in high speed mode through an appropriate infrastructure. For this reason cloud infrastructure services seems to be the right answer

Rationale The Requirement is mandatory to be able to provide the service. Owner

Owner contact

Complexity M




Page 244 (335)


Category FEATURE

ID FEATURE.FINSENY.Registry Services

Name Registry Services

Goal The device registry offers internally in the MGCC different communication services (i.e. REQ/RESP as well as PUB/SUB) over the ESB for other components to provide look-ups.

Version 1.0



Stakeholder

Scope Platform

Status New WP3 Requirement MoSCoW priority SHOULD

Relative priority

Chapter IoT Enabler IoT Resources Management Description The device registry offers different communication services over the ESB

to provide look-up results to other components. These services are request/response as well as subscribe/notification. In the case of subscribe/notification a component can subscribe on changes about a specific query. The registry will notify the component to return updated query results.

Rationale Communication services give flexibility for other components. Subscription/notification avoids polling the registry for updates.

Owner

Owner contact

Complexity M




Page 245 (335)


Category FEATURE

ID FEATURE.FINSENY.Remote Upgrades

Name Remote Upgrades Goal Remote software upgrades of the charging infrastructure (e.g. pool of

charging stations), single charging stations, substations and other grid devices and in the self-configuration case also of sensors and other involved devices.

Version 1.0


Source contact Thomas Loewel

Stakeholder

Scope Platform

Status Pending


Relativ e priority

Chapter Data/Context Management; Applications/Services Ecosystem & Delivery; Internet Of Things (IOT) Services Enablement; Interface To Networks And Devices; Security

Enabler

Description Required software upgrades of the charging infrastructure (e.g. pool of charging stations) and single charging station shall be possible remotely. Furthermore remote software updates of substation and other grid devices shall be also possible. In the self-configuration case the remote software upgrade of sensors and other devices is also required.

Rationale The roll-out of the charging infrastructure is an on-going process. For that it is necessary to maintain and to upgrade the software of charging stations (pool or single). Especially with respect to the increasing number of the charging stations (and thus the complete infrastructure) software upgrades are necessary to enhance the communication between these elements and additional with the grid. Similar is the situation for the grid itself. On-going developments will be takes place in the future. For that it is essential to perform remote software upgrades in the substations and other grid devices to enhance and to maintain the functionality of these devices. The self-configuration aspect makes the grid more agile, reliable, available etc. For that it is necessary to have a lot of sensors in the grid and the amount of sensors should be increased. The development of the firmware of these sensors is an on-going process and the possibility of remote software upgrades is mandatory.

Owner

Owner contact

Complexity L




Page 246 (335)


Category FEATURE

ID FEATURE.FINSENY.Deploy Apps on Smart Grid Devices

Name Deploy Apps on Smart Grid Devices Goal Provide means to modularly manage groups of functionalities (via "Apps")

of plenty, distributed smart grid devices.

Version 2.0




Scope Platform

Status Pending



Chapter IoT

Enabler

Description The smart grid relies more and more on distributed elements (smart grid devices) that are computing and communicating with each other and with control centres. Apart from hardware elements, these distributed elements are able to provide different functions over time. The functionality, once initialized can be changed via updates or upgrades. In order to allow these updates/upgrades, security issues are to be considered.

Rationale Avoids costs for changing communication technology.

Owner

Owner contact

Complexity L




Page 247 (335)


Category FEATURE

ID FEATURE.FINSENY.High Demand for Computing Resources

Name High Demand for Computing Resources Goal For some use cases, it is necessary to provide high performance

computing resources for calculation and simulation models in the Microgrid Control Centre including real-time processing.

Version 1.0


Source contact Rafał Artych

Stakeholder

Scope Platform

Status Under evaluation by FI-WARE


Relative priority

Chapter Cloud Hosting

Enabler PaaS management

Description Extension of FIWARE.Epic.Cloud.PaaS.PaaSScaling for cloud architecture used for the Microgrid Control Centre component. Some operations of the Microgrid Control Centre require higher computing resources than during normal management operations. Therefore the hosting environment should provide means providing computing resources for high demanding tasks. One example is switching to islanding mode in order to quickly check availability of electrical resources in case islanding of the Microgrid is required. Also for long-term planning it may be necessary to provide high performance processing for large-scale planning and simulation. In order to optimize power flow in case of switching to islanding mode, high demand for computing resources for calculation and simulation models in Microgrid Control Centre is required. In order to optimize power flow in case of switching to connected mode, medium processing demand for adaptation to electrical parameters in Overlay Grid is required.

Rationale Performance scaling is needed for hosting of the Microgrid Control Centre in the cloud environment.

Owner

Owner contact

Complexity L




Page 248 (335)

11.2 Domain Specific ICT Requirements

11.2.1 Business Layer


Category EPIC

ID EPIC.FINSENY.Energy Forecast

Name Energy Forecast

Goal To foresee energy consumption and production at different level (Home, Building, neighborhood, city etc.) The consumption/production forecast has to cover from short to long time

Version 1.0



Stakeholder

Scope Domain Specific

Status Pending


Relative priority

Chapter Applications/Services Ecosystem and Delivery Framework

Enabler Marketplace

Description

More accurate forecasting of the Energy consumption and production in a more granular way will be able to support the energy stakeholders to take decisions for Energy trading, for grid load management, for Energy use ( e.g. : in house)

Rationale

Owner

Owner contact

Complexity


Last modified


Page 249 (335)


Category EPIC

ID EPIC.FINSENY.Processing capabilities at the Marketplace

Name Processing capabilities at the Marketplace

Goal The Service at the marketplace will have to implement complex operations between the data that will be collected from the Grid users and operators So high level of processing capabilities are needed

Version 1.0



Stakeholder


Status Pending


Relative priority

Chapter APPS


Description The Service at the marketplace will have to implement complex operations between the data that will be collected from the Grid users and operators

Rationale

Owner

Owner contact

Complexity L




Page 250 (335)


Category STORY

ID STORY.FINSENY.Standardized energy information data

Name Standardized energy information data

Goal Format for information exchange has to be standardized

Version 1.0



Stakeholder


Status Pending


Relative priority


Enabler not applicable as this is a standardization requirement

Description

A standard for energy information and analytic results needs to be available in order to facilitate the transactions and additional services offered in marketplace as well as energy information analytics for the smart city.

Rationale Different HW / SW architectures have to be interfaced to exchange technical and economic information for the energy market: they must speak the same language.

Owner

Owner contact

Complexity S




Page 251 (335)


Category THEME

ID THEME.FINSENY.Control Capability

Name Control Capability

Goal For control functionalities of the Microgrid Control Centre guaranteed performance: deterministic processing time including real-time processing is required

Version 1.0



Stakeholder


Status New WP3 requirement


Relative priority

Chapter Cloud hosting

Enabler

Description


Rationale Control capability is needed for hosting of the Microgrid Control Centre in the cloud environment.

Owner

Owner contact

Complexity L




Page 252 (335)


Category EPIC

ID EPIC.FINSENY.Store and Management of Apps for smart grid devices

Name Store and Management of Apps for smart grid devices

Goal Provide access to a huge amount of applications (app store) packaged with the possibility to easily deploy them and manage them on all operated devices.

Version 2.0





Status Pending



Chapter Cloud; IoT

Enabler

Description

The app store does not provide the possibility to "buy" new apps, but also a method deploys these Apps on a bunch of gadgets and therewith functionally administers the devices. Different players would have own accounts for their profile and therefore can only "reconfigure" the functionality of their devices (high security requirements!).

Rationale Decreases costs of managing many different applications on different devices.

Owner TBD

Owner contact TBD

Complexity M




Page 253 (335)


Category FEATURE

ID FEATURE.FINSENY.Forecasting of production/consumption hourly –daily- monthly- yearly

Name Forecasting of production/consumption hourly –daily- monthly- yearly

Goal Services able to provide reliable forecasts of od energy production are required and use at user premise in order to plan the energy consumption and to participate to energy trading market.

Version 1.0



Stakeholder


Status Pending


Relative priority



Description The users should be able to Know the next/future consumption/production of energy hourly, daily and monthly. Reliable forecasts of energy demand are needed for planning generation and consumption.

Rationale

Owner

Owner contact

Complexity XL




Page 254 (335)


Category THEME

ID THEME.FINSENY.Monitoring & Control Services

Name Monitoring & Control Services

Goal Monitoring and Control Services are needed to get status information from and control signals to the devices in a reliable and timely manner

Version 1.0



Stakeholder




Relative priority

Chapter

Enabler Domain Specific Enabler based on IEC61850

Description Monitoring and Control Services have to be defined to get status information from and control signals to the devices in a reliable and timely manner

Rationale Monitoring and Control Services are needed to get status information from and control signals to the devices in a reliable and timely manner

Owner

Owner contact

Complexity H




Page 255 (335)

11.2.2 Function Layer


Category EPIC

ID EPIC.FINSENY.Transactional mechanisms

Name Transactional mechanisms

Goal


Version 1.0



Stakeholder


Status NEW WP3 requirement


Relative priority

Chapter

Enabler Domain Specific Enabler 'Distributed Transaction Service', enhancement of IEC61850

Description

A transaction is a logical unit of work coordinating distributed data and process (service) handling. Transactions usually start with a begin operation and finishes with either the commit or the abort (rollback) operation. Between the start, the commit or abort operation, data operations and process coordination activities are executed. Classic transactions are bracketed by key control operations as Begin-Transaction, Commit-Transaction and Abort-Transaction. Each transaction must respect all the ACID properties: Atomic, Consistency, Isolation and Durability. Enhanced transaction mechanisms have to control the operations and outcome of multiple applications or services. For this they include a coordination and correlation manager. It is useful to define transaction services for short term and long term transactions.

Rationale requested for e.g. Balancing demand and supply, control services

Owner

Owner contact

Complexity L




Page 256 (335)


Category THEME

ID THEME.FINSENY.Contract information

Name Contract information

Goal To manage contract information

Version 1.0



Stakeholder


Status Pending


Relative priority



Description Contract information need to be updated daily in order to take decisions on the scheduling of the consumption of the energy by the BEMS or the final user.

Rationale

Owner

Owner contact

Complexity S




Page 257 (335)


Category FEATURE

ID FEATURE.FINSENY.Energy source information hourly – daily: generation, price, source …

Name Energy source information hourly – daily: generation, price, source …

Goal The energy source information of the electricity need to be updated hourly-daily in order to take decisions on the scheduling of the consumption of the energy by the BEMS or the final user.

Version 1.0



Stakeholder


Status Pending


Relative priority



Description The energy source information of the electricity need to be updated hourly-daily in order to take decisions on the scheduling of the consumption of the energy by the BEMS or the final user.

Rationale

Owner

Owner contact

Complexity S




Page 258 (335)


Category FEATURE

ID FEATURE.FINSENY.Forecast of grid load and energy demand

Name Forecast of grid load and energy demand

Goal Services able to provide reliable forecasts of grid load and energy demand are required in order to plan energy generation and consumption.

Version 1.0



Stakeholder


Status Pending


Relative priority



Description Reliable forecasts of grid load and energy demand are needed for planning generation and consumption.

Rationale

Owner

Owner contact

Complexity L




Page 259 (335)


Category FEATURE

ID FEATURE.FINSENY.Power limits information

Name Power limits information

Goal For the user to get detailed information of the consumption and to reduce it using a DMS application choosing what it offers.

Version 1.0



Stakeholder


Status Pending


Relative priority



Description The information about the power limit in the electric contracts needs to be updated daily in order to take decisions on the scheduling of the consumption of the energy by the BEMS or the final user.

Rationale

Owner

Owner contact

Complexity S




Page 260 (335)


Category EPIC

ID EPIC.FINSENY.Rating system

Name Rating system

Goal A rating system should be available that facilitates a possibly objective assessment of all marketplace actors. Such a system should be objective, easy to understand, comprehensible and follow state-of-the-art concepts.

Version 1.0



Stakeholder


Status Pending


Relative priority

Chapter APPS


Description

A rating system is available that facilitates a possibly objective assessment of all marketplace actors. This enables the prosumers to consider them prior to transactions in order to enhance the prosumers risk management analysis. The rating system could be similar to well-known systems which are in use on websites such as amazon or eBay.

Rationale

Owner

Owner contact

Complexity M




Page 261 (335)


Category STORY

ID STORY.FINSENY.Accounting for V2G usage

Name Accounting for V2G usage

Goal V2G usage must be accounted properly to ensure that an EV-user is paid for his reinjected energy.

Version 1.0





Status Pending



Chapter Data; IoT; Sec

Enabler

Description Consumed and inserted power is multiplied via amounts (rating), and compared (clearing), and finally billed to the customer (potentially "cash back" for customer).

Rationale EV-users must be paid for his efforts to support the grid providing energy storage capacity.

Owner TBD

Owner contact TBD

Complexity XL




Page 262 (335)


Category EPIC

ID EPIC.FINSENY.Control Apps

Name Control Apps

Goal A control center can remotely install control applications on other devices

Version 1.0



Stakeholder


Status NEW WP3 Requirement


Relative priority

Chapter


Description

Similar to the requirement in FINSENY.EPIC.Modularity.ExecutionContainer code can be deployed at a device. This should also enable to remotely install control apps which have access to the control API of the device.

Rationale

Many different control schemes are currently investigated in the Microgrid context. It is hard to standardize each of these schemes. A flexible device platform can overcome this issue and enables each operator to deploy the control apps they need.

Owner

Owner contact

Complexity XL




Page 263 (335)


Category FEATURE

ID FEATURE.FINSENY.Control of EV (charging signals) Name Control of EV (charging signals) Goal EVSE and EVs must be ready in order to start the power transfer any

time.

Version 1.0




Status Domain Specific



Chapter IoT; I2ND

Enabler

Description EVSE should get charging signals which enable or disable charging at the specific charging outlet of an EVSE. This helps stabilizing the grid and makes intelligent charging possible.

Rationale In case of a high grid load a control center could disable certain a charging outlet of an EVSE to stabilize the grid. On the other side charging could be enabled when the energy prices are low because of a lack of energy demand.

Owner TBD

Owner contact TBD

Complexity M




Page 264 (335)


Category FEATURE

ID FEATURE.FINSENY.High portability applications for fixed and mobile services targeted to the final customer

Name High portability applications for fixed and mobile services targeted to the final customer

Goal The applications for the services about the eMarket4E have to function properly on the widest possible range of devices, whether they are fixed or mobile, with different operating systems.

Version 1.0



Stakeholder


Status Pending


Relative priority

Chapter APPS

Enabler APPS: MARKETPLACE (Multi-channel access (Web-based access, mobile, …))

Description The applications for the services about the eMarket4E have to function properly on the widest possible range of devices, whether they are fixed or mobile, with different operating systems.

Rationale This requirement is mandatory because it's the service that must adapt to the customer devices and not vice versa

Owner

Owner contact

Complexity L




Page 265 (335)


Category EPIC

ID EPIC.FINSENY.Network Cell synchronization

Name Network Cell synchronization

Goal A synchronization protocol is needed to synchronize different networks in terms of frequency, phase and voltage

Version 1.0


Source contact Didier Boeda and Lionel Besson

Stakeholder




Relative priority

Chapter

Enabler

Description


Rationale

This synchronization is needed for the Black Start of the Microgrid at two steps:- At the beginning of the BS process, when the different MG islands synchronize together- At the end of the BS process, when reconnecting the MG to the overlay grid

Owner

Owner contact

Complexity XL




Page 266 (335)


Category THEME

ID THEME.FINSENY.Discovery and identification of non-network-connected entities

Name Discovery and identification of non-network-connected entities

Goal Extension of device configuration mechanisms to physical entities that do not have a network interface

Version 2.0



Stakeholder


Status Pending


Relative priority

Chapter IoT

Enabler

Description

Sensors may play the role of a network interface for physical entities that do not have a network interface (e.g. legacy appliances in a building) : these entities can get discovered, identified and registered through sensors in a way similar to what is done for regular networked devices using plus & play mechanisms

Rationale

Owner

Owner contact

Complexity

Creation Date

Last modified


Page 267 (335)


Category EPIC

ID EPIC.FINSENY.Interoperability of Building energy management system with the grid (distribution network or Microgrid)

Name Interoperability of Building energy management system with the grid (distribution network or Microgrid)

Goal Standard interface between the grid and the building energy management system should allow the exchange of upward monitoring and downward control information between the two

Version 2.0



Stakeholder


Status Pending


Relative priority

Chapter IoT

Enabler

Description

The technologies that can support such a dialogue are extremely diverse. At the most elementary level it is a form of Inter-Process Communication (IPC) between the grid and the building components and, as such, all the following are possible: • SOAP web services • REST web services • semantic web • custom socket-level protocol (low level but reliable and widely deployed). • structured data exchanges (e.g. following an XML, JSON or ASN.1 serialization)

Rationale

Owner

Owner contact

Complexity

Creation Date

Last modified


Page 268 (335)


Category EPIC

ID EPIC.FINSENY.Electricity Price signal hourly – daily

Name Electricity Price signal hourly – daily

Goal

Fixing and managing the Price .The main price to be dealt with are: Energy Price derived from auctions (for who participate to Energy Trading) (prices and quantity exchanged) Final Energy Prices- Tariff (Price/kW to be pay from the final customers) (Defined from the Energy Retails. It derives from the business model and pricing model followed. ) The price has to be notified/shown to all market stakeholders according their roles in the electronic market place.

Version 2.0


Source contact Massimiliano Nigrelli

Stakeholder


Status Pending


Relative priority



Description

The final user should know the price of the electricity in order to incentive or disincentive the consumption of the energy depending on the price. This interface must be as much detailed as possible covering final price per minute, incentives, contra-incentives, etc. The final price of the electricity for customers needs to be updated hourly-daily in order to take decisions on the scheduling of the consumption of the energy by the BEMS or the final user.

Rationale

Owner

Owner contact

Complexity S




Page 269 (335)


Category EPIC

ID EPIC.FINSENY.Operate

Name Operate

Goal Operate (or cancel) control value also at a specific point in time (time activated operate)

Version 1.0



Stakeholder




Relative priority

Chapter


Description Service is specified in detail in IEC61850 ACSI

Rationale Specific control services are needed for energy automation in the Microgrid. It should be possible to use them over the IoT GEs by FI-WARE.

Owner

Owner contact

Complexity M




Page 270 (335)


Category EPIC

ID EPIC.FINSENY.Select before operate

Name Select before operate

Goal Select a control point before sending an operate command. This locks the control point and control sequences can be realized.

Version 1.0



Stakeholder




Relative priority

Chapter




Owner

Owner contact

Complexity M




Page 271 (335)


Category EPIC

ID EPIC.FINSENY.Control Apps

Name Control Apps

Goal A control center can remotely install control applications on other devices

Version 1.0



Stakeholder




Relative priority

Chapter


Description

Similar to the requirement in FINSENY.EPIC.Modularity.ExecutionContainer code can be deployed at a device. This should also enable to remotely install control apps which have access to the control API of the device.

Rationale

Many different control schemes are currently investigated in the Microgrid context. It is hard to standardize each of these schemes. A flexible device platform can overcome this issue and enables each operator to deploy the control apps they need.

Owner

Owner contact

Complexity XL




Page 272 (335)


Category EPIC

ID EPIC.FINSENY.Logging Service

Name Logging Service

Goal The control center can specify logging options at remote device/systems and can query log files afterwards.

Version 1.0



Stakeholder




Relative priority

Chapter


Description Logging service is specified in detail in IEC61850 ACSI

Rationale A logging service reduces network traffic and enables later retrieval of event logs.

Owner

Owner contact

Complexity M




Page 273 (335)


Category EPIC

ID EPIC.FINSENY.Transaction Services

Name Transaction Services

Goal


Version 1.0



Stakeholder


Status NEW WP3 requirement


Relative priority

Chapter extension of https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FINSENY.EPIC.TransactionalMechanisms

Enabler Domain Specific Enabler 'Distributed Transaction Service', enhancement of IEC61850

Description

A transaction is a logical unit of work coordinating distributed data and process (service) handling. Transactions usually start with a begin operation and finishes with either the commit or the abort (rollback) operation. Between the start, the commit or abort operation, data operations and process coordination activities are executed. Classic transactions are bracketed by key control operations as Begin-Transaction, Commit-Transaction and Abort-Transaction. Each transaction must respect all the ACID properties: Atomic, Consistency, Isolation and Durability. Enhanced transaction mechanisms have to control the operations and outcome of multiple applications or services. For this they include a coordination and correlation manager. It is useful to define transaction services for short term and long term transactions.


Owner

Owner contact

Complexity L




Page 274 (335)

11.2.3 Information Layer


Category EPIC

ID EPIC.FINSENY.Conditional Control

Name Conditional Control

Goal A series of control operation have to be executed under certain conditions. A control service should be available which allows to define the conditions on atomic and task level

Version 1.0



Stakeholder




Relative priority

Chapter

Enabler Domain Specific Enabler, enhancement of IEC61850

Description



Owner

Owner contact

Complexity L




Page 275 (335)


Category EPIC

ID EPIC.FINSENY.Create control set

Name Create control set

Goal Switch from one set of setting values to another one

Version 1.0



Stakeholder




Relative priority

Chapter




Owner

Owner contact

Complexity S




Page 276 (335)


Category EPIC

ID EPIC.FINSENY.Creation of data set

Name Creation of data set

Goal Create a data set as a collection of data of several objects

Version 1.0


Source contact Jürgen Goetz

Stakeholder




Relative priority

Chapter


Description

Service that creates an ordered group of data or data attributes organized as single collection for the convenience of the client. Thus, it is avoided that each data or data attribute has to be requested in a single message, the data set values can be requested in a single message which saves bandwidth consumption.

Rationale minimizes need for data exchange --> saving bandwidth enable the aggregation of data from different devices

Owner

Owner contact

Complexity M




Page 277 (335)


Category EPIC

ID EPIC.FINSENY.Customers Profile EV

Name Customers Profile EV

Goal

The customer profile is needed to allow transparent use of charging infrastructure at (foreign) EVSE. For example, the E-Mobility provider needs to know at which (foreign) charging stations his customer is allowed to charge. This information will be stored in the customer’s profile. A high number of other parameters will be stored related the customers profiles.

Version 1.0





Status Pending



Chapter IoT


Description Customers profile data must be storage and available taking into account the legal framework of the EU countries.

Rationale To facilitate any transaction related to a customer.

Owner

Owner contact

Complexity L




Page 278 (335)


Category STORY

ID STORY.FINSENY.Storage of User profile

Name Storage of User profile

Goal User profiles must be stored in consideration of the design principles (security, data integrity ...).

Version 1.0





Status Pending



Chapter Cloud; IoT

Enabler x

Description User profile data must be stored on servers in the cloud to be able to gain access from any end points or back-end that is connected to the cloud.

Rationale The secure storage of user profiles is the base of a confidential relation to customers.

Owner TBD

Owner contact TBD

Complexity M




Page 279 (335)


Category STORY

ID STORY.FINSENY.Tariffing signals and profiles

Name Tariffing signals and profiles

Goal To provide tariff signals updated daily and to have user profiling day by day updated

Version 1.0



Stakeholder


Status Pending


Relative priority



Description Tariffing signals and user profiles need to be updated daily in order to take decisions on the scheduling of the consumption of the energy by the BEMS or the final user.

Rationale

Owner

Owner contact

Complexity S




Page 280 (335)


Category STORY

ID STORY.FINSENY.User Software Agent System

Name User Software Agent System

Goal To use Autonomous SW entity which observes and stores the final user energy buying habits? Then it acts upon request and directs its activity towards achieving best goals.

Version 1.0



Stakeholder


Status Pending


Relative priority



Description Autonomous SW entity which observes and stores the final user energy buying habits. Then it acts upon request and directs its activity towards achieving best goals.

Rationale

Owner

Owner contact

Complexity L




Page 281 (335)


Category STORY

ID STORY.FINSENY.Charging Profile

Name Charging Profile

Goal The EV-user needs the possibility to configure preferences like time, amount of charged energy and charging costs.

Version 1.0





Status Pending



Chapter IoT

Enabler

Description Each time an EV-user is charging at an EVSE, a charging profile may be helpful to pre-select charging specific settings.

Rationale A charging profile reduces the amount of time and work a user has to invest before being able to charge the EV.

Owner TBD

Owner contact TBD

Complexity M




Page 282 (335)


Category STORY

ID STORY.FINSENY.Analysis of (huge amounts of) data

Name Analysis of (huge amounts of) data

Goal The analysis of data is processed in the cloud ("Big data"). There is only a minimal calculation effort for end points like EVs or EVSE.

Version 1.0





Status Pending



Chapter Cloud; Data

Enabler x

Description

The analysis of data stored in databases can be done in the cloud. The computing capacity in the cloud is ideal for all kinds of algorithms and calculations needed for a proper data analysis. For example the analysis of energy demand and supply is a data analysis that is important to forecast energy prices.

Rationale The analysis of data stored in databases is essential for all intelligent services. Especially the behavior of the grid is hard to forecast and takes enormous efforts to be calculated approximately correct.

Owner TBD

Owner contact TBD

Complexity L




Page 283 (335)


Category STORY

ID STORY.FINSENY.Time Data Exchange

Name Time Data Exchange

Goal Exchange in short periods of time for large amounts of data collected and processed in high speed mode.

Version 1.0


Source contact Martin Wagner

Stakeholder


Status Pending


Relative priority

Chapter IoT


Description The exchange of information related to pricing, demand, available energy, etc. Must be done in real time for regional databases and many times daily with centralized systems.

Rationale Large amounts of data need to be collected and processed in high speed mode to support the decision making and manage transactions.

Owner

Owner contact

Complexity XL




Page 284 (335)


Category STORY

ID STORY.FINSENY.Distributed Data processing at local/community level

Name Distributed Data processing at local/community level

Goal A Distributed Data processing at local/community level is needed in order to assure a greater scalability of the services. More it can enable to process and provide services at local level reducing the timing to delivery

Version 1.0



Stakeholder


Status Pending


Relative priority

Chapter CLOUD

Enabler CLOUD: Edge (cloud proxy)

Description At local /community level it is necessary a distributed data processing.

Rationale

Owner

Owner contact

Complexity L




Page 285 (335)


Category STORY

ID STORY.FINSENY.Metering at EVSE

Name Metering at EVSE

Goal Metering different parameters (power, reactive power, current, temperature, voltage …) is necessary for monitoring of EVSE.

Version 1.0





Status Pending



Chapter IoT

Enabler

Description Measurement at EVSE is possible likewise smart metering. Parameters as power, reactive power, current, temperature, voltage …need to be collected for a proper monitoring of an EVSE.

Rationale Metering at EVSE may prevent the grid and the EVSE itself from further damage, if an error occurs.

Owner TBD

Owner contact TBD

Complexity S




Page 286 (335)


Category STORY

ID STORY.FINSENY.Metering at grid nodes and transfer of data to back-end

Name Metering at grid nodes and transfer of data to back-end

Goal Provide available grid load information for management purposes. EVSE (or E-mobility providers) need to have the required intelligence to act according to the received data.

Version 1.0





Status Pending



Chapter Data; IoT

Enabler x

Description

Dynamic grid load information ("Forecast of grid loads") need to be distributed automatically (push) or made available (pull) to charge station providers. In order to facilitate charge station technologies to work with different grid operators, the respective exchange protocols and data formats should be universal.

Rationale

Certain intelligent devices in the smart grid depend on dynamic grid load information. It is essential that this information is available in real time. A push and pull service enables smart devices to react on energy price or grid load changes instantly. This may prevent a blackout or save EV-users money because of intelligent charging possibilities.

Owner TBD

Owner contact TBD

Complexity L




Page 287 (335)


Category STORY

ID STORY.FINSENY.Set Configuration

Name Set Configuration

Goal Set configuration parameter in field device

Version 1.0



Stakeholder




Relative priority

Chapter


Description A service for setting data for configuration purpose.

Rationale required for configuration of devices

Owner

Owner contact

Complexity M




Page 288 (335)


Category STORY

ID STORY.FINSENY.internal Communication Services

Name internal Communication Services

Goal Information transport between sub-devices inside a device

Version 1.0



Stakeholder




Relative priority

Chapter IoT, I2ND

Enabler

Description Internal communication means services to exchange information between components inside or nearby to an IED (e.g. electronic components inside a substation for measurement and control).

Rationale Internal Communication services are a prerequisite for handling data for internal data exchange (monitoring and control).

Owner

Owner contact

Complexity M




Page 289 (335)


Category EPIC

ID EPIC.FINSENY.Operate

Name Operate

Goal Operate (or cancel) control value also at a specific point in time (time activated operate)

Version 1.0



Stakeholder




Relative priority

Chapter




Owner

Owner contact

Complexity M




Page 290 (335)


Category STORY

ID STORY.FINSENY.Publish / Subscribe for data set

Name Publish / Subscribe for data set

Goal Publish / Subscribe for data set

Version 1.0



Stakeholder




Relative priority

Chapter


Description This is a collection of data for the publish / subscribe service.

Rationale

Owner

Owner contact

Complexity M




Page 291 (335)


Category STORY

ID STORY.FINSENY.Real time data exchange between Gateway-Server and Servers- Cloud Data center

Name Real time data exchange between Gateway-Server and Servers- Cloud Data center

Goal In order to provide information to final user in near real time, we need a real time data exchange among the devices in the system.

Version 1.0



Stakeholder


Status Pending


Relative priority

Chapter IoT

Enabler IoT Communication, IoT Gateway device management, IoT Gateway Data Handling

Description It is strongly necessary to have a real time data exchange between Gateway-Server and Servers- Cloud Data center

Rationale

Owner

Owner contact

Complexity L




Page 292 (335)


Category FEATURE

ID FEATURE.FINSENY.Request / Response for data set

Name Request / Response for data set

Goal Request/Response for data set

Version 1.0



Stakeholder




Relative priority

Chapter


Description This is a collection of data for the request / response service.

Rationale

Owner

Owner contact

Complexity M




Page 293 (335)


Category STORY

ID STORY.FINSENY.Scheduled actions

Name Scheduled actions

Goal

Scheduled actions are to be used to transmit automatically a pre-defined set of data to and/or from the power site (e.g. power inverter) without sending messages for ordering that data in before. Such data could be regular status information, metering data, meteorological data, etc. If the transmission time is not deterministic a time-stamp should be part of the transmission.

Version 1.0


Source contact Dieter Eckardt

Stakeholder


Status Pending


Relative priority

Chapter IoT

Enabler

Description

Features: Interoperability on standardized South-bound IT I/Fs as IEC61850, IEC60870 used for control and measurement purposes of SG-devices, DER, DG, Storage and SGEC devices. Interoperability of the IT-System on North-bound IT I/Fs. (Wrt processes, applications and databases in the sense of CIM/IEC61968, GID/IEC61970, GIS and Interactions) founded on available standards and extensions. Please note: The relevant IT-Systems to control the above mentioned devices may be hosted by Aggregators, VPPs and the DSO. Contained functions are: Time-stamped messages, Auto-cyclic messages, setting-up mechanism, and de-install mechanism. Expected issues: Bandwidth reservation Information model interoperability

Rationale Automated and synchronized background processes are serving for optimized communication loads which are necessary to successfully operate a smart grid.

Owner

Owner contact

Complexity M

Creation Date



Page 294 (335)


Category EPIC

ID EPIC.FINSENY.Create control set

Name Create control set

Goal Switch from one set of setting values to another one

Version 1.0



Stakeholder




Relative priority

Chapter




Owner

Owner contact

Complexity S




Page 295 (335)


Category EPIC

ID EPIC.FINSENY.Conditional Control

Name Conditional Control

Goal A series of control operation have to be executed under certain conditions. A control service should be available which allows to define the conditions on atomic and task level

Version 1.0



Stakeholder




Relative priority

Chapter

Enabler Domain Specific Enabler, enhancement of IEC61850

Description



Owner

Owner contact

Complexity L




Page 296 (335)


Category EPIC

ID EPIC.FINSENY.Control Capability

Name Control Capability

Goal For control functionalities of the Microgrid Control Centre guaranteed performance: deterministic processing time including real-time processing is required

Version 1.0



Stakeholder




Relative priority

Chapter Cloud hosting

Enabler

Description


Rationale Control capability is needed for hosting of the Microgrid Control Centre in the cloud environment.

Owner

Owner contact

Complexity L




Page 297 (335)

11.2.4 Communication Layer SGAM framework Communication

Category EPIC

ID EPIC.FINSENY.Addressing (IPV6)

Name Addressing (IPV6) Goal Use IPV6 addressing for each device connected to the Power Grid.

Once it's connected it should keep the same, fix, IPV6 address.

Version 1.0


Source contact Roberto del Olmo Stakeholder

Scope Platform



Relative priority

Chapter I2ND; IoT

Enabler Domain Specific Based on IPV6

Description Almost all Internet Service Providers still offer IPV4 as standard option. ISP feel more comfortable using dynamic address assignment, as fixe assignment is more expensive and limited scalability due to its limited addressing capabilities. This is a problem for Power Grids, where it´s mandatory to know with which equipment the Control Centre is talking with. This problem will not be any more using IPV6, after auto-configuration any device would be assigned with a fixed IPv6 address belonging to the appropriate subnet, or virtual private network. One relevant point that may not be covered by IPv6 protocol as a Standard would be the limited visibility that IPs should have, for example, a customer device should always is able to reach the control centre but never another customer device. Other improvements incorporated in this protocol, as multicast or mandatory security would be also profitable for the Power Grids.

Rationale Addressability is a prerequisite for all use cases which rely on communication.

Owner

Owner contact

Complexity L




Page 298 (335)


Category STORY

ID STORY.FINSENY.Building data transmission availability

Name Building data transmission availability

Goal

The users get detailed information of the consumption in their homes, and also get information from the utilities on the tariffs. The user can monitor home overall consumption and the BMS will be able to reduce the energy consumption at user premises.

Version 1.0



Stakeholder


Status Pending


Relative priority

Chapter not applicable as this is a hardware/infrastructure/connectivity requirement

Enabler not applicable as this is a hardware/infrastructure/connectivity requirement

Description The BEMS installed at the user premises will have to transmit data over the Internet. Always on connectivity and ADSL speeds are required and on the provider side (Marketplace) Data Mining will thus apply.

Rationale

Owner

Owner contact

Complexity M




Page 299 (335)


Category EPIC

ID EPIC.FINSENY.MultiVPN

Name MultiVPN Goal Monitoring, metering and control devices, communicating all with the

Control Centre, are the essential tasks required to manage a power grid. The signals they send are managed by different sub-systems within the control centres. Internet may provide a virtual private network for each of the subsystems, each one, with its own criteria for safety and quality of service.

Version 1.0


Source contact Roberto del Olmo

Stakeholder

Scope Platform

Status Domain Specific MoSCoW priority COULD

Relative priority

Chapter I2ND; IoT

Enabler Domain Specific Enabler Based on MPLS Protocol Description This requirement describes how Internet Service Providers could supply

different private networks "Power Grid" dedicated, over the same physical connection. The three essentials would be: one for remote control tasks, another for monitoring, and the third for billing metering. Each one would have its own security and QoS Requirement. For example, Remote Control and Monitoring will require low latency; meanwhile the billing meters could transit as best effort data. Although, these tasks can be solved nowadays with proprietary added routers at the terminal points or directly at the application layer. Future Internet could provide directly these value added services, even more, Virtual Private Networks could bring new paid services to final customers, for example, remote home automation, bank connections, etc. Expected issues: NAT, Firewall configuration

Rationale Owner

Owner contact

Complexity L




Page 300 (335)


Category STORY

ID STORY.FINSENY.Select before operate

Name Select before operate

Goal Select a control point before sending an operate command. This locks the control point and control sequences can be realized.

Version 1.0



Stakeholder




Relative priority

Chapter




Owner

Owner contact

Complexity M




Page 301 (335)


Category STORY

ID STORY.FINSENY.Service discovery mechanism to set appropriate CoS for communication

Name Service discovery mechanism to set appropriate CoS for communication

Goal A service discovery mechanism needs to be specified and implemented in order to set the communication network CoS according to the SG-devices´ communication requirements.

Version 1.0


Source contact Timo Kyntäjä

Stakeholder


Status Pending


Relative priority

Chapter IoT


Description The service discovery mechanism is required for every service provisioning and usage.

Rationale To provide access to the grid services, there has to be available a system enabling the services discovery mechanism that automatically searches a target application environment for services.

Owner

Owner contact

Complexity L

Creation Date



Page 302 (335)


Category EPIC

ID EPIC.FINSENY.Indirect connectivity

Name Indirect connectivity

Goal Entities that do not have a native network interface should have a network presence

Version 2.0



Stakeholder


Status Pending


Relative priority

Chapter IoT

Enabler

Description Connectivity mediated by sensors and actuators is set up to extend the network beyond natively networked devices, providing a network identity and connectivity to all kinds of physical entities in the building domain

Rationale

Owner

Owner contact

Complexity

Creation Date

Last modified


Page 303 (335)


Category EPIC

ID EPIC.FINSENY.Network Cell synchronization

Name Network Cell synchronization

Goal A synchronization protocol is needed to synchronize different networks in terms of frequency, phase and voltage

Version 1.0


Source contact Didier Boeda and Lionel Besson

Stakeholder




Relative priority

Chapter

Enabler

Description


Rationale

This synchronization is needed for the Black Start of the Microgrid at two steps:- At the beginning of the BS process, when the different MG islands synchronize together- At the end of the BS process, when reconnecting the MG to the overlay grid

Owner

Owner contact

Complexity XL




Page 304 (335)

11.2.5 Component Layer


Category FEATURE

ID FEATURE.FINSENY.Auto-configuration

Name Auto-configuration

Goal

When new devices (e.g. DER, Network Smart Devices) or sub-systems (e.g. Home/Building Energy Management Systems) are installed in or at the edge of a Smart Grid (e.g. a Microgrid) they automatically configure themselves (also frequently denoted as Plug & Play). This theme consists of different requirements w.r.t. addressing, device description, discovery, registration and lock-up as well as secure and trusted access.

Version 2.0



Stakeholder


Status Under Evaluation by FI-WARE


Relative priority

Chapter IoT

Enabler

Description

For details see EPIC.FINSENY.Autoconfiguration.Addressing, EPIC.FINSENY.Autoconfiguration.DeviceDescription, EPIC.FINSENY.Autoconfiguration.RegistrationAndLookUp, EPIC.FINSENY.Autoconfiguration.RegistrationAndLookUp

Rationale Plug & Play concepts are needed to reduce the complexity during device configuration.

Owner

Owner contact

Complexity XL




Page 305 (335)


Category FEATURE

ID FEATURE.FINSENY.Remote Initialization

Name Remote Initialization

Goal Provide the possibility to initialize a newly installed smart grid device (e.g. smart meter) remotely.

Version 1.0



Stakeholder


Status Pending



Chapter I2ND

Enabler

Description

When new smart grid devices are installed, it is usable not only configuring some parameters remotely, but also to choose the actual functionality flexibly depending on the actual place and environment where the device is used (e.g. smart meter).

Rationale Decreases costs of maintaining functionality over time

Owner TBD

Owner contact TBD

Complexity L




Page 306 (335)

12. Annex II – Detailed Security ICT Requirements

ID FINSENY.Theme.AuthenticationAndAuthorization Name Authentication and authorization Goal Ensure secure communications and access control

Architecture Component

Versi on 1.0 Source FINSENY WP1 Source contact Lionel Besson Stakeholder Scope Platform Status MoSCoW priority MUST Relative priority Chapter Security Enabler Category Theme Description System components shall uniquely authenticate users and specific

components before establishing a connection. The components shall enforce separation of duties through assigned access authorization. The user privileges should be restricted to only those that are required for each person’s role, taking into account emergency cases. This reflects least privileged application. Specifically to consider is handling in emergency situations, where a user rights override option should be always implemented. This requires appropriate considerations in the general account policy definition as well as consideration of the specific situation (e.g., by using the situational information (emergency) as additional parameter for access control). Features: - Mechanisms and Protocols supporting Key generation / Key Management - Encryption mechanisms - Access rights to the data - Secure key storage - Processes supporting Key Management - Meta data of the data (data specific protection needs) - Handling of failures

Rationale Peer authentication is the first step towards a secure session establishment and thus builds the base for secured communication. Moreover, authentication and role association are the basis to ensure, that only authorized personnel is able to perform certain actions requiring a dedicated role level.

Owner Owner contact Complexity Creation Date 10/08/2011 Last modified 21/12/2011


Page 307 (335)

ID FINSENY.Theme.DataIntegrity

Name Data Integrity Goal Ensure that data hasn't been modified


Version 1.0 Source FINSENY WP1 Source contact Lionel Besson Stakeholder Scope Platform Status MoSCoW priority MUST Relative priority Chapter Security Enabler Category Theme Description It shall be possible to ensure the integrity of data and to verify whether

the data hasn’t been tampered with. The latency introduced from the protection mechanism shall not degrade the functionality of the system. Data integrity relates to data in transit and also locally stored data needs to be secured appropriately. Features: - Creating and checking cryptographic checksums (selection of integrity mechanisms) - Mechanisms and Protocols supporting Key generation / Key Management - Secure key storage - Processes and policies supporting Key generation / Key Management - Meta data of the data (data specific protection needs) - Handling of failures

Rationale Integrity protection when information is being transmitted from one entity or a group of entities to another entity or a group of entities is necessary in order to assure that the data hasn’t been altered during transmission. Integrity is needed for the communication of information among SCADA system-RTU-Power equipment, Counter-Measures Hub, or actors like Markets and DSO. Moreover, local configuration data like access rights or license information needs to be protected too. Firmware updates are another example for protecting data independent of the transport.



Page 308 (335)

ID FINSENY.Theme.DataConfidentiality

Name Data Confidentiality Goal Prevent the disclosure of information to unauthorized parties


Version 1.0 Source FINSENY WP1 Source contact Lionel Besson Stakeholder Scope Platform Status MoSCoW priority MUST Relative priority Chapter Security Enabler Category Theme Description It shall be possible to ensure the confidentiality of data by cryptographic

mechanisms, unless otherwise protected by alternative physical measures. The latency introduced from the cryptographic mechanism shall not degrade the functionality of the system. Data confidentiality relates to data in transit but locally stored data needs to be secured appropriately as well. Features: - Mechanisms and Protocols supporting Key generation / Key Management - Encryption mechanisms - Access rights to the data - Secure key storage - Processes supporting Key Management - Meta data of the data (data specific protection needs) - Handling of failures

Rationale This requirement relates to the need for confidentiality when information is being transmitted from one entity or a group of entities to another entity or a group of entities as well as locally stored data. The data should be accessible only to authorized users as it is sensitive from a privacy (e.g. user behavior pattern), safety, or economical point of view.



Page 309 (335)

ID FINSENY.Theme.NonRepudiation

Name Non-repudiation Goal It shall be possible to prevent the sender of information from denying

sending it. Architecture Component

Version 1.0 Source FINSENY WP1 Source contact Lionel Besson Stakeholder Scope Platform Status MoSCoW priority MUST Relative priority Chapter Security Enabler Category Theme Description It shall be possible to prevent the sender of information from denying

sending it. Features: - Digital certificates and signature algorithms (e.g., RSA, ECC based solutions) - Hash algorithms (e.g., SHA-1, SHA-256, …) - Secure private key storage - Processes supporting Key generation / Key Management - Certificate revocation - Public Key Infrastructure - Logging (audit), especially for session based approaches

Rationale Authorization validation for audits for dedicated commands Owner Owner contact Complexity Creation Date 10/08/2011 Last modified 21/12/2011


Page 310 (335)

ID FINSENY.Theme.DataBackupAndRecovery

Name Data backup and Recovery Goal Ensure recovery or continuation of service after a natural a human-

induced disaster


Version 1.0 Source FINSENY WP1 Source contact Lionel Besson Stakeholder Scope Platform Status MoSCoW priority MUST Relative priority Chapter Security Enabler Category Theme Description Backups of critical software, applications, and data for all components of

the SCADA system should be assured. Backup should be applied to all data and applications needed to replace failed components within a reasonable period of time as required to satisfy regulatory requirements and to restore the system to normal operation. Backups shall be physically separated from the operational components. Synchronization of the backup and operating data must be assured while the securely stored backup should be appropriately accessible for restoration.

Rationale Backup and (Plug & Play) recovery is crucial to ensure system availability. This is especially necessary in case of system restarts or replacement of dedicated system parts.



Page 311 (335)

ID FINSENY.Theme.SystemProtectionComponents

Name System Protection Components Goal Protection of system components


Version 1.0 Source FINSENY WP1 Source contact Lionel Besson Stakeholder Scope Platform Status MoSCoW priority MUST Relative priority Chapter Security Enabler Category Theme Description The devices deployed in the network shall employ system protection

mechanisms. The up to date protection mechanisms shall be deployed in such a manner as to limit the impact of the attack to a small geographical area prior to detection and eradication. Features: - Firewalls (network and application layer) - Antiviral software - Intrusion Detection Systems / Intrusion Prevention Systems (host and network based, the latter could be distributed) - Alarm handling

Rationale One challenge is that the field deployed devices are typically not suitable for traditional third party malicious code protection mechanisms. This combined with very little or no physical security means that emphasis should be placed on the risk associated with these widely dispersed assets. Therefore it should be ensured that no malicious code can pass some security zones (e.g. from the utility’s NAN to HAN). Field tools represent potentially high risk also because they may be connected to numerous networks.



Page 312 (335)

ID FINSENY.Theme.SecureSoftwareFirmwareUpdates

Name Secure Software/Firmware updates Goal Securely update software and firmware


Version 1.0 Source FINSENY WP1 Source contact Lionel Besson Stakeholder Scope Platform Status MoSCoW priority MUST Relative priority Chapter Security Enable r Category Theme Description The system shall ensure software/firmware updates only with integrity

protected packages from an authorized source. Features: - Definition of integrity protection and authentication mechanisms, e.g., digital signatures - Central generation of integrity check values and authentication values for software/firmware updates - Device local verification of integrity and authentication values, e.g., digital signature verification - Secure storage of certificates on end devices and secure storage of keys on central components generating integrity values - Secure handling of root certificates on involved systems - Processes supporting Key generation / Key Management - Alarm handling in case of authentication or integrity failures

Rationale Malicious software/firmware updates may compromise the whole system.



Page 313 (335)

ID FINSENY.Theme.SecureSystemDesign

Name Secure System Design Goal The system design should obey security design guidelines


Version 1.0 Source FINSENY WP1 Source contact Lionel Besson Stakeholder Scope Platform Status MoSCoW priority MUST Relative priority Chapter Security Enabler Categor y Theme Description The system design should obey security design guidelines, for instance

to restrict the ability of internal or external users to launch denial-of-service attacks against network components. Here, components from the security requirement system protection components shall be applied.

Rationale As single security product or technology cannot protect the IT security of an energy network control system sufficiently. Hence, a multiple layer strategy involving two or more different overlapping security mechanisms (defense-in-depth) is advised so that the impact of a failure in any one mechanism is minimized. Additionally to component based authentication and authorization other access protection means should be used to monitor potential attacks.



Page 314 (335)

ID FINSENY.Theme.SecurityManagement Name Security Management Goal Ensure the global security of the systems through technical and

organizational means

Arc hitecture Component

Version 1.0 Source FINSENY WP1 Source contact Lionel Besson Stakeholder Scope Platform Status MoSCoW priority MUST Relative priority Chapter Security Enabler Category Theme Description Security management has to consider all involved cryptographic

protection means, including key management infrastructure, certificate management, security policies, addressing both, technical and organizational means. The selection should match the protection needs of the information being protected and the protected system operating constraints. Features: - Key generation process - Key generation algorithms - Certificate and CRL generation - Certificate revocation- Patch Management - System hardening according to security measurement plans - Practices and procedures relating to cryptographic key establishment and management (incl. key distribution, periodic key changes, revocation, …) - Security policy definition (including allowed cipher suites) - Account management (including role and associated rights management) - Personnel risk assessment, e.g., security clearance of technical personnel - Separation of duty for control, operation, safety, and security - Security training of personnel (incident handling, security process handling, etc.) - Security documentation (for processes and systems) - Incident response (events and alarming)- Backup and recovery of business and operation relevant information - Establishment of a security organization with defined responsibilities and responsible persons (e.g., for incident handling) - Definition of identification and authentication procedures

Rationale Owner Owner contact Complexity Creation Date 10/08/2011 Last modified 21/12/2011


Page 315 (335)

ID FINSENY.Theme.LoggingAndAudit Name Logging and Audit Goal Understanding and traceability of events


Version 1.0 Source FINSENY WP1 Source contact Lionel Besson Stakeholder Scope Platform Status MoSCoW priority MUST Relative priority Chapter Security Enabler Category Theme Description Logging processes shall be established on devices having appropriate

resources to support monitoring, traceability, and auditing functionality. Logging itself also requires to be protected. Depending of the component providing the logging information this protection may vary from source authentication, integrity protection up to confidentiality, e.g., for privacy related data. Features: - Generation and storage of log files (including timestamps, if possible) - Examination of log files - Protection of log files - Logging and audit policy - Access right to logging information - Alarm handling

Rationale Logging and audit throughout the whole infrastructure is one main factor for detailed understanding and traceability of unexpected and possibly harmful events. Monitoring, control and non-repudiation are supported by fulfilling this requirement.



Page 316 (335)

ID FINSENY.Theme.TimeSynchronization

Name Time Synchronization Goal Time synchronization keeps timer elements on different components

synchronized.


Version 1.0 Source FINSENY WP1 Source contact Lionel Besson Stakeholder Scope Platform Status MoSCoW priority MUST Relative priority Chapter Security Enabler Category Theme Description Time synchronization keeps timer elements on different components

synchronized.

Rationale Inconsistent timestamps within the overall system restrict monitoring abilities or may even lead to grid problems, if correct timing information is needed e.g. for DSM. Another example stems from synchrophasor in the transport network.



Page 317 (335)

ID FINSENY.Theme.ObservationOfPoliciesAndLaws

Name Observation of Policies & Laws Goal Observation of Policies & Laws Architecture Component

Version 1.0 Source FINSENY WP1 Source contact Lionel Besson Stakeholder Scope Platform Status MoSCoW priority MUST Relative priority Chapter Security Enabler Category Theme Description All applicable policies of the utility and its major business partners must

be observed, as well as the relevant legislation and regulation. Non-Compliance may result in banning of the system, which would result in business loss.

Rationale Adherence to policies, laws and regulations is a self-evident requirement. It holds especially when new processes are introduced. Awareness concerning this requirement is always needed.



Page 318 (335)

ID FINSENY.Theme.TransactionSecurity Name Transaction Security Goal Transactions can be securely validated Architecture Component

Vers ion 1.0 Source FINSENY WP1 Source contact Lionel Besson Stakeholder Scope Platform Status MoSCoW priority MUST Relative priority Chapter Security Enabler Category Theme Description It has to be guaranteed that whole transactions can be securely

validated, i.e. that request and response message chains are acknowledged and securely bound together on application layer.

Rationale This requirement concerns negotiations and settlement of contracts, where it is necessary that whole transactions are valid. It helps e.g. in cases of refusal of payment or action (e.g. for Demand Side Management). Requests like offers have to be bound to contract terms that have been agreed upon beforehand and to resulting accept or reject responses, e.g. in a given time frame. If such binding and acknowledgement is not enforced, it may be impossible to settle disputes.



Page 319 (335)

13. Annex III - Summary of Specific ICT Requirements to WP8 The following table reports the original version of the ICT requirements identified as specific. The requirements were reported initially in I/O 8.1 First specific ICT Requirements from WP7 and only were included as annex in this deliverable for compare proposes: All specific ICT requirements were reviewed and updated for the final version by the UC WPs. The final specific ICT Requirements will be described and detailed in the internal report I/O 8.2 - Final specific ICT Requirements from WP7.

Name Category WP UC # Short Description

Prio

.

Features

Dedicated or Shared

Transport Infrastructure

Component WP2 SGEC DCAC MVDAC FLIR

Control from an Aggregator, VPP or DSO needs appropriate transport network capacity, which may be supplied by a dedicated operator on an exclusive or shared basis

MU

ST

South-bound IT (Server) I/Fs need to connect via suitable transport links towards the SG-device locations (e.g. Sub-Stations) Transport links may be realized via: - Optical Fibres, operating WDM, SDH/PDH, Ethernet/LAN, - 3GPP-defined cellular wireless (2G/GPRS 3G/UMTS 4G/LTE) - WIMAX or Microwave private radio network - Powerline based PLC/BPL (Powerline/Broadband Powerline Communication) - Commercial DSL-lines based on ADSL, VDSL or SHDSL Transport infrastructure operated privately - with a dedicated utilization (single DSO) - with shared utilization (multi-DSO/TSO)


Page 320 (335)


Prio

.

Features

Failsafe Mechanisms

Service/ Function

WP2 SGEC DCAC MVDAC FLIR

As stated in the power inverter use-case description, the inverter can have different communication partners (TSO, DSO, Aggregator, Virtual Power plant ...). However, just one communication partner (“Controller”) is allowed to control the inverter, but several communication partners could be simultaneously informed about the status of the inverter and/or additional information like metering and/or forecast data.

MU

ST

Register inverter at a central communication administration unit Automated assign of address-information for each kind of information to be distributed (commercial aspects, metering data, maintenance situation, alarms, warnings ...) Get address-information for acceptance of control data just from one source. Further Security Means Interoperability of the IT-System on North-bound IT I/F’s. (E.g. processes, applications and databases in the sense of CIM/IEC61968, GID/IEC61970, GIS and Interactions) founded on available standards and extensions. Interoperability on standardized South-bound IT I/Fs as IEC61850, IEC60870, DNP3 used for control and measurement purposes of SG-devices, DER, DG, Storage and SGEC devices. Register inverter at a central communication administration unit Automated assign of address-information for each kind of information to be distributed (commercial aspects, metering data, maintenance situation, alarms, warnings,) Get address-information for acceptance of control data just from one source. Further Security Means Interoperability of the IT-System on North-bound IT I/Fs. (E.g. processes, applications and databases in the sense of CIM/IEC61968, GID/IEC61970, GIS and Interactions) founded on available standards and extensions. Interoperability on standardized South-bound IT I/Fs as IEC61850, IEC60870, DNP3 used for control and measurement purposes of SG-devices, DER, DG, Storage and SGEC devices.


Page 321 (335)


Prio

.

Features

Dedicated or Shared

Transport Infrastructure 2

Component WP2 MWFM The Communication Technology (CT) layer requires utilization of any useful link available under disturbed operating conditions. This may be supplied by a dedicated operator on an exclusive or shared basis

CO

ULD

These communication technologies may be utilized: - LTE/4G / WiMAX - Satellite Links - Direct Ethernet to connect into substation networks - Powerline communications (PLC/BPL to Low Voltage data networks, i.e. into Smart Meter Field Area Communication networks - FAN) - Local Mesh Radio communications (ZigBee, Z-Wave, i.e. into Smart Meter Field Area Communication networks - FAN) Transport infrastructure operated privately - with a dedicated utilization (single DSO) - with shared utilization (multi-DSO/TSO)

Telco Infrastructure

Component WP2 SGEC DCAC MVDAC FLIR

Control from an Aggregator, VPP or DSO needs appropriate transport network capacity, which may be supplied by a Telco operator

CO

ULD

South-bound IT (Server) I/Fs need to connect via suitable transport links towards the SG-device locations (e.g. Sub-Stations) Transport links may be realized via: - 3GPP-defined cellular wireless (2G/GPRS 3G/UMTS 4G/LTE) - WIMAX public radio network - Public DSL-lines based on ADSL, VDSL or SHDSL

Environmental Requirements for Information

and Communication

Technology

Service/Function

WP2 SGEC DCAC MVDAC FLIR MWFM

Communication equipment for SG-field-devices / Field Mobile Devices and IT (Servers) operated reliably under different environmental conditions.

MU

ST

SG-related Communication Technology and IT equipment operated reliably in various locations like in - Offices, Data Centres, Sub-Stations (shelter/building) or rural/pole installations, field workers outdoor applications


Page 322 (335)


Prio

.

Features

Bandwidth

Service/Function

WP2 MVDAC Bandwidth requirements for MV secondary substations

CO

ULD

Three different bandwidth are considered: • Maximum bandwidth: Maximum bandwidth that could be obtained for the connection • Guaranteed bandwidth: Minimum bandwidth available for the customer • Strict priority bandwidth: Minimum bandwidth for real time traffic reserved for the customer

Bandwidth allocation

Service/Function

WP2 SGEC DCAC MVDAC FLIR

Bandwidth ~ 100 kbps CO

ULD

Not applicable


Page 323 (335)


Prio

.

Features

Self-organization, Coordination

Service/Function

WP3 CUC-4 If a system disturbance provokes a general black out such that the Microgrid (MG) was not able to separate and continue in islanding mode, and if the system is unable to restore operation in a specified time, a first step in system recovery will be a local black start. The different components of the MG have to auto-organize themselves before reconnecting to the grid. The local controllers of the MG need to dynamically coordinate each other and with the MG control centre for the recovery

MU

ST

The strategy to be followed involves the cooperation of the various system controllers both central and local, using predefined rules and exploiting autonomous agent concepts. The restoration tasks are usually carried out manually, according to predefined guidelines. They have to be completed fast in a real time basis under extreme stressed conditions. A special feature of the MG Control Centre concerns re-connection during Black Start, helping in this way the upstream DMS system that is managing the distribution network. During faults on the main grid the Microgrid may be disconnected from the main utility and will continue to operate with as much connected DG, as possible. During reconnection the issue of out-of phases reclosing needs to be carefully considered. The development of local controllers in close co-ordination with the MG Control Centre functions need to be developed and evaluated from the dynamic operation point of view through studies to be performed in the simulation platform. Advantage for power system operation in terms of reliability Assure an important advantage for power system operation in terms of reliability

Demand management

based on criticality of

loads

Information WP3 CUC-2.2.1 CUC-2.2.2

MG management and control system shall control loads and enable smart load controlling (cancellation of loads, shifting if loads etc.).

CO

ULD


Page 324 (335)


Prio

.

Features

Self-resiliency

Service/Function

WP3 CUC-1.6 The Microgrid shall be created and switched back to main grid automatically without need for operator activity. The option for operator interface to control the Microgrid shall exist. This is due to the potentially large number of Microgrids which would make the on-hands operation expensive.

CO

ULD

Physical layers

Communication

WP4 The physical layers used must allow the coexistence of several communication standards by separation in the frequency, time, coding or spatial domain according to standards

MU

ST

Energy Services and applications decoupled from

available in-home/building

communications technologies

Communication

WP4 Home #2, #3, #4, #5, #6, #7, #8, RB #1

Energy services and applications, while enabled through in home/buildings communications, must not depend on one or some specific communication technologies and remain as communication technology agnostic" as possible.

MU

ST

Remote processing and

storage

Component WP4 Optimize Energy Use

The consideration of demand-shaping measures and the implementation of peak shaving capabilities require the grid administrator to have some sort of visibility into the contracts the various loads subscribe to. This is to allow the grid administrator to use a system of compulsory or incentives-oriented measures so as to bring about the intended changes in the load curve. As such, it is necessary to maintain information about the contract model of each subscriber, the options available to that model, and the extent to which some of these options have already been used.

MU

ST

Define logical model for remote data that needs to be stored in the cloud. Allow the logical model to be extensible so as to accommodate future requirements. Main concepts to model: subscriber, contracts, incentives and counter-incentives for the implementation of peak shaving features. Moreover to correctly anticipate future needs both current, real-time, energy demands as well as historical information should be available, on which to base reliable forecasts and ensure the timely initiation of load-shifting measures. Furthermore, and subject to privacy requirements, socio-economic profiles may also need to be available for the various subscribers (even some rough categorization).


Page 325 (335)


Prio

.

Features

Remote processing of comparative

values

Component WP4 RB #2 The platform should be able to calculate average consumptions and energy related data and costs for buildings with the same profile (homes, depending on the size and use; home buildings; data centres; hotels; SMEs, etc.). Average consumptions and costs per day, week, month and year

SH

OU

LD

External Interoperability

Service/Function

WP4 Shape Demand, Shed Electric Loads, Shift Electric Loads

For the purposes of peak shaving, and demand-side management the residential building, on the one hand, and the smart grid, on the other, need to engage in a conversation that's rich in semantic content and could be very heterogeneous in the mechanics and modalities it employs. The object of this "conversation", which can be described as a "protocol" (understood here in a broad sense) is to convey pertinent information and measurements so as to both: (a) enable the grid to communicate to the building a set of rules / imperatives or incentives / counter-incentives, related to demand-side management and, on the other hand to: (b) allow the building to report information, measurements and projections to the grid. See more extended discussion in referenced document.

MU

ST

Ability of the residential building to engage in a semantically rich dialogue with the Grid / Smart Grid. Definition of a protocol, messages, etc. (technology / syntax / semantics) Need to configure protocol incrementally through long-lived data exchange

Internal Interoperability

with existing building systems

Service/Function

WP4 OB3 - Optimize Energy Use

Communication layer shall enable interoperation of building management system and other systems existing in the building: access controls, surveillance systems, fire alarm systems.

MU

ST


Page 326 (335)


Prio

.

Features

Standardization of

sensor/appliance monitoring

and/or control capabilities

Service/Function

WP4 The devices that are published so that they are available from outside the home should provide a common API (depending on the type) to publish the basic common monitoring and/or control capabilities they offer for service providers. Mechanism should also exist for extended capabilities that some devices could offer beyond these common ones.

SH

OU

LD

Standardization of

sensor/appliance eventing capabilities

Service/Function

WP4 Home #3, #6, #8, RB #4

The FI platform should provide the means for home sensors/appliances to send events (triggered by the sensor/appliance itself)

SH

OU

LD

Standardization of

sensor/appliance programming

capabilities

Service/Function

WP4 Home #4, #5, #7, #8

The devices that are published so that they are available from outside the home should provide a common API (depending on the type) to publish the programming capabilities they offer for service providers

SH

OU

LD

Standardization of

sensor/appliance publication

protocol

Service/Function

WP4 Home #2, #3, #4, #5, #6, #7, #8, RB #1

There should be provided a mechanism for publishing the sensors that can be remotely monitored in the home. This would enable the use of these sensors by other services different from home energy efficiency services that can manage the information provided in a local manner.

SH

OU

LD

Workload profiler

Security WP4 DC5 Develops and executes a series of experiments to characterize how much energy capping can be applied to the servers before the performance target is hit. If implemented, this requirement may increase the autonomy of the UPSs in case of blackouts due to fortuitous events or to physical intentional attacks.

CO

ULD

To do this requirement, the developers must to perform a series of experiments to characterize how much capping can be applied before the performance target is hit. Afterwards, during normal operations, the applications engineer sets power capping targets based on the prior measurements. The system is now said to be “optimized,” because the impact of the application of these caps is now known.


Page 327 (335)


Prio

.

Features

Direct or emergency load

control installation

Service/Function

WP4 SH8 SH10

automatic and secure pairing of control appliances module with the IS of the provider, on one hand, and with smart appliances of the home of another hand

SH

OU

LD

Display installation & configuration

Service/Function

WP4 Home #1 Home #2 Home #3

automatic and secure pairing of display with meter or meter module, on one hand, and with smart appliances of the home of another hand

MU

ST

Display installation & configuration

Service/Function

WP4 SH5 SH6 SH7

automatic and secure pairing of display with meter or meter module, on one hand, and with smart appliances of the home of another hand

MU

ST

Easy addition of new server in

the energy monitoring tools

of the datacentre.

Service/Function

WP4 DC3 DC4

It should be easy and require no complex configuration to add a new server to the Intelligent Power Node Manager SW and an Energy Management SW of the Data Centre

CO

ULD

easy addition of new wireless sensor to AC

control system, of new

component to the energy

mgmt./monitoring system

Service/Function

WP4 DC1 DC2 H3

It should be easy and require no complex configuration to add a new temperature sensor to the sensor network controlling the Air Conditioning of the Data Centre. Can be extended to other sensor types for HVAC system, other component of the energy management system

CO

ULD


Page 328 (335)


Prio

.

Features

Energy Management &

Optimization System

Installation

Service/Function

WP4 SH9 SH11 SH12

Automatic and secure pairing of control appliances module with the meter or the meter module on one hand, and with smart appliances of the home of another hand.

SH

OU

LD

Meter module installation & configuration

Service/Function

WP4 Home #1 automatic and secure pairing of meter module with meter

MU

ST

Meter module installation & configuration

Service/Function

WP4 SH5 automatic and secure pairing of meter module with meter

MU

ST

secure and easy connection of

office workers to BEMS

Service/Function

WP4 OB9 The office worker should be able to see the DR actions related to him and to its location without complex localization questions. If the worker is given the ability to derogate, this again should be left only to allowed people, based for example on their identity or location, without complex configuration but with enough security to prevent someone to "play" with these facilities.

SH

OU

LD

secure connection of

BEMS with DR Operator

Service/Function

WP4 OB8 H4 H6

The DR events or dynamic prices must be certified by the originator before being taken into account, so that faked events (or price information) may be dismissed. The verification by the BEMS should require no difficult configuration yet be secure.

MU

ST


Page 329 (335)


Prio

.

Features

Interoperability of end points for V2G and G2V

Service/Function

WP5 UC-MT-CPA

Syntactic and semantic interoperability between all end points in order to guarantee charge point interoperability

MU

ST

Interoperability of the

communication between EVs and Charging

Stations

Service/Function

WP5 UC-GO-CLM

Electric Vehicles (EVs) need to exchange data with charge stations, e.g., the current Battery State Of Charge (BSOC) and general technical details such as the maximum charging current. This requires that hardware connections are interoperable and that data exchange protocols and data formats from different EVs can be used at the same charging station.

CO

ULD

Interoperability of the

communication between EVs and Charging

Stations

Service/Function

WP5 UC-VAS-ES

Electric Vehicles (EVs) need to exchange data with charge stations, e.g., the current Battery State Of Charge (BSOC) and general technical details such as the maximum charging current. This requires that hardware connections are interoperable and that data exchange protocols and data formats from different EVs can be used at the same charging station.

CO

ULD

Interoperability of Public Charge Points with EV

(ICT and Electrical)

Service/Function

WP5 UC-ST-P The charging point supports various models of electric vehicles.

MU

ST

Interoperability of Public Charge Points with EV

(ICT and Electrical)

Service/Function

WP5 UC-LT-IRCP


MU

ST


Page 330 (335)


Prio

.

Features

Multi-Communication

Media

Service/Function

WP5 UC-ST-P For vehicles that are used in different Use Case categories, different communication media may be required (PLC, Wireless, RFID etc.)

CO

ULD

Network aggregation

nodes

Communication

WP5 UC-MT-CPA

Aggregation nodes are needed in order to use present transport protocols in an efficient way

CO

UL

D

Advanced Communication

EV User - Charge Station

via Virtualisation

Service/Function

WP5 UC-VAS-ES

The network infrastructure should feature non-blocking advanced virtualisation technologies so that many virtual electro-mobility network operators can co-exist on the same physical telecoms network and dynamically scale bandwidth and network services with respect to real-time customer requirements

SH

OU

LD

In-Car GUI Service/Function

WP5 UC-VAS-ES

electro mobility services should be interfaced from an in-car GUI

SH

OU

User Context information:

Battery Information

Information WP5 LT-P1 EV on-board battery and auxiliary information can be sent to a storage system

CO

ULD

Charge Detailed Record

Information WP5 LT-P2 The format for a Charge Detailed Record has to be defined

CO

ULD

Varying Energy suppliers at one Public Charge

Point

Service/Function

WP5 UC-ST-P Different energy suppliers use the same charging point to deliver their services.

MU

ST


Page 331 (335)


Prio

.

Features

Derivation of energy prices

Service/Function

WP5 UC-GO-CLM

Energy providers need to be able to dynamically derive energy prices for the next hours. This requires precise forecasts of the availability of energy, as well as of the expected demand. Dynamic prices are then a means to balance the energy need and to avoid potentially expensive peaks of the demand.

CO

ULD

Forecast of grid loads

Service/Function

WP5 UC-GO-CLM

In electric-vehicle scenarios, unstable electricity grid situations are more likely and they should be avoided. In order to avoid such situations, the grid operators need to be able to precisely forecast the grid load for the next ours. Charge station operators might then react to the current grid situation.

CO

ULD

Smart charging scheduling

Service/Function

WP5 UC-GO-CLM

In a smart-charging scenario, a new (near) optimal schedule needs to be calculated whenever certain parameters change.

CO

UL

D

Smart Metering

Component WP6 WP6_TS_SC5

Microgrid Operators need to have Smart Meters and means to analyse/view the corresponding data in order to be precisely aware of e-Island energy consumption/production.

MU

ST

Microgrid Management

Scalability

Service/Function

WP6 WP6_TS_SC5

The management of forecast in demand/production of e-Island has to be designed in a scalable way, as it is expected that the amount of users and thus transactions will increase.

MU

ST


Service/Function

WP6 WP6_IFUCEU_SC4

An electronic marketplace needs to be available that facilitates the management, negotiation and closing of energy contracts.

MU

ST


Page 332 (335)


Prio

.

Features

Scalability of Marketplace

services

Service/Function

WP6 WP6_IFUCEU_SC4

The Marketplace Services should be offered in a scalable way, as it is expected that the amount of users and thus transactions will increase.

SH

OU

LD

Smart Metering

Component WP6 WP6_IFUCEU_SC4

All consumers need to have Smart Meters and means to analyse/view the corresponding data in order to be precisely aware of their energy consumption.

MU

ST


Service/Function

WP6 WP6_TS_SC3

An electronic marketplace needs to be available that facilitates management, collection and selection of grid issues and issue solution (offers).

MU

ST


services

Service/Function

WP6 WP6_TS_SC3


SH

OU

LD

Smart Metering


All consumers need to have Smart Meters and means to analyse/view the corresponding data in order to be precisely aware of their energy consumption.

MU

ST

Electricity Network

management


Services for monitoring, supervisory control and operation of electrical networks need to be in place.

MU

ST

Standardized grid issue solution

description

Service/Function

WP6 WP6_TS_SC3

A standard for grid issue solutions and grid issue solution offerings needs to be defined in order to facilitate an automated treatment of grid issue situations and to develop tools such as Web-based electronic marketplaces.

SH

OU

LD


Page 333 (335)


Prio

.

Features

Control mechanisms for Smart Homes


Standardized mechanisms to control the energy consumption and production in Smart Homes from the outside need to be in place. This includes in particular communication interfaces and a protocol for information exchange.

MU

ST

Control mechanisms in

the Smart Home


Standardized mechanisms are needed to control of intelligent devices and electric vehicles within a Smart Home (Internet of Things). This includes all aspects: communication interfaces, network connection for all devices and control mechanisms/information exchange (e.g., balancing signals).

MU

ST


Service/Function

WP6 WP6_TS_SC4

An electronic marketplace needs to be available that facilitates the management, recommendation, negotiation and closing of energy (shifting) contracts as well as notification services and reporting.

MU

ST


services

Service/Function

WP6 WP6_TS_SC4


SH

OU

LD

Smart Metering


All consumers need to have Smart Meters and means to analyse /view the corresponding data in order to be precisely aware of their energy consumption.

MU

ST


Page 334 (335)


Prio

.

Features

Energy Monitoring


Mechanisms for delivering data related to the energy consumption and/or production within a Smart House need to be in place for planning, procuring and selling activities. Besides Smart Meters, devices need to be intelligent and to be able to communicate.

MU

ST

Forecast of grid load and energy

demand

Service/Function

WP6 WP6_TS_SC4

Reliable forecasts of grid load and energy demand are needed for planning generation and consumption.

SH

OU

LD

Energy Management

System

Service/Function

WP6 WP6_IFUCEU_SC2

A metering system installed within the final user home and it will be used to measure energy consumed and/or produced

MU

ST

Each smart meter has to be connected with a radio device (e.g. ZigBee node) in order to send the collected data in wireless mode.

User Software Agent System

Security WP6 WP6_ IFUCEU SC3

Autonomous SW entity which observes and stores the final user energy buying habits. Then it acts upon request and directs its activity towards achieving best goals.

MU

ST

The information of this activity should be available in real time also from mobile devices

Energy information

provider

Service/Function

WP6 WP6_TS_SC2

A WEB based information service dedicated to the very small energy retailers providing them the pricing Information, the present local demand and the available energy to bid. Moreover it performs forecasts for the future energy demand coming from the Facility Manager or the Final Customer.

MU

ST

Information and forecasts should be available also in mobility through devices such as smart phones, tablet etc.


Service/Function

WP6 WP6_IFUCEU_SC1

The service will hold user energy information in detail. And it has to feature the capability of personalizing the interface depending on the context and preferences of the users.

MU

ST

Users must be able to connect via any network and device to get updated information. The Interface should be adapted and services must be reconfigured/personalized by the user.


Page 335 (335)


Prio

.

Features

Processing capabilities at

the Marketplace

Service/Function

WP6 WP6_ IFUCEU _SC5

The Service at the marketplace will have to implement complex operations between the data that will be collected from the Grid users and operators

MU

ST

Processing will depend on the simulation capabilities of the service. If the latter are not offered for energy consumption, no big processing engines will be needed.

Efficient and secure service

access and provision

Component WP6 WP6_ DSM _SC1

The Ability of generating contracts on the fly over the internet will need to be reliable by employing standard protocols and interfaces from the users. Security access has to be provided also following usual

SH

OU

LD

The service will need to follow Web 2.0 guidelines and openness. Mostly Web-based interfacing technologies will be used.

Reliable and deterministic

signal commands from the Marketplace

Service/Function

WP6 WP6_ DSM _SC1

This UC will need reliable and provisioning QoS, since signalling is involved between the GRID and the user BEMS. The latter signals will have to arrive reliably in order to shape the demand curve.

MU

ST

In this service, latency, reliability and determinism is key to have a real effect on the demand curve (the user and service provider will have to trust the service quality). Latency will not be demanding (200 ms) but low latency is absolutely required. Reliability (no packet loss) is mandatory (ADSL level).

Decision Making and signalling

energy commands

Service/Function

WP6 WP6_ DSM _SC1

The service that may lie on the Grid User side or in the cloud needs to know the user contract and the installed capabilities. According to the latter processing capabilities are key to decide how to signal the shape demand commends.

MU

ST

The processing requirement in the servers can be really high since users should be able to simulate their energy consumption using advanced models that take into account the functionality of several devices.

Table 4: Specific ICT Requirements to WP8

Documents

D7.2 ICT Requirements specifications v3 - CORDIScordis.europa.eu/.../5/.../001-D72ICTRequirementsspecificationsv30.pdf · EUTC, FIR, ORANGE, GRENOBLE INP, IBE, SWP, SYNELIXIS, TID,