FREDOSAR: Towards a Security-aware Open System Architecture

Framework Supporting Model based Systems Engineering

Michael Fischinger, Christian Neureiter, Christoph Binder, Norbert Egger and Michael Renoth

Center for Secure Energy Informatics Salzburg, University of Applied Sciences, Urstein S

ud 1, 5412 Puch/Salzburg, Austria

Keywords: Open Systems Architecture, Complex Systems, Security by Design, MBSE, Domain Speciﬁc SE, Smart Grid.

Abstract:

The Smart Grid is the leading example when talking about complex and critical systems. Model Based Sys-

tems Engineering (MBSE) represents an appropriate approach for the mastery of this complexity. However,

achieving full traceability between the model of a system and the concrete implementation is still an open

issue. For this, Model Driven Development (MDD) is proposed. Hence, the development of a general middle-

ware framework, which comprises a well-deﬁned, customized architecture and provides accurately elaborated

interfaces, would probably facilitate the Model Based Approach in a decisive manner. Thus, the present work

addresses the development of a versatile architecture framework, the FRee EDucational Open System ARchi-

tecture (FREDOSAR), which also includes an open source implementation. Due to the criticality of systems

like the Smart Grid, Security by Design is another central aspect of this architecture development process. For

evaluation, the applicability of the framework is ﬁnally veriﬁed by the implementation of several case studies

based on FREDOSAR, focusing on the quality attributes mentioned.

1 INTRODUCTION

In recent years, a transition of the original power grid

towards the so-called Smart Grid has become appar-

ent. This is encouraged by the expected reduction

of primary energy resources like fossil fuel or nu-

clear power. Furthermore, technological advances of-

fer new possibilities for the efﬁcient use of more sus-

tainable and environmentally-friendly sources. This

leads to major changes concerning the unidirectional

energy ﬂow from centralized facilities towards its cus-

tomers, resulting in a dynamic network containing

multiple producers and consumers. However, since

dealing with this complexity in the Smart Grid is a

difﬁcult task, new methods for describing and devel-

oping current and future energy systems need to be

deﬁned.

The ﬁrst set of problems can be identiﬁed by us-

ing the classiﬁcation proposed by Haberfellner et al.

(2015). In more detail, the authors distinguish types

of systems based on the attributes dynamic and alter-

ability as well as diversity, variety and scale. This re-

sults in the description of four different system types:

If it is only comprised of a few elements which are

statically interconnected, it is deﬁned as a simple sys-

tem. However, a complicated system emerges by

adding a large number of elements and connections or

adding dynamical interaction behavior between those

elements. By including both of these characteristics,

the result is a complex system. By applying this clas-

siﬁcation scheme, the traditional power system can

be considered as a complicated system whereas the

Smart Grid is classiﬁed as a complex system. Go-

ing even further, the term System-of-Systems (SoS) is

suggested to be used in order to emphasize the au-

tonomous character of the system’s individual partic-

ipants (Maier, 1998).

According to these considerations, the Smart Grid

is speciﬁed to be a critical infrastructure, which needs

to address several requirements in order to integrate

functional safety. More speciﬁcally, the requirements

reliability, availability, maintainability, safety and se-

curity are summarized by the term RAMSS and are

used to describe the dependability of a technical sys-

tem (Avizienis et al., 2004). Since one effect result-

ing from the aforementioned technological advances

is the possibility to build powerful network devices on

the customer’s premises, a special need for consider-

ing privacy and security arises. However, the concepts

of Model Based Systems Engineering (MBSE) specif-

ically target issues such as dealing with the upcoming

complexity during the development of a SoS or de-

livering Privacy & Security by Design. Neureiter et

al. (2016) and Knirsch et al. (2015) provide several

108

Fischinger, M., Neureiter, C., Binder, C., Egger, N. and Renoth, M.

FREDOSAR: Towards a Security-aware Open System Architecture Framework Supporting Model based Systems Engineering.

DOI: 10.5220/0007710201080115

In Proceedings of the 8th International Conference on Smart Cities and Green ICT Systems (SMARTGREENS 2019), pages 108-115

ISBN: 978-989-758-373-5

examples on how those issues are addressed by apply-

