Interoperability Testing for Explicit Demand Response in Buildings

Abstract

The explicit demand response (DR) is a key program for reinforcing the participation of end customers and making the most out of the potential of the smart grid. The DR is a key topic in the field of buildings to make use of the flexibility that they can offer. However, in order to guarantee the correct functionality of a DR system, it is fundamental to perform interoperability tests among the various components/actors. In this paper, we take into consideration the technological solutions suggested in the framework of the DRIMPAC project to enable the DR in buildings. We consider all actors/devices involved in order to reach the objective of executing a flexibility order by an asset. Following a structured interoperability testing methodology created by the Joint Research Centre, we perform interoperability tests regarding all critical links of the full chain of interacting actors to obtain the DR in buildings. The results show that the system functions properly and the benefits from the DR can be exploited. On the other hand, we provide a concrete example of how to apply the interoperability methodology in the field of testing the DR in buildings.

1. Introduction

The modern grid needs to cope with several challenges. It needs to accommodate numerous renewable energy sources and to manage energy in an efficient way. Smart programs, like the demand response (DR), can contribute to better energy management, taking advantage of the green energy produced during peak hours and, on the other hand, reducing the peak demand in crucial time slots. Indeed, managing energy in a smart way can result in grid security and can reduce any investments reinforcing the grid through reducing the peak demand. DR programs are being implemented throughout the world, and developments have also been accomplished from a regulations point of view. It is worth mentioning that, in Europe, the recently approved Regulation (EU) 2019/943 [1] and Directive (EU) 2019/944 [2] for the internal market for electricity address the DR in several articles. In addition, due to its quick penetration in the global market, there have been several attempts to depict the DR status in Europe [3], in the USA [4], and at a global level [5], all of whom have reported their recent status, proving the importance of the DR for the modern grid.

1.1. Literature Background and Motivation for This Work

The DR gives incentives to customers who alter their consumption pattern, thus alleviating the need for the grid to cope with elevated energy demands. It is more advanced in the industrial and commercial sector, since these sectors have greater amounts of flexibility to offer. In [6], the DR in industrial and commercial sectors is presented with the respective barriers and challenges. In [7], the authors propose a framework to quantify the DR potential of an industrial consumer; this is achieved by using smart meter data to propose operational patterns, which then help in defining the flexibility boundaries of industrial consumers. Industrial customers are also examined in [8], particularly industrial parks. A method is proposed to realise the self-scheduling process of the demand response aggregator, taking into account a load disaggregation algorithm. On the other hand, in [9], the authors propose a demand response program for an industrial micro-grid, including manufacturing facilities, photovoltaic panels, and battery energy storage systems. The program forecasts PV production, the usage of the battery energy storage system, and it schedules production for manufacturing facilities, thus making the most out of the flexibility potential of all components in the grid. In [10], a dynamic pricing mechanism is presented for the demand response programs offered to industrial parks.

On the other hand, the demand response is not only gaining attention in the industrial sector, but also in the residential and commercial sectors, with numerous scientific tools facilitating the realisation of demand response programs. In [11], the authors propose a scheduler and energy management controller (SEMC) to optimise the energy consumption within a smart home; artificial intelligence is used to schedule residential consumption. Internet of Things solutions for the real-time management of residential assets are proposed in [12] for power balance and voltage regulation, thus facilitating interactions between aggregators and DSOs. Interactions between consumers, aggregators, and DSOs, in terms of incentives for the flexibility being offered to consumers by the aggregators and, as a further step, aggregated flexibility being offered to DSOs, are examined in [13].

Efficient energy management within a home is also the objective in [14], where energy management is proposed for microgrids. On the other hand, efficient energy management is the objective in [15], where a mutual optimal solution was proposed both for utilities and customers. Flexibility scheduling is also examined in [16], where price and load levels are taken into consideration as the uncertainties for the stochastic scheduling program. In [17], the coordination of multiple residential assets on behalf of a flexibility service provider is proposed, taking into consideration the constraint of having a maximum of 10 connection points providing flexibility control within a radius of 100 m. The scheduling of appliances within the house is also the research objective in [18], where the authors propose an algorithm for optimal appliance scheduling for the residential sector.

A residential demand response implies the aggregation of multiple residential loads, and aggregation is the subject of research in [19], where a methodology is proposed that integrates demand response aggregators with distribution system operators for an efficient scheduling of the residential demand response in radial feeders. In [20], a methodology is proposed to deliver multiple system services, particularly by aggregating and disaggregating residential thermal energy storage, while also focusing on comfort aspects on behalf of the consumers. The residential demand response is examined in [21] under the perspective of consumer participation; particularly, a demand response model focused on procuring flexibility is proposed. In [22], the scheduling of residential home appliance loads is examined in coordination with the requirements of DSOs for flexibility.

