<figure><img src="image_1.png" /></figure>

HAL
open science

# Systems Engineering for Assessment of Virtual Power System Implementations

Slobodan Lukovic, Igor Kaitovic

► To cite this version:

Slobodan Lukovic, Igor Kaitovic. Systems Engineering for Assessment of Virtual Power System Implementations. 9th Artificial Intelligence Applications and Innovations (AIAI), Sep 2013, Paphos, Greece. pp.667-676, 10.1007/978-3-642-41142-7_67. hal-01459659

HAL Id: hal-01459659

https://inria.hal.science/hal-01459659

Submitted on 7 Feb 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Systems Engineering for Assessment of Virtual Power System Implementations

Slobodan Lukovic, Igor Kaitovic

University of Lugano – Faculty of Informatics – AlaRI

e-mail: {slobodan.lukovic, igor.kaitovic} @usi.ch

**Abstract.** In this work we present an adoption of systems engineering methodology for design and assessment of a Virtual Power System (VPS). The VPS has been defined as an aggregation of distributed energy resources, consumers and storages which can operate autonomously, and is presented to the power system as a single unit in technical and commercial terms. The complexity of these critical systems is tackled by means of systems engineering. We have applied our approach in scope of a research project AlpEnergy.

**Keywords:** systems engineering, modeling; SysML; VPS; assessment

## 1 Introduction and Background

In the present work based on achieved results in the course of the international AlpEnergy project we provide description of a methodology used for design, implementation and assessment of Virtual Power System (VPS). VPS integrates, manages and controls distributed energy generators, electrical vehicles (and other controllable loads) and storage capacities and links their technical operation to the demand of consumers and the energy market. Detailed VPS description providing basic definitions and explanation of the concept is presented in [12,14].

One of the main challenges of the project is considered to be tackling of multidisciplinary nature of VPS concept and developing of a model of the supporting ICT structures which are crucial to critical infrastructures. Moreover, an evaluation strategy for pilot implementations was supposed to be developed. To cope with the challenge we have adopted systems engineering methodology already proven as a very efficient instrument to tackle complexity of different heterogeneous systems and different technical backgrounds of stakeholders [8]. The methodology is based on instruments provided by SysML modeling language - widely accepted UML profile for modeling of complex heterogeneous systems. The methodology is presented in details in [1], [13] while similar approach is also applied in [3]. In this work we focus on assessment of different project implementations showing how proposed methodology can be used for that purpose.

VPS concept supposes a flexible structure that embraces widest set of technical and commercial issues. Furthermore, VPS model has to absorb all the changes and adaptations in the system and its environment and for that reason has to be constantly
updated depending on the newly identified stakeholders or requirements as well as
results obtained from results provided by pilot implementations.

VPS design, involves many stakeholders that are not ICT (Information and Com-
munication Technologies) experts. For that reason it was necessary to propose a rather
simple, easy to explain - communication and system design strategy. Therefore, we
adopted systems engineering methodology, still capable of coping with dynamic
model changes [13]. Moreover, the same methodology has to take into account par-
ticularities of project and be able to embrace various VPS requirements, results and
particularities of implementations from different partners. The main benefit the meth-
odology brings is that it supposes an interactive and not a straight-forward process of
system design and that is fully open to changes and upgrades that are inevitable in
project development. The ultimate result of the methodology application to the VPS is
a reference architecture that is later used for assessment of specific implementations.

## 2 General Approaches and methodologies

The first step of the methodology represents context description. It refers to unambig-
uous definition of system environment in terms of surrounding systems and their rela-
tions to the designed system. By correlating information from relevant research pro-
jects [2-5] we managed to identify existing and foreseen future stakeholders as well as
system context in terms of surrounding systems as well as VPS itself.

A full set of identified stakeholders, includes individuals and organizations: Dis-
tribution System Operator (DSO), Electricity retailers, Energy Exchange Stock, Ener-
gy market legislation, Local authorities, Equipment producers, VPS shareholders,
consumers (i.e. Residential users, Industrial users etc.),as detailed in [13]. Still, as
already stated, additional stakeholders could emerge in the future. Moreover, some of
the stakeholders identified above are foreseen to just appear or to drastically change in
the future (e.g. Energy Exchange Stock). Such changes would consequently trigger
additional changes in system requirements and models proposed.