ing the methods introduced by MBSE for developing

domain-speciﬁc system architectures. Furthermore,

the approach for Domain Speciﬁc System Engineering

(DSSE) (Neureiter, 2017) is a result of several years

of research and use in international projects. The re-

search mentioned introduced an Integration Toolchain

to illustrate the holistic workﬂow, which describes

an optimized development process for systems based

on the Smart Grid and inherits consistent supporting

methods for developing in different phases through-

out the whole life-cycle of a system.

Therefore, this paper introduces the conception

and development of an open systems architecture

framework that enables the application of complex

systems. By doing so, the special focus of the frame-

work is the seamless integration into the DSSE ap-

proach and to deliver security by design. Therefore,

the remainder of this contribution is structured as fol-

lows: In Section 2, an overview of already existing

frameworks with similar objectives and open aspects

in this area is given, before relevant features are ex-

tracted. Based on these features, in Section 3, the re-

quirements for the development are speciﬁed. After

that, the implementation details of the framework it-

self are stated in Section 4. However, to demonstrate

the applicability of the implemented architecture, a

PoC implementation is taken for evaluation in Sec-

tion 5. Finally, in Section 6 the paper is summarized

and then the conclusion is given.

2 RELATED WORK

This section gives an overview of the state-of-the-art

and the related work. Basically, the idea of establish-

ing generic software architecture frameworks is not

new. Hence, existing solutions and attempts for com-

parable problem formulations have been analyzed and

evaluated.

The AUTomotive Open System ARchitecture (AU-

TOSAR) (F

urst et al., 2009) is therefore the ﬁrst ar-

chitecture (framework) to be mentioned. AUTOSAR

is a middleware platform for the automotive industry.

The standardization of base functionality, the scala-

bility of systems, the transferability of software to dif-

ferent control devices, the cooperation between vari-

ous manufacturers and the development of highly de-

pendable systems have been the major incentives for

founding an open systems architecture framework in

the automotive domain. There are obviously some

parallels within the given problem formulations. A

central aspect is therefore that the software com-

ponents of AUTOSAR are generated from software

models. Besides some of the non-functional require-

ments, this model based approach is a potential as-

pect, where the intended framework probably could

refer to the architecture of AUTOSAR.

Drawing the attention from the approaches of AU-

TOSAR in automotive engineering to the Smart Grid

and other domains leads to a number of frameworks

and architectures that could perhaps be taken as base

for further implementations. The most famous solu-

tion are probably OpenHAB and Eclipse SmartHome,

shortly described by Kreuzer (2014). Basically, they

address the IoT sector and Smart Home. The primary

goal is the consolidation of various technologies by

adding a framework that acts as an abstraction layer.

The implementation is based on OSGi

. The research

of Pichler et al. (2015) therefore additionally com-

pares potential OSGi based solutions for Customer

Energy Management Systems (CEMS). Especially for

security- and privacy-related requirements Pichler et

al. show, that there is still a great need to catch up.

Summing up the lessons learned from the state-

of-the-art analysis, it turns out that there are already

a couple of approaches and frameworks addressing

modular architectures for IoT. Nevertheless, there

are a number of missing features regarding to a

model based approach and the abovementioned

toolchain integration. Under these circumstances, it

makes sense to pursue the implementation of a new,

customized framework, the FRee EDucational Open

System ARchitecture (FREDOSAR). FREDOSAR for

the main part addresses the following features:

Feature Security by Design: The work of Pichler

et al. (2015) points out, that the most popular com-

parable frameworks primarily focus on operational

functionality. Topics like security and privacy are of-

ten disregarded or regarded marginally. For this very

reason, the present work also tries to draw its atten-

tion to applicable security-related research issues, to

make the framework also prepared for trustable envi-

ronments and applications.

Feature Model Based Approach: As FRE-

DOSAR is generally addressing applications in com-

plex, heterogeneous and distributed systems, the

framework should also be designed as a feasible tool

to obtain full traceability according to the stated ap-

proaches in MBSE. The architecture design is guided

by the systems engineering approach proposed by

Neureiter (2017). Model Driven Development (MDD)

in a well-deﬁned environment could close the trace-