The demand response in the residential sector, and in buildings in general, means that we need to make the most out of the flexibility that can be offered by buildings. In [23], the objective is to achieve energy flexibility forecasts for buildings, with the authors proposing a mechanism for that.

Dynamic pricing has been also a topic for the residential demand response. For example, in [24], dynamic pricing is examined for the residential demand in order to manage the constraints of distribution networks. On the other hand, bidding strategies are examined in [25] for aggregators in order to take into account the potential of residential customers.

Several projects have been realised in Europe to make use of the DR potential in the residential sector. For example, the Dr-BoB project addresses the benefits of the DR in the residential sector (blocks of buildings), taking into account different tariffs and the optimization of locally produced energy combined with storage options and locally consumed energy [26]. The RESPOND project addresses also the DR in buildings, making use of smart energy, monitoring infrastructure, and taking into account both the supply and demand [27]. The FlexCoop project also addresses residential users, providing the option to end-users to actively participate in the DR [28]. The SEMIAH project also deals with the residential DR, focusing on the aggregation and scheduling of loads in houses and suggesting business models for such consumers [29]. The DELTA project also aims at promoting the DR to residential customers via the concept of virtual nodes and clustering different customers with similar characteristics in the same virtual node [30]. The above projects are only examples of the recent work performed in the sector for promoting the DR in residential customers, thus exploiting their potential for a more robust and modern grid.

Another project where the residential DR is particularly examined and solutions are suggested for its exploitation is the DRIMPAC project—Unified DR interoperability framework which enables the market participation of active energy consumers, on which this work is focused. The project deals with aggregating flexibility from residential consumers by handling specific assets within the house. For this purpose, the so-called smart box has been designed, which communicates with the energy provider or the aggregator through the DRMS (DR Management System v1.0). The whole system is made to enable the components to communicate with each other, and flexibility messages are successfully sent with the ultimate goal of enabling the energy service provider to manage assets’ flexibility within the house [31]. It should be noted here that the whole DRIMPAC solution has been designed and developed in order to be applied in both small and extensive distribution networks, provided that the necessary equipment and information are available. For instance, if deemed necessary, over a certain number of end-users, for example over 100,000, a component within the DRMS can be employed, whereby, in using clustering techniques, end-users are properly grouped, and then DR signals might be provided according to the group assigned. This way, the necessary DR signals will be provided fast enough from the aggregator to them. The same extension and consideration have been made at the level of the DSO to the aggregator, where, if necessary, the DSO, or DSOs, can send its/their DR requests to multiple aggregators.

As can be easily deducted, for the successful implementation of the DR in the residential sector, several components and systems need to communicate with each other so as to achieve the aggregation of separate assets’ flexibility. Therefore, it is clear that interoperability is fundamental and needs to be preserved in order to achieve the desired results. To preserve interoperability, tests need to be made in order to ensure that all components speak to each other. The Joint Research Centre (JRC) of the European Commission has developed a novel interoperability methodology for testing in smart grids [32] and has applied it to various use cases in the smart grid field [33]. This methodology takes into account CEN/CENELEC documents [34] and the SGAM (Smart Grid Architecture Model) framework, which maps each component on the five interoperability layers, the six zones, and the five domains. The methodology takes into account the basic application profiles (bAps) and basic application interoperability profiles (BAIOPs) and defines step-by-step the interoperability tests.

The interoperability methodology for testing in smart grids has been utilised extensively by the JRC in order to test the interoperability of various use cases. For this purpose and in order to facilitate the scientific community to benefit from the interoperability testing methodology and smart grid use cases, the smart grid design of interoperability tests (SG-DoIT) platform was created [35]. It is a tool that automatically creates the steps for interoperability testing with minimum intervention from the users. The interoperability testing methodology has been successfully used outside of the JRC, like for example the Maesha project [36], which is a big European project entailing 21 partners. Among others, the project’s objective has been to offer flexibility services, by fostering the usage of RES and decarbonise the energy systems of specific islands. The project focuses on the island of Mayotte and is intended to expand the concept to five other islands. In the framework of the project, a platform has been created in order to aggregate the flexibility services; such flexibility is expected to stabilize the electricity grid on the island. The project manages different technologies to enable industrial flexibility, to take advantage of storage, and to handle charging points for e-mobility. In order to guarantee the correct functionality of the systems and their interactions, interoperability tests have been performed following the structured methodology created by the JRC team.

