wp4 data acquisition, management and security

Horizon 2020 – LCE-2017 - SGS

FLEXCoop

Democratizing energy markets through the introduction of innovative

flexibility-based demand response tools and novel business and market models

for energy cooperatives

WP4 – DATA ACQUISITION, MANAGEMENT AND

SECURITY

D4.3 – FLEXCoop Common Information

Model - Preliminary Version

Due date: 31.05.2019 Delivery Date: 24.06.2019

Author(s): Andreas Muñoz (CIRCE), Jesús Torres (CIRCE), Katerina Valalaki (Hypertech), Panos

Andriopoulos (Hypertech), Germán Martínez (ETRa), Peter Hasse (Fraunhofer), Peder

Bacher (DTU), Hrvoje Keko (KONCAR), Dimitris Bikas (S5), Jordi Cipriano (CIMNE),

Eloi Gabaldon (CIMNE), Evi Rontogianni (MERIT),Christos Malavazos (GRINDROP)

Editor: Andreas Muñoz (CIRCE)

Lead Beneficiary of Deliverable: CIRCE

Contributors: CIRCE, Fraunhofer, ETRa, Hypertech, DTU, KONCAR, S5, CIMNE, MERIT,

GRINDROP

Dissemination level: Public Nature of the Deliverable: Report

Internal Reviewers: Katerina Valalaki (Hypertech), Germán Martínez (ETRA)

HORIZON 2020 –773909 - FLEXCoop D4.3 – FLEXCoop Common Information


WP4 – Data Acquisition, Management and Security FLEXCoop Consortium of 35

FLEXCOOP KEY FACTS

Topic: LCE-01-2016-2017 - Next generation innovative technologies

enabling smart grids, storage and energy system integration with

increasing share of renewables: distribution network

Type of Action: Research and Innovation Action

Project start: 01 October 2017

Duration: 36 months from 01.10.2017 to 30.09.2020 (Article 3 GA)

Project Coordinator: Fraunhofer

Consortium: 13 organizations from nine EU member states

FLEXCOOP CONSORTIUM PARTNERS

Fraunhofer Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V.

ETRa ETRA INVESTIGACION Y DESARROLLO SA

HYPERTECH HYPERTECH (CHAIPERTEK) ANONYMOS VIOMICHANIKI

DTU DANMARKS TEKNISKE UNIVERSITET

GRINDROP GRINDROP LIMITED

CIRCE FUNDACION CIRCE CENTRO DE INVESTIGACION DE RECURSOS

Y CONSUMOS ENERGETICOS

KONCAR KONCAR - INZENJERING ZA ENERGETIKUI TRANSPORT DD

S5 SUITE5 DATA INTELLIGENCE SOLUTIONS Limited

CIMNE CENTRE INTERNACIONAL DE METODES NUMERICS EN

ENGINYERIA

RESCOOP.EU RESCOOP EU ASBL

SomEnergia SOM ENERGIA SCCL

ODE ORGANISATIE VOOR HERNIEUWBARE ENERGIE DECENTRAAL

Escozon ESCOZON COOPERATIE UA - affiliated or linked to ODE

MERIT MERIT CONSULTING HOUSE SPRL

Disclaimer: FLEXCoop is a project co-funded by the European Commission under the Horizon

2020 – LCE-2017 SGS under Grant Agreement No. 773909.

The information and views set out in this publication are those of the author(s) and do not

necessarily reflect the official opinion of the European Communities. Neither the European

Union institutions and bodies nor any person acting on their behalf may be held responsible for

the use, which may be made of the information contained therein.

© Copyright in this document remains vested with the FLEXCoop Partners




EXECUTIVE SUMMARY

This deliverable provides the preliminary version of the Common Information Model (CIM) of

the FLEXCoop project.

The focus of this document is the explanation of the process followed to define a common data

model of the variables that are going to be communicated between the different subsystems.

The CIM itself is submitted along with this document.

The document contents begin with a description of the CIM, with a detailed explanation of all

the fields selected to determine each variable. Then an explanation of the methodology followed

to include the contributions of all the partners and to solve the contradictions and discussions

that emerged during the curse of the task. Next, some examples of the mapping of the data

structure in the standard protocols selected for the deployment of communications are

displayed. Finally, the conclusion of the first part of this task and the next steps to continue the

work are listed.

The CIM has been defined in an Excel file that could be shared if needed to a better evaluation.

In this deliverable has been included as an Appendix. In order to share the resulting structure,

the information has been divided by components of the architecture, presenting the inputs and

outputs of each one in a different sheet. The characteristics of the variables were agreed by all

the partners and explained in the section 2 of this document. A more general overview of the

communications between modules is included as an Appendix in this document to facilitate the

understanding of the data flow.

This deliverable will be used as a reference for the implementation of the communications in

T6.4 during the progress of the project. A new version will be produced, as planned in the time

distribution of Task 4.2, by the end of the developments, to merge the final outcomes, formats

and data exchanges, which at this point are strongly dependent on the resulting implementations

to meet the overall FLEXCoop goals. This will require common effort from all implementing

partners, according to the approach adopted so far.

In any case, the current version of this deliverable contributes to a relevant milestone, for it has

settled down a common agreement for the information interfaces within the project architecture.

This paves the way for (i) ensuring the interoperability of the FLEXCoop systems and (ii) the

final upcoming documentation of the CIM, including domain-related definitions.




Table of Contents

FLEXCOOP KEY FACTS ................................................................................................................................... 2

FLEXCOOP CONSORTIUM PARTNERS ....................................................................................................... 2

EXECUTIVE SUMMARY ................................................................................................................................... 3

LIST OF FIGURES .............................................................................................................................................. 5

LIST OF TABLES ................................................................................................................................................ 6

CODE LISTINGS ................................................................................................................................................. 6

ABBREVIATIONS ............................................................................................................................................... 7

1. INTRODUCTION ............................................................................................................................................. 8

2. DESCRIPTION OF THE COMMON INFORMATION MODEL .............................................................. 9

3. METHODOLOGY .......................................................................................................................................... 13

4. EXAMPLE OF FLEXCOOP CIM MAPPING INTO STANDARDS ........................................................ 15

5. CONCLUSIONS AND NEXT STEPS ........................................................................................................... 18

REFERENCES .................................................................................................................................................... 18

APPENDIX A: SCHEMATIC OF THE DATA EXCHANGE OF THE COMPONENTS .......................... 19

APPENDIX B: COMMON INFORMATION MODEL .................................................................................. 25




LIST OF FIGURES

Figure 1: FLEXCoop Architecture ............................................................................................. 9

Figure 2: Example of variables of the final CIM. .................................................................... 11

Figure 3: Methodology followed in T4.2 ................................................................................. 14

Figure 4: Data Exchange for Local Demand Manager ............................................................ 19

Figure 5: Data Exchange for Global Demand Manager ........................................................... 20

Figure 6: Data Exchange for DR Settlement Remuneration .................................................... 20

Figure 7: Data Exchange GDM View ...................................................................................... 20

Figure 8: Data Exchange DER Aggregator View .................................................................... 21

Figure 9: Data Exchange DER Registry .................................................................................. 21

Figure 10: Data Exchange Marketplace View ......................................................................... 22

Figure 11: Data Exchange Open Marketplace ......................................................................... 22

Figure 12: Data Exchange OSB ............................................................................................... 23

Figure 13: Data Exchange Demand Flexibility Profiling......................................................... 23

Figure 14: Data Exchange Flexibility Profiling ....................................................................... 24

Figure 15: Data Exchange Prosumer Portal ............................................................................. 24

Figure 16: Data Exchange Middleware .................................................................................... 24

Figure 17: Complete Data Model for Local Demand Manager ............................................... 25

Figure 18: Complete Data Model for Global Demand Manager. ............................................ 26

Figure 19: Complete Data Model for DR Settlement & Remuneration ................................... 27

Figure 20: Complete Data Model for GDM View ................................................................... 27

Figure 21: Complete Data Model for Prosumer Portal ............................................................ 28

Figure 22: Complete Data Model DER Aggregator View ....................................................... 29

Figure 23: Complete Data Model DER Registry ..................................................................... 29

Figure 24: Complete Data Model Marketplace View .............................................................. 30

Figure 25: Complete Data Model Open Marketplace .............................................................. 30




Figure 26: Complete Data Model for OSB .............................................................................. 31

Figure 27: Complete Data Model for Demand Flexibility Profiling ........................................ 33

Figure 28: Complete Data Model for Flexibility Forecasting .................................................. 34

Figure 29: Complete Data Model for Middleware ................................................................... 35

LIST OF TABLES

Table 1: Explanation of the CIM fields. ................................................................................... 12

CODE LISTINGS

Code Listing 1.- Example of OpenADR report. ....................................................................... 17

Code Listing 2.- JSON format for 'attribute'………………………………………………….18




ABBREVIATIONS

API APPLICATION PROGRAMMING INTERFACE

CIM Common Information Model

D Deliverable

DR Demand-Response

DoA Document of Action

EC European Commission

EMS Energy Management System

EU European Union

GDPR General Data Protection Regulation

GUI Graphical User Interface

H2020 Horizon 2020 Programme

HTTP HyperText Transfer Protocol

MoM Message Oriented Middleware

OSB Open Smart Box

PM Person Month

PU Public

R Report

REST Representational State Transfer

T Task

VEN Virtual End Node

VPP Virtual Power Plant

VTN Virtual Top Node

XML Extensible Markup Language

WP Work Package

Y1, Y2, Y3 Year 1, Year 2, Year 3




1. INTRODUCTION

Several definitions of data standardization can be found in the literature, such as “the process

by which similar data received in various formats is transformed to a common format that

enhances the comparison process” or “the critical process of bringing data into a common

format that allows for collaborative research, large-scale analytics, and sharing of

sophisticated tools and methodologies” [1]. All of them agree in the final goal of this

standardization, which is no other than enabling data exchange within a system with common

rules as a tool to reach the desired functionalities. This is especially relevant in communications

or data-based architectures, such as the ones required to manage DER scenarios in a combined