Requirements engineering that includes collecting, tracing, analyzing, qualifying
and managing user requirements constitutes the next stage of the system design. The
main purpose of this phase is the efficient extraction of system requirements and their
refinement trough use cases that are latter traced to specific components.

For each user requirement collected from stakeholders (or in particular case from
some of the project partners), a set of system requirements has been derived. The
same set of system requirements has been mapped to use cases describing system
functionalities and services that are finally traced to one or a group of system compo-
nents [13]. A conceptual (i.e. general abstract) system model of VPS is supposed to
serve as an intermediate step for better orientation in development of reference model
(as shown in [11]). The next step represents behavioral modeling of each system func-
tionality presented through use cases and assumed set of components [4]. Interaction
based behavioral models are presented by means of sequence diagrams. While pro-
gressing with behavioral models of system functionalities, system structure changes in
terms of inserting additional components or changing their roles. In some cases, struc-
tural change will induce additional behavioral changes. The outcome of this step is set of consistent structural and behavioral models. It is important to notice that these of models are developed in parallel and they impact and complement each other. Based on these models methodology finally yields reference model.

Being flexible and iterative, methodology described can be used in different stages of project development. That makes it suitable for the application to the research projects such as VPS design is. Since not all stakeholders are known at the moment (e.g. energy market), some requirements are tailored to project goals and realistic assumptions.

## 3 VPS requirements and use cases definition

Having stakeholders identified, requirements engineering phase starts by collecting user requirements from them. Once initial set of user requirements has been obtained, initial abstract model of the system has to be defined. This refers to identification of components, so that system requirements related with components and their interaction can be identified. For each user requirement separate sequence diagram has been developed representing the way that requirement can be satisfied through interaction of initially assumed VPS system components and surrounding systems. While focusing on functional ones, we have carefully collected and organized user requirements in three packages representing communication, commercial and technical requirements. For each interaction that appear among VPS and surrounding systems as well as so far identified internal components, system requirement is defined. Each user requirement has been mapped to one or more use cases describing VPS functionalities (as detailed in [13]). As the system modeling progress, set of system components could change, and those sequence diagrams could be re-engineered after validation.

Applying the same principle to all other user requirements, the final set of system requirements has been derived. In fact, user requirements are mapped into system ones. The definition of use cases initiates behavioral modeling of the system. Use cases development is based on system requirements, through grouping and refinement process. A few basic use cases, describing the main functionalities of the VPS are defined at first and related with the actors and internal components involved in operations they describe. While defining those main use cases relating them with actors, major user requirements were taken into account (as shown in [11]). This marks the starting point for understanding the system functionalities. Each stakeholder can identify use cases that he is interested in, and latter follow decomposition only of these use cases, unburden from the functionalities of the rest of the system. So, managing system complexity is done through its functional and hierarchical decomposition.

### 3.1 Use-cases decomposition

Each of the major use cases is further decomposed through more fain-grained diagrams with atomic use cases directly traced (i.e. related) to system requirements. Still, further extension of all diagrams is possible and even expected with project evolution
as new requirements could evolve. The model represents a result of an iterative pro-
cess taking place during entire course of the project. As an demonstrator of the further
steps of the methodology we focus on energy trading scenario (i.e. use case) which
implies external and internal contracting. In later steps these use cases will be elabo-
rated in details. Use cases are related by proper requirements as shown in the figure.

Applying a comprehensive approach based on initial findings on system function-
alities and composition (coming from related projects and knowledge of the project
partners) a general abstract model of the VPS has been developed as an intermediate
modeling result (see [11]). It defines initial set of components and their interactions
and serves for orientation in further phases of the modeling methodology.

## 3.2 Basic system components

Brief description of the main components in the model is given in the following:

* Control Center are manages the system assuring the power quality.

* Advanced Measuring Infrastructure (AMI) goes way beyond consumption metering and includes measuring of additional parameters and their collecting

* Actuating Embedded Systems (AES) are extending the SCADA functionali-
ties and directly control field devices (smart load, DER or storage).

* *Trading Agent* is envisioned as component that handles all the commercial issues of the VPS including biding, energy selling etc.

* *VPS operation manager* is the brain of the system that manages energy bal-
ance, verifies the feasibility of predicted production, etc.