Although the literature is rich with projects and articles addressing the residential demand response in particular, to the best of our knowledge, there lacks an emphasis on the interactions between the various actors, and especially of the interoperability tests needed to guarantee smooth interactions among the actors. For instance, in [11,14], techniques are used to manage consumption within a smart home, but the interaction with external actors is not examined, whereas in [15], energy management was performed for a microgrid. On the other hand, although in [19], the topic of residential aggregation is examined, scheduling is the main focus, and testing the interaction among components is not addressed. The same goes for [16], where stochastic scheduling is proposed for flexibility. In [17], the interactions of assets are examined along with their scheduling under specific constraints but testing the smooth interaction between assets and the aggregator or DSO is not examined. In addition, although in [22] asset scheduling is performed taking into consideration the DSO requirements for flexibility, the interaction between actors and how this takes place is not tested. Interactions between aggregators and DSOs are examined in [12] for a real-time management scheme of residential assets, but there is a lack of focus on how the assets store flexibility requests or how the communication of flexibility offers takes place. Similar is the case of [13], where interactions among consumers, aggregators, and DSOs are considered, but in terms of the incentives for realising demand response programs; in our work, we examine the interactions from a technical point of view, as well as how flexibility requests and offers can be tackled by the respective actors. On the other hand, whereas energy flexibility forecasting is the subject of research in [23], focus is not given to how the actors interact to achieve the accomplishment of flexibility orders or how the assets store flexibility requests. With respect to projects addressing the residential demand response, as it is clear, they address various topics in the field, like the optimization of locally produced energy, smart energy monitoring infrastructure, load scheduling, and the clustering of different customers, just to name a few. However, interoperability issues are not addressed in terms of the interaction between actors in order to guarantee the smooth operation of the system overall.

1.2. Focus of the Current Work

In this work, we apply this interoperability methodology to testing in smart grids on a particular configuration of the DRIMPAC project, in order to evaluate the interoperability of the various components and to ensure that all steps are completed according to a well-defined procedure. We take into account the explicit DR scenario, where the energy service provider (DSO) makes a request for flexibility and the several assets within the house respond through the DRMS. The scope of this work is to prove the interoperability maintenance of the various components that reassure the participation of residential customers in DR programs, highlighting the importance of a structured methodology for interoperability testing.

The contribution of this paper is summarised as follows:

• We design a system that facilitates the demand response for the residential system.
• We focus on interoperability in order to guarantee the smooth operation of the system and the interactions among actors.
• We apply a structured interoperability methodology in order to perform tests and reassure the correct functionality of the system components.
• The main component of the system is the demand response management system, which communicates both with the assets within the house and also the aggregator and DSO.
• We show how interactions among actors take place, how flexibility requests and orders are stored in the assets, and how aggregated flexibility is communicated to the aggregator and DSO.

The rest of the paper is structured as follows: Section 2 shows the system description as well as the use case description. The links and communications among various actors are shown, whereas the use case to be analysed through the interoperability methodology is presented. Section 3 depicts the SGAM representation and the BAPs that form the use case to be tested according to the interoperability methodology. Section 4 presents the BAIOPs, thus describing the interoperability tests step by step. Section 5 concludes the paper.

2. System and Use Case Description—Interoperability Issues

In this section, we describe the system that is considered for the interoperability use case that is examined. In the framework of the DRIMPAC project, the DR management system has been designed in order to communicate from one side with the assets within the house and on the other side with the aggregator or DSO. In this work, we examine the interoperability of the end-to-end chain, from the DSO to the asset within the house. The following figure shows the interaction among the several actors mentioned above.

The concept is that, initially, the DSO forecasts a congestion point and sends a flexibility request to the DRMS. Subsequently, as depicted in Figure 1, the DRMS sends this flexibility request to the registered assets for that congestion point. These assets are within the house premises. The assets perform a flexibility calculation and forward this to the DRMS, which calculates the aggregated flexibility. The aggregator processes this flexibility, and the offer of flexibility is forwarded to the DRMS and the DSO. The DSO then selects the most suitable flexibility offer and sends an order for its execution to the DRMS, which subsequently disaggregates the order and sends it to the equivalent assets. The asset itself executes this flexibility order, and finally a report is created by the DRMS.

It is clear from the above description that there are three links of interactions as follows: between the DRMS and the asset; between the DRMS and the aggregator; and between the DRMS and the DSO. The interoperability testing methodology indicates that only one link of interest can be examined each time, whereas the rest of the links comprise the testbed.

Therefore, in this work, in order to perform interoperability tests for the whole chain of interactions, three use cases are considered, each of which examines one of the aforementioned links of interaction.

Table 1. Use cases, link of interest, and actors comprising the testbed.