way to upper level business and technical goals from the service-provision or grid point of view.

The definition of a common data model is a challenging effort, especially at the beginning

stages of extensive, multiple-components developments, but comes with a lot of benefits. It

allows different agents to understand each other, improves the follow-up of the information

flow through the system and helps the integration of the system with third parties, or the

addition of new modules in the existent architecture.

FLEXCoop Task 4.2 will provide a Common Information Model (CIM) to ensure the

interoperable information exchange in the system and that every partner has the necessary

variables to perform their functionalities defined in the “Concept and Approach” section of the

Annex I, Part B, of the FLEXCoop Grant Agreement.

A methodology has been defined to have an ordered procedure for the definition process. This

task has been based on the study of the current standardization performed in D2.3, and the

explanation of the architecture in D2.6 to carry out the first steps. After defining a common data

structure to include the variables of the system, a recurrent process was started to periodically

produce new or updated versions of the data model.

This deliverable explains the structure according to which the data are stored and the process

that has been followed to achieve both the structure and the information items themselves.

These outcomes required a compound effort of several partners with different necessities and

concerns to be addressed.

The obtained result will be used by each partner to develop their communications mapping of

the data structure into the selected standard protocol of its corresponding links. Also, an

example of mapping for the selected protocols is shown in this deliverable.




2. DESCRIPTION OF THE COMMON INFORMATION MODEL

Based on the FLEXCoop Architecture (see also D2.6 “FLEXCoop Framework Architecture

including functional, technical and communication specifications - Preliminary Version” for

the initial version) shown in Figure 1, the communication between the different modules has to

be defined in order to ensure semantic interoperability among them and within the whole

system. To fulfil this purpose, a data model defining all the variables and the information

exchange flows, called Common Information Model (CIM), has been developed.

Figure 1: FLEXCoop Architecture

The definition of the data model was agreed in the meeting in Athens during month 13

(23/10/2018). The resultant document of the work in this task is included as an Appendix at the

end of this document. The format is an Excel file where each line represents a variable shared

in the architecture, and the different columns show the characteristics of each variable. To make

easier the reading of the document, the information has been divided in different sheets, one

per component. The column structure will be explained below.

The current structure is the result of the discussion between all involved partners, started at the

task beginning and producing the first agreed version, as an initial proposal. It has been refined

and completed over the subsequent periodical teleconferences and meetings between tasks

participants. This structure includes all the relevant characteristics that define a variable in the

standardized FLEXCoop communication interfaces, considered by the partners as key

parameters for the implementation of the FLEXCoop components. Having a common reference

model helps to reduce the problems of integration of the components in the architecture that

will be performed in the T6.4 “Integration of FLEXCoop Components, Preliminary Testing,

Parameterization and Pre-Pilot Validation”.




Besides the communications characteristics, another key feature included in the data model, as

pointed out in the description of the task, is the use of standard models of communications, as

OpenADR. As explained in chapter 3, the presented approach and the methodology of this task

makes it possible to define and set the data in a technology-independent way and later assess

and select the most suitable standards for mapping the information elements into

communication messages. The resulting model remains available to perform this process even

with new protocols, for example when designing new applications or updating the underlying

components of the current architecture.

The study of the relevant standards in this field have been included in the D2.5 “Analysis of

EU-wide Interoperability Standards and Data Models and Harmonization Requirements”

(submitted during month 12). This outcome was taken into account in the discussions about the

CIM and was decided that the standard to be used in each communication link will be included

in the final result.

Another relevant topic included in the CIM is the centralization of information. According to

the initial architecture, the Message Oriented Middleware (MoM) component was handling all

the information of the system, but after the initial discussions the responsible of the storage of

the information was not so clear. This is an important issue to consider because of the

responsibility of ensuring the security of the information according to the new EU General Data

Protection Regulation (GDPR). Therefore, a new field indicating if the data is going through

the middleware or not has been included. This will be used to code if the information is stored

in the MoM, because all the information going through this module will be stored in its

database. The result of the final revision was that all the information will be save in the MoM,

but also other modules could store their own information in their systems.

Figure 2 shows some examples of the final composition of the CIM. The cases where not all

the fields are completed belong to interfaces that are not totally defined, so their communication

requirements are not concluded. At the end of the project, when the developments of the

modules will be finished and the final version of the CIM of the project is submitted, all the

missing fields will be fulfilled.

Attribute name MeaningContainer Subsystem -

Physical element

Information

exchange

source

Information

exchange

destination

Is going

through

middleware

?

Device ID Unique identifier of the status of the device DER Registry- Middleware DER Registry DER Agr Viewyes

Status State of the device DER Registry- Middleware DER Registry DER Agr Viewyes

Availability If the DER is available or not DER Registry- Middleware DER Registry DER Agr Viewyes

Type Type of the DER device DER Registry- Middleware DER Registry DER Agr Viewyes

Location Geographical location of the DER DER Registry- Middleware DER Registry DER Agr Viewyes

OSB_ID OSB ID of the DER DER Registry- Middleware DER Registry DER Agr Viewyes

Account Account where the devices belong to DER Registry- Middleware DER Registry DER Agr Viewyes




Figure 2: Example of variables of the final CIM.

The following table contains the description of all the columns of the CIM.

COLUMN NAME COLUMN MEANING

Attribute name A representative identifier that should help to easily identify

the information modelled in the attribute.

Meaning Definition of the variable in the FLEXCoop communication

context.

Container subsystem Module from the architecture that holds the information

exchange source for this attribute. Sometimes is the same as

the information exchange source.

Information exchange source Component that sends the variable to its destination

element. In case of multicast communication, the variable

will be duplicated or replicated in the data model with the

same source.

Information exchange

destination

Component that receives the variable from the source

information exchange source.

Is going through middleware? Indicates if the data flow between source and destination is

going through the middleware, and therefore stored in its

database.

Proposed suitable standards Communications standard proposed for this specific

exchange. The options vary between OpenADR and API

REST.

Attribute nameProposed suitable standards

(if applicable)Data type Data range

Data

frequencyGranularity

Historical

periodComments

Device ID REST String 64 bit On demand N/A N/A Random number

Status REST Enum ON-off-UnknownOn change N/A N/A

Availability REST Enum YES-NO N/A N/A

Type REST Enum Light, HVAC, DHW, EV

Location REST String N/A On change 1 meter N/A TBD coordinate system

OSB_ID REST Enum 64 bit N/A N/A

Account REST Enum 64 bit N/A N/A




Data type Attribute that indicates how the variable must be interpreted

in order to extract its value. Some examples are String,

integer, float, etc.

Data range Quantitative limits for the value of the magnitude or

parameter coded by this attribute.

Data frequency The periodicity which this variable is going to be sent

Granularity This parameter shows the time distance between

measurements when an historic of data is sent. For example,

one measurement every 15 minutes.

Historical period Amount of measures of the variable that are going to be sent

each time a new communication occurs (depends on the

frequency).

Comments This field contains any additional information that must be

considered in the development phase.

Table 1: Explanation of the CIM fields.




3. METHODOLOGY

The first step of this task was the definition of a methodology for the partners to develop the

common data model in a collaborative way, in order to establish a roadmap with the appropriate

milestones. The definition of a common model of data exchange is always a challenge,

especially when the number of components of the architecture is high and there are several

partners involved.

The beginning of the task involved the study of the results of Task 2.5 in D2.6 “FLEXCoop

Framework Architecture including functional, technical and communication specifications”

(submitted during month 12) and the models delivered in WP3. The analysis of the role of the

components of the architecture was performed in parallel with the study of the data standards

coming from D2.5 “Analysis of EU-wide Interoperability Standards and Data Models and

Harmonization Requirements”.

After this preliminary study, a workshop was performed in month 13 (during a face-to-face

consortium meeting), to start an open conversation about how to structure the information of

the project. The result of this discussion was a first outline of the composition of the CIM,

meaning the characteristics that will define each variable were determined.

Using this outline, each partner defined a first version of the variables of each module, those

that they expect to provide for the system, and those that they need to perform the functionalities

stablished in D2.6. To speed up this process, each partner developing a component in the project

worked on its own and delivered their output to CIRCE.

As leader of the task, CIRCE gathered all this information and unified it in a common version.

This common version included a comparison between inputs and outputs of each module, to

identify the variables that were present in the source and the destination component, and to

check if the format of both definitions were compatible. The incompatibilities or contradictions

between modules were marked so that they could be solved in the next version.

The common version was shared with the partners, pointing out the open points to discuss to

the responsible for each one. The following steps were performed by a recurrent process showed

in Figure 3. In this phase the work focused on solving the issues by pairs of modules.

Bidirectional partner-to-partner revisions were performed, under the supervision of CIRCE and

CIMNE, as leader of task and work package respectively.

Following the advances in these individual communications, CIRCE was in charge of updating

the common version to share it with the rest of the partners. This process has been repeated in

several iterations.




While parallel conversations between each two partners was the fastest solution to focus on the

specific aspects to be discussed, for some problems the implication of all the technical partners

was mandatory. The face-to-face consortium meetings that took place during the working

period of this task (from month 10 till month 20) were used to put in common the status of the

document and to address the unsolved problems in technical sessions that allowed every partner

to contribute in the solution.

A common version was generated highlighting the main considerations to be addressed. A

technical workshop for the CIM was organized taking advantage of a consortium meeting

celebrated in Barcelona during month 17. With the help of all the partners, all corresponding

points were dealt with one by one, and most of them were clarified.

The result was a document containing all the needed modifications. Each partner looked over

its contributions and modified what was necessary. The iterative process established previously

was carried out again until the last consortium meeting in Zagreb (15/04/2019) during month

19, where the last inconsistencies of the CIM were worked out in a specific working session.

The result of the meeting was very satisfactory, having most of the data contradictions solved

and focusing on defining more specific fields of the variables, as data frequency or periodicity,

that are always more difficult to determine until the development starts.

Figure 3: Methodology followed in T4.2




4. EXAMPLE OF FLEXCOOP CIM MAPPING INTO STANDARDS

