Operation of Modular Smart Grid Applications Interacting through … · Donau-City-Straße 1, 1220 Vienna, Austria, {mario.faschang, mark.stefan} ... that a growing number of devices

c© 2018 by the authors; licensee RonPub, Lübeck, Germany. This article is an open access article distributed under the terms and conditions ofthe Creative Commons Attribution license (http://creativecommons.org/licenses/by/4.0/).

Open Access

Open Journal of Big Data (OJBD)Volume 4, Issue 1, 2018

http://www.ronpub.com/ojbdISSN 2365-029X

Operation of Modular Smart Grid ApplicationsInteracting through a Distributed Middleware

Stephan CejkaA, Albin FrischenschlagerA, Mario FaschangB, Mark StefanB, Konrad DiwoldA

A Siemens AG, Corporate Technology, Research in Digitalization and Automation,Siemensstraße 90, 1210 Vienna, Austria, {stephan.cejka, albin.frischenschlager, konrad.diwold}@siemens.com

B AIT Austrian Institute of Technology GmbH, Energy Department,Donau-City-Straße 1, 1220 Vienna, Austria, {mario.faschang, mark.stefan}@ait.ac.at

ABSTRACT

IoT-functionality can broaden the scope of distribution system automation in terms of functionality andcommunication. However, it also poses risks regarding resource consumption and security. This article presentsa field approved IoT-enabled smart grid middleware, which allows for flexible deployment and management ofapplications within smart grid operation. In the first part of the work, the resource consumption of the middlewareis analyzed and current memory bottlenecks are identified. The bottlenecks can be resolved by introducing a newentity that allows to dynamically load multiple applications within one JVM. The performance was experimentallytested and the results suggest that its application can significantly reduce the applications’ memory footprint onthe physical device. The second part of the study identifies and discusses potential security threats, with a focuson attacks stemming from malicious software applications within the framework. In order to prevent such attacks aproxy based prevention mechanism is developed and demonstrated.

TYPE OF PAPER AND KEYWORDS

Regular research paper: IoT application management, distributed Smart Grid applications, Java virtual machine,memory optimization

1 INTRODUCTION

The increased integration of renewable energy in theEuropean energy system has led to a paradigm shiftregarding the operation of medium and low voltagedistribution grids [2]. These grids were designed for thedistribution of energy among consumers, which requiresvery little control. As renewable energy sources (e.g.,PV-systems) are usually integrated at a medium lowvoltage level, the role of distribution grids has changed.In order to facilitate this new role new means of controland monitoring mechanisms/solutions are required tomanage renewable energy installed on the distributionsystem level and maintain the required operation quality

within distribution grids. Mechanisms discussed inthe context of active distribution system control andmonitoring are usually coined under the term “smart gridoperation”. The term Smart Grid can be defined as “anelectric system that uses information, two-way, cyber-secure communication technologies, and computationalintelligence in an integrated fashion across the entirespectrum of the energy system from the generation to theend points of consumption of the electricity” [20].

In order to facilitate new means of monitoring andcontrol distribution system operation has started to adoptInternet of Things (IoT) concepts. IoT constitutes theefforts of integrating information technology seamlesslywith real world things [28]. In the context of distribution

14

http://creativecommons.org/licenses/by/4.0/

http://www.ronpub.com/ojbd

S. Cejka et al.: Operation of Modular Smart Grid Applications Interacting through a Distributed Middleware

system operation (DSO) this has led to a transformationof formerly passively/manually operated devices suchas transformers, breakers or switches into devices,which are actively integrated in the system operationprocess [29]. Using IoT-concepts in the DSO domainhas led to a wide range of novel applications [27] aswell as business cases [21], which aim for increasing theefficiency of operation and fostering the decarbonisationof power supply systems.

This article extends the work presented in [6],focusing on the memory optimization of a distributedmiddleware by introducing a mechanism fordynamically loading multiple applications into singlerun-time environments. In addition this article analysessecurity threats to which this middleware is susceptibleand demonstrates how the application of proxies canbe used to prevent threats emanating from maliciousthird party applications hosted on the middleware. Thememory and security issues show-cased in this articleare based on a system developed in the context of anIoT-enabled secondary substation. In a first step thearchitecture underlying the system is presented and therole that applications hosted on such a substation play isoutlined.

1.1 IoT-compliant Power Distribution Gridsand the Role of Applications in SuchSystems

The application of IoT devices in the context ofsmart grid operation as well as the role such devicescould take within new forms of distribution systemoperation has been extensively discussed in the contextof fog/edge computing (see e.g. [1]). The reason isthat a growing number of devices such as smart meters,smart breakers, electric vehicles or smart storage systemswhich are active in distribution grids already displaythis functionality. These devices can effect severaldomains of the smart grid (cf., domains of the Smart GridArchitecture Model [7]). Such devices are integrated intosmart grid operation since their application increases theeconomical and ecological effectiveness and allows theactive operation of power distribution grids [15].

In order to fully exploit IoT functionality within adistribution grid novel services are required which utilizeICT-connected power grid components and externalservices. Especially, in the context of low voltage gridautomation novel solutions based on IoT-functionalityare actively developed (e.g., [10, 23]). Possible examplesof such a utilization are forecasting mechanisms andthe integration of weather information into systemoperation [15].

There are different means how IoT-enabled powergrid devices can be integrated into grid operation

from an architectural point of view. One option isto shift computation into the cloud or a dedicateddata warehouse. In such a scenario field devices areused to measure and aggregate grid information, whilecomputation happens elsewhere. Such an approach hasbeen investigated in the context of distribution systemoperation [11]. The architecture underlying such anapproach can be scalable [22] and it has been shownthat such cloud based approaches yield a better executiontime than their non-cloud equivalent [9].

Within this study an edge-based approach is presented,where data storage and computation are performed ona dedicated field devices. The reason for choosingsuch an approach in contrast to a cloud approach liesin the fact that edge-based computation constitutesless strict infrastructure requirements (in terms of theavailability of an uplink and downlink) as computationand aggregation are performed in the field, whileguaranteeing the execution and performance of systemcritical applications.

It should be noted that the presented approach doesnot exclude a hybrid approach where different means ofcomputation are used both in the field as well as in thecloud, as the system can be easily extended to interactand utilize higher level systems such as a data warehouseor a dedicated cloud environment. The integration ofsuch services in the context of the presented framework(given that the required infrastructure is at hand) wouldfurther boost the scope of operation of the presentedsystem.

An important component regarding the operationof low voltage distribution grids is the secondarysubstation. It can be seen as a link between themedium (MV) and the low voltage (LV) grid. Undera passive operation scheme the substation constitutesan isolated device, i.e. all functionality within thesubstation is pre-installed and every interaction withthe substation requires staff on site. As outlined suchan approach is no longer feasible given the increasedintegration of renewables into the energy system. Forsuch scenarios a proactive substation is required, whichallows to adjust its functional scope by the deploymentof applications and active integration of information inthese applications.

An intelligent secondary substation (iSSN) aspresented in [15] can be seen as the result of theevolution from a passive towards an active substationallowing for a novel function scope. In order to achievethis functionality increased computational power andmeans of communication (both north and southbound)are required. In contrast to passive systems wherethe functional scope is fixed, the iSSN allows toextend the functional scope. Examples for such new

15

Open Journal of Big Data (OJBD), Volume 4, Issue 1, 2018

iSSNAutomation HW component

MV

LV

SW ecosystem

AppsApp

Manager

Data

Storage

SCADA

uplink

Apps

Figure 1: Architectural overview of the iSSN,containing power and communication links, aswitchable medium (MV) to low voltage (LV)transformer and an automation hardware (HW)component – typically an industry-grade computer –which operates the smart grid applications [15].

functionality are voltage and (re-)active power control,the optimization of distributed generation, virtualization,or even decentralized market interaction. The functionsare realized as distributed software applications – socalled Smart Grid applications – which can be deployedon the iSSN. Figure 1 gives an architectural overview ofan iSSN. A key requirement is the ability of applicationsto communicate with each other. This allows to bundlefunctionality in applications (in terms of services) andcompose complex functionality via the interaction ofapplications. Within this study this is achieved via aproprietary distributed middleware system, the Gridlink,which has been previously introduced [15, 4].

1.2 Similarity between IoT and InteractingDistributed Power Applications

In many industrial applications built on top of adistributed middleware framework, applications caneither be hosted and distributed on several automationcomponents or on the same machine. Gridlink wasbuilt with a focus on distributed computation. Theratio was the ability to establish iSSN functionalityacross device boundaries – i.e., a substation with severaldedicated automation devices (e.g., one device beingresponsible for the interaction with the transformer andother devices being responsible for data aggregationand/or southbound and northbound communication).

A special case arises if all applications are hostedon one automation device. This is a likely scenarioregarding distribution system operation as the number ofautomation devices required for power system operationincreases exponentially with decreasing voltage level.A DSO typically has to manage a few MV grids towhich several hundreds of LV-grids are connected. Forexample, in 2014 Wiener Netze GmbH, the DSO for

Vienna and surrounding areas, was responsible for 46substations between high and medium voltage level, and10.718 secondary substations between medium and lowvoltage level [26]. Therefore, the cost effectiveness ofthe automation component is an important aspect.

In the case of Gridlink this leads to a large numberof industrial applications (i.e., interlinked Javaapplications) running on one constraint automationcomponent (i.e., an industry grade computer).Each application demands for a specific amount ofcomputation and memory resources. Besides theresources required for the operation of the iSSNadditional computational power, memory and bandwidthneeds to be reserved for the provisioning features(deploying, updating and installing applications).

This situation maps well to the domain of IoT, wheredistributed functionality has to be achieved by low pricedand resource constraint components via the interactionof functional modules. In addition, the number ofapplications (in IoT terminology: functional modules)running on a device should have a limited effect on theperformance. Another requirement is that functionalityis not coupled to a specific hardware platform in order tofacilitate a heterogeneous world of devices.

1.3 Outline

This article shows that the desired modularity of iSSNapplication modules running on a constraint device isrestricted by limited computation resource available ontypical automation hardware. In order to overcome thisobstacle the framework of the distributed middlewarehas to be extended. In addition the article investigatessecurity threats that can arise in IoT-like applicationenvironments via malicious third party applications, andpresents a potential solution that allows to minimizethese threats.

Section 2 summarizes our previous work on theiSSN application framework, including the middlewareGridlink, its provisioning features as well as previouslydeveloped smart grid applications. In Section 3 atypical use case scenario with several iSSN applicationsis presented which is used to evaluate the system’sperformance. In Section 4 the performance of theuse case scenario is evaluated. It is shown thatmodularity jars with limited resources in the presentedsetup. In order to overcome this problem a frameworkenhancement is proposed. The old solution is comparedwith the new one, showing that significant savings inresource consumption can be achieved.

The second part of the article deals with potentialsecurity threats which can arise in a distributedmiddleware. Section 5 identifies potential threats for theproposed system. A specific threat which can arise in

16


the context of distributed automation is the unauthorizedaccess of control/information by malicious applications.To overcome this problem a proxy mechanism issuggested and its application is demonstrated. Section 6concludes this article and outlines planned future work.

2 APPLICATION FRAMEWORK FORDISTRIBUTION SYSTEM OPERATION

The application framework for distribution systemoperation used in this article has been previouslyproposed [14, 15, 4]. It was developed to establisha flexible and modular software ecosystem in thecontext of intelligent secondary substation automation.The resulting distributed middleware – the Gridlink(Section 2.1) – comprises a runtime environment fordistributed applications, a communication infrastructurefor the interaction of applications as well as meansto manage (deploy/update/remove) applications duringruntime. During the development of Gridlink anumber of non-functional requirements were taken intoconsideration which include the modularity, resilience,and scalability of the resulting system. A keyrequirement was to achieve an easy integration ofSmart Grid applications as well as the management ofrunning applications, while keeping the influence of anapplication on others minimal.

Figure 1 sketches a potential scenario regarding thedeployed components on an iSSN. Besides a numberof applications the iSSN hosts an AppManager witha remote uplink to establish provisioning features(Section 2.2). Thus, the application framework allowsfor the use of a Plug & Automate paradigm, i.e.,applications can be activated and deactivated during theruntime of other applications. In addition a data storageis deployed, which can be used by applications for thelocal aggregation of information received from the grid.Previously a number of Smart Grid applications havebeen introduced, including services and functions for

• acquisition, processing, and analyzing of fieldcomponent measurement data (e.g., Smart Metermeasurements) [14, 4],

• linking the iSSN to the energy market [18, 17], and

• making decisions, e.g., by a voltage controllerapplication able to switch the transformer’s tap-changer based on historical and/or current data[12, 4].

2.1 Gridlink

Gridlink was introduced as a middleware solution forintelligent secondary substations, based on vert.x and

StorageModule

storage

. . .

shutdown

createDataPointaddMeasurementgetMostRecentValue. . .

Figure 2: Modules, roles and services [4]A module (in this example the StorageModule)is registered for the roles storage and shutdown.The role storage provides several services (e.g.,createDataPoint).

Hazelcast [4, 15]. Gridlink as distributed middlewaresolution (in contrast to many typical IoT middlewaresolutions, as e.g. listed in [25]) has a key advantage innot creating a single-point-of-failure within the system.

A Gridlink-based secondary substation is composedof several application modules (written in Java),which interact via a message bus. The event busunderlying the system is based on an asynchronouscommunication model, which allows to couple moduleswith management functions such as a service registryand application update, upgrade and provisioning.Application modules run on a single Java virtual machine(JVM) that dynamically form a cluster of knowninstances during execution using multicast discovery. Inaddition, modules are able to enter and leave the systemat any time without influencing other modules’ executionor communication. While the failure of modules canimpact the overall operational reliability of applications,the impact of a failing module on the overall applicationscan be limited by introducing redundancy and increasingtimeouts to react on failed transmissions.

Message Exchange: The communicationinfrastructure provided by Gridlink for the applicationmodules includes the concepts of roles, topics andservices. An example is outlined in Figure 2.

Messages (i.e., requests or events) are identified by atype (e.g., createDataPoint), contain a destinationaddress (e.g., the role storage) and may optionallyinclude a payload (e.g., the data point to be created).They are either sent to a designated module role addressor published to a topic address reaching all registeredmodules, by default being marshalled into a JSONrepresentation for transmission. Dedicated proxies areexecuted after the module called the send or publishcommand but before the message is really transmitted(Figure 3). This allows for prior executing additionalmessage processing steps, including the modification ofa message (e.g., for encryption). The recipient module,

17


Sender

Encryption Proxy

Receiver

Decryption Proxy

Logging ProxyLogging Proxy

GL

Figure 3: Example that utilizes the Gridlink proxyconcept for logging and encryption of messagepayloads [15]

registered to the role or topic to which the message wasissued to, is the data sink. After the respective proxiesare executed on the recipient side, e.g., for decryption,the received message is handed over to the module’sregistered service handler for the message type andprocessed, which may include issuing a reply messageto the sender.

Whether a proxy is in use, is defined only by theoperator and stays completely transparent to sender andreceiver module. These proxies are attached via themodule’s configuration file and can be plugged in andout during runtime of the affected module. Accordingto their appearance in the configuration file, multipleproxies are executed in sequence.

Gridlink Registry: A module can access a distributedlist of all currently attached and active modules – theGridlink Registry. It furthermore includes all roles andtopics the modules are registered to, the list of requeststhey are able to handle and the associated replies, aswell as their proper JSON format specification. Thus,using the Gridlink Registry each module knows at anytime which modules are currently present to behaveaccordingly. By using the defined message schemataeven components outside the Gridlink system couldestablish communication to Gridlink modules.

2.2 Provisioning Tasks

At some time it is necessary to install new features,update applications, reconfigure them or uninstall them.These steps are grouped under the term provisioning,requiring – for cost efficiency – a functionality to initiatethese steps directly from the remote operator controlcenter without requiring staff on site.

A designated core module – the AppManager module– is responsible for such tasks. Figure 4 shows thesimplified steps that are necessary:

1. The provisioning task is initiated from the remoteoperator site, for example a web-based dashboardof the DSO.

Figure 4: Provisioning tasks are initiated from theremote site, e.g., by an operator’s dashboard,communicated to and executed by the localAppManager module. Status information iscommunicated back to the operator.

2. The AppManagaer receives these provisioningcommands. In case of an installation it downloadsthe respective module.

3. The AppManager manages installation,configuration, updating, and removal of theother modules – hence, they are termed managedmodules.

As the AppManager is a normal Gridlink moduleitself, it is able to communicate with any other moduleby sending and receiving Gridlink messages. TheAppManager does not introduce a single point of failureto the functionality of the iSSN, as its fail crashesthe remote provisioning features only. Interferences ofmodules with the operation of other modules can thus bekept to a minimum.

Since starting and stopping modules is tightlyconnected with the AppManager, selected designchoices of this software will be highlighted, to betterunderstand the later proposed solution.

Start-Up: During the AppManager’s start-up, allGridlink modules in its managed directory are started– currently as a new Java process (cf., Figure 5). Thesemodules are the AppManager’s managed modules.

Module Installation: The Module Installation taskallows a functionality upgrade of the iSSN. First, theAppManager receives an install command triggeredfrom the remote side. Afterwards the respectiveapplication is downloaded, the content of the archive isextracted and started.

Module Configuration Update: The ModuleConfiguration Update task allows a modification of

18


Node 1

AppManager

Node 2

Storage

Node 3

Dashboard Interf.

Node 4

Data Generator

Node 5

Volt. Problem H.

Node 6

OLTC Controller

Node 7

Voltage Guard

Gridlink

Figure 5: The current solution with one module per JVM/node

operation parameters during the module’s execution.Once the configuration file is changed, the correspondingmodule is automatically notified. By design, theconfiguration update shall not require a restart. Inthe same way, Gridlink proxies can be attached anddetached from a module dynamically during its runtime.

Module Uninstallation: When a module shall beremoved, the AppManager sends a shutdown request tothe module and waits for the module to disappear fromthe Gridlink Registry. Therefore, each module implicitlyimplements a shutdown role (cf. Figure 2). On success,the module’s directory is deleted from the file system.Otherwise, the AppManager can be requested to kill theprocess over its remote link.

Further Provisioning Tasks: Information of therunning modules, such as their state and the currentlyused configurations can be requested. This may alsoinclude information that bases on the Gridlink Registry.

During the runtime, it may be required to replacea module in execution with another version. Thisprocedure is basically a combination of the moduleuninstallation and installation procedures, including –however – to keep the current module’s state for (nearto) continuous work of the module.

3 ISSN USE CASE SCENARIO: ACTIVEVOLTAGE REGULATION

Secondary substations are typically used to transformand distribute electric energy to connected customerswithin a restricted voltage band. Active voltageregulation measures are required to counteract voltagefluctuation caused by renewable generation units andhigh loads. Such active regulation can be achieved,e.g., by using on-load-tap-changer transformers [12].Subsequently we demonstrate a use case dealing withthe detection and handling of voltage band violations [4].All seven Gridlink modules that are required for this usecase are running on one host machine in the iSSN (cf.,Figure 5).

1. AppManager Module: The AppManager modulehandles the software provisioning tasks described in

Section 2.2. This module has a remote communicationconnection, where the provisioning commands arereceived and downloads of artifacts take place.

2. Storage Module: The applications typicallyrequire access to some historical and current data. TheStorage module is used for the permanent storage of theaccumulated data and to make these data available toother modules on request. In this use case, the module isresponsible for measurement data (i.e., simulated voltagevalue time series) and meta data of the simulated datapoints [5].

3. Dashboard Interface Module: The DashboardInterface module provides a web-browser based viewon current and historical values of sensors and thetransformer.

4. Data Generator Module: The Data Generatormodule generates measurement values by simulatingsome houses’ power consumption during the day as wellas their power production in case they are equippedwith a photovoltaic (PV) installation using predefinedprofiles.

5. Voltage Problem Handler Module: The VoltageProblem Handler module is a monitoring module thatdetects problematic voltages in the grid. The permittedvoltage band in the use case is defined to be between220 V and 240 V and is thus tighter than power qualitycriteria limits specified in EN 50160, that requires 95 %of all ten minutes-average values within a week to bewithin 207 V and 253 V (Un±10 %) [8]. Upon detectionof a violation the operator is notified such that propercountermeasures can be taken.

6. On-Load-Tap-Changer (OLTC) ControllerModule: The OLTC Controller module links themessage bus and the transformer in the substation. Tapchange requests transmitted to the transformer result inan increase of the voltage level by 2.5 V on tap up; adecrease on tap down, respectively.

19


Figure 6: Minimum and maximum voltage level inthe simulated low voltage grid before installation ofthe Voltage Guard Module.

7. Voltage Guard Module: The Voltage Guardmodule analyses the voltage levels in the grid and reactswhen approaching the voltage band limits. Once avoltage value below 225 V or above 235 V is detectedat one of the monitored data points, the module maydecide to request the OLTC controller to change thetransformer’s tap position. The algorithm in use triesto keep the number of tap changes at a minimum levelby not reacting immediately when hitting the barrier butonly after a certain defined threshold level of cumulativevoltage violations over time is exceeded [24, 30].

Scenario Execution: The simulated low voltage gridscenario consists of a group of apartment houses yieldinga voltage level over the day submitted by the DataGenerator module (Figure 6). During the day, avoltage level violation is detected by the Voltage ProblemHandler module and communicated to the operator.Note that at this time all modules except the VoltageGuard Module are installed and running.

As countermeasure to the limit violations the operatordecides to install the Voltage Guard Module (7) duringthe runtime of the Gridlink middleware and the modules1–6. Due to its installation, tap position changes arecommunicated to the OLTC and thus the values allremain within the allowed voltage band (Figure 7).

Further Modules and Related Work: For presentingthe impacts of node management it is reasonable toutilize the shown use case scenario. Some of thedescribed applications are – however – only of basicfunctionality and need to be replaced or extended forreal world use cases. The data generator – for example –necessarily needs to be replaced by a Data Concentratormodule connected to the sensors and smart meters

Figure 7: Minimum and maximum voltage level inthe simulated low voltage grid with the Voltage Guardinstalled. Arrows show the submitted OLTC tapchanges during the day.

installed in the grid. Other publications that focusmore on the module functions than on the framework,have introduced more sophisticated modules, e.g., fordata processing, analysis, and grid operation [14, 13].These applications enable novel functions on the powerdistribution grid level.

4 MIDDLEWARE OPTIMIZATION

The usage of the presented iSSN Application Frameworkin the Smart Grid testbed of the Aspern Smart CityResearch (ASCR) revealed two shortcomings. First,the necessity to specify roles over which messagesare exchanged on sender and receiver side resulted ina complicated and error prone configuration process(Section 4.1). The second problem was a high mainmemory demand created by the modular approach(Section 4.2).

4.1 Service Discovery Optimization

As described in Section 2.1, Gridlink modules registerhandlers for various message types on roles to receivemessages. On the recipient side, the pseudo-code toregister a handler looks as follows:

registerHandler(<role-name>,<message-type>, <handler>)

To send a message, a module needs to supply amessage of the appropriate type and the role to whichthe message shall be delivered:

send(<role-name>, <message>)

Thus, the sender needs to know the role name onwhich the receiver awaits messages and the message

20


type the receiver can handle. In systems consisting ofhigh numbers of modules, this resulted in complicatedconfiguration files for each module; as requiring tospecify on which roles the module has to listen forwhich message-types and to which roles the modulehas to send messages of which message type. Errorsin these configurations inhibited the communicationbetween those modules.

Field experiences show that in most cases, the senderdoes not care who the recipients of its messages are. Theinformation, to which modules messages shall be sent to– however – is required by mentioned send command.This information which message-types are handled bywhich module is already located in the registry. Hence,the client module sending a message of a specifiedtype could search in the registry for modules handlingthose message types and more importantly over whichroles those messages have to be exchanged. With thisinformation the module is able to send the messageonce for each found role. Since a new module couldhave registered a handler, this registry search has to beperformed every time a message is sent. With the helpof this mechanism, the cumbersome and error proneconfiguration process is reduced significantly.

The second step is to remove the trouble for moduledevelopers to search the registry and thus to removeduplicated code. Thus, Gridlink API was extended toinclude the described behavior, such that the role addressis no longer required to be specified:

send(<message>)

If a module uses the send method without supplying arole, the message is sent to all modules with a registeredhandler appropriate to the message-type, by implicitlyquerying the registry. As the registry is distributed toall modules and all role registrations by modules areobserved by the local registries, the search for that rolerequires local available information only.

4.2 Memory Optimization

The modularity of the approach requires running ahigh number of various modules for small independenttasks simultaneously. Previously, one Gridlink nodeexecuted exactly one module (cf., Figure 5), i.e., theAppManager initializes a new process for each moduleit is managing, introducing a high overhead in terms ofmain memory consumption. In consequence, the numberof required modules for a typical Smart Grid use caseis typically higher than the RAM-constrained devicescan host simultaneously, before undesirable effects liketrashing occur.

The use case consisting of seven modules beingexecuted concurrently on the same machine, requires

already more than 800 MB of main memory, notavailable on the target hardware platform. Thus, amechanism to execute multiple Gridlink modules inone node and thus in one JVM process had to bedeveloped (“scale up”). The proposed extensionsshall however not invalidate any of the Gridlinkfunctions. It shall be possible to run all modules aspreviously intended, therefore decisions like the start-upof modules, communication etc., should remain.

To solve the described problem of excessivememory consumption, a new Gridlink module –the NodeManager – is proposed. It introduces the abilityof managing multiple modules on the same node, andthus, in the same JVM instance (Figure 8). To avoidambiguous use of the term “managed”, we will nowdistinguish between app-managed for management bythe AppManager, and node-managed for managementby the NodeManager, respectively. Therefore, theNodeManager is responsible for the module’s start-up,provides a command line interface to node-managedmodules, and is able to undeploy them. The process ofapplication provisioning is notably influenced by theintroduction of a NodeManager:

Start-Up: The AppManager was introduced as anunmanaged module [4]. However, besides installingit on its own node (cf., Node 1 in Figure 5), theAppManager now can – just like any other module– be started parallel to and by a NodeManager – asa node-managed module (cf., Node 1 in Figure 8).As in the old setup, all Gridlink modules in theAppManager’s managed folder are started during itsstart-up by creating a new JVM process, including aNodeManager module if it is contained in this folder(cf., NodeManager on Node 2 in Figure 8). Nospecial handling is necessary, as the NodeManagercomplies with the module structure conventions. Onthe NodeManager’s start-up, all Gridlink modules nestedinside its own managed subfolder are started withinthe NodeManager’s node/process (cf., the remainingmodules on Node 2 in Figure 8). Special attention hasto be paid to libraries of these node-managed modules:Java does not allow for including two classes with thesame fully qualified name to the classpath. By using anown class loader for each module, possible problems ofinfluences between libraries are kept to a minimum (cf.,isolated bundles in OSGi [19, 16]).

Module Installation: The module’s configurationneeds to include whether it shall be started traditionallyas its own process via the AppManager or on an existingnode next to a NodeManager. Based on this decision,the artifact is extracted to the respective directory. In the

21


Node 1

AppManager Storage

NodeManager1

Node 2

Dashboard Interf. Data Generator Volt. Problem H. OLTC Controller Voltage Guard

NodeManager2

Gridlink

Figure 8: Solution with multiple modules on one JVM/node (“scale up”).In this example it is decided to execute the AppManager and the Storage module on one node; all othermodules together on one other node, respectively.

latter case the request to start the module needs to becommunicated to the respective NodeManager module.

Module Configuration Update: Configurationchanges of a module always reach the AppManager,which is responsible for the modification of theJSON configuration file. The location of a module’sconfiguration file depends on whether it is node-managed or not, as it either is located in theNodeManager’s or in the AppManager’s manageddirectory. The AppManager internally knows all themodules it has started, but not necessarily all modulesstarted by other node managers (e.g., the Storagemodule in Figure 8). However, the AppManager is onlyresponsible for its app-managed modules and thus, allmodules of which he is capable of configuration changesare known.

Module Uninstallation: In case of the node-managedmodule’s refusal to shut down, the AppManager cannotkill the process as earlier, as this would also shut downthe NodeManager and every other module on that node.It can however request the managing NodeManager tostop the module, shifting the responsibility. As forconfiguration, for removal of the module’s files theAppManager has to know the directory location.

Summary: In consequence, both AppManagerand NodeManager module are responsible for their?-managed modules. The difference is that app-managedmodules are started in their own JVM and thus, havetheir own process; node-managed modules are startedbeside the NodeManager in the already existing process.Figure 8 shows both options:

1. NodeManager1 on Node 1 is an unmanagedmodule, initially started.

2. It has started the Storage and the AppManager.These two modules are node-managed modules –managed by NodeManager1.

0

200

400

600

800

1000

Old New

MB

RA

M

NodeManagerAppManager

StorageDashboard Interface

Data GeneratorOLTC Controller

Voltage Problem HandlerVoltage Guard

Figure 9: Evaluation results

3. The AppManager on Node 1 has traditionallystarted NodeManager2 as its own process onNode 2. Therefore, NodeManager2 is an app-managed module – managed by the AppManageron Node 1.

4. The five modules running within Node 2 have eitherbeen started (node-managed) by NodeManager2 orby request of the AppManager to NodeManager2(in result being app-managed by the AppManagerand node-managed by NodeManager2).

In the scenario of Section 3, the AppManager wouldthus issue an request to NodeManager2 to start theVoltage Guard module after its download.

As communication of all modules is done via theGridlink – and so are the start commands from theAppManager to the NodeManager – the AppManager isalso able to request modules to be started on Node 1 byissuing requests to its own NodeManager1.

Evaluation Results: We conducted experiments toshow the impact of the new solution. Thus, we facedthe memory consumption of the old solution – all sevenmodules of the iSSN use case (cf. Section 3) beingstarted within their own node – with the new solutionusing the proposed NodeManager concept to start themodules in one JVM.

22


Figure 9 shows the results of both experiments. Itis shown that each JVM requires at least 100 MB inmain memory. Thus, the start of the NodeManagermodule shows a comparable memory consumption toeach module in the first experiment. More specifically,for n modules with their memory consumption foradditional required libraries, its logic, and its datastructures mi and a (for simplification assumed) constantamount of Gridlink dependencies’ memory consumptionc, the memory consumption for the old solution was:

Mold =

n∑i=0

(c+mi) = nc+

n∑i=0

mi

In contrast, the memory consumption of the new– NodeManager-based – solution requires Gridlinkdependencies to be load only once, resulting in asignificant reduction of the total memory consumption:

Mnew = c+

n+1∑i=0

mi

Therefore, the higher the number of modules, thegreater the difference of the required memory betweenold and new Smart Grid application managementsolutions becomes. However, when only one moduleshould be started on a host, the old system requires lessmemory. This results from the NodeManager’s memoryrequirements for its own logic and a small Gridlinkmiddleware overhead.

5 SECURITY THREATS

Potential security threats of Gridlink communicationhave been first identified and analyzed in [3].Countermeasures against potential attacks relating nodemanagement consist of trusted applications and themiddleware’s security layer.

5.1 Event Bus Blocking Attack / TrustedGridlink Apps

The event bus thread is shared between all modulesrunning on one vert.x node. This aspect gets important– and security relevant – with the introduction of nodemanagement. If the thread is blocked by one module allother modules on the node are affected, e.g. by gettingstuck or showing other unexpected behavior (Event BusBlocking Attack) [3]. A malicious module could thusdeny all other modules on the node from their properexecution.

As modules developed by other parties are possible, amechanism for certified modules needs to be introduced(Trusted Gridlink Apps). An execution of uncertified and

thus untrusted modules beside trusted ones on the samephysical node may be prohibited. This partly solves theEvent Bus Blocking Attack, as the influence of untrustedto trusted modules’ execution remains limited.

To further improve the availability, fundamentalmodules (e.g., the storage), modules with higherprocessor consumption or modules that are required toreply fast could be moved to their own nodes, such thatthey are not required to share the event bus with othermodules.

5.2 Communication Issues / Gridlink SecurityLayer

We earlier introduced Gridlink proxies that allow thenormal execution to be interrupted to run user-definedcode for interception or modification of messages or toexecute additional tasks when messages are transmittedover the component (cf. Figure 3). A number of proxiescan be defined for an application allowing a proxy sidecustomization of the in- and outgoing data.

Message Encryption Proxies: The use of Gridlinkproxies for encrypting messages before sending anddecrypting them again at the receiver denies thatmalicious modules can read the communication. Theseproxies can either use symmetric or asymmetriccryptography. By use of proxies only features thatare already included in the Gridlink are utilized;cryptography proxies are thus termed the GridlinkSecurity Layer establishing end-to-end encryption [3].

Message Filter Proxies: This subsection willdemonstrate the application of proxies in the contextof the secure integration of third party Gridlinkapplications. In such cases, the communication betweenGridlink modules needs to be observed. The need formessage filter proxies is shown by the following threemotivating examples:

1. Assume that the Voltage Problem Handler moduleis developed by a third party. Such analyticsmodules pre-process sensor information. Whilethis module should be able to request the Storagemodule for measurement data, other informationand services available on the message bus shouldnot be accessible by the module.

2. The OLTC Controller Module module provides alink between the message bus and the transformerin the substation. Applications are able toaccess current information on the tap position andcan issue service requests regarding tap positionchanges, which are forwarded to the substation

23


controller via the module. The operation of thetransformer is critical due to active interferencewith grid operation. If the voltage is too high at anypoint in the grid, machines of industries and devicesof households can get damaged; if the voltage is toolow, they may cease to operate. Thus, it must beensured that only authorized modules are able toissue tap change requests to the OLTC Controllermodule.

3. The AppManager module issues shutdown requeststo all modules using normal Gridlink messages.It needs to be ensured that only this module cansend such requests, furthermore that every moduleaccepts such requests only from that sender.

The intended behavior can be achieved using theproxy concept outlined previously. Modules areequipped with proxies which monitor and control theincoming and outgoing messages of a module, such thatmessages identified as prohibited can be filtered out.

Message Filter Security Proxy for incomingmessagesOn receiving a message check message type andsender; if permitted hand message over to module,drop it otherwise.

Message Filter Security Proxy for outgoingmessagesBefore sending a message check message andreceiver; if permitted send message, drop itotherwise.

Both proxies work likewise: if the type of themessage is not among the allowed types and/orcommunication with the other party (i.e., sender orreceiver) is not permitted the message is dropped.Otherwise, the incoming message is handed over to thedesignated module; the outgoing message is sent overthe communication network, correspondingly. Note thatall proxies in use are specified by the module’s user(i.e., the operator) and not by its developer. Thus, thismechanism allows to specify the allowed communicationof a module without requiring in-depth inspection of thethird party module.

For the motivating examples – besides encryption ofmessages – the following proxies are reasonable:

1. a proxy filtering outgoing messages of the VoltageProblem Handler module, that let pass onlymessages of permitted type and destination, e.g.,this module is not permitted to issue tap changerequests to the OLTC Controller module. In thiscase, the proxy is defined to drop all outgoing

messages that are not data retrieval requests to theStorage module.

2. a proxy filtering incoming messages at the OLTCController module, that let pass only messages ofpermitted type and source, e.g., this module mustnot accept tap change requests from the VoltageProblem Handler module. In this case, the proxy isdefined to drop all incoming messages that are nottap change requests by the Voltage Guard module.

3. a proxy for all modules except the AppManagerthat filters outgoing shutdown request messages;furthermore a proxy for all modules that filterincoming shutdown requests not originating fromthe AppManager.

Proxy Security Concept Demonstration Todemonstrate the concept a malicious analytics modulewas generated. Besides its designated task (i.e.,receiving current sensor information from the datagenerator module, preprocessing them and storing themin the Storage module) the module will also try tosubscribe information from the OLTC module in orderto receive information of the current tap position as wellas send tap position change requests and therefore try toactively interfere into the grid operation process.

To demonstrate the application of proxies the scenariowas tested under two setups. In the first setup no proxieswere used, while the second second setup equippedeach module with a module specific proxy defining theallowed in- and output of each module. The exemplaryproxies for incoming and outgoing messages for theanalytics module are shown in Listing 1.

The proxy of Listing 1 checks if incoming messagesare sent from the specified sender as well as correspondto the data model which is required from the sender. Ifan incoming message does not correspond to an expectedpayload from an expected sender it is not forwarded tothe module.

The proxy of Listing 2 works in a similar mannerfor outgoing message, filtering them according to datatype and receiving module. Messages which do notcorrespond to the specification are not forwarded andwill thus not reach their destination module.

When running the scenario without proxies eachmodule is able to access information as well asservices from all the other modules. Therefore themalicious module can access information on the currenttap position as well as request the tap position tobe changed. This behavior can be prevented usingapplication specific proxies which manage the incomingand outgoing communication and service scope of themodules. Using proxies the analytics module is only

24


Listing 1: Example incoming proxy for an analytics modulep u b l i c c l a s s A n a l y t i c s I n P r o x y e x t e n d s L a y e r I n P r o x y {

p r i v a t e f i n a l Logger l o g g e r = . . . ;

. . .

p u b l i c Enve lope a p p l y ( Enve lope message ) {i f ( message i n s t a n c e o f Gr idEven t && message . getFrom ( ) == " Data

G e n e r a t o r " ) {l o g g e r . i n f o ( " Rece ived Gr idEven t message from DG. Th i s message t y p e i s

a l l o w e d and w i l l be f o r w a r d e d t o t h e module " ) ;r e t u r n message ;

} e l s e {l o g g e r . i n f o ( " Rece ived message t y p e o r s e n d e r which was n o t s p e c i f i e d .

Th i s message t y p e i s n o t a l l o w e d and w i l l n o t be f o r w a r d e d t o t h emodule " ) ;

r e t u r n n u l l ;}

}}

Listing 2: Example outgoing proxy for an analytics modulep u b l i c c l a s s A n a l y t i c s O u t P r o x y e x t e n d s LayerOutProxy {

p r i v a t e f i n a l Logger l o g g e r = . . . ;

. . .

p u b l i c Enve lope a p p l y ( Enve lope message ) {i f ( message i n s t a n c e o f AddEnt ryReques t && message . ge tTo ( ) ==

" S t o r a g e " ) ) {l o g g e r . i n f o ( " Outgoing AddEnt ryReques t t o S t o r a g e . Th i s message t y p e

i s a l l o w e d and w i l l be d e l i v e r e d " ) ;r e t u r n message ;

} e l s e {l o g g e r . i n f o ( " Outgoing message o f f o r b i d d e n t y p e o r f o r b i d d e n r e c e i v e r .

Message w i l l n o t be f o r w a r d e d " ) ;r e t u r n n u l l ;

}}

}

25


Machine 1

Node 1 Node 2

Machine 2

Node 3 Node 4

Gridlink

Figure 10: Solution with modules on two machines (“scale out”)

able to receive information from the data generator(of the type GridEvent) and store information in theStorage module using the AddEntryRequest service. Allother means of communication are blocked. While theprovided example is very simple it demonstrates theapplication of proxies in the context of security.

As mentioned, the numbers of proxies used in thecontext of a module is not limited. Therefore, a numberof proxies can be defined for an application allowing aproxy side customization of the incoming and outgoingdata.

6 CONCLUSION AND OUTLOOK

To counteract the high memory demand of multipleSmart Grid application modules running each on its ownJVM instance, we introduced the new NodeManagerentity. Using node management, multiple Gridlinkmodules can be executed concurrently within oneJVM without influencing installation, update anduninstallation during the runtime of the node and othermodules. Memory usage was thus reduced by a hugeextent as dependency libraries need to be loaded onlyonce and no additional JVM caused memory overheadis introduced. Additionally required main memory justresults from the module’s implementation.

The evaluation shows that the described extensionallows for modular applications plugged in(installed/started) and out (stopped/uninstalled) duringthe runtime of the node (Plug & Automate paradigm)and the concurrent execution of a high number ofmodules. With this solution, we raised a potentialproblem by a commonly used event bus which mightlead modules to mutually block each other on the samenode. We thus introduced some security measures(Trusted Gridlink Apps, Gridlink Security Layer) thatallow to specify the allowed modules on one nodeand the allowed communication of modules withoutrequiring changes in the (possibly third party) module’simplementation. The proxy concept was demonstratedin a scenario where a malicious third party applicationtries to access information and services. This behaviorcan be prevented using application specific proxies

which limit the information scope of each application.In future work, it may be necessary to run modules

on different machines (Scale Out, cf. Figure 10).While Gridlink has always been able to communicatebeyond the barriers of physical machines, applicationprovisioning is more complicated in this setup requiringfile transfer to and process execution on the othermachine. This extension would allow various use cases,such as load balancing and the use of fault tolerant andstandby modules. Those functionalities are future work,once needed in a concrete use case.

ACKNOWLEDGEMENTS

The presented work is developed in the Smart Gridtestbed of the Aspern Smart City Research (ASCR) andconducted

(i) in the “iNIS” project (849902), funded andsupported by the Austrian Ministry for Transport,Innovation and Technology (BMVIT) and theAustrian Research Promotion Agency (FFG), and

(ii) in the “SCDA-Smart City Demo Aspern” project(846141), funded and supported by the AustrianClimate and Energy Fund (KLIEN).

REFERENCES

[1] F. Bonomi, R. Milito, J. Zhu, and S. Addepalli,“Fog computing and its role in the internet ofthings,” in Proceedings of the first edition ofthe MCC workshop on Mobile cloud computing.ACM, 2012, pp. 13–16.

[2] R. E. Brown, “Impact of smart grid on distributionsystem design,” in Power and Energy SocietyGeneral Meeting-Conversion and Delivery ofElectrical Energy in the 21st Century, 2008 IEEE.IEEE, 2008, pp. 1–4.

[3] S. Cejka, A. Frischenschlager, M. Faschang, andM. Stefan, “Security concepts in a distributedmiddleware for smart grid applications,”in Symposium on Innovative Smart Grid

26


Cybersecurity Solutions 2017, Mar 2017, pp.104–108.

[4] S. Cejka, A. Hanzlik, and A. Plank, “Aframework for communication and provisioningin an intelligent secondary substation,” in 2016IEEE 21st International Conference on EmergingTechnologies and Factory Automation (ETFA),Sept 2016.

[5] S. Cejka, R. Mosshammer, and A. Einfalt, “Javaembedded storage for time series and meta datain Smart Grids,” in 2015 IEEE InternationalConference on Smart Grid Communications(SmartGridComm), Nov 2015, pp. 434–439.

[6] S. Cejka, A. Frischenschlager, M. Faschang,and M. Stefan, “Memory optimization of adistributed middleware for smart grid applications,”in Proceedings of the 2nd International Conferenceon Internet of Things, Big Data and Security,IoTBDS 2017, Porto, Portugal, April 24-26, 2017,2017, pp. 331–337.

[7] CEN-CENELEC-ETSI, “Smart Grid ReferenceArchitecture,” CEN-CENELEC-ETSI SmartGrid Coordination Group, Technical Report,Nov 2012. [Online]. Available: http://ec.europa.eu/energy/sites/ener/files/documents/xpert_group1_reference_architecture.pdf

[8] CENELEC, “EN 50160:2010 - Voltagecharacteristics of electricity supplied by publicelectricity networks,” Mar 2011.

[9] V. Chang and G. Wills, “A model to comparecloud and non-cloud storage of big data,” FutureGeneration Computer Systems, vol. 57, pp. 56–76,2016.

[10] Y. Chollot, P. Deschamps, A. Jourdan, andS. Mishra, “New approach to regulate lowvoltage distribution network,” in 23rd InternationalConference on Electricity Distribution (CIRED),Jun 2015, paper 1145.

[11] G. L. De Alvaro, G. A. Taylor, D. C. Wallom,G. Gershinsky, A. Y. Huete, and K. Diwold, “Highperformance computing and communicationstechnology solutions for future smart distributionnetwork operation,” IET Conference Proceedings,pp. 0730–0730(1), 2013.

[12] A. Einfalt, F. Zeilinger, R. Schwalbe, B. Bletterie,and S. Kadam, “Controlling active low voltagedistribution grids with minimum efforts on costsand engineering,” in 39th Annual Conference of theIEEE Industrial Electronics Society (IECON), Nov2013, pp. 7456–7461.

[13] A. Einfalt, S. Cejka, K. Diwold,A. Frischenschlager, M. Faschang, M. Stefan,and F. Kupzog, “Interaction of smart gridapplications supporting plug & automate forintelligent secondary substations,” CIRED, OpenAccess Proceedings Journal, vol. 2017, no. 1, pp.1257–1260, Oct. 2017.

[14] M. Faschang, M. Stefan, F. Kupzog, A. Einfalt,and S. Cejka, “‘iSSN Application Frame’ – Aflexible and performant framework hosting smartgrid applications,” in CIRED Workshop 2016, Jun2016, paper 255.

[15] M. Faschang, S. Cejka, M. Stefan,A. Frischenschlager, A. Einfalt, K. Diwold,F. Pröstl Andrén, T. Strasser, and F. Kupzog,“Provisioning, deployment, and operation of smartgrid applications on substation level,” ComputerScience - Research and Development, vol. 32,no. 1, pp. 117–130, 2017.

[16] K. Gama and D. Donsez, Towards DynamicComponent Isolation in a Service OrientedPlatform. Berlin, Heidelberg: Springer BerlinHeidelberg, 2009, pp. 104–120.

[17] T. Gawron-Deutsch, S. Cejka, A. Einfalt, andD. Lechner, “Proof-of-Concept for market basedgrid quality assurance,” in 23rd InternationalConference on Electricity Distribution (CIRED),Jun 2015, paper 1495.

[18] T. Gawron-Deutsch, F. Kupzog, and A. Einfalt,“Integration of energy market and distribution gridoperation by means of a flexibility operator,” e &i Elektrotechnik und Informationstechnik, vol. 131,no. 3, pp. 91–98, 2014.

[19] N. Geoffray, G. Thomas, B. Folliot, andC. Clément, “Towards a new isolation abstractionfor osgi,” in Proceedings of the 1st Workshop onIsolation and Integration in Embedded Systems,ser. IIES ’08. New York, NY, USA: ACM, 2008,pp. 41–45.

[20] H. Gharavi and R. Ghafurian, “Smart grid: Theelectric energy system of the future,” Proceedingsof the IEEE, 2011.

[21] V. Giordano and G. Fulli, “A business case forsmart grid technologies: A systemic perspective,”Energy Policy, vol. 40, pp. 252–259, 2012.

[22] C.-S. Li, H. Franke, C. Parris, B. Abali,M. Kesavan, and V. Chang, “Composablearchitecture for rack scale big data computing,”Future Generation Computer Systems, vol. 67, pp.180–193, 2017.

27

http://ec.europa.eu/energy/sites/ener/files/documents/xpert_group1_reference_architecture.pdf




[23] M. Mangani, F. Kienzle, M. Eisenreich,Y. Farhat Quinones, R. Bacher, and A. Brenzikofer,“GridBox: An Open Platform for Monitoringand Active Control of Distribution Grids,” in23rd International Conference on ElectricityDistribution (CIRED), Jun 2015, paper 1070.

[24] A. Plank, F. Zeilinger, and A. Einfalt,“Untersuchung der Effektivität vonRegelkonzepten in Verteilnetzen,” in 14.Symposium Energieinnovation, Graz, Austria,Feb 2016, in german.

[25] M. A. Razzaque, M. Milojevic-Jevric, A. Palade,and S. Clarke, “Middleware for internet of things:A survey,” IEEE Internet of Things Journal, vol. 3,no. 1, pp. 70–95, Feb 2016.

[26] T. Schuster, “Auswirkungen der unsymmetrischenBelastung im Niederspannungsnetz für dezentraleEnergieeinspeiser,” in Tagungsunterlagen Eninnov2014, 2014, in german.

[27] M. L. Tuballa and M. L. Abundo, “A reviewof the development of smart grid technologies,”Renewable and Sustainable Energy Reviews,vol. 59, pp. 710–725, 2016.

[28] D. Uckelmann, M. Harrison, and F. Michahelles,“An architectural approach towards the futureinternet of things,” in Architecting the internet ofthings. Springer, 2011, pp. 1–24.

[29] X. Yu and Y. Xue, “Smart grids: A cyber-physicalsystems perspective,” Proceedings of the IEEE, vol.104, no. 5, pp. 1058–1070, May 2016.

[30] F. Zeilinger, A. Einfalt, K. Diwold, A. Plank, andA. Lugmaier, “Influence of Different FrameworkConditions on the Effectiveness of ControlConcepts in Distribution Grids,” in CIREDWorkshop 2016, Jun 2016, paper 259.

AUTHOR BIOGRAPHIES

Stephan Cejka joined thedepartment for CorporateTechnology of Siemens Austriain 2014. There he works asResearch Scientist and JuniorExpert in a research groupfor Smart Grids and SmartBuildings. He received hisbachelors degree in Software& Information Engineeringfrom Vienna University of

Technology in 2013 and his magister degree in Lawsfrom University of Vienna in 2016. Currently, he isenrolled in the master study "Software Engineering &Internet Computing" at Vienna University of Technologyand in the PhD study in Laws at University of Vienna.Research interests include distributed systems, datastorage and privacy in the Smart Grid area.

Albin Frischenschlager wasborn in 1988 in Vienna. Hereceived a master degree inComputer Engineering fromthe Vienna University ofTechnology. His diplomathesis was about: “Autonomouspath planning using probabilisticmaps”. During his studies, AlbinFrischenschlager was employedas system-administrator and

software developer for different companies. SinceOctober 2014, Albin Frischenschlager is working in aSmart Grid research group of Corporate Technology atSiemens AG Austria as a project manager and softwaredeveloper.

28


Mario Faschang was researchengineer and project manager atthe Energy Department of AITAustrian Institute of TechnologyGmbH in Vienna until August2017. Faschang holds a M.Sc.(Dipl.-Ing.) degree (2011)in electrical engineering andinformation technology fromTU Vienna and a Ph.D. inengineering science (2015).

Before joining AIT, he was with Siemens AG Austriaand research assistant at TU Vienna. Faschang’sresearch focuses on future power grids and voltagecontrol in low voltage distribution grids with highshare of distributed, alternative power generation andelectro mobility. Faschang was awarded the AustrianINiTS award, the “green tech” award, and the AustrianSmart Grids Pioneer Award together with his colleaguesin 2012. He is member of Austrian ElectrotechnicalAssociation (OVE), IEEE Austria, and officer of IEEEAustria Young Professionals Affinity Group.

Mark Stefan studied ComputerScience (Bachelor and Master)at the Vienna University ofTechnology. He started hisprofessional career at RobertBosch AG in Vienna (softwareand function development,project management) where hewas working for about 2.5 years.In 2012, he joined the Instituteof Computer Aided Automationat the Vienna University of

Technology, working as project assistant and doing hisPhD-studies. He developed an algorithm for optimizingrailway systems in terms of deadlock detection andavoidance as well as the minimization of the tractionenergy consumption. Since June 2014, he is workingas Research Engineer and Project Manager at the AITAustrian Institute of Technology GmbH. Since 2014,Dr. Stefan holds lectures at St.Pölten University ofApplied Sciences (Application of Graphs in the RailwaySector).

Konrad Diwold received amaster degree in ArtificialIntelligence from the FreeUniversity Amsterdam(Netherlands) in 2007. From2008 until 2011 Konrad Diwoldwas a research associate at theparallel and complex systemsworkgroup at the University ofLeipzig (Germany). His workconcerned biological inspired

algorithms. He received a Ph.D. in computer sciencefrom the University of Leipzig in 2012. From 2011until 2014 Konrad Diwold was a research associateat the Fraunhofer Institute for Wind Energy andEnergy System Technology (Kassel, Germany) inthe department of distribution system operation. Hiswork concerned the smart integration of renewableenergy resources in distribution system operation.Since January 2015, he is working in a research groupof Corporate Technology with focus on Smart Gridtechnologies at Siemens AG Österreich.

29

Operation of Modular Smart Grid Applications Interacting through … · Donau-City-Straße 1, 1220 Vienna, Austria, {mario.faschang, mark.stefan} ... that a growing number of devices

Documents