Use Case	Link under Test	Testbed
1	DRMS–ASSET	DRMS–Aggregator DRMS–DSO
2	DRMS–Aggregator	DRMS–ASSET DRMS–DSO
3	DRMS–DSO	DRMS–ASSET DRMS–Aggregator

shows the use cases and the link of interest for each one of them, along with the actors comprising the testbed.

It is worth noting here that when the three use cases are combined together, an end-to-end mechanism involving the DSO–aggregator–prosumer takes place, thus enabling swift and robust communication among the aforementioned participants, and thus enabling in return a swifter application of demand response programs to be conducted effectively. This might not involve only adjustments to the energy assets, according to the day-ahead market electricity prices, but also intra-day prices and the provision of ancillary services to the DSO. Additionally, in case of an emergency for the grid, this mechanism might also prove effective, for instance, in case of preventing a black out.

In the following, we will apply the interoperability testing methodology for each use case, defining the BAPs and BAIOPs. It should be mentioned that to perform all interoperability tests for the whole chain of actors, multiple BAIOPs are considered for the first use case, thus multiple interoperability tests are performed for one use case.

3. SGAM Representation and BAPs

The smart grid architecture model (SGAM) has been the outcome of the mandate “Smart Grid Mandate–Standardization Mandate to European Standardization Organizations (ESOs) to support European Smart Grid deployment” of the Reference Architecture working Group [37]. It defines the following:

• five domains—the generation, transmission, distribution, DER, and customer premise domain;
• six zones—the process, field, station, operation, enterprise, and market zone;
• and five interoperability layers—the component, communication, information, function, and business layer.

The SGAM representation is shown in Figure 2.

In this work, we perform interoperability tests for the first layers, focusing on the communication and information layer. Therefore, we depict the actors and links of interest in the first interoperability layers, namely the component, communication, and information layers.

Figure 3 above shows the representation of the actors and interactions on the component layer. It is shown that the asset belongs to customer premises (private assets). On the other hand, we provide the representation of the communication and information layer of the respective actors and their respective links of interaction, as depicted in Figure 4. The labels CLS1, CLS2, CLS3 and ILS1, ILS2, ILS3 represent the possible standards that can be used for the respective links that comprise the testbed and the link of interest in each use case. These are used to form the various BAPs, as is explained later in this Section.

In each link of interaction, there are more than one standard/protocol/option that can be used.

Table 2. Possible standards for the links of interaction.

CLS1	CLS2	CLS3
HTTPSHTTPS, OpenADR, Message brokers (i.e., RabbitMQ)	HTTPs/USEF	HTTPs/USEF
ILS1	ILS2	ILS3
OpenADR/Restful web APIs, Message brokers (i.e. RabbitMQ), FlexOffer (custom DR standards)	JSON/XML/USEF	JSON/XML/USEF

shows all of these various options.

For each use case, the link of interest changes for the interoperability tests, thus the considered testbed is also altered.

For Use Case 1, the link under test is considered the one between the asset and the DRMS, thus all the other links are considered to be part of the testbed with fixed standards/protocols/options of the standards with which they operate. For Use Case 2, the link under test is considered to be between the aggregator and the DRMS, whereas for Use Case 3, the link under test is considered to be between the DSO and the DRMS. For each use case and for the link under test, a choice of one standard/protocol/option of standard needs to be made.

Table 3. BAPs for the equipment comprising the testbed and equipment under test.

Standard/Protocol/Specification	Interaction Link between Actors	Interoperability Layer	Role of Standard/Protocol/Specification
JSON/XML/USEF	Aggregator–DRMS	Information	BAP for Use Case 1, 3 Choice for link under test for Use Case 2
JSON/XML/USEF	DSO–DRMS	Information	BAP for Use Case 1, 2 Choice for link under test for Use Case 3
openADR/JSON	DRMS–Asset	Information	BAP for Use Case 2, 3 Choice for link under test for Use Case 1
HTTPs/USEF	DSO–DRMS	Communication	BAP for Use Case 1, 2 Choice for link under test for Use Case 3
HTTPs/USEF	Aggregator–DRMS	Communication	BAP for Use Case 1, 3 Choice for link under test for Use Case 2
USEFopenADR/JSON	DRMS–Asset	Communication	BAP for Use Case 2, 3 Choice for link under test for Use Case 1

shows the standards that would form the BAPs as well as the choice for the standard/protocol/option of standard that has been chosen to be tested for the link under test. It should be noted that the standards/protocols/options for the standards mentioned for one link of interest that comprises the testbed in one use case (BAPs) are the ones chosen as the standards/protocols/options of standards for the link under test for the other use cases and vice versa.

