To better understand the conceptual space in which the efforts presented in the previous section exist, requires to first examine the core idea; in this case, the SGAM framework. This section highlights some of the important components relevant to distributed control and monitoring. A general overview of the important parts of the SGAM framework itself is given in Additional file 1: Appendix. The full detail can be found in the related standard Bruinenberg et al. (2012).

As was shown in the related work section in the literature there exist a variety of approaches that build upon centralised control of the system and a hierarchical aggregation structure. The centralised control allows for the computation of optimal configuration of the DRES operation with high accuracy as several commonly used optimisation techniques can be applied in this setting. The hierarchical aggregation structure mimics the hierarchical structure in the grid where the different voltage levels are separated by transformers substations. An architecture approach that utilises this paradigm therefore, closely resembles the existing structures in the power grid of today. In this section a simplified version of an ICT architecture SGAM model for an hierarchical structure with centralised control, but distributed provision of AS is presented.

Business layer

As a start a brief stakeholder analysis of the envisioned system is presented. First, this analysis considers the SOs, which from the perspective of the AS serve as the customers. Then the resources which are used to provide these services are considered and finally, additional third parties are taken into account.

The role of the SO is encapsulating the needs of the power system side of the overall system. The goal is to have a stable grid which is operated efficiently i.e., with a minimal amount of losses. Therefore in our context, the SO fills the role of the customer seeking certain grid services.

The role of the third party is to perform the aggregation and optimisation required to provide the services to the SOs. This role is introduced to provide the system with flexibility regarding future market or regulatory developments. As such, an actual third party may be a subsidiary of a SO or a completely separate entity. This party also serves as the broker between a potential large amount of connected DRES and a small number of SOs consuming services.

Distribution System Operators (DSO)

DSOs are charged with managing both the MV and LV distribution grids, supplying the end consumer with electricity directly. In this case, their primary challenge is the reversal of power flow in situations where end-consumers also have some generation capacity, such as on-site solar installations. This in turn leads to concerns around voltage spikes as power from these sites may spike unpredictably causing overly high back-feed into the LV grid. Traditionally, these problems are solved through the implementation of grid reinforcements, preventing the propagation of these problems upstream.

With the introduction of smart grid architectures, the DSOs can take direct action to control the power feeds and flows, enabling them to become an active component in the management of the grid, rather than simply a passive consumer of higher-voltage ingress. This involves the integration of vastly higher fidelity energy monitoring in the form of smart metering, and smart converter devices. These two technologies place the DSO in a prime position to execute very fine-grained control over their grid. This has real, tangible benefits as it allows the DSO to reduce their dependence on upstream power generation when dealing with the management of reactive power, line losses and the bidirectional power flow with renewable injection.

Transmission System Operator (TSO)

TSOs, on the other hand, are responsible for maintaining the balance of power in the grid, and have control over the high-voltage power lines transmitting power from traditional bulk generators over long distances where the connections are made with the DSOs to step down into the medium-voltage grids. This naturally has wide-reaching effects, as balancing supply and demand at this scale will have knock-on effects with bulk generators and DSOs supply alike, and any deviation in this balance will immediately become apparent in globally monitored parameters such as grid frequency. As such, ASs dealing with grid inertial response, primary frequency response and fault currents (and fault mitigation) are required to be provided at this scale to keep the grid operation stable and safe.

DRES owners

Finally, the DRES owners are the people actually providing contributions to grid services via their DRES. This term generalises installations containing different types of energy resources. Batteries, capacitors banks, super capacitors, controllable loads, Electric Vehicle (EV) charging stations, PV systems and many more resources can all provide valuable contributions to maintaining the operation within limits of the power grid. The variety of generation sources implies also differences in the business goals of the DRES owners. As an example, the owner of a large scale PV system might be solely focused on maximising their profits to increase the returns on their initial investment. Owners of rooftop PV systems for their own home might primarily be interest in optimising their self-consumption and only sell excess energy to the power grid. Finally, owners of EVs and charging stations equipped with PV panels may want to ensure their transportation is available for their trips to and from their workplace.

In order to simplify the model, it is assumed that these considerations can be handled on a local level. This means especially that when a DRES owner reports the capacity to provide ASs of their installation, their own goals are already accounted for.