One of the main goals of defining a Common Information Model, is to be able to develop

different protocol communications in different links without losing the interoperability and data

cohesion of the system.

In the analysis performed in Task 2.5, a broad study of the most relevant interoperability

standards and data models was presented. Using this information, two standards has been

selected: OpenADR and Representational State Transfer (REST).

OpenADR is a flexible data model to facilitate common information exchange between

electricity service providers, aggregators, and end users. The concept of an open specification

is intended to allow anyone to implement the two-way signalling systems, providing the servers

that publish information to the automated clients subscribing to the information. This standard

covers the signalling data models and includes information related to specific Demand

Response (DR) electric reduction or shifting strategies, which are taken at the facility. This

standard can be leveraged to manage customer energy resources, including load, generation and

storage, via signals provided by grid and/or market operators. These resources may be identified

and managed as individual resources with specific capabilities, or as virtual resources with an

aggregated set of capabilities.

There are several services that allows the communications of different messages between the

Virtual Top Node (VTN) and the Virtual End Nodes (VENs). The OpenADR 2.0b profile

supports the following services:

- EiEvent – to notify the VENs of upcoming DR events and sending DR signals from VTN

to VEN

- EiOpt – opt-in and opt-out capability by the VEN

- EiReport – specifies the report by the VEN to the VTN; typically supports the VTN’s

prediction and monitoring capabilities

- EiRegisterParty – establishment of communication between a VEN and a VTN.

For the need of the project, not all the messages must be used. To share information of the

components, mainly the EiReport is going to be used, and the EiEvents will be used to send

information when a DR event occurs, that is not going to be very frequent. OpenADR defines

eight standard Reports to send information to the VTN, but it admits the possibility to define

new reports with other names if necessary. In case of Events there is no such possibility.

So far, the implementation of this communications is in the early process and the messages are

still not defined, but first trials have been implemented to ensure that the format messages are

correct and that every partner can read the information from it. The messages are sent in

Extensible Markup Language (XML) format. In Code Listing 1 there is an example of the

current test that are being performed.




<oadr:oadrPayload xmlns:oadr="http://openadr.org/oadr-2.0b/2012/07"

xmlns:pyld="http://docs.oasis-open.org/ns/energyinterop/201110/payloads"

xmlns:ei="http://docs.oasis-open.org/ns/energyinterop/201110"

xmlns:xcal="urn:ietf:params:xml:ns:icalendar-2.0"

xmlns:strm="urn:ietf:params:xml:ns:icalendar-2.0:stream">

<oadr:oadrSignedObject>

<oadr:oadrUpdateReport ei:schemaVersion="2.0b">

<pyld:requestID>ReportUpdateRequest_1</pyld:requestID>

<oadr:oadrReport>

<xcal:dtstart>

<xcal:date-time>2019-01-01T10:30:00Z</xcal:date-time>

</xcal:dtstart>

<xcal:duration>

<xcal:duration>PT1M</xcal:duration>

</xcal:duration>

<strm:intervals>

<ei:interval>

<xcal:dtstart>


</xcal:dtstart>

<xcal:duration>

<xcal:duration>PT15S</xcal:duration>

</xcal:duration>

<oadr:oadrReportPayload>

<ei:rID>real_power</ei:rID>

<ei:payloadFloat>

<ei:value>500.0</ei:value>

</ei:payloadFloat>

</oadr:oadrReportPayload>

</ei:interval>

<ei:interval>

<xcal:dtstart>


</xcal:dtstart>

<xcal:duration>

<xcal:duration>PT15S</xcal:duration>

</xcal:duration>

<oadr:oadrReportPayload>

<ei:rID>real_power</ei:rID>

<ei:payloadFloat>

<ei:value>500.0</ei:value>

</ei:payloadFloat>

</oadr:oadrReportPayload>

</ei:interval>

</strm:intervals>

<ei:eiReportID>RP_1202</ei:eiReportID>

<ei:reportRequestID>ReportReqID130615_192625_730</ei:reportRequestID>

<ei:reportSpecifierID>ReportSpecID120615_122512_481_2</ei:reportSpecifierID>

<ei:reportName>TELEMETRY_USAGE</ei:reportName>

<ei:createdDateTime>2019-01-01T10:30:00Z</ei:createdDateTime>

</oadr:oadrReport>

<ei:venID>VEN130615_192312_582</ei:venID>

</oadr:oadrUpdateReport>

</oadr:oadrSignedObject>

</oadr:oadrPayload>

Code Listing 1: Example of ADR report

REST communication is a software architecture for web development sustained by HTTP

standard. Basically, it establishes a set of rules that must be followed in the definition of an

Application Program Interface (API). Nowadays there is no project or application that doesn’t

use some API REST in their development.

In the Code Listing 2 it can be seen an example of the JSON message communicated from the

Local Demand Manager component to the Message Oriented Middleware by using the REST

API. This is the same format that the Global Demand Manager will get from the Message

Oriented Middleware when requesting this information by using, also, the API REST.




{

"ldemID": "LDEM001",

"flexibility": [

{

"timestamp": "2019-01-01T00:00:00Z",

"upwards": {

"value": 10.1,

"price": 3

},

"downwards": {

"value": 5.1,

"price": 1.3

}

},

{

"timestamp": "2019-01-01T00:15:00Z",

"upwards": {

"value": 12.1,

"price": 3.5

},

"downwards": {

"value": 4.5,

"price": 1

}

},

{

"timestamp": "2019-01-01T00:30:00Z",

"upwards": {

"value": 12.1,

"price": 3.6

},

"downwards": {

"value": 4.6,

"price": 1.1

}

},

...

]

}

Code Listing 2: JSON format for 'attribute'




5. CONCLUSIONS AND NEXT STEPS

The current version of the CIM is included in this document as an Appendix, along with a

schematic representation of it to help having a general overview of the system. This is the result

of the effort of all the technical partners involved in the development of the components of the

FLEXCoop architecture. This effort has been supervised by CIRCE and CIMNE, as leader of

the task and work package respectively.

The data model will be the basis for the development of communications in the corresponding

tasks of WP5 and WP6. It is important to follow the format agreed with the rest of the partners,

because otherwise incompatibility problems could arise in the future when trying to integrate

the individual developments into the general architecture. Having a common data model is also

useful for the future, in case of trying to integrate the architecture with third parties, adding new

components or updating the existing ones. Besides, in case a different protocol is going to be

used in the implementation of a new communication, with just mapping the CIM in the structure

of the protocol, the communication should work without inconsistencies.

Since the core development work of the project is still to be done, some of the information

expected in the CIM was not able to be provided at this point. It depends on the final

implementation of the system, and the functionalities that will be developed in each module.

As the work in the rest of WP advances, this missing information will be decided and included

in the CIM. Probably other variables already described will have to be modified in its

implementation.

These changes during implementation are usual in the data models, because usually the initial

idea for the communication variables will not match entirely with the capabilities of the system

to provide it. Therefore, there is a new release of the CIM scheduled by month 29 of the project,

when all the modules will be developed, and the communications are the definitive ones, which

will allow to provide and accurate result of this task.

REFERENCES

[1] Q. He, «"Three lessons of data standarization",» 2016. [Online]. Available:

https://www.linkedin.com/pulse/three-lessons-data-standardization-qi-he.




APPENDIX A: SCHEMATIC OF THE DATA EXCHANGE OF THE COMPONENTS

The architecture of FLEXCoop is quite complex, and so are the communications defined

between the different components. To help having a general view of the information exchanged,

in this Appendix a simple scheme of the data flow between components is displayed. As

explained in previous sections, all the communications goes through the middleware, so this

module is removed from the diagrams, except when it is the source or destination of the

information.

In each image, the central module is the one being focused (in grey). The modules that provide

information to the central module are in the bottom of the image (in blue), and the ones

receiving information from the central module are in the top (in orange). On the side of the

components are the variables or messages that are being exchanged in each case. The variables

that are not clear in its definition, are included in red boxes at the side of the images.

Figure 4: Data Exchange for Local Demand Manager




Figure 5: Data Exchange for Global Demand Manager

Figure 6: Data Exchange for DR Settlement Remuneration

Figure 7: Data Exchange GDM View




Figure 8: Data Exchange DER Aggregator View

Figure 9: Data Exchange DER Registry




Figure 10: Data Exchange Marketplace View

Figure 11: Data Exchange Open Marketplace




Figure 12: Data Exchange OSB

Figure 13: Data Exchange Demand Flexibility Profiling




Figure 14: Data Exchange Flexibility Profiling

Figure 15: Data Exchange Prosumer Portal

Figure 16: Data Exchange Middleware

APPENDIX B: COMMON INFORMATION MODEL

Here the complete Common Information Model is included as images of the sheets of the Excel file. Each sheet includes the information

relative to a component of the architecture.

Figure 17: Complete Data Model for Local Demand Manager


Physical element Information exchange source


destination

Is going through the

middleware?

Proposed suitable standards (if

applicable)Data type Data range

Data


Historical

periodComments

Value Amount of consumption that needs to be modified at that moment Double

LDEM id ID of the LDEM sending this message String 64 bit

Timestamp Time Date time

Device ID Device ID

Status Status

Availability Availability

Location Location

Type Type

OSB_ID OSB ID of the DER

Account Account

Contract ID Unique identifier of the contract

Contract start date Date the contract is valid from

Contract end date Date the contract is valid to

Contract accounts Accounts involved in the contract

Contract details Conditions, Pricing, Energy amount ….

Contract status active, cancelt, on hold

OSB id id of the OSB

DER id id of the DER device

DERDevice Type of DER device

Flexibility Flexibility that can be offered by each DER device. It will include flexibility profiles, DHW flexibility profiles and EV flexibility profiles

OSB id Id of the OSB

DER id Id of the DER device

Type Type of the DER device

Ramping up How long does it take to the DER to respond to DR signals

Delivery period Period when the full requested change of power is provided

Deactivation period Time taken for demand side installation to be restored

Weather Weather Weather Data info Middleware Middleware Local Demand Manager YES REST On demand