ability gap between the model of a system and the

concrete implementation.

https://www.osgi.org/

FREDOSAR: Towards a Security-aware Open System Architecture Framework Supporting Model based Systems Engineering

109

How to Address Security by Design?

A central architecture decision regarding the security

concept is to follow a layered architecture including

appropriate security levels. Thus, there are differing

permissions and restrictions which are bound to the

FREDOSAR layers Core, Management, Service and

Application. Another aspect of the security concept is

a proper integration of common security practices in

regard to integrity and conﬁdentiality as well as mak-

ing use of encryption mechanisms and protocols.

How to Address the Model Based Approach?

Due to the absence of an adequate implementation

platform Neureiter (2017) describes the model based

source code generation as ”rather visionary”. Based

on the SGAM Toolbox and the related toolchain inte-

gration, it is described as one of the research issues

to be further attended to. For that very reason a part

of the toolchain is particularly emphasized in Figure

1. The goal of the depicted Model Based Approach

therefore is the transfer from a detailed functional de-

scription in an architecture model to concrete exe-

cutable software. Regarding this key challenge, the

framework’s architecture has to be designed in a mod-

ular and precisely deﬁned manner, offering clearly

structured interfaces, that can later be traced to de-

tailed architecture model descriptions across the lay-

ers of SGAM.

SGAM Toolbox

Smart Grid Subsystem

FREDOSAR Base SW

Core Services Security

…

FREDOSAR Application SW

FREDOSAR Application

Figure 1: Toolchain Integration.

Basically, the Model Based Approach and

the link to the toolchain is an attempt to enhance

the general awareness concerning the relevance of

MBSE, especially for SoS. Hence, the approach

is applicable for various domains. Applications in

other domains follow the same procedure using other

domain speciﬁc languages and toolboxes like the

RAMI 4.0 Toolbox (described by Binder et al. (2019))

for industrial purposes.

After formulating the most relevant features Sec-

tion 3 pays attention to the requirements engineer-

ing, followed by the concrete implementation of FRE-

DOSAR in Section 4.

3 REQUIREMENTS

The requirements engineering process as well as the

concrete elaborated requirements are based on the in-

tended features. The requirements engineering pro-

cess included software architects, software develop-

ers, domain experts and stakeholders as well as users.

3.1 Non-functional Requirements

The non-functional requirements have been selected

from a number of common quality attributes. The ex-

tracted requirements are listed in Table 1. Finally,

these requirements have been considered as highly

relevant to address the chosen features.

Table 1: Non-Functional System Requirements.

No. Requirement

1.1 Modularity: Separation of Concerns and

Loose Coupling should be fulﬁlled by imple-

menting well-deﬁned interfaces.

1.2 Extensibility: The software should provide

the ability to be simply extended without in-

ﬂuencing the running system.

1.3 Autonomy: The software components on the

application layer should be kept completely

stand-alone according to dependencies be-

tween each other.

1.4 Updatability: The framework should pro-

vide the ability to update any of the systems

software components on the ﬂy.

1.5 Dependability: The software should be kept

reliable and stable and should automatically

react to failures (e.g. by restarting).

1.6 Conﬁgurability: The system should provide

an interface to centrally conﬁgure applica-

tions and/or services.

3.2 Security-related Requirements

This section addresses security-related requirements

that are relevant for service-oriented architectures

(SOA) in critical domains. Based on Hafner et al.

(2008), Conﬁdentiality and Integrity have been taken

as hypernym for a chosen set of security require-

ments. The speciﬁed security-related requirements

that have for now been estimated for FREDOSAR are

listed in table 2. As a basic principle, the systems

architecture should strive towards a secure solution.

Thus, the chosen process for (architecture) develop-

ment includes an ongoing security requirements engi-

neering, approaching upcoming changes regarding to

technology, security or privacy aspects.

SMARTGREENS 2019 - 8th International Conference on Smart Cities and Green ICT Systems

110

Table 2: Non-Functional Security-related Requirements.

No. Requirement

2.1 Integrity: The framework should provide

the ability to verify the integrity of any ap-

plication to be executed.

2.2 Conﬁdentiality: The framework should re-