Third parties

Several other parties have an interest in the energy system coupled with an ICT system. Regulators and law makers give restrictions on the operation conditions to be ensured and the framework for trading of energy and services between the SO and DRES owners. Regulatory policies in the future might forbid the SO from being the consumer of ASs and at the same time selling the aggregated capacities of the devices in their respective grids to other SOs. Further, the trading of ASs offers a new business opportunity which previously not involved parties might attempt to seize. This might lead to them becoming an intermediary that contracts individual DRES owners to sell their aggregated capacity to SOs. Finally, cloud service providers might be integral to setting up and managing the communication links to the distributed components in the grid while offering a platform for other parties to host their required services on.

Role model

The main focus of the present architecture is the monitoring and control of ASs on a moment to moment basis. As such considerations towards the law makers and cloud service providers are less relevant as these need to happen in advance to any service provision. Further, as already mentioned when talking about the DRES owner the multitude of different DRES types is resolved on a local level. With this only one actor is created in the model to serve the role of providers of ASs.

As was just described the DSO and the TSO both seek to have stable operation of their respective grid levels. However, the services they require and therefore request from the system are different. This difference is assumed to be minor enough that a general actor, the SO, serving as the client who request any AS is sufficient.

To model either the separation of concerns within a SO or the integration of other third parties serving as aggregators of ASs a separate role is introduced. This third party has the task of controlling and coordinating the grid-wide operation of the DRES they are responsible for. Their business interest is twofold: On the one hand, they want to earn money from their aggregation of services i.e., they seek to optimise the operation of DRES with respect to monetary gains; on the other hand, as a requirement from the side of the SOs, they have to ensure the operation of their DRESs stays within permissible grid limits.

As a final consideration to satisfy the business interests of the described actors, the existence of a mutual contract between these three actors, the third party, the SO and the DRES owners, is assumed. Models for these contracts exists when it comes to trading of wholesale energy as can be made evident by considering the operation of companies such as Kiwi Power (2022). When buying energy on the wholesale market the customer expects that the requested amount of energy is fed in during the request period. The trading of ASs is different however in this key aspect. When requesting an AS the customer expects a certain behaviour to be present when a contingency in the grid arises. On the one hand, this means that the DRES is uncertain when exactly it must provide the service; on the other hand, this raises the importance of the requirement to keep track of the state of the DRES as it must be available otherwise critical emergency resources are lacking. This changes the requirements in a way that the existing contracts may not translate on a one to one basis. As there is no regulatory framework for this exact relation to the best of our knowledge until now, the exact details of this contract are intentionally left vague. However, it is assumed to serve as the contractual basis that regulates the provision and remuneration of the different ASs.

Function layer

The high level goal of the system of providing ASs requires a set of services to be available.

First, the participants in the system need to be aware of the available resources and the system state. This is enabled by a service referred to as monitoring. Considering that each stakeholder has different business interests they may be concerned with different monitored values. Furthermore, monitoring needs to be split in monitoring done for a human operator and monitoring done for a software system to ensure the proper operation of the DRES.

Second, once the SOs are aware of the grid state and the available resources, they are in a position to formulate requests for certain ASs. These request need to be mapped in an appropriate way onto the DRESs available to contribute to the respective AS. Usually, it is not enough to just forward these request but an optimal distribution to the DRES is desirable. The optimisation employed should consider grid constraints and economic benefits for the actors. As the goal of this paper is not to develop novel optimisation algorithms, further details on the design of such software is not included.

Finally, after the system has received a request, processed it to configure the DRES and these devices have provided the respective AS, the DRES owner expects to be remunerated for this in some way. To enable the cashflow between the participants, trustworthy accounting is required. To this end considerations with regards to non-repudiation, reliable metering, and storage of data, as well as storage solutions offering enough throughput and disk space are required. As mentioned in the Introduction the full scope of this function is not included in this paper. Instead we focus on structuring the information exchange from the meters to the storage system and leave the details with regards to the structure / protocol for this information exchange intentionally open.

