1. Introduction
According to the European Environment Agency [
1], in 2017, the transportation sector was responsible for 27% of total greenhouse gas (GHG) emissions in Europe, of which road transport was responsible for almost 72% of total transport GHG emissions. Electric vehicles (EVs) enable the transition to less polluting transport. Another important aspect of EVs is their potential to interact with the electricity grid [
2]. Vehicle-to-Grid (V2G) mode is a kind of bidirectional energy exchange model in which plug-in hybrid electric vehicles (PHEVs) communicate with the power grid for the supply of demand response services, either by providing electricity to the grid or by limiting the charging rate of the vehicle. The large-scale application of V2G EVs brings a possible effect on the power grid [
3,
4,
5,
6,
7,
8]. The adoption of EVs as a distributed storage asset leads to a more decarbonized infrastructure, while the management of the charging process through time schedules and power profiles opens new opportunities to both EV owners and flexibility markets. Smart EV charging reduces the detrimental effect of EVs on the grid and assists in increasing the system’s efficiency in several ways. EVs can provide a variety of services to power systems through their V2G capability, including control of frequency [
9], control of voltage [
10], management of the peak load [
11], filling of the load profile valley [
12], and decrease in power losses [
13]. Furthermore, by charging during off-peak hours, when the amount of renewable energy is at its highest, and discharging during peak hours, EVs can successfully enhance the use of Renewable Energy Sources (RES) in the power grid [
14]. Moreover, the use of smart charging in EVs can lead to more decarbonized neighborhoods through the integration of RES from the energy mix or from renewable surpluses detected in the charging process. By providing flexibility, EVs can become a resource that can enhance the operation of the system, constituting an appealing benefit for the Distribution System Operator (DSO). With recent technological developments, new forms of local EV support can be developed, provided that an appropriate regulatory framework is established [
15].
One of the main challenges for the creation of an intelligent world, with concepts such as smart cities and smart grids, is the architectural design of the smart grid’s complex systems, considering the number of actors and systems involved [
16]. The Smart Grid Architecture Model (SGAM) [SG-CG/C] is a standard model used for technology-neutral analysis and mapping of smart grid use cases. The SGAM was delivered by EU Mandate M/490′s Reference Architecture working group [
17], and it has been realized not only in the power and energy sector but also in industrial automation, legislation, the automotive and maritime domain, smart cities, and software tools [
18]. For example, in the DISCERN project [
19], the SGAM was used to enable DSOs to analyze smart grid architectures, taking into account their business goals and any financial or legal restrictions. In the ELECTRA project [
20], a new real-time control concept was created in order to more effectively handle the huge integration of renewable generators and flexible loads. Based on the SGAM, the so-called Web-of-Cells (WoC) control architecture was developed for the use case modeling and the proof-of-concept testing of the WoC methodology.
In [
21], based on the SGAM approach, an ICT architecture was created to enable ancillary services in distributed renewable energy sources. The testbed was mapped to the SGAM model to demonstrate its contribution in analyzing many inter-operability examples. In [
22], the ERIGrid project aimed to improve testing and validation methods of innovative smart grid technologies. The Holistic Test Description (HTD) process, a formal process that guides the creation, documentation, and application of complex smart grid system-level test cases, is included in the works [
23,
24]. The SGAM and IEC 62259 use case approach inspired the development of the HTD process. In addition to the power and energy grids, the SGAM has been adopted in the industrial automation sector where the Reference Architecture Model for Industry 4.0 (RAMI), probably the most advanced derivative of the SGAM, aims to bring together different user perspectives and share a common knowledge of the relationship between Industry 4.0 components and solutions [
25]. The Maritime Architecture Framework (MAF) was also derived from the SGAM architecture model to overcome the challenge of harmonizing heterogeneous systems and integrating new methods into existing structures. As analyzed in [
26], the SGAM’s architectural methodology was applied to the MAF in order to manage the development of new systems considering technology issues, governance concerns, and users between existing maritime systems. The approach in [
27] implements the SGAM concepts to develop a Generic Smart City Architecture Model (GSCAM), introducing a new dimension called “Application Domain” that enables a holistic description of smart city systems.
The SGAM can be regarded as state-of-the-art for documenting high-level smart grid architectures, as it has been implemented successfully in numerous projects, particularly standardization. Nevertheless, since electromobility is a component of the overall smart grid, a more suitable fit to this domain can be accomplished by adjusting the SGAM framework and layers to the special needs of EV functions and services.
The objective of this paper is to analyze the potential implementation of electromobility as a distributed storage asset for the benefit of grid performance using as a foundation the Use Case Approach and the Smart Grid Architecture Model (SGAM) framework. The overall goal is to develop an open, secure, and flexible customer-centric architecture of the High-Level Use Case (HLUC) of e-mobility’s usage for the grid’s capacity optimization. More specifically, a specific Primary Use Case (PUC) scenario, booking a charge session in a mobile application, is mapped on the European SGAM framework. The methodology is evaluated in the framework of the TwinERGY project [
28]. The proposed architecture takes into consideration the local neighborhood transactions for energy delivery and other aggregated services. The SGAM methodology is implemented in diverse environments, based on the different use cases, detailed decomposition, and the profound understanding of their requirements to support the development of an architecture that will allow the optimal utilization of the interconnections in a scenario of high penetration of renewables, increased electrical vehicles presence, increased energy storage, and demand response campaigns. This study contributes to the optimization of e-mobility usage, developing an open and flexible user-centric architecture of the process of booking a charge session through a mobile application, taking into consideration the energy grid’s requirements and capacity restrictions. Considering the number of actors involved and the complexity of the actions that are executed during the process of booking a charging session, the results produced in this paper are valuable, as drivers are able to reserve the optimal available charging station according to their own needs.
The paper is structured into five sections.
Section 2 presents the general concepts of use cases and the SGAM framework; the proposed methodology is described in
Section 3, which is then applied in
Section 4 in the UC of grid capacity optimization utilizing e-mobility.
Section 5 highlights the results, while the main conclusions and an outlook on future work are presented in
Section 6.
2. Background
The methodology followed in this study is based on the Use Case Methodology defined in IEC 62559 Standard and the SGAM Framework. This section provides a description of these approaches.
2.1. Use Case Methodology
A common understanding of functionalities, actors, and processes among various technical committees or different organizations of complex systems is supported by the use case methodology. According to SyC Smart Energy [
29], smart systems call for cooperation between experts from several different domains (domain experts). SyC Smart Energy is an organization related to standardization in the domain of smart energy aiming to support systems-level standardization, coordination, and guidance in the smart grid and smart energy fields. Standards play an essential role in obtaining interoperable, safe, secure, and cost-effective solutions for their specification and design. Thus, a common cooperation platform, including a collaboration framework (terminology, quality guidelines, workflows, etc.) for involved stakeholders, is needed both in project development and standardization work. In the framework of energy systems, the Use Case Approach is identified as a template in the standard IEC 62559-2 [
30].
Building the use cases usually is based on a simple business case without any technical detail. Use cases are based on a description of business objectives in different levels of specificity, which can be divided into high-level, generic, specialized, or individual use cases. The distinction between these terms is based on the purpose and the author of the case and follows either a top-down or bottom-up approach. A high-level use case relates to an advanced and abstract function, but its actual technical application is not necessary from this perspective [
31].
2.2. Smart Grid Architecture Model (SGAM) Framework
The Smart Grid Coordination Group/Reference Architecture Working Group (SG-CG/RA) developed the SGAM in the context of the European Commission’s Standardisation Mandate M/490 (EU-M490) [
32]. The first version of the Smart Grid Reference Architecture was completed by EU-M490 for the smart grid with the European Telecommunications Standards Institute (ETSI), European Committee for Standardization (Comité Européen Normalisation—CEN), and the European Committee for Electrotechnical Standardization (CENELEC) in November 2012, including comments and suggestions for the development of the second version, in line with the SGAM architecture approach [
33]. The evolution of the Smart Grid Reference Architecture is presented below. An analysis of the SGAM Framework follows.
The Reference Architecture (RA) concept is used to provide an abstract schema of a standard architecture. In the world of Smart Grids (SG), many different models are employed to describe the different aspects of grid functionality and the involved stakeholders. The model’s developed processes should be dictated by strict rules to result in the production of simple models capable of describing the overall picture of an SG. Low-level details (e.g., different aspects of SG functionality or the architectural design) should also be provided by the model [
32]. The design process of SG-RA should be performed carefully in order to comply with already established standards. Consistency with the M/490 conceptual model is recommended, aiming at the production of a universal schema, able to provide a clear view of SG domains, zones, and layers and allow the participation of all stakeholders involved. The inclusion of the NIST Conceptual Model (NIST) [
34] is also important since it can cover most of the grid’s aspects of interest and decrease the complexity of different Use Case (UC) models. The NIST is a framework for discussing the characteristics, uses, requirements, and standards of an SG [
34]. It is based on three basic general concepts: loose coupling (enabling transactions without elaborate pre-arrangement), layered systems (a collection of functions offering services to the higher layer and taking from the lower layers), and shallow integration (not keeping knowledge of the managed configured components). In this framework, seven different domains are identified (Bulk Generation, Transmission, Distribution, Customers, Operations, Markets, and Service Providers).
Even though the NIST model has been quite useful over the years, lately, it cannot be characterized as a completely satisfactory modeling framework. This is due to the lack of discrimination mechanisms between the Distributed Energy Resources (DER), Bulk Generation, and Customers domains, each of which is accompanied by various economic and technical details. Regarding the DER domain, the introduction of prosumers has modified the classical production–consumption model, demanding the support of dynamic role switching. These modifications have been applied to the NIST model, creating the European Conceptual Model [
35]. The European Conceptual Model consists of four main domains, each of them containing subdomains associated with different actors and functions. The Operations domain includes system metering, transmission, and distribution operations, as well as the physical equipment involved (transformers, switches, transmission/distribution lines, etc.). In the Grid Users domain, the actors dealing with bulk generation, storage, and consumption of electricity are included (the DER subdomain is also included here). These two domains (Operations, Grid Users) address the more technical part of the system (generation and distribution of electricity and ICT actors). To describe the transaction processes of electricity produced and the services provided, two more domains are presented. Energy Services are actors responsible for the flexibility operations of the system, which would guarantee its total balance in terms of electricity, and secondly, within the Market domain are actors associated with the economical aspect of the grid [
36].
The SGAM Framework is an architectural structure that provides a safe and systematic way of modeling and analyzing different SG scenarios without disrupting the smooth operation of the individual processes [
32]. The role of the different actors involved can be clearly defined, while the outcome of the process should consist of an analytical model where UC details are depicted. While every UC can be analyzed from many different perspectives, the coherency of the whole process is guaranteed through tight and analytic communication flows between the different SGAM layers, zones, and domains.
Figure 1 presents the SGAM framework, which is thoroughly explained below.
While a UC scenario is being modeled, three main categories interoperate with each figureare also taken under consideration; the relationships between them are described in [
37]. Regarding the SGAM methodology, five different “levels” encapsulate the various functionalities associated with typical SG operational periods and are associated with the first dimension (1D) of the three-dimensional SGAM modeling framework [
35]. Starting from the lowest SGAM layer, the Component layer describes the physical layer of the grid, which includes the system equipment, protection infrastructure, and network devices. Next, the Communication layer describes the protocols and mechanisms used for information exchange between the model entities. The Information layer deals with the information objects and data models exchanged between UC actors/functions, followed by the Function layer, which refers to the UC’s different functionalities. Finally, the Business layer models the business logic of the UC scenarios through the involved market partners, business objectives, goals, and restrictions. This last layer comes with a great degree of peculiarity. As a result, this model complies with already existing standards that allow the proper mapping of roles and actors, as well as their interactions.
The Harmonized Electricity Market Role Model (HEM-RM) by ENTSO-E [
38], EFET [
39], and ebIX [
40] seems like a very promising candidate since it can fit in all European electricity markets. During this step, using the HEM-RM of ENTSO-E, EFET, and ebIX is strongly recommended in order to model each UC scenario properly, as it helps market participants from different countries communicate using a common name for each role and associated object within the European electricity market information exchange. It also emphasizes creating a standard language information exchange supported by IT. The SGAM layers are merged with a two-dimensional plane to the final, complete structure of the framework. The SG plane could be described as a double-axis area: electrical processes (domains) and the information management viewpoints (zones) involved in each UC. In terms of the domains, firstly, the Bulk Generation domain refers to the substantial generation of electricity. This is followed by the Transmission domain, which involves the complete infrastructure and organization processes for the transportation of the energy produced. The DER domain is differentiated from the Distribution domain since the former refers to the DER connected to the distribution grid (3 kW–10,000 kW). Finally, the Customer Premises refers to the prosumers involved in the UC. Hierarchically, there are six zones in the smart grid plane, designed to support the framework coherency by following a similar conceptual pattern. The first zone, known as the Process zone, refers to the transformation of energy and the physical equipment involved. Next comes the Field zone (protection, control, and monitor equipment), followed by the Station zone, succeeded in turn by the Operation zone (control of operating systems). Moving on to the business aspect of a UC, the Enterprise and Market zones refer to the commercialization of the total amount of electricity produced and distributed. The SGAM framework is a combination of the concept of interoperability layers and the smart grid plane. This merger results in a model which spans three different dimensions: (1) Domain, (2) Interoperability (layer), (3) Zone.
Regarding the more practical aspect of the modeling process, UC incorporation into the SGAM framework is actualized through the SGAM Toolbox [
41]. This useful tool provides a simple and structured way of combining the available information to extract a unified model, distributed to the different parts of the framework. There are three basic components that are aggregated into the SGAM Toolbox: the SGAM MDG Technology (connected to Enterprise Architect to provide additional toolboxes, UML profiles, and other modeling resources), the SGAM Model Templates (UC analysis and SGAM layers), and the SGAM Reference Data (providing information regarding the model import/export). The core component of the framework, the SGAM Metamodel, is aggregated to the MDG Technologies, which is the basis of the Model Templates.
The different components (protection devices, cable lines, ICT-associated components, etc.) are presented in the Component layer. These components need to interoperate with each other while complying with the standards and specific protocols of the market. The Communication layer takes care of these procedures, providing an intermediate stage where the components’ behavior is transformed into information that the actors and functions can use. In the Information layer, the objects are defined through data models allowing the information to flow to the level above. The objects designed at this stage are used to compose the Primary Use Case (PUC) scenarios, which are called the High-Level Use Case (HLUC) in the Function layer. Furthermore, at this stage, a general description of the actors and the roles involved is also provided. It is worth mentioning that a PUC is composed of a number of different Secondary Use Cases (SUC). Moving on to the Business layer, HLUCs are requested by the Business case, involving the actors necessary to realize the business goals that have been defined.
3. Materials and Methods
This section describes the methodology followed during the execution of the TwinERGY project; an example is given in
Section 4. Implementation. The methodology is based on the SGAM development process [
17], and a high-level point of view of this methodology is represented in
Figure 2. The transformation of the PUC scenario into objects compatible with the SGAM Toolbox was also necessary. In order to initially develop the SGAM, a system analysis phase was performed. The PUC was examined so that the information needed (objectives, PUC diagram, actors, type, preconditions, assumptions, steps, information exchanged, requirement) was present. This phase resulted in the elaboration of a Computation Independent Model (CIM), which focuses on the desired behavior and function of the system without describing how the system is implemented. This was followed by the elaboration of the system architecture phase, in which the rest of the SGAM layers (Information, Communication, Component) were produced. This resulted in a Platform Independent Model (PIM), which aims to define major function blocks without relating them to a concrete implementation. After the creation of these two models, the last step in the SGAM creation was the design and implementation phase, where the systems were designed using engineering methods. In this stage, both a Platform Specific Model (PSM) and a Platform Specific Implementation (PSI) were produced. The PSM describes the design for the specific components in relation to the selected platform, while the PSI depicts the implementation itself [
42].
Specifically, the Use Case Mapping Process goes from the mapping of project objectives into Business and High-Level Use Cases (BUCs and HLUCs) to the description of each element defined in the different SGAM layers. One consideration in the methodology is that we do not complete each layer by their natural order but rather based on the detail we have in each moment, as the information is interdependent. A second consideration is that the layers are not composed in a sequential way but in different refinements and loops.
As a starting point, each project objective is analyzed, discovering logical actors and business goals for each of them, and this information is the basis for the definition of the BUCs and their decomposition into HLUCs. The HLUCs are also decomposed into Primary Use Cases (PUCs), which are also decomposed into Secondary Use Cases (SUCs) if needed. Moreover, each HLUC, PUC, and SUC is completely described in a document that contains information such as scope, actors, objectives, and a narrative of the UC. These actions are implemented in the Business layer. After that, and considering the information described, each UC is represented in a diagram belonging to the Component layer. Components are placed in a position related to their domain and zone, and they are related to each other with links indicating the technology of communication. For instance, a domestic environmental sensor should be placed in cell “Process-Customer Premise”, and it could be connected to its controller through a physical connection, while a database server could be in cell “Operation-DER” and connected to an external application through the internet (a virtual link).
Once all UCs are represented in a component layer diagram, the next step is to define the protocols of communication used in virtual links. This is done in the Communication layer. A similar schema to the previous one is produced, representing the links with those protocols. By protocols of communication, we mean HTTPS, MQTT, and so on. The following step is the representation of the scope of each UC and its relationship with the logical actors defined previously in the Business layer. This is represented in diagrams belonging to the Function layer. By scope, we refer to the cells occupied by the components involved in the UC. On the other side, logical actors are placed in the correct cell of the diagram. For instance, a Distribution System Operator should be placed in the cell “Enterprise-Distribution”. As it can be deduced, this step cannot be performed before defining the Component and Communication layers.
After this, we develop the Information layer, where each UC is represented in several diagrams indicating the set of interchanged data (information objects) and messages sent through links described in previous layers. Finally, we return to the Business layer in order to generate two more diagrams per each UC: sequence and activity. The activity diagram represents the actions followed and the information object generated per each action in block notation. The sequence diagram is the classic representation of events, actions, and messages interchanged used in computer science.
The next section depicts the methodology of the SGAM applied within the TwinERGY project for the HLUC of “Electromobility as a distributed storage asset in the benefit of the energy grid”. Considering that there are several PUC scenarios that could be analyzed, in the framework of this paper, the booking of a charge session in a mobile application constitutes the PUC scenario, while SUCs are not applicable in this case. In order to proceed with the PUC incorporation into the SGAM framework, the SGAM Toolbox was used. Diagrams were created using the software Sparx Enterprise Architecture [
43]. This tool facilitated the representations of the diagrams as well as exported information to images.
4. Implementation
The use case and SGAM methodologies are implemented to model the architecture of a specific scenario (PUC scenario), which aims to enhance the grid’s capacity utilizing e-mobility (HLUC). There are other PUC scenarios that can be analyzed which are outside the scope of this work, such as smart charging to follow grid requests, smart charging to maximize RES integration (green electricity), smart charging to minimize charge costs, and smart charging to minimize the time of charge.
To carry out this purpose, the following electromobility aspects are considered for this HLUC:
EV batteries as a distributed asset to offer ancillary services to the DSO (Congestion and Voltage Management) through the integration by V2G connection;
A smart charging scheme for EV owners from which EV charging could focus on the use of green energy (both from the renewable sources in the energy mix or from the renewable surpluses from renewable generating assets) and minimizing the costs of the charging sessions;
EV batteries for participation in flexible energy markets using demand response campaigns;
Smart charging profiles to generate charging curves for EVs that would lead to the integration of RES, helping the decarbonization of neighborhoods.
The actors and roles involved in this HLUC and taken into account are Aggregator, Retailer, Distributed System Operator (DSO), MV/LV End Consumers/Prosumers, Electric vehicle driver (EV driver), Electric Vehicle Supply Equipment operator or charging stations operator (EVSE operator), Public Authorities, and VPP operator.
4.1. Primary Use Case (PUC) Description
The process of booking a charge session through a mobile application (PUC) starts when a user wants to charge his/her vehicle in a nearby station [
44]. This mobile application enables drivers to book charge points, manage their data, and receive suggestions about where it is better to charge their vehicles. The user can directly manage the application without an account, and he/she can view a map with available EV charging stations and some basic information about them. Only free stations with a charger compatible with the vehicle and closer than the user-marked distance are included in the list of shown stations. The steps to complete this are as follows:
1. In a mobile application, the user introduces the vehicle identifier and selects a station with free charging points (CP);
1.1. The backend loads the request and sends a petition of “Lock” to the Charging Point Operator (CPO);
1.2.1. The TwinEV backend creates an identifier for the reservation;
1.2.2. The CPO locks the charging point as a consequence of the request to charge;
1.3. The TwinEV backend confirms to the user throughout the mobile application the confirmation of that reservation;
1.4. The user is able to confirm that the reservation has been successfully completed.
In case of an error, the interface shows an error message.
2. The driver drives the EV to the charging point. If the driver does not drive to the charging point, the CPO unlocks the charging point after a defined time period (15 min).
3. The process of charging starts, so the CPO unlocks the charging point;
3.1. The charging point receives the information from the reservation process;
3.2. This data is provided to the TwinEV backend;
4.2. The TwinEV backend calculates the optimal curve that the charging point follows, taking into account the mode of charging, the desired time, and the target State of Charge (SoC);
4.3. The charging pattern is communicated to the charging point;
4.3.1. The electric vehicle receives the energy flow from the charging point;
4.4. At the same time, the CPO has access to the optimal charging curve;
4.5. The charging curve is displayed on the mobile application;
4.6. The user has access to visualize the life status of its charging process;
4.7. When the electric vehicle achieves the target SoC, the charging session ends. The TwinEV backend communicates it to the charging point and the electric vehicle;
4.8. The end of the charging session is also communicated to the mobile application, which the user can see displayed on the mobile application.
Figure 3 shows the flow of actions for a charge session from the moment the user books a charge point, as described above.
4.2. SGAM Layers
This section describes the different SGAM layers of the PUC scenario.
4.2.1. SGAM Business Layer
The SGAM Business layer analysis is produced at a higher level, taking into account the HLUC “Grid capacity optimization utilizing e-mobility”. Several project objectives are linked to the HLUC’s purpose. Overall, the Business layer accomplishes introducing residential energy consumers as active players, providing them with intelligence to integrate with the systems in order to safeguard local flexibility markets and enhance the grid distribution reliability and its transition to a more fossil-free energy future.
Figure 4 describes the SGAM Business layer of the HLUC.
4.2.2. SGAM Component Layer
The simplified technical display of the software and hardware components for this PUC is located in the SGAM Component layer of the PUC scenario. The user input is introduced directly via the TwinEV module, using the developed TwinEV Graphical User Interface (GUI), which centralizes the inputs for the user. The TwinEV module backend compiles these requirements, which are transferred to the Charging Point Operator (CPO) through the CPO gateway. The CPO sends the control to the charging point, which allows the electric vehicle to receive its charge. The hardware and software elements that participate in the PUC scenario are (1) Electric Vehicle, (2) Charging Point, (3) Charging Point Operator, (4) Charging Point Operator Gateway, (5) TwinEV Module, and (6) TwinEV GUI.
4.2.3. SGAM Communication Layer
The link between the TwinEV Graphical User Interface and the electric vehicle is shown in the SGAM Communication layer of the PUC scenario. Two different communication types are identified in the figure, Physical Connections (marked in red) and Wireless Connections (marked in green). The protocol that is expected to support depends on the interface that the smart appliance produces. In order for the TwinEV GUI to communicate with its backend, it uses HTTPS protocol to exchange variables as required for the setpoint. The charging point operator gateways communicate with the TwinEV module through the OCPP 2.0 Protocol [
45]. Internally, the CPO gateway communicates with the CPO through the IEEE 802.5 protocol. The charging point operator actuates on the charging point via an electrical connection. The connection to the electric vehicle is carried out in the same manner. The communication technologies involved in the PUC scenario are:
IEEE 802.3: IEEE defines standards for local area networks (LAN), personal area networks (PAN), and metropolitan area networks (MAN) [
46];
OCPP 2.0: The Open Charge Point Protocol is the protocol used for communication between the electric vehicles, the charging sessions, and the central management system;
HTTPS: HyperText Transfer Protocol Secure. This is an extension of the Hypertext Transfer Protocol (HTTP), which ensures safe communication over a computer network. HTTPS protocol encrypts communication using Transport Layer Security (TLS), formerly known as Secure Sockets Layer (SSL). As a result, the protocol is also mentioned as HTTP over TLS or HTTP over SSL.
4.2.4. SGAM Function Layer
The overall goal of this PUC is to allow a charging session. While booking a charging session, it refers to the process of locking a charging point in a station during the time the user charges his/her vehicle. First, the EV owner needs to search for a station in which he/she can charge their vehicle. The search is performed through the TwinERGY interface dedicated to it, the TwinEV Module. The backend loads the request and sends the petition of “locking” to the Charging Point Operator (CPO). The driver takes the EV to the charging point, where the charging process starts. This functional decomposition of the system appears in the SGAM Function layer of the PUC scenario. The actors involved in the PUC scenario are:
Charging Point, which is a device;
eVehicle, which is a device;
Charging Point Operator, which is an organization;
EV Owner, which is a logical actor;
TwinEV Module, which is an application.
4.2.5. SGAM Information Layer
The communications links presented in this PUC are placed in three different sections of the infrastructure: the communication between the user and the system, the internal communication within the system, and the communication from the system to the electric vehicle. From the Information layer’s perspective, the message exchanged between the user and the system is modeled as an information object. The user and the system communicate the request for the reservation and its confirmation. The internal communication within the system produces the charging point locking order and the result. Finally, the communication from the system to the electric vehicle is physically connected.
Figure 5 presents the SGAM Component, Communication, Function, and Information layers of the PUC scenario.
The data entities and relationships present in this PUC can be expressed in the simplest form. The data models of the PUC scenario are (1) the TwinEV Bookings Data Model and (2) the Standard and Information Object Mapping Data Model. Within these two Canonical Data Models, the communication links are located. The Bookings Data Model includes the communication between the user and the system. The Standard and Information Object Mapping Data Model includes the internal communication within the system as well as the communication from the system to the electric vehicle.
The interlinkage of the communication links and the data models, already described in previous sections of this work, are described in
Figure 6. The Information objects of the PUC scenario are:
Charging Point reservation result;
Charging Point reservation confirmation;
Charging Point Locking;
Charging Point Locking result.
The data models of the PUC scenario are:
TwinEV Bookings Data model;
OCPP Data Model.
Figure 6.
SGAM Standards and Information Object Mapping in the PUC scenario.
Figure 6.
SGAM Standards and Information Object Mapping in the PUC scenario.
The functional steps to achieve the PUC scenario are related to the information objects exchanged in the PUC. Activity diagrams are used to dynamically model software components such as operations, procedures, and functions for systems and processes. They also easily depict sequential and concurrent activities, the causes of a particular event, and the control flow from a start point to a completion point while displaying the numerous decision pathways that are available during the execution of the activity [
47]. The activity diagram illustrates the flow of control in a system and describes the functional steps to achieve the PUC. As an extra value, this diagram adds the information objects previously defined. The functional steps are related to the information objects exchanged in the PUC. The activity diagram defines the functional steps of the PUC, from the request of the reservation through the TwinEV module to the sending of the reservation results to the EV owner.
As a further step of the activity diagram, it can be complemented with the different actors involved in the PUC to create a sequence diagram. Sequence diagrams are used to visualize how messages and tasks move between objects and components in a system and to comprehend the specific functioning of present or future systems. They also show the relationships between the objects as well as the sequence in which these relationships occur [
48]. The sequence diagram, shows the details of who is communicating with whom, as well as the information and functionality that is being introduced and developed.
Figure 7a,b show the activity and sequence diagrams.
5. Results
The methodology proposed in this article was evaluated in the context of the TwinERGY project. The Use Case and SGAM approaches were applied to analyze the architecture of the potential implementation of electromobility as a distributed storage asset for grid capacity optimization. The specific use case scenario of booking a charge session through a mobile application was mapped into the SGAM model, and the benefits were analyzed. The SGAM was used to analyze the use case scenario and describe the activities involved in the process of booking a charge session. The steps and the interaction of actors and information systems were also defined with respect to the requirements of the use case scenario. The SGAM also provided the graphical structure and visual representation of the use case, which is a three-dimensional model comprised of zones, domains, and interoperability layers.
The Use Case and SGAM methodologies provide a description of aspects that would not be possible to be considered in another approximation. As an outcome of the information modeled and analyzed through the SGAM modeling, a set of different information objects, assets, protocols, and actors were identified. More specifically, as presented in
Section 4., Implementation, the following have been defined:
Elements that participate in the booking of a charge point: actors, electromobility modules, external modules, physical devices, and gateways;
The flow of actions that are going to be executed during the PUC;
Messages interchanged;
Data generated.
The SGAM model proved to be a useful solution in the development of system architecture in a canonical and standardized manner. The information produced is valuable not only for the implementation but also during the testing and validation phase of the system. The SGAM constitutes a structured basis for the architectural design of different smart grid complex systems and the evaluation of new solutions/technologies considering the number of actors and systems involved.
Due to the complexity of modern electrical power networks, it is essential to use suitable methods and procedures to manage the architectures of different layers from different stakeholders’ points of view. Among the various conceptual models, the SGAM is one of the most appropriate for methodical smart grid architecture development, as it combines use case management, visualization, and interoperable systems and provides a set of concepts and methods for precise modeling, analysis, and design. It depicts a variety of interconnected aspects of smart grid architectures, such as information, and facilitates the identification and management of elements on different levels through its organized set of perspectives. Additionally, its perspectives help to identify interoperability problems and enhance the awareness of interconnected aspects.
It may be difficult to compare solutions for various smart grid systems, and performance indicators may not be able to be correctly evaluated at the system level and determine the necessary intelligence. To facilitate such a necessary assessment, the SGAM acts as a common language to describe the functionality and facilitate the performance assessment of the smart grid.
The SGAM methodology provides a quick, clear output and a thorough overview of the potential scalability of the proposed solution, making it easily replicable to other use case scenarios. It enables the identification of crucial specifications for brand-new elements that could be integrated into existing systems in order to implement a new solution. Additionally, it involves each of the actors in the defined solution, encouraging collaboration and raising internal and external awareness of all actors, as they are all part of the analysis hypotheses and prerequisites.
6. Conclusions and Future Work
This work presents the SGAM as a standardized, recognized way to analyze smart grid architectures, introducing electromobility aspects and, specifically, focusing on booking a charge session. The use case approach outlined in the IEC TC8 62559 standard and the SGAM framework developed by the EU Mandate M/490’s Reference Architecture working group serve as the foundation of the methodology. The proposed methodology was implemented and evaluated in the framework of the TwinERGY project. This approach could be further implemented in real life through the application and study of the HLUC “Grid capacity optimisation utilizing e-mobility” in two of the TwinERGY project’s pilot sites, Athens in Greece and Hagedorn Village in Germany.
EVs could be analyzed as a distributed storage asset for grid purposes. EV smart charging, in collaboration with a V2G connection, could allow the grid to stabilize through the integration of RES and the possibility of participating in energy-flexible markets. Additionally, smart charging could benefit EV users in terms of economic performance by reducing energy costs when charging and through scheduling their charging sessions. EVs as a distributed storage asset could also have an influence on the performance of Distributed System Operators (DSO). Batteries could help these entities in congestion and voltage management, taking advantage of the flexibility that batteries can provide when they are connected through V2G connectors in charging points. In addition, the use of smart charging in EVs could lead to more decarbonized neighborhoods through the integration of RES from the energy mix or from renewable surpluses detected in the charging process.