strict the access to internal communication

channels to a minimum. Each software com-

ponent should only be able to receive content

that directly concerns it.

2.3 Access Control: The framework should con-

ﬁne the service access of applications to a

minimum, considering their deﬁned rights.

2.4 Standard Encryption Protocols Support:

The framework should support the standard

encryption protocols HTTPS and TLS.

3.3 Functional Requirements

In the course of an extensive functional requirements

analysis, it turned out that keeping the functional re-

quirements in the framework’s base software as gen-

eral and clear as possible is necessary to achieve a

comprehensive, well-deﬁned architecture. The more

use case speciﬁc requirements will therefore be dedi-

cated to the corresponding application software. The

ﬁnally elaborated functional requirements are stated

in Table 3. The clarity and abstraction of the chosen

requirements is a fundamental concept to support the

Model Based Approach.

Table 3: General Functional Requirements.

No. Requirement

3.1 Internal Communication Interface: The

software should provide a simple interface

for internal communication between applica-

tions and/or other system components.

3.2 Deﬁned Communication Service Inter-

faces: The software should provide a general

and simple interface to implement any exter-

nal technology or service (I/O) considering

the concomitant communication protocol.

3.3 Deﬁned Communication Data Structures:

The software should deﬁne well-formed data

structures for communication between inter-

nal components or applications as well as

communication to external services.

3.4 Technology- and Address Management:

The system should offer the functionality for

centrally managing multiple communication

technologies and the associated address data.

4 FREDOSAR

This section gives an overview of the concrete archi-

tecture of FREDOSAR as well as an insight into some

implementation details. The results shown are selec-

tive aspects of the associated development. As the

progressing work for FREDOSAR does not only in-

clude the architecture development but also an Open

Source implementation

, this paper also comprises

the most relevant implementation details and technol-

ogy decisions. Based on incentives from the state-

of-the-art for middleware platforms, a SOA has been

chosen, using Java and OSGi for implementation.

Apache Felix

in version 5.4.0 and higher is sug-

gested for execution.

4.1 The Core System

Figure 2 illustrates the component model of the ar-

chitecture. FREDOSAR comprises a layer for Core,

Management and Service components in the basic

software and a layer for Application components in

the application layer.

The major and most important part of FRE-

DOSAR is called the Core system. In short, the Core

deﬁnes all relevant interfaces, the management of ser-

vices, communication, typical data structures and fur-

ther central functionality. A visualization of the Core

can be seen in the green area of Figure 2. It will be

described below.

Interfaces and Types Deﬁnition

In the FREDOSAR core the standard interfaces for

all further components or services are deﬁned and

provided by the Interfaces bundle. For standard

data structures the Types bundle has been established.

It centrally handles and provides previously deﬁned

Data Transfer Objects (DTO). This architectural de-

cision is a crucial step to reach the maximum level

of autonomy. According to the external package de-

pendencies, all other components are therefore only

dependent on these two bundles.

The FREDOSAR Whiteboard Pattern

One of the used patterns for FREDOSAR is a slightly

modiﬁed implementation of the Whiteboard Pattern

(OSGi Alliance, 2004). In the FREDOSAR imple-

mentation, two OSGi Service Trackers have been cou-

pled. This concept guarantees control over service

https://www.fredosar.org

http://felix.apache.org/

FREDOSAR: Towards a Security-aware Open System Architecture Framework Supporting Model based Systems Engineering

111

cmp Component Model

FREDOSAR Basic Software

FREDOSAR Application Layer

Core Management Service

System

OSGi

System

OSGi

«IO»

EnOcean

«IO»

XMPP

«Mgmt»

User Interface

«Mgmt»

Configuration

«Mgmt»

Module

Management

Webserver HTTP

Interface

Authorization and

Authentication

Communication Console Logger

Cryptography

Mapping

Data Storage Interfaces

Messaging

Security

Type Definitions

«Application»

Demand Side Management (DSM)

«Application»

Electric Vehicle Charching (EVC)

«Application»

...

«interface»

...

Figure 2: FREDOSAR Layered Architecture Model.

restrictions during the service injection. The white-

board pattern of FREDOSAR further comprises a spe-