The services described above are the functionalities considered for the function layer. From a functional point of view the system must be able to do the following: Take an request from the SO and send it to the third party. In order to determine how this request is to be realised the third party should have monitoring data about the grid available. Using the available data a optimal usage of the available contributions from the individual DRES is computes and communicated to them. Once the signal has reached the DRES each of them can change its local behaviour to provide the service.

This functional decomposition of the system is also shown in Fig. 2. Starting from the top in this figure the interface to the SO is the function AS Request Handling. As this represents the front end that the SO interacts with, it is located in the market zone and distribution domain. It is assumed that a SO knows which ASs with which parameters is required. As such this function provides to them the possibility to enter this demand into the system. The sum of their AS requests is forwarded to the third party where this request is then translated into a provision of the service via the available DRES.

Fig. 2
figure 2

Function layer of the proposed architecture

Next the role of the third party is split into three functions: Monitoring, Setpoint Communication and Optimal Setpoint Computation. These functions aggregate the behaviour of the DRES located in the distribution grid to a distribution grid level service. Therefore they are located in the distribution domain and operation zone. The computation of optimal setpoints and setpoint communication happens in multiple aggregation levels as mentioned at the start of the section. Take as an example a MV grid which is connected to many different LV grids. This structure would indicate two hierarchy levels. First, the optimal setpoints for all the LV grids in the MV grid can be computed. Then these setpoints can be sent to these LV grids and inside of them they can be dispatched again by a similar procedure to the individual DRESs.

Finally, the functionality the DRES owner is responsible for is twofold. Firstly, the local control of a DRES and the actual provision of contributions by low level controller and actual hardware is modelled by the function Grid Service Provision. This function is located in the DER domain and spans the process and field zones since it involves both the control of the generation hardware and the generation hardware itself. Once a control signal has reached this function the appropriate changes to the settings of the DRES are made to provide the required response. Secondly, the management of the DRES is modelled by the function DRES Local Control. This function deals with the coordination of the different devices inside the DRES. As such any inputs received from the Setpoint Communication function need to be translated to appropriate output to the Grid Service Provision. Considering the flow of monitoring data from DRES to Third Party within this function the business goals outlined on the business layer for the DRES owner are to be resolved. This means that when reporting the available resources for ASs an appropriate amount of the actual resources is reserved to ensure these business goals are met. This function represents a form of operational control. Thus, it is located on the operation zone of the DER domain.

Information layer

When considering communication links there are four different sections of the infrastructure. The link between the user and the system, the internal communication links within the system, the communication link from the system to the DRES gateways, and finally a communication link between the DRES gateways and the different components of the DRES. These four links are what is described further in the following paragraphs from the viewpoint of the information and communication layer.

From the viewpoint of the information layer the message exchange between the user and the system is modelled as requests for collections of services. Then, the message a user sends to the system is a collection of requests for individual AS with the corresponding parameters set by the user. Thinking in terms of a collection of services has the advantage that it closely mirrors the utility provided to the system by traditional synchronous generators. Synchronous generators do not only provide a single AS like inertia but also simultaneously may contribute to the reactive power balance of the system, inject the required high currents during faults and many other ASs.

For the message exchange within the system there is a degree of freedom still left in the model. The hierarchical aggregation schema along the hierarchical optimisation impose different requirements on the information objects for determining the available amount of each AS (aggregation) and for a given request computing a effective dispatch (optimisation). Further, each AS has different requirements when it comes to the involved information. It is therefore required to come up with flexible formats and protocols for both aggregation and optimisation. One possibility solution is the use of loosely structured data objects like for example JSON provides. From an implementation perspective this has the benefit that the code for managing the message exchange can be the same and only the pieces of code for (de-)serialising to JSON objects need to be created. Additionally, this reduces the required effort to include new ASs with new optimisation and aggregation procedures.

For the aggregation and optimisation schemes the DRES serve as the smallest quantity one can talk about. As such the DRES gateways are the final smart entities involved in these processes. Therefore, the same format for data exchange as with higher levels of aggregation is suitable for this link.

For the final link between the DRES gateways and the DRES themselves, one has to keep in mind that in a future smart grid different types of DRES with different devices connected to them which are produced by different vendors will be the norm. As such the DRES gateway has the important additional task to translate the information objects received in an appropriate manner to fit with the information objects required by the different installations. As an example the received JSON objects may be required to be translated to appropriate Modbus registers. While doing so one has to keep in mind things like the number of bits available for each data point i.e., the precision to round to.