After defining the BAPs, the next step is defining the BAIOPs, which actually show the steps for the interoperability tests, as described in the following Section.

4. BAIOPs—Interoperability Tests

As explained in the previous Sections, in this work, we perform interoperability tests to check that all actors interact with each other properly without compromising the functionality of the whole system.

4.1. Interoperability Tests for Use Case 1

In this use case, the most critical link is considered to be the one between the DRMS and the asset within the house. The interoperability tests performed respect the situation depicted in Figure 1. We have performed six interoperability tests, three for the communication and three for the information layer of the SGAM framework. These interoperability tests are described through the BAIOPs according to the smart grid testing methodology, which describes the test as well as the test purpose and summary; the test steps are also described. The first BAIOP describing the interoperability test of interest is related to the communication layer and tests the communication between the DRMS and the asset, focusing on the capability of the asset of storing a flexibility request in its database. After a PASS is obtained in this test, an equivalent test is being performed for the information layer. This initial step is fundamental for the whole test case, since it is one of the first steps of the whole procedure of actually executing a flexibility order on behalf of the asset. The equivalent BAIOPs are shown in

Table 4. BAIOP for the communication layer for testing the communication between the DRMS and the asset—capability of the asset of storing a flexibility request in its database.

Test Case ID	ComTest1
Interoperability Layer	Communication
Summary of the Test	The DRMS needs to communicate with the asset within the house so that a flexibility offer is sent to the asset and correctly stored.
Test Purpose	To test the interaction between the DRMS and the asset.
Test Description	The DRMS has received a request for flexibility by the DSO; it has found which assets are relevant to this request and forwards the request to these assets. The assets store this request and calculate the flexibility that it can offer; in case the manager of the asset agrees, this flexibility offer is communicated with the DRMS.
Step 1	The DRMS finds which assets are relevant to the DSO flexibility request.
Step2	The DRMS dispatches the request to the assets.
Step 3	The request is received by the asset.
Step 4	Test verdict PASS: The request is stored in the asset’s database, proving the establishment of communication between the DRMS and the asset. FAIL: Otherwise, the communication is not established.

and

Table 5. BAIOP for the information layer for testing the semantic interoperability between the DRMS and the asset—capability of the asset of showing a flexibility request to its manager.

Test Case ID	InfoTest1
Interoperability Layer	Information
Summary of the Test	Communication needs to be established between the DRMS and the asset. A flexibility request needs to be correctly communicated and stored in the asset’s database. Semantic interoperability needs to be maintained, meaning that messages need to be interpreted correctly.
Test Purpose	To test the interaction between the DRMS and the asset.
Test Description	The DRMS has received a request for flexibility by the DSO; it has found which assets are relevant to this request and forwards the request to these assets. The assets store this request and calculate the flexibility that it can offer; in case the manager agrees, this flexibility offer is communicated to the DRMS.
Step 1	A PASS in the previously described test is required.
Step2	The flexibility that can be offered with respect to the request sent by the DSO is calculated by the asset management system.
Step 3	The asset management UI allows the manager to opt in or out of the request.
Step 4	Test verdict PASS: The flexibility offer can be visualised by the asset manager. FAIL: Otherwise, semantic interoperability is not maintained.

.

The aforementioned tests have been performed in the CERTH premises. USEF has been used as the option for communication between the two actors. Figure 5 shows the flexibility request stored in the asset database.

The reason behind showing the screenshot is to demonstrate that communication has taken place, and the flexibility request has been stored in the asset database. As it is clear, the aforementioned tests have been performed and a PASS has been obtained, meaning that the asset stores the request in its database, thus the communication is established. On the other hand, semantic interoperability is preserved, meaning that the asset manager visualises the offer of flexibility.

The next tests to be performed examine the capability of the DRMS to store a flexibility offer sent by the asset, which is the next critical step, as depicted in Figure 1, in order to complete the final objective of the relevant asset executing the flexibility order. Similarly, we perform interoperability tests both for the communication and information layer. The equivalent BAIOPs are shown in

Table 6. BAIOP for the communication layer for testing the communication between the DRMS and the asset—capability of the DRMS of storing a flexibility offer from the asset.

Test Case ID	ComTest2
Interoperability Layer	Communication
Summary of the Test	Communication needs to be established between the DRMS and the asset, so that the asset can communicate its flexibility offer to the DRMS.
Test Purpose	To test the interaction between the DRMS and the asset.
Test Description	The asset has a flexibility offer to communicate to the DRMS. This flexibility offer is communicated to the DRMS.
Step 1	A positive outcome of the previously described tests is needed.
Step2	The asset communicates its flexibility offer to the DRMS.
Step 3	Test verdict PASS: The DRMS receives the flexibility offer and stores it, meaning that successful communication takes place between DRMS and the asset. FAIL: Otherwise, the communication is not established.