cial convention. If a service or application wants

to access any of the core services, it has to imple-

ment the corresponding aware interface. All in all the

whiteboard pattern has been customized to meet the

needs and requirements of FREDOSAR. This means,

that regardless of whether using service injection or

extending the framework’s functionality with further

services, this pattern must be applied to meet the

FREDOSAR convention.

Internal Communication

The component for internal communication or Inter

Process Communication (IPC) is realized in the Mes-

saging bundle, which is a central unit of the core sys-

tem. The bundle comprises two essential service in-

terfaces. The ﬁrst, the MessageConsumer provides

the ability for applications or other bundles to register

for speciﬁc Topics, which is comparable with a queue

or a channel. The implemented patterns also imply a

solution for a messaging topic restriction for incom-

ing messages. To send an internal message to another

application or component, the second service inter-

face, the MessagingService, can be applied. Having

regard to the restriction for outgoing messages, the

sending applications rights according to the outgoing

topic have to be checked before sending the message.

This is done by the OSGi Service Tracker using a

Proxy Pattern for the management of the individual

rights of applications.

External Communication

The interfaces for external communication have been

realized in the Communication bundle. The services

for the technologies are made available via service

injection and are delivered in a map, including all

permitted service implementations. They can be ac-

cessed by making an application bundle Communica-

tionServiceAware. Each of the supplied services com-

prises a method for sending messages, which has to be

implemented individually for any declared Communi-

cationService. The sending method of the interface

expects a speciﬁc data structure according to the mes-

sage to be sent (EventDTO) as well as a data transfer

object including the receiver information (Address-

DTO). In this respect address management is also part

of the Communication bundle. It is implemented as

AddressService and can be accessed via AddressSer-

viceAware. The service includes functionality for

managing addresses and the associated technologies.

As most external communication services are in

fact bidirectional, a topic for incoming messages has

to be established. Therefore, the internal messag-

ing service is consulted. Each external communica-

tion service in consequence implements the Messag-

ingServiceAware interface and possesses a ﬁxed topic

for incoming messages, which is a reserved string

based on the underlying technology. This pattern has

to be complied with any new external communication

service implementation.

Besides to the above in detail described function-

ality, patterns and services, further implemented gen-

eral core services have to be mentioned in short. In

particular, FREDOSAR also includes a Console Log-

ger, a Web Server implementation, a Data Store ser-

vice interface offering data storage solutions and a

Mapping service for the mapping of Java objects to

deﬁned strings and vice versa. Further aspects to be

discussed are the management an the service layer.

SMARTGREENS 2019 - 8th International Conference on Smart Cities and Green ICT Systems

112

4.2 The Management Layer

The Management layer comprises extension function-

ality for the FREDOSAR Core. More precisely it of-

fers services for conﬁguration, observation and mod-

ule management. Therefore, the management layer as

a whole addresses the conﬁgurability.

The Module Management bundle monitors the life

cycles of all FREDOSAR bundles and provides fur-

ther services or applications to be downloaded from

a central repository. To furthermore achieve an ad-

equate solution for bundle conﬁguration, the OSGi

ConﬁgAdmin service has been extended in the Con-

ﬁguration bundle. As a result, any service or appli-

cation bundle can simply be extended with the Con-

ﬁguredService interface. In combination with the

ManagedService from OSGi it can be used for pre-

conﬁguring service properties as well es updating ser-

vice properties during runtime.

4.3 The Service Layer

The Service layer of FREDOSAR primarily applies

to extensibility and autonomy. From the architecture

viewpoint, the service layer follows a well-deﬁned

process for service extension. As a result, new ser-

vices always have to implement existing core inter-

faces to reach autonomy. This is the major concept of

FREDOSAR services.

The current implementation includes services for

I/O, DataStore, Mapping and Messaging, which can

be seen as extensions and/or alternatives to existing

core services. As FREDOSAR is declared as an open

systems architecture, adding new technology-speciﬁc

services is also a major part of the ongoing implemen-

tation process. At this point of time the service layer

already contains I/O services for RabbitMQ, XMPP,

EnOcean, OPC UA, Serial, P2P, KNX, GPIO, Blue-