The figure for the information layer largely coincides with the communication links shown in Fig. 3 as blue lines. Therefore the figure is omitted.

Fig. 3
figure 3

Component layer of the proposed architecture

Communication layer

For the link between the DRES gateway and the DRES shown in Fig. 3 multiple communication protocols need to be supported. Which protocol is to be supported depends on the interface that the smart converter offers. The DRES gateway therefore was introduced to serve as the mediator between the ICT system and smart converter. This flexibility with regards to the employed protocol allows for converters from different manufacturers to easily be integrated in the system.

Apart from this connection, two different technologies for the communication links are used. In order to communicate the dispatch of an AS to individual DRES installations point to point links between the optimisation and the individual DRES are required. These links must be able to reliably deliver messages for different ASs that can differ greatly in the required parameters. In simple cases, the payload can only be a Boolean value which needs to be communicated. In other cases, a set of numbers indicative of total energy amounts or to be interpreted as a droop curve needs to be sent. Standard web technology, like HTTP, is suitable for dealing with this task.

The second protocol is to deal with monitoring requirements. In order to take an optimal decision inside the ICT system up to date measurements of some DRES parameters are required. For example, take the state of charge of a battery system or available active power from the primary source of a DRES system. When deciding if and to what extent a DRES can provide an AS these information must be available. Further, optimisation algorithms for different AS may be interested in different measurements from different device. For this reason, a publish-subscribe scheme allowing for a flexible distribution of the measurements to the interested parties is proposed.

Considering the requirements outlined in this section the OPC-UA protocol described in Lehnhoff et al. (2012) also offers the required capabilities. On the one hand, this technology offers to create sessions between a client and a server using HTTP to exchange variables as required for the setpoint communication; on the other hand, the subscription mechanism it offers is suitable to allow for a publish-subscribe scheme to be implemented. This system further offers the additional capability of implementing events and alarms to notify listeners of imminent changes in the production of the DRES.

The figure for the communication layer coincides with the communication links shown in Fig. 3 as blue lines. Therefore the figure is omitted.

Component layer

A possible simplified technical realisation in software and hardware components is shown in Fig. 3.

For the user input handling some hardware owned by the DSO is required to run or access the frontend of the system. This DSO hardware needs to be connected with the third party hardware. A set of virtual entities is located on this third party hardware. These virtual entities are organised hierarchically to facilitate the hierarchical optimisation described in the function layer section. Thus creating a virtual representation of the actual physical entities in the power grid and their aggregation hierarchy.

To this end an exchange of information between the virtual entities for higher and lower hierarchy levels and from the lowest level virtual entities to the physical DRES location is required. In order to enable this communication a directory service is envisioned allowing each virtual entity to lookup the communication address of other virtual entities and DRES.

The virtual entities and the directory service together realise the setpoint communication function. Further, the virtual entities alone are enough to realise the monitoring through collection of data received from the DRES and aggregating this information towards the top of the virtual entity hierarchy.

Finally, a service performing the optimisations is required. Virtual entities which represent an aggregate, can provide measuring data to this service, and receive the optimal allocation of contribution to the virtual entities they aggregated. As such the optimisation service realises the Optimal Setpoint Communication function.

In order to realise the AS Provision function two components are involved: the smart converter controller, as the controlling device for the DRES generation hardware, and the DRES generation hardware itself. The DRES generation hardware can for example be a smart converter connected to a battery system or a PV system. It is responsive to certain changes in its parameters made by the smart converter controller.

Inside this smart converter controller real-time sensitive processing of data and determination of operational setpoints for the DRES hardware is done. It also forwards the required measurements from the DRES hardware to the gateway. The job of the DRES gateway is to translate the signals received from the third party hardware to a format that is understood by the smart converter controller and sending measurements taken from the DRES back to the third party hardware.

Rights and permissions

Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article’s Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article’s Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons.org/licenses/by/4.0/.

Disclaimer:

This article is autogenerated using RSS feeds and has not been created or edited by OA JF.

Click here for Source link (https://www.springeropen.com/)