Different kinds of scenarios (i.e. use cases) have been developed. In order to show
effectiveness of the approach, we use an example of energy trading. Energy trading
for AlpEnergy VPS considers ‘day-ahead’ market contracting and it may concern
amount and prices of bulk energy, ancillary services and so forth. This major use case
has been decomposed in two phases (i.e. sub-cases): External contracting- negotia-
tion between SmartGrid; Internal contracting - negotiation - between VPS and its
clients. We will show main actors and describe their interaction in the following.

3.3 External and internal trade contracting

Basically the process starts by a request from the VPS manager (which keeps portfo-
lio with preferences and statistics of all VPS consumers and producers) to the Smart
Grid for obtaining the energy price. The trading agent of VPS communicates with the
AMI and the predictions manager for current meter data and energy balance predic-
tions, respectively, in order to verify affordability of the contract (e.g. offered price
and amount of energy) obtained from the Smart Grid. Eventually, negotiation takes
place between the VPS manager and Smart Grid and the process iterates until an op-
timal price is reached. The sequence diagram describing this process is given in Fig.1.

Ones the contract is set at the level of entire VPS it is also necessary to negotiate
in the context of local contracts (for each VPS member in particular). In this case VPS
manager requests from the tariff manager to calculate the dynamic prices for each
individual consumer (or producer). AMI and predictions manager are contacted again
to check current and expected energy balance in the system and per each VPS member. Demand Side Management (DSM) is involved to customize offers for each VPS member individually based on their statistics and portfolios. The price is then negotiated with the local energy manage (LEM - which is a component assigned to each member of VPS), since the price in this case is a local (i.e. internal VPS matter), rather than external. The sequence diagram in Fig. 1 (on the right) describes the process.

<figure><img src="image_3.png" /><figcaption>Fig. 1. – Internal and external contracting</figcaption></figure>

## 4 Structural VPS model.

Applying the methodology, we continue with defining system behavior and structure needed for achieving each of the use cases previously defined. For each VPS functionalities/use case a specific sequence diagram has been derived describing how particular use case can be satisfied through interaction of various components. Initially each component has some predefined set of functionalities that is being extended and additionally defined through each sequence diagram. Basics of behavioral model of the system are set in the previous Section where sequence diagrams were given (Fig. 4 and 5) denoting information flow.

Starting from the general abstract model defined as a tentative system structure at early phase of the project and iteratively improving it through new findings from developed use cases we build a set of main VPS components together with identified functionalities.

Eventually we present simplified VPS internal block diagram providing details about information flow between components which facilitates defining the communication standard inside VPS. With a clear identification of components and its functionalities, same methodology described here can be used for deriving further fine-grain model of the components. It should be noted that model presented is derived from the requirements of AlpEnergy project while considering contemporary results of other relevant projects as well [2-4]. Thus, with additional upgrades, it can be used as a reference point for other similar projects dealing with Smart Grid aggregations.
## 4.1 Building reference model

General, abstract model of proposed ICT supporting structure for VPS (given in [11]) has been developed according to existing state-of-the-art solutions and inputs coming from different pilot implementations. The model is a result of discussions among all the partners and wide compromise about all its elements has been achieved. The later findings obtained through described systems engineering process have resulted in VPS structural models. As a very next step in the project a reference model of VPS ICT structure has been built. It is used as a central point of the AlpEnergy project and it is considered to be one of its main achievements as it elaborates the result of mutual efforts and gives an overview on the system infrastructure.

The reference model shown in Fig.1 is intended to be a starting point for ICT assessment process. It represents a suggested solution that would also serve as a reference for evaluation of all pilot implementations. Apart of that, as a visual description, it can assist project dissemination activities as it has been made to be general, comprehensive and understandable using the widely accepted SysML modeling language.

The reference model has been adopted to identified specific requirements of AlpEnergy and regularly upgraded according to proven solutions coming from exact pilot implementations. As lighthouse guidelines for abstract model we have considered solutions provided by related relevant international projects like [2-4], respectable international institutions and initiatives [5] and also cutting-edge research achievements [6,7]. The basic abstract model developed from such a theoretical approach is developed in SysML modeling language, it represents an intermediate step.

Still such a model served just for orientation and provided good guidelines for other phases of the project development. The input from existing pilot implementations and experiences gained in field testing are another precious source of information needed for development of the precise reference model. We interviewed AlpEnergy implementing partners and studied their technical documentation. Nevertheless, without an unified describing method and in absence of defined mutual understanding platform for VPS design we faced many problems in extracting technical details from available informal descriptions.

## 4.2 System composition

