1 Introduction and related work

In Austria, local energy communities (LECs) in the form of “Erneuerbare Energiegemeinschaften” (EEGs), aim at increasing the number of renewable energy resources while providing financial benefits to its participants but not for the EEG itself. Communities such as these are geographically limited by their substation and subsequently the low-voltage grid they are connected to. While the decreased fees offer the incentive to invest in renewables, this should be done in a way that is grid-friendly and socio-economically fair. In addition, as additional IT infrastructure is needed to accommodate the creation of LECs, security and privacy are important factors to consider in all stages of IT architecture development. This is the goal of the project ECOSINT, which has already been described in [1].

The central task of phase two of the project is the development of the software architecture. This will be accomplished using the model-based systems engineering (MBSE) technique. MBSE was chosen because it is a well-known approach for developing systems guided by a model. The model is built with a coherent and consistent set of views that reflect several perspectives on the system and its applications [10]. Currently, the project is in the middle of the corresponding process, and first results are shown. Results are demonstrated by means of an EV charging scenario and comprise the conceptual model, a first schematic overview of the system and its environment and finally, various UML models. The smart grid is envisioned to be an ecosystem consisting of numerous heterogeneous information and communication devices that need to interact with each other to enable, for example, enhanced communication and control and bring about the eponymous intelligence. Therefore, interoperability is a key property for future energy systems, as ICT problems can lead to issues in the energy domain. This is reflected also for example in the different layers of the smart grid architecture model (SGAM) which made an important contribution towards interoperability in the energy domain. In this paper, the intended way to achieve interoperability using VLab is presented and demonstrated for a comparatively simple scenario for EV charging.

The document is structured as follows: some background about interoperability and modelling frameworks is shown in Sect. 2. In Sect. 3, the architectural part consisting of the collection and organization of requirements, the generation of the conceptual model, and the module view of the use case scenario is shown. VLab is described and applied to this use case in Sect. 4. Finally, a conclusion and an outlook are given in Sect. 5.

2 Background

Interoperability is a critical enabler of smart grid potential and should be considered an inherent component of any smart grid application being developed from the very beginning. It is a design consideration, so considering it early on saves time and resources. Furthermore, when engaged partners and stakeholders have a better understanding and documentation of automation interfaces, dependencies, and expectations, communication becomes more effective and easier. As part of its discussion of the advantages of interoperability, NIST 4.0 [4] notes that these include, on the one hand, reducing the time and effort needed for successful integration and, on the other, identifying automation points that might lead to the provision of value-added services on top of an existing solution and infrastructure. Yet another benefit is interchangeability, which makes it possible to quickly swap out one component for another similar one.

To demonstrate the concept, Fig. 1 displays a meta-model of interoperability between two generic systems. The model depicts a relatively simple situation in which two systems (System A and System B) are interested in exchanging information with one another in order to work toward a shared objective. Two fundamental notions must be made available by both systems in this fundamental situation. These include concepts like a data model and an interface. The interface, as defined by the IEEE Standard Computer Dictionary [9], is the shared boundary that serves as a conduit for data communication between the two systems in this instance. A data model, on the other hand, is an abstract model that organizes a system’s properties and structure in a way that other systems could find useful to know.

Fig. 1
figure 1

A simplified meta-model of interoperability between two systems [6]

Full size image

The process of estimating a system’s interoperability is complex and cannot be boiled down to, e.g., a binary yes/no answer. Instead, interoperability can be evaluated using a maturity scale like the one shown in Fig. 2. This approach, proposed by the GridWise Architecture Council, divides a system’s interoperability into three categories: pragmatics, semantics, and syntax. Then, each of these groupings is further separated into two or three tiers. The model suggests that there is a mechanism for creating physical and logical links between systems at the lowest level of interoperability, “1. Basic Connectivity,” while the highest level of interoperability, “8. Economic/Regulatory Policy,” is reached when all parties involved have a common understanding of the political and economic goals in policies and regulations.

Fig. 2
figure 2

GridWise Architecture Council’s Interoperability Context Setting Framework [7]

Full size image

Two models and frameworks are relevant for the discussion on the design and development of interoperable smart grid solutions. The first is the NIST Smart Grid Conceptual Model which is part of the NIST 4.0 smart grid interoperability framework [4]. The conceptual model, shown in Fig. 3, presents the smart grid as several high-level domains (customer, distribution, generation including DER, market, operations, service provider, and transmission) along with the ICT and electrical interactions among them. The model is aimed at making communication easier and more understandable among various stakeholders.

Fig. 3
figure 3

NIST Smart Grid Conceptual Model [4]