and

Table 7. BAIOP for the information layer for testing the interaction between the DRMS and the asset—capability of the DRMS of storing a flexibility offer from the asset.

Test Case ID	InfoTest2
Interoperability Layer	Information
Summary of the Test	Semantic interoperability needs to be maintained with respect to the flexibility offer communicated by the asset to the DRMS.
Test Purpose	To test the interaction between the DRMS and the asset.
Test Description	The flexibility offer from the asset needs to be communicated to the DRMS, which also needs to interpret it correctly, maintaining semantic interoperability. This step is important since the DRMS needs to process the flexibility offer so as to calculate the aggregated flexibility from various assets.
Step 1	A positive outcome of the previously described tests is needed.
Step 2	The DRMS calculates the aggregated flexibility offered by different assets.
Step 3	Test verdict PASS: The DRMS gives the aggregated flexibility as its output. FAIL: Otherwise, semantic interoperability is not maintained.

.

Both of the aforementioned interoperability tests have been performed in the CERTH premises. A PASS has been obtained for both tests, showing that communication has been established properly between the two actors and that the flexibility offers are correctly stored in the DRMS database. Figure 6 shows this situation.

The screenshot is shown as a proof that the flexibility offer is stored in the DRMS database. Based on Figure 1, the last important action related to the link of interaction between the DRMS and the asset within the house has to do with the reception and execution of the flexibility order sent by the DRMS to the asset. The following interoperability tests on the communication and information layer, respectively, depict these two tests, shown in

Table 8. BAIOP for the communication layer for testing the communication between the DRMS and the asset—capability of the asset of receiving a flexibility order from the DRMS.

Test Case ID	ComTest3
Interoperability Layer	Communication
Summary of the Test	The DRMS needs to communicate its flexibility order to the asset, which in turn needs to execute this flexibility order.
Test Purpose	To test the interaction between the DRMS and the asset.
Test Description	The DRMS needs to disaggregate the flexibility order it receives by the DSO and dispatch it to its relevant assets, which in turn need to receive the order correctly and store it.
Step 1	A positive outcome of the previously described tests is needed.
Step 2	The DRMS has received a flexibility order by the DSO and disaggregates the order according to the assets’ flexibility offer.
Step 3	The DRMS dispatches the order to the assets
Step 4	Test verdict PASS: The asset receives the flexibility order and stores it, meaning that successful communication takes place between DRMS and the asset. FAIL: Otherwise, the communication is not established.

and

Table 9. BAIOP for the information layer for testing the semantic interoperability between the DRMS and the asset—capability of the asset of executing the flexibility order from the DRMS.

Test Case ID	InfoTest3
Interoperability Layer	Information
Summary of the Test	The DRMS needs to communicate its flexibility order to the asset, which in turn needs to execute this flexibility order. Semantic interoperability needs to be maintained.
Test Purpose	To test the interaction between the DRMS and the asset.
Test Description	The DRMS needs to disaggregate the flexibility order it receives by the DSO and dispatch it to its relevant assets, which in turn need to receive the order correctly and store it.
Step 1	A positive outcome of the previously described tests is needed.
Step 2	The asset receives the flexibility order and executes is correctly.
Step 3	Test verdict PASS: The asset executes the flexibility order. FAIL: Otherwise, semantic interoperability is not maintained.

.

These tests have also been performed at the premises of the CERTH, focusing on testing the correct reception of the flexibility order by the asset. A PASS has been obtained in both tests. Figure 7 shows the flexibility order stored in the database of the asset, which is the objective of this test.

4.2. Interoperability Tests for Use Case 2

In this use case, the link under test is the one between the DRMS and the aggregator. The focus of this use case is to check the capability of the DRMS to successfully receive the flexibility offer from the aggregator. USEF is used as the communication technology between the two actors; thus, it is used for storing the flexibility offer. Again, we consider the communication and information layer for the interoperability tests. The equivalent BAIOPs are shown in

Table 10. BAIOP for the communication layer for testing the communication between the DRMS and the aggregator—capability of receiving a flexibility offer from the aggregator.