It is possible to notice, from these figures, basic similarities and differences in VPS design from one to another case. Nevertheless, the lack of unified and standardized description method aggravates communication, knowledge and best practice transfer, and at the same time assessment process. Therefore, the need for establishing common mutual describing instrument is quite obvious.

As already stated we have approached the problem using System Engineering methodologies based on SysML modeling language that has been developed during the project and described in previous annual reports and publications [10,11]. Finally bringing all together, abstract model and selected best-practice implemented solutions, the reference model has been built. The working version of the model has been reconsidered by the partners several times (according to Systems Engineering practice
[8]) and eventually the VPS reference model in Fig. 7 has been obtained as the recommended optimal solution accepted by entire AlpEnergy consortium.

<figure><img src="image_4.png" /><figcaption>Fig. 2. – VPS ICT infrastructure – general reference model</figcaption></figure>

The entire ICT structure of VPS is logically encapsulated in three groups represented in reference model in form of three layers: Power Systems Management Applications (Control Center), Communication and Data Acquisition Field Devices.
Each of these layers represents a functional block in VPS design (note that func-
tionalities that are grayed out are deemed optional in VPS operation). Considering the
model in Fig. 2, it should be noted that it considers even foreseen future scenarios
(e.g. deregulated energy market that requires trading functionalities) which results in
components that are considered but not yet implemented (given in blue color). In the
following we explain structure and certain components of the model in greater detail:

**Control Center (CC):** is responsible of controlling and managing various VPS operations, both commercially and technically related. The heart of CC represents VPS Manager composed of different components performing specific functionalities of VPS Manager. It acts as the VPS interface with the Smart Grid, as well as coordination unit among various specific subunits. From the commercial perspective, the *Trading Agent* component performs energy price negotiations and contracting with the appropriate counterpart in Smart Grid. Efficient negotiation process requires precise information on current and predicted grid balance (Trading Agent obtains this information from the appropriate components of the VPS). Once the compromise is reached the contract valid for certain period of time is made. This process is described using *use case* and *sequence diagram* given in Fig. 4. Upon achieving of external pricing contract (between VPS i.e. Trading Agent and the rest of Smart Grid) the predicted energy balance is then used as an input for the *Tariff Manager* that calculates the internal energy prices separately for each aggregated VPS user (consumer, producer or prosumer) based on another input coming from *Demand Side Management* (DSM) component. The DSM based on statistics, predictions, system balance and user portfolios provides customers with tailored incentive plans - informs on energy price trends; applies penalty plans in cases of contract violation and so forth. *Billing Manager* is responsible for producing the invoices which are eventually communicated to customers through user communication interface (e.g. SMS or a web portal). The *Technical Operation Manager* acts as an executive unit on demand from VPS Manager, it may also take part in contracting process supplying information on technical feasibility of specific requests. It performs different fundamental grid operations like DER management, Smart Appliances control, power flows and outages management etc.

**Communication and Data Acquisition layer:** The advanced metering infrastructure (AMI) is the interface through which smart meter readings and other status monitoring data are gathered, stored, preprocessed and communicated in understandable form to the VPS Manager. It is rather vendor depended structure but due to increased penetration of standardization also in this segment of power system several crucial standard components have been identified for most of implementations. The Data Concentrator (DC) gathers smart meter measurements and stores the data in structured and standardized fashion into the Database which maintains the web portal configuration as well as administrative data arranged according to customers IDs. In some implementations, the database block can be part of the CC, rather than data acquisition one. **Meter Data Management (MDM)** further process the data on different granularity levels (i.e. from appliances to DER level), filters them by time period and presents them in a required structured form to CC components. VPS deals with integration of
many different technologies so that it should support system like Supervisory Control and Data Acquisition (SCADA) module to work as a data bridge/interface between field devices and the VPS manager.

**Field Devices – backend layer:** This layer considers backend embedded systems which measure, control or actuate electro-mechanical devices directly attached to the energy entities (energy entities may be - generators, home appliances, storages etc.). These embedded systems include smart meters, PLC (Programmable Logic Control-lers), RTU (Remote Terminal Units), ‘smart sockets’ and so forth. The devices from this layer translate the control signals received directly from the VPS manager (or Local Energy Management in case of distributed control) into an action (e.g. reduce power level, disconnect/reconnect customer etc.). The Local Energy Management unit provides local control decision based on user preferences and constraints but also requests from VPS Manager.