Full size image

The second important methodology is the Smart Grid Architecture Model (SGAM) [3], a three-dimensional architectural framework, shown in Fig. 4. It is a reference model as well as a methodology for designing and visualizing smart grid solutions in an interoperable way. There are five interoperability layers, and each layer is a two-dimensional plane. This plane is divided into domains and zones that correspond to different areas of the power system. Smart grid use cases, when defined for example using the IEC62559‑2 [5] template, can be visualized using the SGAM model to have them interpreted in an interoperable way.

Fig. 4
figure 4

Smart Grid Architecture Model [3]

Full size image

3 Architectural process

3.1 Collection and organization of requirements

As the main goal of the project is a software architecture for LECs, in the first step, requirements have been collected in a stakeholder workshop including representatives from industry, academia and an association that supports the foundation of renewable energy communities. Subsequently, these broad requirements were then assigned one or more of five labels (economic, technical, ICT, interoperability, and sociographic) in a multi-labelling process.

3.2 Generation of the conceptual model

Out of these requirements, the following six main objectives for the software architecture have been selected.

  1. 1.

    Grid-friendliness (provide flexibility, decrease peak loads, predict flexibility, optimize self-consumption, avoid concurrent effects, support islanding)

  2. 2.

    Modularity of architecture (easy exchange, extension, and removal of components)

  3. 3.

    Openness and interoperability (open standards, easy integration for external service providers, vendor independence)

  4. 4.

    Scalability of the system (favourable behaviour of communication, computation, and maintenance costs with changing number of participants)

  5. 5.

    Resilience (robust communication within LEC, fault tolerance, failure detection and correction, graceful degradation)

  6. 6.

    Security and Privacy (protection against external and internal attackers, e.g., via secure and authenticated communication, model-based threat identification, application of privacy-by-design strategies and privacy enhancing technologies)

These are mainly technical requirements. Note that the software architecture must be able to handle various tariffs but itself cannot fulfil economic or sociographic requirements. The technical requirement of interoperability is the focus of this paper. Furthermore, we aim at using already existing infrastructure, especially for the near-term scenarios.

In the next step, actors were selected and revised. Although this project is European, actors were chosen based on the NISTIR 7628 Rev. 1 cybersecurity guidelines [2]. The benefit of this approach is the utilization of the according security guidelines in the following stages. Then, actors for the distribution grid were pre-selected after mapping these actors in the SGAM model [8]. Out of this pre-selected list, the final actors were selected manually, renamed, and adjusted to reflect the European counterparts and the intended purpose (e.g., customer premise display was changed to user interface to enable interactivity). As the project focuses on the addition of LECs, most actors located at the customer premises were kept while many specific actors from operations or distribution were removed.

The result of this process is shown in the conceptual model of Fig. 5. The envisaged system interacts with the following four Smart Grid domains as described in NISTIR: Distribution, Operations, Service Provider and Customer Premises. The conceptual model shows that the solution is a pure ICT solution: energy production and consumption are only influenced (i) directly by Operations (independently of the envisioned solution) or (ii) indirectly by changing the behaviour of the households in response to received information such as information about current or future tariffs. As interoperability and usage of established solutions are among the main goals, the Operations part contains the existing EDA platform (Energiewirtschaftlicher Datenaustausch) that handles the secure data exchange between utilities as well as between utilities and external customers.

Fig. 5
figure 5

Conceptual model showing that the envisioned solution purely focuses on ICT flows, whereby electrical flows are only influenced indirectly

Full size image

3.3 Modelling in UML

As a basis for later UML models a schematic overview of the system and its environment was created. Figure 6 illustrates this overview for an envisioned EV charging process. In short, the scenario shows, how forecasting provided by ECOSINT may be used in the optimization of charging patterns for the LEC’s EVs.

Fig. 6
figure 6

Schematic overview of the system and its environment for the EV charging scenario

Full size image

The EV charging process works as follows: Smart meter data that is provided by a household within a LEC may be used in conjunction with day-ahead prices for energy to control the charging of an electric vehicle (EV) connected to an intelligent charge point. This is achieved by aggregating the smart meter data of all households, which is already sent to the Distribution System Operators (DSO), within a LEC and then passing it to ECOSINT’s intelligent forecasting algorithms. The results of this forecasting (timeslots for EV charging optimized to use as much of the LEC’s self-produced energy as possible while taking grid-friendliness into account) are then sent to the intelligent charging point. In a first step, this information may be provided to the user alongside the day-ahead price for external energy to help them determine appropriate charging times for their EV. A more advanced scenario would then include fully automated systems based on the information provided by energy service providers and ECOSINT’s algorithms.