tooth and HTTP, DataStore services for JSONFile and

MySQL, a GSON Mapping service and a Messaging

service based on RabbitMQ.

4.4 Security-related Concepts

Regarding the Security by Design feature and the re-

lated requirements, the FREDOSAR core system has

been designed with a complying architecture, cover-

ing several pivotal concepts and services, including

authentication and authorization, a bundle signing and

verifying procedure, a component for general service

restriction management, a concept for FREDOSAR

communication service and channel or topic restric-

tion, and ﬁnally a service dealing with basic crypto-

graphic issues.

Bundle Signing and Veriﬁcation

The bundle signing and veriﬁcation process is a cen-

tral aspect of the FREDOSAR security concept. Basi-

cally OSGi provides a Conditional Permission Admin

(CPA). It is applied within the FREDOSAR core Se-

curity bundle and provides the ability to deﬁne Rules

for any service or application bundle in the OSGi ex-

ecution environment. As a concrete example, the Se-

curity bundle of FREDOSAR implements a Rule for

Core bundles. It grants comprehensive access rights

for bundles that have been signed by the FREDOSAR

core certiﬁcate. This can be done for any layer or ap-

plication.

The fundamental element of this approach is the

OSGi Delegation Model shown in ﬁgure 3. In this ap-

proach the platform Operator assigns speciﬁc rights

to a chosen Enterprise. The rights can be bound to a

certiﬁcate. As a result, the Developer is able to use

all services that are needed for a certain development

proposal, still having restrictions to services that are

not required.

Figure 3: OSGi Delegation Model (OSGi Alliance, 2018).

To accomplish the integrity check, FREDOSAR

performs a signature check by default. For this rea-

son, a Certiﬁcation Authority (CA) has been estab-

lished at the highest level of a Chain of Trust. The CA

is able to sign underlying certiﬁcates, to ﬁnally prove

full integrity for a service in a speciﬁc FREDOSAR

layer or for applications of any enterprise.

Authentication and Authorization

Based on the framework’s deep focus on security, a

dedicated bundle for authentication and authorization

has been implemented. A service for both is part of

the Auth bundle. Authentication for now has been ap-

plied for basic user authentication in the HTTP web

server implementation. However, the user authentica-

tion and authorization service is designed to be sim-

ple and straightforward. Hence, it can be used for

any user interaction purpose and simply be extended

to a token based authentication approach for external

service interaction. Regarding the internal commu-

nication restrictions, the service also implements an

interface for module authorization.

FREDOSAR: Towards a Security-aware Open System Architecture Framework Supporting Model based Systems Engineering

113

Communication Service and Topic Restriction

As already mentioned above, FREDOSAR follows

a strictly deﬁned layered architecture with layer-

speciﬁc security restrictions. Thus, no application has

access rights to do a direct service injection. The in-

jection is handled by means of the Whiteboard Pattern

explained earlier. This is where the ModuleAutho-

rizationService can be integrated to the ServiceAware-

Tracker of the chosen service to be ﬁnally able to

restrain the service injection if needed. This ap-

proach has been implemented for communication ser-

vice restriction in FREDOSAR. In the concrete im-

plementation, the ModuleAuthorizationService holds

a list of authorized applications and the correspond-

ing communication service permissions. To eventu-

ally achieve the rights to use the requested commu-

nication service, the user has to approve the applica-

tions request via the user interface. This is where the

application will be authorized for service injection.

The same procedure in a slightly modiﬁed way is

applied for the internal messaging topic restriction.

Thereby, the consuming application requests a spe-

ciﬁc topic to read from and/or to write to. The ap-

proval for the requested topics is again done by the

user. With the aid of the ModuleAuthorizationService,

the core Messaging service then handles the permis-

sions of all applications and services. If an application

is not permitted to access a topic, the affected message

will not be further processed or forwarded.

Cryptography

The CryptoService is a core service that provides stan-

dard cryptographic methods and security-related pro-

cedures like certiﬁcate and key store handling. To ful-

ﬁll the standard encryption protocols, the Cryptogra-

phy bundle also manages secure sessions for HTTPS

and TLS. Furthermore, it offers hashing functionality

as well as RSA and AES encryption with appropriate