Test Case ID	ComTest4
Interoperability Layer	Communication
Summary of the Test	The aggregator processes the aggregated flexibility calculation sent by the DRMS and generated by the equivalent assets. The aggregator comes with a flexibility offer, which needs to be communicated and properly received by the DRMS (stored using USEF).
Test Purpose	To test the interaction between the DRMS and the aggregator.
Test Description	After the assets have given their flexibility to the DRMS, and the latter has resulted in the aggregated flexibility calculation, the aggregator processes the aggregated flexibility and comes up with an offer, which is communicated to the DRMS. This flexibility offer needs to be correctly stored and interpreted, and the DSO is also informed about it.
Step 1	A positive outcome is needed for the tests ComTest1, ComTest2, InfoTest1, InfoTest2.
Step 2	The aggregator has received the aggregated flexibility calculated by the DRMS.
Step 3	The aggregator processes this aggregated flexibility and comes up with a flexibility offer.
Step 4	The aggregator communicates this offer to the DRMS.
Step 5	Test verdict PASS: The DRMS receives the flexibility offer and stores it (using USEF), meaning that successful communication takes place between DRMS and the aggregator. FAIL: Otherwise, the communication is not established.

and

Table 11. BAIOP for the information layer for testing the communication between the DRMS and the aggregator—capability of receiving a flexibility offer from the aggregator, thus maintaining semantic interoperability.

Test Case ID	InfoTest4
Interoperability Layer	Information
Summary of the Test	The aggregator processes the aggregated flexibility calculation sent by the DRMS and generated by the equivalent assets. The aggregator comes with a flexibility offer, which needs to be communicated and properly received by the DRMS (stored using USEF), maintaining semantic interoperability.
Test Purpose	To test the interaction between the DRMS and the aggregator.
Test Description	After the assets have given their flexibility to the DRMS, and the latter has resulted in the aggregated flexibility calculation, the aggregator processes the aggregated flexibility and comes up with an offer, which is communicated to the DRMS. This flexibility offer needs to be correctly stored and interpreted, and the DSO is also informed about it.
Step 1	A positive outcome is needed for the tests ComTest1, ComTest2, InfoTest1, InfoTest2, ComTest4.
Step 2	Test verdict PASS: The flexibility offer is interpreted correctly, and the DSO can be informed about this flexibility offer. FAIL: Otherwise, the information cannot be interpreted correctly.

.

Both tests described above have been performed at the CERTH premises and a PASS has been obtained. Figure 8 depicts the screenshot showing that the flexibility offer is stored in the DRMS database. As a PASS is obtained, this means that the DSO can proceed with the flexibility offer selection and go further with the flexibility order, sending it to the DRMS and subsequently to the equivalent assets, which is the focus of the last use case examined in this paper.

4.3. Interoperability Tests for Use Case 3

In this use case, the link under test is the one between the DRMS and the DSO. The aim of this use case is to examine the capability of the DRMS to successfully receive the flexibility order by the DSO and interpret it correctly so as to be able to proceed with the flexibility order disaggregation. USEF is used as the communication technology between the DRMS and the DSO. Once more, we consider the communication and information layer for the interoperability tests. The equivalent BAIOPs are shown in

Table 12. BAIOP for the communication layer for testing the communication between the DRMS and the DSO—capability of receiving a flexibility order from the DSO.

Test Case ID	ComTest5
Interoperability Layer	Communication
Summary of the Test	After elaborating on the flexibility offers from the aggregator, the DSO sends these offers to the DRMS. USEF is used for this scope.
Test Purpose	To test the interaction between the DRMS and the DSO.
Test Description	The DSO has received the flexibility offers from the aggregator. The DSO processes these offers and makes the most suitable selection. USEF is used to send these offers to the interested parties, like the DRMS.
Step 1	A positive outcome is needed for the tests ComTest1, ComTest2, ComTest4, InfoTest1, InfoTest2, InfoTest4.
Step 2	The DSO elaborates on the flexibility offers received and makes the most suitable flexibility offer selection.
Step 3	The DSO sends the flexibility order via USEF to the DRMS.
Step 4	Test verdict PASS: The DRMS successfully receives the flexibility order, which is stored via USEF, meaning that communication has been established with success. FAIL: Otherwise, the communication is not established.

and

Table 13. BAIOP for the information layer for testing the communication between the DRMS and the DSO—capability of receiving a flexibility order from the DSO, maintaining semantic interoperability.

Test Case ID	InfoTest5
Interoperability Layer	Information
Summary of the Test	After elaborating on the flexibility offers by the aggregator, the DSO sends these offers to the DRMS. USEF is used for this scope.
Test Purpose	To test the interaction of the DRMS and the DSO.
Test Description	The DSO has received the flexibility offers from the aggregator. The DSO processes these offers and makes the most suitable selection. USEF is used in order to send these offers to the interested parties, like the DRMS, where semantic interoperability needs to be preserved.
Step 1	A positive outcome is needed for the tests ComTest1, ComTest2, ComTest4, ComTest5, InfoTest1, InfoTest2, InfoTest4.
Step 4	Test verdict PASS: The flexibility order is interpreted correctly by the DRMS, which can proceed with the flexibility order disaggregation, meaning that semantic interoperability is preserved. FAIL: Otherwise, the information cannot be interpreted correctly.