# 5 Assessment of ICT solutions

The assessment process has been agreed to be done in three phases:

* Development of a reference model

* Development of specific implementations' models according to same principles and standards

* Comparison of these two kinds of models by mapping a model of specific case into reference model according to defined standards

* Bearing in mind the reference model represented in Fig. 7. and details provided by each partner, appropriate models of pilot implementations have been developed. It can be noted that all the considered case have some differences in the implementation but still the basic structure was preserved. The exact models are result of technical documentation studding and direct interviews with implanting partners.

We present here assessment of one implementation that we consider as the most demonstrative. The assessment models of all other implementations are given in AlpEnergy Report [11]. The implementation to be assessed has been the one from the Allgäu region [11]. It has been considered as the most mature pilot and like this also served for the reference model development. The implementation reflects very well conceptual solutions even though some considered solutions like Trading Agent and Local Energy Manager are not fully implemented. The implemented VPS comprises different kind of generators (like PV cells, windmills etc.), Smart Homes, dynamic tariffs management, some elementary DSM and so forth. The detailed assessment report for all the pilot implementations in SysML fashion, is given in [11].

# 6 Conclusion

In this paper we have presented how system engineering methodology can be efficiently adapted and applied for the design and assessment of a critical structure that is
a virtual power system. Even though, due to the size of the system we focus only on
functional requirements and structural model of the system in this work, similar
methodology can be applied to ensure that critical non-functional properties of the
system have been achieved. Given reference model is highly scalable and easily can
be extended to support more both functional and non-functional requirements. As a
future work, we plan to assess availability and safety of implemented solutions.

# 7 References

1. Lukovic, S., Kaitovic, I., Bondi, U.: Adopting system engineering methodology to Virtual Power Systems design flow. In: proc. of the 1st Workshop on Green and Smart Embedded System Technology: Infrastructures, Methods and Tools (CPSWEEK/GREEMBED 2010)

2. E-ENergy project, http://www.e-energy.de

3. Fenix project, http://www.fenix-project.org/

4. ADDRESS project, http://www.addressfp7.org/

5. SmartGrids Technology Platform, http://www.smartgrids.eu/

6. Li, F., Qiao, W., Sun, H., Wan, H., Wang, J., Xia, Y., Xu, Z., Zhang, P.: Smart Transmission Grid: Vision and Framework. In: Smart Grid, IEEE Transactions on, Volume: 1 Issue:2, p.p.168 – 177, IEEE Press, (2010)

7. Sauter, T., Lobashov, M.; End-to-End Communication Architecture for Smart Grids. In: Industrial Electronics, IEEE Transactions on; Volume: 58 Issue:4 p.p. 1218–1228, IEEE Press, Apr. (2010)

8. Weilkiens, T.:Systems Engineering with SysML/UML: Modeling, Analysis, Design, Kaufmann OMG Press, (2007)

9. Vukmirovic, S., Lukovic, S., Erdeljan, A., Kulic, F.: A Smart Metering Architecture as a step towards Smart Grid realization. In: Energy Conference and Exhibition (EnergyCon), 2010 IEEE International, pp.357-362 (2010)

10. Vukmirovic, S., Lukovic, S., Erdeljan, A., Kulic, F.: Software architecture for Smart Metering systems with Virtual Power Plant", In MELECON 2010 - 15th IEEE Mediterranean Electrotechnical Conference, pp. 448-451 (2010)

11. Lukovic, S., Kaitovic, I., Sami, M.G.: AlpEnergy: Virtual Power System (VPS) as an Instrument to Promote Transnational Cooperation and Sustainable Energy Supply in the Alpine Space - Rapport final", Bundesamt für Energie, Pub. no. 290677 (2012).

12. AlpEnergy White Book: http://www.alpine-space.eu/uploads/tx_txrunningprojects/AlpEnergy_White_Book_Virtual_Power_Plants.pdf

13. Kaitovic, I., Lukovic, S.: Adoption of Model-Driven methodology to aggregations design in Smart Grid. In Industrial Informatics (INDIN), 2011 9th IEEE International Conference on, pp.:533-538, (2011)

14. Lukovic, S., Kaitovic, I., Mura, M., Bondi, U.,: Virtual Power Plant as a bridge between Distributed Energy Resources and Smart Grid. In System Sciences (HICSS), 2010 43rd Hawaii International Conference on, pp.1-8.(2010)