Type Type of DER device

Set point Set point of the device (dimming level for lights, temperature for HVAC)

Status State of the device

Mode Only for HVAC

Colour Only for Lights




Value Measured consumption value

Timestamp Time of measurement




Value Measured consumption value (only for roof top PVs)

Timestamp Time of measurement

DER id Id of the DER

Value Current SoC

Availability Availability of an EV to act as an ESS

Timestamp Time

OSB id ID of the OSB controlling the device which consumption is being modified String 64 bit

Device type Type of DER Enum Light, HVAC, DHW, EV

Device ID ID of the device which compsumtion is being modified String 64 bit

Value Amount of consumption to be increased or decreased Double

Timestamp When this signal has been generated Date time

LDEM id ID of the LDEM sending this message String 64 bit

Numerical code Unique numerical code for this type of message Integer

Message Human readable message explaining what has happened String

Step of time From the FlexibilityGloballyNeeded, the slot of time in where the expected consumption hasn't been provided Date time

Consumption value Amount of consumption thay can't be covered at that step of time Double

Value Amount of flexibility that can be provided at that moment Double

LDEM id ID of the LDEM providing this flexibility String 64 bit

Price The price of using that flexiblity Double

Timestamp Time Date time

Timestamp When the signal was sent to the device Date time

LDEM id ID of the LDEM that has sent this DR Event String 64 bit

OSB id ID of the OSB controlling the device which consumption is being modified String 64 bit

Device ID ID of the device which compsumtion is being modified String 64 bit

DEROperationalStatus Complex Object received as isput Complex Attribute

ACK If the asset responded as expected to the sent signal or not Boolean True, False

LDEM id ID of the LDEM aggregating the consumption of all its DERs String 64 bit



REST On change 15 minutes N/A When de LDEM receives that input, that means that the DR Campaign begins

DER Middleware DER Registry Local Demand Manager

DRSignal Middleware Global Demand Manager Local Demand Manager YES

YES REST See its details on the "DER Registry" tab On demand See its details on the "DER Registry" tab

See its details on the "Open Market Place" tab

LocalFlexibilityProfiles Middleware Demand Flexibility Profiling Local Demand Manager REST See its details on the "Demand Flexility Profiling" tabYES On demand See its details on the "Demand Flexility Profiling" tab 24h See its details on the "Demand Flexility Profiling" tab

Contract Middleware Open Market Place Local Demand Manager RESTYES See its details on the "Open Market Place" tab On demand

See its details on the "Demand Flexility Profiling" tab On demand

See its details on the "Demand Flexility Profiling" tab

See its details on the "Middleware" tab See its details on the "Middleware" tab

DEROperationalStatus Middleware OSB Local Demand Manager YES REST See its details on the "Demand Flexility Profiling" tab On demand See its details on the "Demand Flexility Profiling" tab

DRAttributes Middleware Demand Flexibility Profiling Local Demand Manager RESTYES See its details on the "Demand Flexility Profiling" tab On demand

OSB Local Demand Manager REST Its details should appear on the "Demand Flexibility Profiling" tabOn demandYES

See its details on the "Demand Flexility Profiling" tab

DERProduction Middleware OSB Local Demand Manager REST See its details on the "Demand Flexility Profiling" tabYES On demand See its details on the "Demand Flexility Profiling" tab

DERConsumption Middleware OSB Local Demand Manager RESTYES

Its details should appear on the "Demand Flexibility Profiling" tab

ControlSignal Middleware Local Demand Manager Demand Flexibility Profiling REST On demand N/AYES

YES

YES

YES

N/A

Message Middleware Local Demand Manager

DERStorage Middleware

Global Demand Manager REST On demand N/A N/A The main usage of this messages will be to communicate to the GDEM if it has been possible (or not) to apply the DR Campaign signal at each step of time

FlexibilityLocallyProvided Middleware Local Demand Manager Global Demand Manager REST 15 minutes 15 minutes N/A Amount of flexibility that this LDEM can provide for the next 24 h

The rest of its internal structure will be the same as the "DERStorage"The rest of its internal structure will be the same as the "DERStorage"

The rest of its internal structure will be the same as the "DERProduction" The rest of its internal structure will be the same as the "DERProduction"

The DEROperationalStatus is encapsulated with more information, and sent to the GDEM for tracking the current status of the DR campaign

The rest of its internal structure will be the same as the "DERConsumption" The rest of its internal structure will be the same as the "DERConsumption"

DREvent Middleware Local Demand Manager Global Demand Manager REST On demand N/A N/A

DERsAggregatedStorage Middleware Local Demand Manager Global Demand Manager YES REST 15 minutes Its internal structure will be the same as the "DERStorage"

DERsAggregatedConsumption Middleware Local Demand Manager Global Demand Manager YES REST 15 minutes Its internal structure will be the same as the "DERConsumption"

DERsAggregatedProduction Middleware Local Demand Manager Global Demand Manager YES REST 15 minutes Its internal structure will be the same as the "DERProduction"

HORIZON 2020 –773909 - FLEXCoop D4.3 – FLEXCoop Common Information Model - Preliminary Version


Figure 18: Complete Data Model for Global Demand Manager.




destination


middleware?

Proposed suitable standards (if

applicable)Data type Data range

Data


Historical

periodComments

Value Amount of flexibility that can be provided at that moment

LDEM id ID of the LDEM providing this flexibility

Price The price of using that flexiblity

Timestamp Time

DSOSignal TBD Signal coming from the DSO for triggering a DR Campaign Middleware ? Global Demand Manager ? ? ? ? ? ? ?

Timestamp When this signal has been generated


Numerical code Unique numerical code for this type of message

Message Human readable message explaining what has happened

Step of time From the FlexibilityGloballyNeeded, the slot of time in where the expected consumption hasn't been provided

Consumption value Amount of consumption thay can't be covered at that step of time

Timestamp When the signal was sent to the device


OSB id ID of the OSB controlling the device which consumption is being modified

Device ID ID of the device which compsumtion is being modified

DEROperationalStatus Complex Object received as isput

ACK If the asset responded as expected to the sent signal or not

Spanish Wholesale price market Middleware Middleware Global Demand Manager YES REST

24h predicted wholesale price market Middleware Middleware Global Demand Manager YES REST

Historical weather

"id" ,

"stationId",

"time",

"temperatureError",

"cloudCover",

"Difusse Horizontal

Irradiance",

"humidity",

"GHI",

"Clear sky DHI",

"temperature",

"dewPoint" ,

"windSpeedError",

"latitude",

"pressureError",

"windBearing" ,

"precipAccumulation",

"windBearingError",

"apparentTemperature",

"pressure",

"Clear sky BHI",

"visibility",

"Clear sky Beam Normal

Irradiance",

"Beam Horizontal

Irradiance"

"cloudCoverError" ,

"Beam Normal Irradiance"

See its details on the "Middleware" tab Middleware Middleware Global Demand Manager YES REST

Forecasted weather

Forecasted Temperature, RH,

Solar Radiation, Wind

velocity, day clearness....

See its details on the "Middleware" tab Middleware Middleware Global Demand Manager YES REST

Type Type of the DER device Double

Value Consumption value

Timestamp Time of measurement Date Time







Value Amount of consumption that needs to be modified at that moment


Timestamp Time

DRCampaignResult DREvent[] All the events that have been sent during the DR Campaign Middleware Global Demand Manager DR Settlement & Remuneration YES REST On trigger

DRCampaignResult DREvent[] All the events that have been sent during the DR Campaign Middleware Global Demand Manager GDM View YES REST On trigger

Timestamp When this signal has been generated Date time

Numerical code Unique numerical code for this type of message Integer

Message Human readable message explaining what has happened String

Step of time From the FlexibilityGloballyNeeded sent to the LDEM(s), the slot of time in where the expected consumption hasn't been provided Date time

Consumption value Amount of consumption thay can't be covered at that step of time Double

VPPConfiguration Middleware Global Demand Manager GDM View YES REST







YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

TBD TBD

DREvent Middleware Global Demand Manager GDM View REST

Global Demand Manager Middleware REST On demand N/A

See its details on the "Local Demand Manager" tabOn trigger See its details on the "Local Demand Manager" tab

N/AThe main usage of this messages will be to communicate to the DSO if it has been possible (or not) to apply the DR Campaign signal at each step of time

Output

DRSignal Middleware Global Demand Manager Local Demand Manager

On demand TBD 1 day ahead

REST See its details on the "Local Demand Manager" tabOn demand See its details on the "Local Demand Manager" tab

See the details of the DREvent on the "Local Demand Manager" tab See the details of the DREvent on the "Local Demand Manager" tab



Message Middleware

ForecastConsumption Middleware IEC 61850? DER Management System? Global Demand Manager REST

ForecastStorage Middleware IEC 61850? DER Management System? Global Demand Manager REST


ForecastProduction Middleware IEC 61850? DER Management System? Global Demand Manager REST

See its details on the "Local Demand Manager" tab

DERsAggregatedStorage? See its details on the "Local Demand Manager" tab Middleware Local Demand Manager Global Demand Manager REST See its details on the "Local Demand Manager" tab15 minutes See its details on the "Local Demand Manager" tab

DERsAggregatedProduction See its details on the "Local Demand Manager" tab Middleware Local Demand Manager Global Demand Manager REST See its details on the "Local Demand Manager" tab15 minutes

15 minutes See its details on the "Local Demand Manager" tab

See its details on the "Local Demand Manager" tabOn trigger See its details on the "Local Demand Manager" tab

DERsAggregatedConsumption See its details on the "Local Demand Manager" tab Middleware Local Demand Manager Global Demand Manager REST

DREvent Middleware Local Demand Manager Global Demand Manager REST

See its details on the "Local Demand Manager" tab15 minutes See its details on the "Local Demand Manager" tab



See its details on the "Middleware" tab

See its details on the "Middleware" tab

Input

FlexibilityLocallyProvided Middleware Local Demand Manager Global Demand Manager REST See its details on the "Local Demand Manager" tab15 minutes See its details on the "Local Demand Manager" tab