.

The reason why the screenshot is displayed here is to show that the flexibility offer is indeed stored in the DRMS database.

Both tests described above have been performed at the CERTH premises and a PASS has been obtained. Figure 9 depicts the screenshot showing that the flexibility order is stored in the DRMS database, proving that the interoperability tests have been executed and have obtained a PASS. The screenshot serves as a proof that the flexibility order is stored in the DRMS database.

4.4. Discussion and Future Work

From the above sections, it has been concluded that all interoperability tests have been performed successfully, providing a PASS as an outcome.

Table 14. Interoperability tests performed for the system designed for the residential DR.

Link under Test	Use Case	Test(s) Performed	Requirements for Successful Test	Interoperability Layer Tested	Outcome
DRMS –> Asset	1	Flexibility request is sent by the DRMS to the asset	Request is stored in the DRMS database	Communication	PASS
			Request is correctly visualised in the database	Information	PASS
Asset –> DRMS	1	Flexibility offer is sent by the asset to the DRMS	Offer is stored in DRMS database	Communication	PASS
			DRMS can process the offer and can calculate the aggregated flexibility	Information	PASS
Aggregator -> DRMS	2	Aggregated flexibility offer is processed and sent by the aggregator to the DRMS (using USEF)	Offer is stored with success	Communication	PASS
			Offer is interpreted correctly and can be sent to DSO	Information	PASS
DSO -> DRMS	3	Flexibility order is sent by the DSO to the DRMS	Flexibility order is stored with success	Communication	PASS
			Flexibility order is interpreted correctly and the DRMS can go on with flexibility order disaggregation	Information	PASS
DRMS -> Asset	1	DRMS sends flexibility order to the asset	Flexibility order is stored with success	Communication	PASS
			Flexibility order is interpreted correctly and can be executed	Information	PASS

summarises the tests being performed, and the outcome obtained.

From the above table, we can see that a variety of interoperability tests have been performed to cover the whole chain of actors, from the DSO to the asset within the house. All these tests guarantee that the system functions properly in order to guarantee that the DR for residential customers is delivered successfully. In addition, a structured testing methodology has been followed in order to ensure the quality of the tests performed and that this is in accordance with the high standards of work. The tests show that a PASS has been obtained, meaning that the designed system can deliver DR events for residential customers with success, which is the overall objective of the project.

The scheme described in this paper shows that the inclusion of residential consumers in demand response programs can be achieved successfully. It is planned to extend the integration of buildings of all other sectors, namely residential, commercial, and industrial, under the same proposed approach. This way, reflecting a more inclusive portfolio for the aggregators and giving more flexibility to them, and to the DSO as well. For this reason, tests will take place to examine how the integration of different consuming sectors can occur, and it is envisioned to have a demand response orchestrator, aggregating flexibility offers and distributing flexibility orders to different customers.

5. Conclusions

In this paper, we perform interoperability tests in order to guarantee the smooth interaction of the relevant actors for the realization of the explicit demand response in buildings in the framework of the DRIMPAC project. We focus on the interaction of the demand response management system, which is the core component for the realization of the demand response, with the assets within residential homes and also the aggregator and the DSO. For the interoperability tests, and in order to guarantee the correct functionality of the system, the structured smart grid interoperability methodology is used, which has been developed by the JRC team. The key findings and conclusions of the tests performed, which show how the explicit demand response for residential consumers can take place, are summarised as follows:

• The DRMS needs to communicate flexibility requests to the assets, and each asset needs to successfully store these flexibility requests.
• The flexibility offer is calculated by the asset and is visualised by the asset manager who needs to give the green light for further actions.
• The DRMS receives and stores the flexibility offer from each asset. It aggregates flexibility offers from assets and then sends this information to the aggregator.
• The aggregator process aggregated the flexibility offers and comes up with a flexibility offer that is then forwarded to the DRMS. The DRMS needs to store this information successfully.
• The DRMS communicates the selected flexibility offer to the DSO, and the DSO selects the best flexibility offer. It then sends a flexibility order to the DRMS. The DRMS needs to store this information correctly and disaggregate the flexibility order accordingly to the assets.
• The asset receives and stores a flexibility order, which it executes further down the line.

All the above tests have been performed successfully, proving that the actors can interact smoothly with each other and guarantee that the explicit demand response can take place successfully for residential consumers. The results show that the ultimate goal of executing a flexibility request via the assets at home has been achieved.