key lengths and algorithms. The CryptoService API

is generally designed with clear and simple interfaces,

making the Cryptography bundle a powerful core ser-

vice for security- and privacy-aware applications.

5 DEMAND SIDE MANAGEMENT

For evaluation, the present work refers to a general as-

sessment approach based on a case study and the con-

sequential appraisal of architects, developers, stake-

holders and users. During the development process

of FREDOSAR, various case studies have been estab-

lished and implemented as PoC FREDOSAR applica-

tions (FRAPPS

). Smarthome, Ambient Assisted Liv-

ing, Smart Metering, Demand Side Management and

Electric Vehicle Charging are some of the energy do-

main related FRAPPS. For the framework (architec-

ture) evaluation, Demand Side Management (DSM)

has been taken into consideration.

One of the major problems of Smart Grids is the

unpredictability of the generated energy from renew-

able energy systems. The goal of DSM therefore is to

achieve power grid stability by controlling huge elec-

trical loads (e.g. heat pumps). DSM has been im-

plemented as a PoC FRAPP, including a number of

”real” consumers in a demo world model.

The primary focus during the DSM development

was the veriﬁcation of the general functional require-

ments of FREDOSAR. Therefore, requirement 3.2

has been tested by making use of two external Com-

municationServices, GPIO for LEDs simulating the

electrical loads and RabbitMQ for the communication

between the Distribution System Operator (DSO) and

the CEMS. External communication in FREDOSAR

is usually accompanied by technology- and address

management (requirement 3.4). Therefore, the Ad-

dressService has been implemented and tested. An-

other aspect of DSM is the individual load control. In

this context the DSO sends control commands to the

CEMS concerned. This is where the internal Messag-

ing has been deployed and requirement 3.1 has been

veriﬁed. The whole communication procedure has to

be built upon clear data structures (requirement 3.3).

Hence, a DTO for the control commands has been

constructed and tested regarding its simplicity of inte-

gration. A ﬁnal issue was that the Web Server service

was used to run a RESTful JSON API for the front-

end. The whole execution was automatically logged

by the Logging module.

Another important aspect about the DSM devel-

opment was the veriﬁcation of security-related re-

quirements. The goal was to develop DSM in a

security-aware manner using the given functionality

and the suggested practice of FREDOSAR. Follow-

ing the OSGi delegation model, a certiﬁcate of the

enterprise DSM was signed by the FREDOSAR CA,

giving DSM related applications access to the needed

services and allowing them to be executed in the FRE-

DOSAR execution environment. Both, the integrity

check (requirement 2.1) and the system function re-

striction (requirement 2.3) turned out to be fulﬁlled,

as the execution was denied in cases where the ap-

plication tried to circumvent one of the restrictions.

The requirements 2.2 and 2.3 furthermore are a fun-

damental demand for any FREDOSAR application.

Thus, the entitlement to conﬁdentiality has been im-

https://ressel.fh-salzburg.ac.at/FREDOSAR-Frapps

SMARTGREENS 2019 - 8th International Conference on Smart Cities and Green ICT Systems

114

plemented using pre-deﬁned, dedicated communica-

tion topics for DSM applications (requirement 2.2).

Besides, the communication service restriction (re-

quirement 2.3) has been added to the DSM applica-

tion as prescribed by the FREDOSAR convention. In

terms of requirement 2.4 and the standard encryp-

tion protocols support, the abovementioned RESTful

JSON API fulﬁlls the conditions of HTTPS, and the

RabbitMQ communication implemented meets the re-

quirements of TLS. Hence, the whole range of the

security-related requirements has been implemented,

veriﬁed and validated regarding its applicability.

Regarding the evaluation process carried out, it

turned out that Security by Design led to a quite com-

plex system architecture and a sophisticated imple-

mentation. Even though most of the security mech-

anisms have been simpliﬁed as effectively as possi-

ble, the additional complexity could act as a deterrent

for potential developers, especially in cases where se-

curity plays a secondary role. However, because of

the general criticality of applications in the energy do-

main, security and privacy will deﬁnitely remain rel-

evant for FREDOSAR and its further research topics.

6 CONCLUSION AND FUTURE