Message Middleware Local Demand Manager Global Demand Manager REST See its details on the "Local Demand Manager" tab



Figure 19: Complete Data Model for DR Settlement & Remuneration

Figure 20: Complete Data Model for GDM View

Attribute name MeaningContainer Subsystem - Physical

element Information exchange source Information exchange destination Is going though the middleware?

Proposed suitable

standards (if applicable)Data type Data range

Data


Historical

periodComments

DRCampaignResult DREvent[] All the events that have been sent during the DR Campaign Middleware Global Demand Manager DR Settlement & Remuneration YES REST On trigger

Contract ID Unique identifier of the contract

Contract start date Date the contract is valid from

Contract end date Date the contract is valid to

Contract accounts Accounts involved in the contract

Contract details Conditions, Pricing, Energy amount ….

Contract status active, cancelt, on hold

Account Account where the device involved in the DR campaign belongs to

Remuneration Economical remuneration Double N/A N/A

DREvent[] All the events that have been sent during the DR Campaign regarding this user

Remuneration Economical remuneration Double N/A N/AOn demand

See the details of the DREvent on the "Local Demand Manager" tab

See its details on the "Open Market Place" tab

ParticipationInfoSee the details of the DREvent on the "Local Demand Manager" tab

On demandSee its details on the "Open Market Place" tab

YES

YES

Ouput

Middleware DR Settlement & Remuneration Prosumer Portal REST

Remuneration[] Middleware DR Settlement & Remuneration GDM View REST

Input


Contract Open Market Place DR Settlement & RemunerationMiddleware REST See its details on the "Open Market Place" tab See its details on the "Open Market Place" tabOn triggerYES

Attribute name MeaningContainer Subsystem - Physical

element Information exchange source Information exchange destination Is going though the middleware?

Proposed suitable

standards (if applicable)Data type Data range

Data


Historical

periodComments

VPPConfiguration Middleware Global Demand Manager GDM View YES REST







DRCampaignResult DREvent[] All the events that have been sent during the DR Campaign Middleware Global Demand Manager GDM View YES REST On trigger

Account Account where the device involved in the DR campaign belongs to

Remuneration Economical remuneration Double N/A N/A

SegmentationService MiddlewareFlexibility forecasting, segmentation and

aggregation moduleGDM View YES REST On Demand

ForecastingService MiddlewareFlexibility forecasting, segmentation and

aggregation moduleAggregator UI YES REST On Demand

TrendAnalysisService MiddlewareFlexibility forecasting, segmentation and

aggregation moduleAggregator UI YES

RESTOn Demand

Remuneration[] Middleware DR Settlement & Remuneration GDM View

See its details on the "Flexibility forecasting, segmentation and aggregation" tab

Input

On demandSee its details on the "Open Market Place" tab


See its details on the "Flexibility forecasting, segmentation and aggregation" tabSee its details on the "Flexibility forecasting, segmentation and aggregation" tabSee its details on the "Flexibility forecasting, segmentation and aggregation" tab

See its details on the "Local Demand Manager" tab


TBD TBD

DREvent Middleware Global Demand Manager GDM View REST See its details on the "Local Demand Manager" tabOn trigger



YES

YES

See its details on the "Flexibility forecasting, segmentation and aggregation" tab See its details on the "Flexibility forecasting, segmentation and aggregation" tab


RESTSee its details on the "Open Market Place" tab



Figure 21: Complete Data Model for Prosumer Portal

Attribute name Meaning Container Subsystem - Physical element Information exchange source Information exchange destinationProposed suitable standards (if

applicable)Data type Data range Comments

Stat

ic

Static Config ParametersAvailable DERs and Config parameters per

OSB/Asset??OSB??/ DER Registry??? Middleware Prosumer Portal REST/ JSON TBD Static configuration parameters

Elec Consumption

Historical timeseries and (near) real time data

about total/ meter level electricity consumption -

hourly data granularity (00:00- 01:00, etc…)

OSB Middleware Prosumer Portal REST/ JSON float

The same information at

community level once commnity

has been defined

Elec Consumption ForecastingSubscription to get Day ahead (24 h) forecsting of

total elec consumption - hourly dataIEC 61850?? DER Management System? Middleware Prosumer Portal REST/ JSON float



has been defined

Demand Flexibility


about total/ meter demand flexibility - hourly data

granularity (00:00- 01:00, etc…)

Demand Flexibility Profiling Middleware Prosumer Portal REST/ JSON float



has been defined

CO2 Emissions


about total/ meter CO2 emissions -hourly data


Global Demand Manager ?? Middleware Prosumer Portal REST/ JSON float



has been defined

Elec Cost


about total/ meter electricity cost - hourly data


Global Demand Manager ?? Middleware Prosumer Portal REST/ JSON float

Elec Rewards


about total/ meter electricity rewards for DR

contracts participation - hourly data granularity

(00:00- 01:00, etc…)

DR Settlement Middleware Prosumer Portal REST/ JSON float

Local Generation


about total/ meter level generation - hourly data


IEC 61850?? Middleware Prosumer Portal REST/ JSON float



has been defined

Local Generation ForecastingSubscription to get Day ahead (24 h) forecsting of

electricity generation - hourly dataIEC 61850?? DER Management System? Middleware Prosumer Portal REST/ JSON float



has been defined

Self Consumption


about total/ meter self consumption- hourly data


Local Manager? Middleware Prosumer Portal REST/ JSON float



has been defined

Grid Import


about total/ meter grid import - hourly data


Local Manager? Middleware Prosumer Portal REST/ JSON float



has been defined

Battery Charging/Discharging


about device level electricity charging/discharging -

hourly data granularity (00:00- 01:00, etc…)

IEC 61850?? DER Management System? Middleware Prosumer Portal REST/ JSON float

EV Consumption


about device level electricity consumption - hourly

data granularity (00:00- 01:00, etc…)

OSB?? Middleware Prosumer Portal REST/ JSON float

HVAC Consumption





Lights Consumption





DHW Consumption





Plug Devices Consumption





EV Demand Flexibility


about device level demand flexibility - hourly data



HVAC Demand Flexibility





Lights Demand Flexibility





DHW Demand Flexibility





Plug Devices Demand Flexibility





Battery Status Real time device status - subscription to updates IEC 61850?? DER Management System? Middleware Prosumer Portal REST/ JSON TBD

EV Status Real time device status - subscription to updates OSB?? Middleware Prosumer Portal REST/ JSON TBD

HVAC Status Real time device status - subscription to updates OSB?? Middleware Prosumer Portal REST/ JSON TBD

Lights Status Real time device status - subscription to updates OSB?? Middleware Prosumer Portal REST/ JSON TBD

DHW Status Real time device status - subscription to updates OSB?? Middleware Prosumer Portal REST/ JSON TBD

Plug Devices Status Real time device status - subscription to updates OSB?? Middleware Prosumer Portal REST/ JSON TBD

Notifications about New Contracts Real time subscription to contract notifications Open Marketplace Middleware Prosumer Portal REST/ JSON TBD

Contractual parameters -subscriber Real time subscription to contractual parameters Open Marketplace Middleware Prosumer Portal REST/ JSON Contractual Template -TBD

Contractual parameters -publisherReal time pulbishing updates on contractual

parametersProsumer Portal Middleware Open Marketplace REST/ JSON Contractual Template -TBD Same as above (with subscriber)

Historical Contractual Parameters History of consumer/prosumer contracts DER Registry Middleware Prosumer Portal REST/ JSON Contractual Template -TBD

DER Configuration ParametersDER available to get registered in contractual

AggrementsProsumer Portal Middleware DER Registry??? /Marketplace? REST/ JSON boolean

Notifications about DR events Real time subscription to DR notifications Global Demand Manager ?? Middleware Prosumer Portal REST/ JSON TBD

DER Availability in DR campaigns DER available to get registered in DR campaigns Prosumer Portal Middleware DER Registry???/Global Demand Manager? REST/ JSON boolean

DR contractual rewardsAggregated (for a time period) information about

user performance in DR contractsDR Settlement Middleware Prosumer Portal REST/ JSON TBD

Updates on Comfort preferences User updating settings about comfort conditions Prosumer Portal Middleware Demand Flexibility Profiling REST/ JSON float

User Registration User Registration process - Oauth Prosumer Portal Middleware Middleware / Oauth Server REST/ JSON TBDUse

r Se

ttin

gsin

form

atio

n v

isu

aliz

atio

nC

on

trac

tual

Par

ame

ters

DR

eve

nts

Man

age

me

nt

Hypertech:

Historical normalised data

to be provided by the

midleware. OSB will not

store historical data



Figure 22: Complete Data Model DER Aggregator View

Figure 23: Complete Data Model DER Registry


Physical element

Information

exchange

source

Information

exchange

destination

Is going

through

middleware

?

Proposed suitable standards


Data


Historical

periodComments

Device ID Unique identifier of the status of the device DER Registry- Middleware DER Registry DER Agr Viewyes REST String 64 bit On demand N/A N/A Random number

Status State of the device DER Registry- Middleware DER Registry DER Agr Viewyes REST Enum ON-off-UnknownOn change N/A N/A

Availability If the DER is available or not DER Registry- Middleware DER Registry DER Agr Viewyes REST Enum YES-NO N/A N/A

Type Type of the DER device DER Registry- Middleware DER Registry DER Agr Viewyes REST Enum Light, HVAC, DHW, EV

Location Geographical location of the DER DER Registry- Middleware DER Registry DER Agr Viewyes REST String N/A On change 1 meter N/A TBD coordinate system

OSB_ID OSB ID of the DER DER Registry- Middleware DER Registry DER Agr Viewyes REST Enum 64 bit N/A N/A

Account Account where the devices belong to DER Registry- Middleware DER Registry DER Agr Viewyes REST Enum 64 bit N/A N/A

Input

Attribute

nameMeaning

Container Subsystem -

Physical element

Information

exchange source


destination


middleware?

Proposed suitable

standards (if

applicable)

Data type Data rangeData


Historical

periodComments