The next step in the overall process is the creation of a model using UML. It was decided to utilize use case diagrams and sequence diagrams to reflect the behaviour and component diagrams to visualize the structure of the modelled system. We start by showing the use case diagram in Fig. 7. The use case extends two currently existing use cases. The first existing use case is the metering use case where the LEC gets the metering data, i.e., the measured consumption and production values in 15-minute time resolution at the end of each day. In the other existing use case, an intelligent charging point acts on behalf of the user and tries to minimize the charging costs. In the extension, the envisioned solution forwards metering data to the intelligent charging point. Thereby, the car can be charged with the locally produced excess PV energy from the LEC, which in turn is beneficial to the grid. While only the EV charging process is shown here, it should be noted that an extended metering use case has also already been modelled. It provides data with higher granularity and in real-time via the customer interface of the smart meter, which would lead to more accurate and timely forecasts.

Fig. 7
figure 7

EV charging use case model

Full size image

The sequence diagram of the EV charging scenario is simple as it does not require any sophisticated interaction among the participants. To provide a more comprehensive sequence diagram, we instead show the diagram for the basic metering use case in Fig. 8, on which the EV charging use case relies. For the construction of the diagram, some internal actors of the DSO needed to be introduced: the data transmission process is initiated on a daily basis by the DSO, either by the Meter Data Management (MDM, typically located at the DSO premises) or by the Smart Meter Aggregator (typically located at the secondary substation). After the measurements have been aggregated, they are forwarded and stored at the MDM. The LEC can subsequently request and get the measurements using the already commonly used EDA platform for the transmission. In order to use the EDA platform, the LEC needs to be initially registered there beforehand.

Fig. 8
figure 8

Sequence diagram of the basic metering and data transmission use case on which the EV charging scenario relies

Full size image

4 Application of AIT VLab

4.1 AIT VLab

The AIT Virtual Lab (VLab) is a framework that consists of a methodology and a toolkit for support in developing smart grid solutions that can attain higher levels of interoperability. The framework advocates creating a shared understanding of both the problem and solution domains first so that the functional objectives of the solution can be aligned with the implementation needs. In this way, it also aids in closing the knowledge and comprehension gap between the teams responsible for requirements and implementation. System architects and developers, along with most other stakeholders, can equally benefit from the framework.

The main input to the framework is the specification of the solution described using a Microsoft Excel template. In the template, a solution-level data model is defined that is then shared among the individual modules when specifying the interfaces and the data models, in accordance with the interoperability meta-model shown in Fig. 1. This input is then processed with the toolset for the generation of virtual Docker-based environments with mock-ups and then can be used for prototyping, development, and/or integration testing.

4.2 Application of VLab framework for the EV charging process

The AIT VLab framework is used for creating a prototype for the EV charging use case described in Sect. 3 above. The virtual mock-up environment contains the modules for an EV controller, an intelligent charge point controller, a smart meter, a LEC service provider module, and an energy service provider module. Each of these components provides various REST APIs for interacting and triggering/executing the provided functionalities. Furthermore, each component is configured to emit PrometheusFootnote 1 measures that are then displayed using a GrafanaFootnote 2 dashboard. The generated virtual environment will be made available publicly on GitHubFootnote 3 and Docker HubFootnote 4 and can be executed by cloning the repository for experimentation, and analysis. The environment is extendable and can be adapted to suit the needs of another scenario, for example with multiple instances of some of the selected components (such as the EV controller). This capability further provides the possibility to use the environment for scalability and replicability analysis. Figure 9 describes the high level ECOSINT solution for energy communities. Parts that are involved in the EV charging process described above are highlighted in red and are currently in the process of being specified in detail using real-world scenarios.

Fig. 9
figure 9

Overview of VLab’s generated virtual test environment for ECOSINT-specific LEC use cases

Full size image

5 Conclusion and outlook

This paper shows the first results of developing a system architecture for LECs. They comprise the conceptual model and UML diagrams. Use case diagrams and sequence diagrams reflect the behaviour and component diagrams visualize the structure of the modelled system. These diagrams are shown for an exemplary EV charging scenario. It is demonstrated, how the envisaged solution should be built on and extend already existing infrastructure such as smart meters and the EDA platform. Interoperability, which has been identified as a core requirement during the creation of the concept, is achieved by employing the VLab framework.

Subsequently, it is planned to process an extended list of use cases, several of which will be modelled in more detail than the example presented here. Components and interfaces will be implemented in VLab, enabling seamless integration and interoperability.