WORK

The present work has made it a goal to accomplish

a trustable, versatile OSGi-based open system archi-

tecture for application in complex systems and SoS.

Based on previous research in the ﬁelds of security

in Smart Grids and MBSE and the analysis of re-

lated work, a number of features and requirements

have been established for the architecture develop-

ment. The primary focus was on Security by Design

and the Model Based Approach. The results of the

architecture and some insights into the development

have been presented.

Basically, the continuing research will focus on

further attempts regarding MBSE and the correspond-

ing MDD process for the toolchain integration. In the

ﬁrst step an automated process for code generation in

the style of a FREDOSAR application will be inte-

grated. Combined with a co-simulation approach for

complex systems, thereby a sustainable, automated

life-cycle management process for Smart Grid sys-

tems and other SoS should be achieved. Another

security-related aspect will be the integration of End-

to-End security for applications including a Hardware

Security Module (HSM) for encryption. FREDOSAR

therefore will ﬁnally serve as a base framework to do

these further steps.

ACKNOWLEDGEMENTS

The ﬁnancial support by the Federal State of Salzburg

is gratefully acknowledged.

REFERENCES

Avizienis, A., Laprie, J.-C., Randell, B., and Landwehr, C.

(2004). Basic concepts and taxonomy of dependable

and secure computing. IEEE transactions on depend-

able and secure computing, 1(1):11–33.

Binder, C., Neureiter, C., Lastro, G., Uslar, M., and Lieber,

P. (2019). Towards a standards-based domain speciﬁc

language for industry 4.0 architectures. In Complex

Systems Design & Management, pages 44–55, Paris,

France. Springer International Publishing.

urst, S., M

ossinger, J., Bunzel, S., Weber, T., Kirschke-

Biller, F., Heitk

amper, P., Kinkelin, G., Nishikawa, K.,

and Lange, K. (2009). Autosar–a worldwide standard

is on the road. In 14th International VDI Congress

Electronic Systems for Vehicles, volume 62, Baden-

Baden, Germany.

Haberfellner, R., de Weck,, O., Fricke, E., and V

ossner, S.

(2015). Systems Engineering - Grundlagen und An-

wendung. Orell F

ussli, 13 edition.

Hafner, M. and Breu, R. (2008). Security engineering for

service-oriented architectures. Springer Science &

Business Media. Berlin Heidelberg, Germany.

Knirsch, F., Engel, D., Neureiter, C., Frincu, M., and

Prasanna, V. (2015). Model-driven privacy assessment

in the smart grid. In 2015 International Conference on

Information Systems Security and Privacy (ICISSP),

pages 173–181, Angers, France. SciTePress.

Kreuzer, K. (2014). openHAB 2.0 and Eclipse

SmartHome. http://kaikreuzer.blogspot.de/2014/06/

openhab-20-and-eclipse-smarthome.html.

Maier, M. W. (1998). Architecting principles for systems-

of-systems. Systems Engineering: The Journal of

the International Council on Systems Engineering,

1(4):267–284.

Neureiter, C. (2017). A Domain-Speciﬁc, Model Driven

Engineering Approach for Systems Engineering in the

Smart Grid. MBSE4U - Tim Weilkiens.

Neureiter, C., Eibl, G., Engel, D., Schlegel, S., and Uslar,

M. (2016). A concept for engineering smart grid se-

curity requirements based on sgam models. Computer

Science - Research and Development, 31(1):65–71.

OSGi Alliance (2004). Listener pattern considered harm-

ful: The whiteboard pattern. https://www.osgi.org/

wp-content/uploads/whiteboard1.pdf.

OSGi Alliance (2018). OSGi service platform, core speciﬁ-

cation. https://osgi.org/speciﬁcation/osgi.core/7.0.0/.

Pichler, M., Veichtlbauer, A., and Engel, D. (2015). Evalua-

tion of OSGi-based architectures for customer energy

management systems. In Proceedings of IEEE Inter-

national Conference on Industrial Technology (ICIT)

2015, pages 2455–2460, Seville, Spain. IEEE.

FREDOSAR: Towards a Security-aware Open System Architecture Framework Supporting Model based Systems Engineering

115