Device ID Unique identifier of the status of the device DER DER DER Registry yes OpenADR String 64 bit On demand N/A N/A Random number

Status State of the device DER DER DER Registry yes OpenADR Enum ON-off-UnknownOn change N/A N/A

Availability If the DER is available or not DER DER DER Registry yes OpenADR Enum YES-NO N/A N/A

Location Geographical location of the DER DER DER DER Registry yes OpenADR String N/A On change 1 meter N/A TBD coordinate system

Type Type of the DER device DER DER DER Registry yes OpenADR Enum Light, HVAC, DHW, EVOn change N/A N/A

OpenADR_ID OpenADR ID of the DER DER DER DER Registry yes OpenADR Enum 64 bit N/A N/A

OSB_ID OSB ID of the DER DER DER DER Registry yes OpenADR Enum 64 bit N/A N/A

Account Account where the devices belong to DER DER Open Market Place yes Open ADR Enum 64 bit N/A N/A

Device ID Unique identifier of the status of the device DER Registry- Middleware DER Registry Open Market Place yes Open ADR String 64 bit On demand N/A N/A Random number

Status State of the device DER Registry- Middleware DER Registry Open Market Place yes Open ADR Enum ON-off-UnknownOn change N/A N/A

Availability If the DER is available or not DER Registry- Middleware DER Registry Open Market Place yes Open ADR Enum YES-NO N/A N/A

Location Geographical location of the DER DER Registry- Middleware DER Registry Open Market Place yes Open ADR String N/A On change 1 meter N/A TBD coordinate system

Type Type of the DER device DER Registry- Middleware DER Registry Open Market Place yes Open ADR Enum Light, HVAC, DHW, EVOn change N/A N/A

OSB_ID OSB ID of the DER DER Registry- Middleware DER Registry Open Market Place yes OpenADR Enum 64 bit N/A N/A

Account Account where the devices belong to DER Registry- Middleware DER Registry Open Market Place yes Open ADR Enum 64 bit N/A N/A

Device ID Unique identifier of the status of the device DER Registry- Middleware DER Registry DER Agr View yes REST String 64 bit On demand N/A N/A Random number

Status State of the device DER Registry- Middleware DER Registry DER Agr View yes REST Enum ON-off-UnknownOn change N/A N/A

Availability If the DER is available or not DER Registry- Middleware DER Registry DER Agr View yes REST Enum YES-NO N/A N/A

Type Type of the DER device DER Registry- Middleware DER Registry DER Agr View yes REST Enum Light, HVAC, DHW, EV

Location Geographical location of the DER DER Registry- Middleware DER Registry DER Agr View yes REST String N/A On change 1 meter N/A TBD coordinate system

OSB_ID OSB ID of the DER DER Registry- Middleware DER Registry DER Agr View yes REST Enum 64 bit N/A N/A

Account Account where the devices belong to DER Registry- Middleware DER Registry DER Agr View yes REST Enum 64 bit N/A N/A

Device ID Unique identifier of the status of the device DER Registry- Middleware DER Registry Local Demand Manager yes REST String 64 bit On demand N/A N/A Random number

Status State of the device DER Registry- Middleware DER Registry Local Demand Manager yes REST Enum ON-off-UnknownOn change N/A N/A

Availability If the DER is available or not DER Registry- Middleware DER Registry Local Demand Manager yes REST Enum YES-NO N/A N/A

Location Geographical location of the DER DER Registry- Middleware DER Registry Local Demand Manager yes REST String N/A On change 1 meter N/A TBD coordinate system

Type Type of the DER device DER Registry- Middleware DER Registry Local Demand Manager yes REST Enum Light, HVAC, DHW, EVOn change N/A N/A

OSB_ID OSB ID of the DER DER Registry- Middleware DER Registry Local Demand Manager yes REST Enum 64 bit N/A N/A

Account Account where the devices belong to DER Registry- Middleware DER Registry Local Demand Manager yes REST Enum 64 bit N/A N/A

Input

Output



Figure 24: Complete Data Model Marketplace View

Figure 25: Complete Data Model Open Marketplace


Physical element

Information

exchange source

Information

exchange

destination

Is going

through

middleware

?

Proposed suitable standards


Data


Historical

periodComments

Contract ID Unique identifier of the contract Middleware datastore Open Market Place Marketplace View yes REST String 64bit N/A N/A Random number

Contract start date Date the contract is valid from Middleware datastore Open Market Place Marketplace View yes REST String day TBD date format

Contract end date Date the contract is valid to Middleware datastore Open Market Place Marketplace View yes REST String day 1 day N/A

Contract accounts Accounts involved in the contract Middleware datastore Open Market Place Marketplace View yes REST String N/A 2 day N/A list of Account ids

Contract details Conditions, Pricing, Energy amount …. Middleware datastore Open Market Place Marketplace View yes REST String N/A TBD format, probably xml

Contract status active, cancelt, on hold Middleware datastore Open Market Place Marketplace View yes REST ENUM in-force, not-in-force, ended

Device ID Unique identifier of the status of the device DER Registry- Middleware DER Registry Marketplace View yes REST String 64 bit On demand N/A N/A Random number

Status State of the device DER Registry- Middleware DER Registry Marketplace View yes REST Enum ON-off-Unknown On change N/A N/A

Availability If the DER is available or not DER Registry- Middleware DER Registry Marketplace View yes REST Enum YES-NO N/A N/A

Type Type of the DER device DER Registry- Middleware DER Registry Marketplace View yes REST Enum Light, HVAC, DHW, EV

Location Geographical location of the DER DER Registry- Middleware DER Registry Marketplace View yes REST String N/A On change 1 meter N/A TBD coordinate system

OSB_ID OSB ID of the DER DER Registry- Middleware DER Registry Marketplace View yes REST Enum 64 bit N/A N/A

Account Account where the devices belong to DER Registry- Middleware DER Registry Marketplace View yes REST Enum 64 bit N/A N/A

Input


Physical element

Information

exchange source


destination


middleware?

Proposed

suitable

standards

(if

applicable)

Data type Data rangeData


Historical

periodComments

Device ID Unique identifier of the status of the device DER Registry- Middleware DER Registry Open Market Place yes Open ADR String 64 bit On demand N/A N/A Random number

Status State of the device DER Registry- Middleware DER Registry Open Market Place yes Open ADR Enum ON-off-UnknownOn change N/A N/A

Availability If the DER is available or not DER Registry- Middleware DER Registry Open Market Place yes Open ADR Enum YES-NO N/A N/A

Location Geographical location of the DER DER Registry- Middleware DER Registry Open Market Place yes Open ADR String N/A On change 1 meter N/A TBD coordinate system

Type Type of the DER device DER Registry- Middleware DER Registry Open Market Place yes Open ADR Enum Light, HVAC, DHW, EVOn change N/A N/A

OSB_ID OSB ID of the DER DER Registry- Middleware DER Registry Open Market Place yes OpenADR Enum 64 bit N/A N/A

Account Account where the devices belong to DER Registry- Middleware DER Registry Open Market Place yes Open ADR Enum 64 bit N/A N/A

Contract ID Unique identifier of the contract Middleware datastore Open Market Place Marketplace View yes REST String 64bit N/A N/A Random number

Contract start date Date the contract is valid from Middleware datastore Open Market Place Marketplace View yes REST String day TBD date format

Contract end date Date the contract is valid to Middleware datastore Open Market Place Marketplace View yes REST String day 1 day N/A

Contract accounts Accounts involved in the contract Middleware datastore Open Market Place Marketplace View yes REST String N/A 2 day N/A list of Account ids

Contract details Conditions, Pricing, Energy amount …. Middleware datastore Open Market Place Marketplace View yes REST String N/A TBD format, probably xml

Contract status active, cancelt, on hold Middleware datastore Open Market Place Marketplace View yes REST ENUM in-force, not-in-force, ended

Contract ID Unique identifier of the contract Middleware datastore Open Market Place Local Demand Manager yes REST String 64bit N/A N/A Random number

Contract start date Date the contract is valid from Middleware datastore Open Market Place Local Demand Manager yes REST String day TBD date format

Contract end date Date the contract is valid to Middleware datastore Open Market Place Local Demand Manager yes REST String day 1 day N/A

Contract accounts Accounts involved in the contract Middleware datastore Open Market Place Local Demand Manager yes REST String N/A 2 day N/A list of Account ids

Contract details Conditions, Pricing, Energy amount …. Middleware datastore Open Market Place Local Demand Manager yes REST String N/A TBD format, probably xml

Contract status active, cancelt, on hold Middleware datastore Open Market Place Local Demand Manager yes REST ENUM in-force, not-in-force, ended

Contract ID Unique identifier of the contract Middleware datastore Open Market Place DR Settlement Remuneration yes REST String 64bit N/A N/A Random number

Contract start date Date the contract is valid from Middleware datastore Open Market Place DR Settlement Remuneration yes REST String day TBD date format

Contract end date Date the contract is valid to Middleware datastore Open Market Place DR Settlement Remuneration yes REST String day 1 day N/A

Contract accounts Accounts involved in the contract Middleware datastore Open Market Place DR Settlement Remuneration yes REST String N/A 2 day N/A list of Account ids

Contract details Conditions, Pricing, Energy amount …. Middleware datastore Open Market Place DR Settlement Remuneration yes REST String N/A TBD format, probably xml

Contract status active, cancelt, on hold Middleware datastore Open Market Place DR Settlement Remuneration yes REST ENUM in-force, not-in-force, ended

Input

Output



Figure 26: Complete Data Model for OSB


Physical element


source


destination

Proposed suitable

standards (if applicable)Data type Data range Data frequency Granularity

Historical

periodComments

Input ControlSignal OSB idID of the OSB controlling the device

which consumption is being

modified

String 64 bit


DER id ID of the DER device String 64 bit

DER OperationalStatusSet point and operational status of

the DERDouble

ControlSignal OSB id

ID of the OSB controlling the device

which consumption is being

modified

String 64 bit


DER id ID of the DER device String 64 bit

DER OperationalStatusSet point and operational status of

the DERDouble

Output OSB id id of the OSB OSB OSB Middleware Open ADR String On change N/A N/A

DER id id of the DER device OSB OSB Middleware Open ADR String On change N/A N/A

Type Type of DER device OSB OSB Middleware OpenADR Enum Light-HVAC On change N/A N/A

Set point

Set point of the device (dimming

level for lights, temerature for

HVAC

OSB OSB Middleware OpenADR Double On change N/A N/A

Status State of the device OSB OSB Middleware OpenADR Enum On-off On change N/A N/A

Mode Only for HVAC OSB OSB Middleware OpenADR Enum Heat-Cool-Fan-Dry On change N/A N/A

Timestamp Time when a user setting is applied OSB OSB Middleware OpenADR Date time On change N/A N/A

Colour Only for Lights OSB OSB Middleware OpenADR Colour On change N/A N/A Colour: Custom Object containing temperature, saturation or colour

OSB id id of the OSB OSB OSB Middleware Open ADR String On change N/A N/A

DER id id of the DER device OSB OSB Middleware Open ADR String On change N/A N/A

Type Type of DER device OSB OSB Middleware OpenADR Enum Light, HVAC, DHW On change N/A N/A

Set point

Set point of the device (dimming

level for lights, temperature for

HVAC)

OSB OSB Middleware OpenADR Double On change N/A N/A

Status State of the device OSB OSB Middleware OpenADR Enum On-off On change N/A N/A

Mode Only for HVAC OSB OSB Middleware OpenADR Enum Heat-Cool-Fan-Dry On change N/A N/A

Colour Only for Lights OSB OSB Middleware OpenADR Colour On change N/A N/A

OSB id id of the OSB OSB OSB Middleware Open ADR String On change N/A N/A event frequency ~sec

DER id id of the DER device OSB OSB Middleware Open ADR String On change N/A N/A event frequency ~sec

Type Type of the DER device OSB OSB Middleware OpenADR Enum Light, HVAC, DHW, EV On change N/A To be defined event frequency ~sec

Value Measured consumption value OSB OSB Middleware OpenADR Double On change To be defined To be defined event frequency ~sec

Timestamp Time of measurement OSB OSB Middleware OpenADR Date Time On change To be defined To be defined event frequency ~sec

OSB id id of the OSB OSB OSB Middleware Open ADR String On change N/A N/A event frequency ~min

Value Presensce-Absence OSB OSB Middleware OpenADR Boolean On change To be defined To be defined event frequency ~min

Timestamp Time OSB OSB Middleware OpenADR Date Time On change To be defined To be defined event frequency ~min

OSB id id of the OSB OSB OSB Middleware Open ADR String On change N/A N/A event frequency ~min

Type Type of conditions measured OSB OSB Middleware OpenADR EnumTemperature, Humidity,

Air Quality, IlluminanceOn change To be defined To be defined event frequency ~min (could be sec for e.g. illuminance)

Value Measurement OSB OSB Middleware OpenADR Double On change To be defined To be defined event frequency ~min (could be sec for e.g. illuminance)

Timestamp Time OSB OSB Middleware OpenADR Date Time On change To be defined To be defined event frequency ~min (could be sec for e.g. illuminance)

OSB id id of the OSB OSB OSB Middleware Open ADR String On change N/A N/A event frequency ~sec

DER id id of the DER device OSB OSB Middleware Open ADR String On change N/A N/A event frequency ~sec

Type Type of the DER device OSB OSB Middleware OpenADR Enum Rooftop PV On change N/A To be defined event frequency ~sec

ValueMeasured production value (only

for roof top PVs)OSB OSB Middleware OpenADR Double On change To be defined To be defined event frequency ~sec

Timestamp Time of measurement OSB OSB Middleware OpenADR Date Time On change To be defined To be defined event frequency ~sec

EnvironmentalConditions

DERProduction

N/A

UserConfigurationSettings

DEROperationalStatus

DERConsumption

OccupancySensorData

MiddlewareDemand Flexibility

ProfilingOSB OpenADR On demand N/A

Middleware N/AProsumer Portal OSB OpenADR On demand N/A






destination


middleware?

Proposed suitable

standards (if applicable)Data type Data range Data frequency Granularity

Historical

periodComments

Input OSB id id of the OSB Middleware OSB Demand Flexibility profiling YES REST String On change N/A N/A

DER id id of the DER device Middleware OSB Demand Flexibility profiling YES REST String On change N/A N/A

Type Type of DER device Middleware OSB Demand Flexibility profiling YES REST Enum Light-HVAC On change N/A N/A

Set pointSet point of the device (dimming level for lights,

temerature for HVACMiddleware OSB Demand Flexibility profiling YES REST Double On change N/A N/A

Status State of the device Middleware OSB Demand Flexibility profiling YES REST Enum On-off On change N/A N/A

Mode Only for HVAC Middleware OSB Demand Flexibility profiling YES REST Enum Heat-Cool-Fan-Dry On change N/A N/A

Timestamp Time when a user setting is applied Middleware OSB Demand Flexibility profiling YES REST Date time On change N/A N/A

Colour Only for Lights Middleware OSB Demand Flexibility profiling YES REST Colour On change N/A N/AColour: Custom Object containing

temperature, saturation or colour

Type Type of measurement Middleware Middleware Demand Flexibility profiling YES REST EnumTemperature, Solar

Radiation, Wind Speed On demand N/A N/A

Value Measured/ Acquired value Middleware Middleware Demand Flexibility profiling YES REST Double On demand N/A N/A

Timestamp Time Middleware Middleware Demand Flexibility profiling YES REST Date time On demand N/A N/A

"id" ,

"stationId",

"time",

"temperatureError",

"cloudCover",

"Difusse Horizontal Irradiance",

"humidity",

"GHI",

"Clear sky DHI",

"temperature",

"dewPoint" ,

"windSpeedError",

"latitude",

"pressureError",

"windBearing" ,


"windBearingError",


"pressure",

"Clear sky BHI",

"visibility",

"Clear sky Beam Normal Irradiance",

"Beam Horizontal Irradiance"

"cloudCoverError" ,


"longitude" ,

"Clear sky GHI",

"ozone" :,

Historical weather data coming from DarkSky, Meteo

Galicia and Coppernicus Meteo Services. For all Europe

Middleware-Short

term database Middleware

Global demand manager, Local

demand manager, Demand

Flexibiility profilling

YES REST

JSON, XML 64 bits On demand hourly Last year There are many variables available

OSB id id of the OSB Middleware OSB Demand Flexibility profiling YES REST String Once N/A N/A

DER id id of the DER device Middleware OSB Demand Flexibility profiling YES REST String Once N/A N/A

Type Type of DER device Middleware Demand Flexibility profiling YES REST EnumHVAC, Lights, DHW, PV,

EVOnce N/A N/A

Characteristic Name Type of nominal characteristic of a DER device Middleware Demand Flexibility profiling YES REST List <String> To be defined Once N/A N/A

Characteristic Value Relevant value Middleware Demand Flexibility profiling YES REST String Once N/A N/A

OSB id id of the OSB Middleware OSB Demand Flexibility profiling YES REST String Continuously N/A N/A event frequency ~sec - Raw data required

DER id id of the DER device Middleware OSB Demand Flexibility profiling YES REST String Continuously N/A N/A event frequency ~sec - Raw data required

Type Type of DER device Middleware OSB Demand Flexibility profiling YES REST Enum Light, HVAC, DHW Continuously N/A N/A event frequency ~sec - Raw data required

Set pointSet point of the device (dimming level for lights,

temperature for HVAC)Middleware OSB Demand Flexibility profiling YES REST Double Continuously N/A N/A event frequency ~sec - Raw data required

Status State of the device Middleware OSB Demand Flexibility profiling YES REST Enum On-off Continuously N/A N/A event frequency ~sec - Raw data required

Mode Only for HVAC Middleware OSB Demand Flexibility profiling YES REST Enum Heat-Cool-Fan-Dry Continuously N/A N/A event frequency ~sec - Raw data required

Colour Only for Lights Middleware OSB Demand Flexibility profiling YES REST Colour Continuously N/A N/A event frequency ~sec - Raw data required

OSB id id of the OSB Middleware OSB Demand Flexibility profiling YES REST String Continuously N/A N/A event frequency ~sec - Raw data required

DER id id of the DER device Middleware OSB Demand Flexibility profiling YES REST String Continuously N/A event frequency ~sec - Raw data required

Type Type of the DER device Middleware OSB Demand Flexibility profiling YES REST Enum Light, HVAC, DHW, EV Continuously N/A To be defined event frequency ~sec - Raw data required

Value Measured consumption value Middleware OSB Demand Flexibility profiling YES REST Double Continuously To be defined To be defined event frequency ~sec - Raw data required

Timestamp Time of measurement Middleware OSB Demand Flexibility profiling YES REST Date Time Continuously To be defined To be defined event frequency ~sec - Raw data required

OSB id id of the OSB Middleware OSB Demand Flexibility profiling YES REST String Continuously N/A N/A event frequency ~min - Raw data required

Value Presensce-Absence Middleware OSB Demand Flexibility profiling YES REST Boolean Continuously To be defined To be defined event frequency ~min - Raw data required

Timestamp Time Middleware OSB Demand Flexibility profiling YES REST Date Time Continuously To be defined To be defined event frequency ~min - Raw data required

OSB id id of the OSB Middleware OSB Demand Flexibility profiling YES REST String Continuously N/A N/A event frequency ~min - Raw data required

Type Type of conditions measured Middleware OSB Demand Flexibility profiling YES REST EnumTemperature, Humidity,

Air Quality, IlluminanceContinuously To be defined To be defined event frequency ~min - Raw data required

Value Measurement Middleware OSB Demand Flexibility profiling YES REST Double Continuously To be defined To be defined event frequency ~min - Raw data required

Timestamp Time Middleware OSB Demand Flexibility profiling YES REST Date Time Continuously To be defined To be defined event frequency ~min - Raw data required

Input ControlSignal OSB idID of the OSB controlling the device which consumption

is being modifiedYES String 64 bit

Device type Type of DER YES Enum Light, HVAC, DHW, EV

DER id ID of the DER device YES String 64 bit

ValueAmount of consumption to be increased or decreased

YES Double

OSB idID of the OSB controlling the device which consumption

is being modifiedString 64 bit

Device typeType of DER

Enum Light, HVAC, DHW, EV

DER idID of the DER device

String 64 bit N/A N/A

HorizonTime horizon that the flexibility forecast is required

Time

ISP Imbalance Settlement Period Time

N/A N/A

WeatherData

UserConfigurationSettings

OccupancySensorData

On demand

DERCharacteristics

DEROperationalStatus

DERConsumption

EnvironmentalConditions

On changeMiddleware Local Demand Manager Demand Flexibility profiling REST

FlexibilityForecastingPeriod MiddlewareLocal Demand Manager or Globa

Demand Manager ?? Demand Flexibility profiling YES REST



Figure 27: Complete Data Model for Demand Flexibility Profiling

OSB id id of the OSB Middleware Demand Flexibility profiling String On Demand N/A N/A

DER id id of the DER device Middleware Demand Flexibility profiling String On Demand N/A N/A

Type Type of the DER device Demand Flexibility profiling Enum HVAC - Light - DHW On Demand N/A N/A

Ramping up

How long does it take to the DER to respond to DR

signalsDemand Flexibility profiling

DoubleOn Demand N/A N/A

Delivery period

Period when the full requested change of power is

providedDemand Flexibility profiling

DoubleOn Demand N/A N/A

Deactivation period Time taken for demand side installation to be restored Demand Flexibility profilingDouble

On Demand N/A N/A

OSB id id of the OSB Middleware Demand Flexibility profiling

Local Demand Manager, Global

Demand Manager, Flexibility

forecasting, segmentation and

aggregation module

YES REST String On demand N/A N/A

DER id id of the DER device Middleware Demand Flexibility profiling




aggregation module

YES REST String On demand N/A

DERDevice Type of DER device Middleware Demand Flexibility profiling




aggregation module

YES REST Enum Light, HVAC, DHW, EV On Demand N/A N/A

Flexibility

Flexibility that can be offered by each DER device. It will

include flexibility profiles, DHW flexibility profiles and

EV flexibility profiles

Middleware Demand Flexibility profiling




aggregation module

YES REST Flexibility On Demand N/A N/A

Flexibility:Custom object including the

respective flexibility response depending

on der device type (baseline, upwards,

downwards flexibility)

OSB id id of the OSB Middleware Demand Flexibility profiling YES REST String On demand N/A N/A

ComfortType Visual / thermal Middleware Demand Flexibility profiling YES REST Enum Visual, Thermal On demand N/A N/A

VisualComfortProfileVisual comfort profile (illuminance vs probability of

discomfort)Middleware Demand Flexibility profiling YES REST VisualComfortProfile On demand N/A N/A Custom object

ThermalComfortProfileThermal comfort profile (temperature vs probability of

comfort and discomfort)Middleware Demand Flexibility profiling YES REST ThermalComfortProfile On demand N/A N/A Custom object

DRAttributes YES

Output

Local Demand Manager REST

Middleware

LocalFlexibilityProfiles

ComfortProfiles



Figure 28: Complete Data Model for Flexibility Forecasting


Physical element


sourceInformation exchange destination Is going through the middleware?

Proposed suitable

standards (if

applicable)

Data type Data range Data frequency GranularityHistorical

periodComments

Type Type of DER device DER Registry- Middleware DER RegistryFlexibility forecasting, segmentation

and aggregation moduleREST Enum Light, HVAC, DHW, EV On change N/A N/A

ID Identifier of the status of the device DER Registry- Middleware DER RegistryFlexibility forecasting, segmentation

and aggregation moduleREST String 64 bit On demand N/A N/A Random number

Account Account where the devices belong to DER Registry- Middleware DER RegistryFlexibility forecasting, segmentation

and aggregation moduleREST Enum 64 bit On demand N/A N/A

Location

Static geographical representation of

the different assets of the portfolio DER Registry- Middleware DER RegistryFlexibility forecasting, segmentation

and aggregation moduleREST String 64 bit On demand N/A N/A

Coordinates DER Registry- Middleware DER RegistryFlexibility forecasting, segmentation

and aggregation moduleREST String 64 bit On demand N/A N/A Who will provide such info?

Availability If the DER is available or not DER Registry- Middleware DER Registry

Global Demand Manager, Flexibility


aggregation module

REST Enum Yes - No On Demand

Contracts

Contract ID Unique identifier of the contract Middleware datastore Open Market Place

Flexibility forecasting, segmentation

and aggregation moduleYES

REST String

64bit On Demand

N/A N/A Random number

Contract start date Date the contract is valid from Middleware datastore Open Market PlaceFlexibility forecasting, segmentation

and aggregation moduleYES REST String day On Demand TBD date format

Contract end date Date the contract is valid to Middleware datastore Open Market PlaceFlexibility forecasting, segmentation

and aggregation moduleYES REST String day On Demand 1 day N/A

Contract accounts Accounts involved in the contract Middleware datastore Open Market Place



REST String N/AOn Demand

2 day N/A list of Account ids

Contract details Conditions, Pricing, Energy amount …. Middleware datastore Open Market Place



REST String N/AOn Demand

TBD format, probably xml

Contract status active, cancelt, on hold Middleware datastore Open Market Place



REST ENUM in-force, not-in-force, ended

On Demand

OSB id id of the OSB MiddlewareDemand Flexibility

profiling


and aggregation moduleYES REST String On Demand N/A N/A

DER id id of the DER device MiddlewareDemand Flexibility

profiling


and aggregation moduleYES REST String On Demand N/A N/A

DERDevice Type of DER device MiddlewareLocal Flexibility Analysis

and Forecasting Engine



aggregation module

YES REST Enum Light, HVAC, DHW, EV On Demand N/A N/A

Flexibility

Flexibility that can be offered by each

DER device. It will include flexibility

profiles, DHW flexibility profiles and

EV flexibility profiles

MiddlewareLocal Flexibility Analysis

and Forecasting Engine



aggregation module

YES REST Flexibility On Demand N/A N/A

Flexibility:Custom object

including the respective

flexibility response

depending on der device

type

Criteria Criteria

Criteria used for segmentation /

clustering, etc. e.g. location,

flexibility, contractual related crireria,

etc.

Middleware Aggregator UIFlexibility forecasting, segmentation

and aggregation moduleYES REST On Demand

SegmentationService DERCluster

Clusters of DER devices that have

common characteristics based on the

defined criteria

Middleware

Flexibility forecasting,

segmentation and

aggregation module

Aggregator UI REST TBD On Demand

ForecastingService DERClusterForecastingForecasting of the flexibility that can

be offered by a DER clusterMiddleware


segmentation and

aggregation module

Aggregator UI REST Timeseries On Demand

TrendAnalysisService DERBehaviour

Trends and patterns of a group of DER

devices based on different criteria

e.g. time vs flexibility

Middleware


segmentation and

aggregation module

Aggregator UI REST Timeseries, other? TBD On Demand

Output

LocalFlexibilityProfiles

Input

RegisteredDER YES



Figure 29: Complete Data Model for Middleware

Attribute name Meaning

Container

Subsystem -

Physical element

Information exchange source

Information

exchange

destination

Proposed

suitable

standards (if

applicable)

Data type Data range Data frequency GranularityHistorical

periodComments

Electricity market variables

All the variables

published at the e-sios

Web service of the

Spanish TSO

Middleware-Short

term database e-sios Middleware Open ADR JSON, XML

Euros, 64

bits On demand hourly Last 11 years

This

information

comes from

the Spanish

electricity

market

Historical Weather data

Historical weather data

coming from DarkSky,

Meteo Galicia and

Coppernicus Meteo

Services. For all Europe

Middleware-Short

term database Dark Sky, Coppernicus Meteo Middleware Open ADR JSON, XML 64 bits On demand hourly Last year

This

information

comes from

the Spanish

electricity

market

Forecasting weather data

Forecasting of weather

variables at different

horizon forecastings

Middleware-Short

term database Middleware Middleware Open ADR JSON, XML 64 bits On demand hourly Last year

This

information

comes from

the Spanish

electricity

market

Spanish Wholesale price

market

Historical and real time

wholsale market price

Middleware-Short


Global demand

manager Open ADR JSON, XML

Euros, 64

bits on demand hourly Last 11 years

This

information

comes from

the Spanish

electricity

market

24 h predicted Wholesale price

market

Hourly prediction of the

price for the next 24 h

Middleware-Short


Global demand

manager Open ADR JSON, XML

Euros, 64

bits Once a day hourly NO

This

information

comes from

the Spanish

electricity

market"id" ,

"stationId",

"time",

"temperatureError",

"cloudCover",

"Difusse Horizontal

Irradiance",

"humidity",

"GHI",

"Clear sky DHI",

"temperature",

"dewPoint" ,

"windSpeedError",

"latitude",

"pressureError",

"windBearing" ,


"windBearingError",


"pressure",

"Clear sky BHI",

"visibility",

"Clear sky Beam Normal

Irradiance",

"Beam Horizontal Irradiance"

"cloudCoverError" ,


"longitude" ,

Historical weather data

coming from DarkSky,

Meteo Galicia and

Coppernicus Meteo

Services. For all Europe

Middleware-Short


Global demand

manager, Local

demand

manager,

Demand

Flexibiility

profilling Open ADR JSON, XML 64 bits On demand hourly Last year

There are many

variables

available

Forecasted Temperature, RH,

Solar Radiation, Wind velocity,

day clearness....

Forecasting of weather

variables at different

horizon forecastings (0 to

48 h)

Middleware-Short


Global demand

manager, Local

demand

manager,

Demand

Flexibiility

profilling Open ADR JSON, XML 64 bits On demand hourly Last year

There are many

variables

available

Input

Output

wp4 data acquisition, management and security

Documents