Situation-Aware Management of Cyber-Physical Systems

alm

an K

epes, Uwe Breitenb

ucher and Frank Leymann

Institute of Architecture of Application Systems, University of Stuttgart, Universit

atsstraße 38, 70569 Stuttgart, Germany

Keywords:

Application Management, Cyber-Physical System, Situation-Aware System, TOSCA.

Abstract:

The current trend of connecting the physical world with the so-called cyber world resulted in paradigms such

as the Internet of Things or the more general paradigm of Cyber-Physical Systems. The wide range of do-

mains applicable results in a heterogeneous landscape of software and hardware solutions. To beneﬁt of the

paradigm, developers must be able to integrate different solutions from a range of different domains. How-

ever, these systems must therefore be able to change components, conﬁgurations and environments, hence, be

adaptable at runtime. We present an approach that is based on the combination of Situation-Aware Adaptation

concepts and Deployment Models. The general idea is to start processes that can change application structure

and conﬁguration when a certain situation in the context of applications occur. We validated the technical

feasibility of our approach by a prototypical implementation based on a Smart Home scenario.

1 INTRODUCTION

The current trend of connecting the physical world

with the so-called cyber world results in applica-

tions that depend on integrated software and hardware

components that created paradigms such as the Inter-

net of Things (IoT) (Atzori et al., 2010) or the more

general paradigm of Cyber-Physical Systems (CPS)

(Gunes et al., 2014). There is a wide range of possi-

ble scenarios for applying CPS, such as the domains

of health care (Haque et al., 2014; YIN et al., 2016),

mobility (Guo et al., 2017; Zorzi et al., 2010) and

energy (Andr et al., 2011; Shrouf and Miragliotta,

2015), that promise a seamless integration within our

everyday life. To beneﬁt of the CPS paradigm, de-

velopers must be able to integrate different CPS solu-

tions either by using single or a whole set of software

and hardware components. A CPS that controls cer-

tain aspects of a Smart Home must be able to adapt to

changes at runtime, enabling a home owner to contin-

uously extend the system with new functionality.

However, achieving adaptability, i.e., reconﬁgura-

bility in CPS is a complex challenge. The chang-

ing of CPS has to regard aspects, such as, changes

to infrastructures, system conﬁguration, components

and users, therefore CPS must be aware of their con-

text. The research ﬁeld of Context-Aware Systems

(CAS) investigates the challenge of making applica-

tions aware and adaptable to their context. According

to Dey context can be deﬁned as ”..any information

that can be used to characterize the situation of an en-

tity.” (Dey, 2001) which can be categorized into, e.g.,

spatial-, temporal-, device- and environmental context

(Knappmeyer et al., 2013). Therefor applying con-

cepts of CAS to CPS is a promising way to achieve

high adaptability, as already identiﬁed by Perera et al.

(Perera et al., 2014). The execution of management

logic at the right time in and state of the context of

a CPS enables it to be situation-aware and therefore

enable the Situation-Aware Management of CPS.

In this paper our approach is to use Manage-

ment Process that are able to execute various tasks,

such as, storing backups, scale up or update compo-

nents. These processes are combined with situations

aussermann et al., 2010; Wieland et al., 2015) that

can occur for physical or virtual ’things’ and are ob-

served in separated applications with the sole purpose

of the observing situations occurring to things. Based

on the occurred situations it is possible to execute

logic at runtime, therefore, enabling Situation-Aware

Management of running CPS applications. We proto-

typically implemented our approach in the language

TOSCA with a Smart Home scenario.

This paper is structured as follows: In Section 2

we describe a motivating scenario and background.

We describe our approach on integrating Situations

and Management Processes in Section 3. Section 4

describes our prototypical implementation of the ap-

proach. Related work is discussed in Section 5. We

conclude and outline future work in Section 6.

Képes, K., Breitenbücher, U. and Leymann, F.

Situation-Aware Management of Cyber-Physical Systems.

DOI: 10.5220/0007799505510560

In Proceedings of the 9th International Conference on Cloud Computing and Services Science (CLOSER 2019), pages 551-560

ISBN: 978-989-758-365-0

551

Light&Control

Version:&1.0

..0

0…

Update&Light&Control&

to new Version

Update&only when the

update&files are available

Update&when the device

has enough energy

Update&only when the

owner is not&at&home

IoT Device

Light&Control

Version:&1.1

IoT Device

..and..

Figure 1: Motivating example scenario, depicting the need for CPS to adapt according to the current context.

2 MOTIVATION &

BACKGROUND

This section describes our motivational scenario for

Situation-Aware Management of CPS and a short

overview of the SitOPT project that researched the

adaptation of Workﬂows based on situations.

In industry and research the current trend of in-

tegrating physical entities that are not in the do-

main of IT with software components emerged to

be paradigms such as IoT (Atzori et al., 2010;

Gubbi et al., 2013) or the more general paradigm of

CPS (Gunes et al., 2014). These paradigms are at the

core a combination of software and hardware systems

that monitor their physical and virtual environment

based on sensors and act with the help of actuators

connected. There is a wide range of scenarios to ap-

ply CPS, such as, healthcare (Haque et al., 2014; YIN

et al., 2016), mobility (Guo et al., 2017; Zorzi et al.,

2010) and energy (Andr et al., 2011; Shrouf and Mi-

ragliotta, 2015). Each system operates in a different

domain but can overlap, e.g., a healthcare application

to monitor high-risk patients can utilize mobility solu-

tions to call an ambulance. Therefore, the integration

of different CPS, hence, the combination of domains

yields great beneﬁts but is also one of the main chal-

lenges of CPS (Gunes et al., 2014), as with each com-

bination these systems get more complex, error-prone

and harder to maintain. The Reconﬁgurability (Gunes

et al., 2014) of these systems must ensure that they

can adapt themselves to changing requirements, envi-

ronments and components at runtime. For example, a

change on requirements regarding performance may

need to scale up certain components, a change in the

environment would start reconﬁguration of the net-

work, while a change of the components themselves,

such as a new version, could change the conﬁguration

of the overall system. Therefore designing CPS in a

context-aware manner (Perera et al., 2014) to enable

such adaptations (Muccini et al., 2016) is a promis-

ing direction. According to the widely used deﬁni-

tion by Dey context can be deﬁned as ”..any informa-

tion that can be used to characterize the situation of

an entity.” (Dey, 2001), therefore a plethora of differ-

ent data sets can be used to describe the situations in

the context of a CPS, such, as location, environment,

people, devices and activities, all with their describing

attributes such as GPS coordinates, the type of envi-

ronment, the roles of users, the capabilities of devices

and running processes. In Figure 1 we depict a Smart

Home scenario that needs an approach for Situation-

Aware Management. A running CPS application run-

ning on a local device monitors movement in rooms

and turns on light if movement is detected (See mid-

dle in Figure 1), therefore controlling the energy con-

sumption. This system can may need update proce-

dures as the Light Control application must enable the

connection to new light systems or patch open secu-

rity issues. However, the update, i.e., the adaptation

of such a system should be achieved preferably in an

autonomous manner and not interrupt the function-

ality when it is needed, e.g., updating when a user

wants use functionality will disrupt the availability,

thus, reduce customer satisfaction. Therefore, the up-

date should only be started when a system owner is

not at home, the device has enough energy to exe-

cute the update and still be able to run the application

for an appropriate amount of time; and an update is

available on the internet (See right hand side in Figure

1). This means a management system must be able

to monitor different entities and their situations, such

as, the location of people, the battery levels of devices

and updates ﬁles on servers. To detect situations, con-

text data combined with management operations must

be incorporated which is a complex and error-prone

task, as developers have to deﬁne ﬁne-grained states

in context and complex management tasks.

To cope with the challenge of modeling appli-

cations to be able to adapt to context the SitOPT

(Wieland et al., 2015) project developed the concept

of Situation-Aware Workﬂows. In SitOPT the basic

concept for context was enhanced to so-called Situa-

tions modeled within Situation Templates, a modeling

concept to enable the modeling of situations that oc-

cured to so-called Things (H

aussermann et al., 2010;

Hirmer et al., 2017). This abstraction allows modelers

to deﬁne arbitrary situations for physical and virtual

entities which encapsulate low-level context informa-

tion and therefore ease the modeling of Context-, i.e.,

Situation-aware applications or the management of

applications, on which our approach is based on.

CLOSER 2019 - 9th International Conference on Cloud Computing and Services Science

552

Situation(Detection Deployment Models

Situation-Aware(

Management(Process Models

Deployment &(Situation-Aware(

Management(System

Situation(Detection Layer

Situation-Aware(Management(Layer

Application Instance

Situation(Detection Instances

Modeling(

Runtime &(Management

..0

0…

Deployment

Model

..0

0…

Update(Process

…

Update(Process

…

Update(Process

…

Application Package

✔

✗

Figure 2: Overview of our Situation-Aware Deployment and Management System enabling Situation-Aware Management of

applications.

3 SITUATION-AWARE

MANAGEMENT

In this section we describe an overview of our ap-

proach to enable Situation-Aware Application Man-

agement in Subsection 3.1, a detailed description of

the modeling concepts in Subsection 3.2 and runtime

aspects in Subsection 3.3.

3.1 Concept Overview

In the following we give an overview of our approach

depicted in Figure 2. The basis are Application

Packages (See 1 in Figure 2) that contain a Deploy-

ment Model, so-called Situation-Aware Management

Process Models and Situation Detection Deployment

Models. A Deployment Model speciﬁes the structure

of applications, e.g., the software-, hardware compo-

nents and relations among each other. Additionally,

the Situation-Aware Management Process Models de-

ﬁne the possible tasks on an application instance, e.g.,

to backup the contents of state-full components, up-

date components to new versions or scale up parts of

the application. These processes are annotated with

Situation-Aware Process Triggers that specify a cer-

tain set of situations that must hold to start a process,

e.g., when an user is not at home, a device has enough

energy or there is an update available. The second part

of an application are Situation Detection Deployment

Models that encapsulate the detection of certain situa-

tions. Such a model is another Deployment Model, as

the applications’ Deployment Model itself, but speci-

ﬁes a utility application that is able to detect the spec-

iﬁed situations, e.g., an instance of SitOPT Middle-

ware (Wieland et al., 2015) with suitable Situation

Templates, a Python application reading the battery

levels on a Raspberry Pi or a simple Cron job check-

ing for software updates on the Internet. A Situation

Detection Deployment Model therefore speciﬁes the

kinds of situations it can detect, these situations are

referenced by Situation-Aware Management Process

Models within the Situation-Aware Process Triggers.

After having modeled the Deployment Model,

Processes and necessary Situation Detection Deploy-

ment Models the complete Application Package is up-

loaded to the Deployment & Situation-Aware Man-

agement System (See 2a in Figure 2). The system is

responsible for creating instances from the given De-

ployment Model and Situation Detection Deployment

Models by installing, conﬁgure and starting the mod-

eled software components according to their speciﬁ-

cation, e.g., installing necessary packages, uploading

and starting Python scripts on a Raspberry Pi. This

deployment process starts with the creation Situation

Detection Deployment Model instances, which is a

mandatory to be started ﬁrst as the detection of situa-

tions must be available (See 2b in Figure 2) before an

instance of an application can be created (See Subsec-

tion 3.2 for more details). After instances of Situation

Detection Deployment Models are available users can

create instances of the application itself (See 2c in

Figure 2), by requesting the system to install, con-

ﬁgure and start software components speciﬁed within

the applications’ Deployment Model. Additionally, to

creating such instances, the attached Situation-Aware

Management Process Models deployed within the de-

ployment system are bound against the situations de-

tected by the system and therefore creating an in-

stance of a Situation-Aware Process Trigger that will

start a process attached to it when the speciﬁed situa-

tions occur, i.e., are active.

Situation-Aware Management of Cyber-Physical Systems

553

Situation-Aware.Application Instance

Situation.Recognition.Instance

Deployment &.

Situation-Aware.Management.

System

Situation(Description

SituationId:.@Runtime

Situation.Template:.50Energy

Thing.Ids:.@Runtime

Thing.Types:.Raspberry Pi

Situation(Description

SituationId:.@Runtime

Situation.Template:.50Energy

Thing.Ids:.@Runtime

Thing.Types:.Raspberry Pi

Situation(Description

ID:.[SetByRuntime]

Situation.Id:.[SetByRuntime]

Situation.Type:.50Energy

Thing.Ids:.[SetByRuntime]

Thing.Types:.Raspberry Pi

Situation-Aware(Process Trigger

ID:.[SetByRuntime]

Process ID:.UpdateProcess

Single.Instance:.true/false

Situation.Descriptions:.[BoundAtRuntime]

✔

✗

Figure 3: Modeling details of a Situation Detection Deployment Models and Situation-Aware Management Process Models.

The runtime aspects of the system are in gen-

eral the following: (i) the running Situation Detection

Model Instances are continuously monitoring their re-

spective situations and send the current state to the

Situation Detection Layer of the system (See 3a in

Figure 2). As the situations are referenced within

Situation-Aware Process Triggers a change of a sit-

uation state activates such a trigger and therefore

starts an instance of the respective Management Pro-

cess (See 3b in Figure 2). These Management Pro-

cesses are invoked within the Situation-Aware Man-

agement Layer and interact with the running applica-

tion to achieve the speciﬁed management tasks, such

as, backing up, scale up and updating software com-

ponents (See 3c in Figure 2)

3.2 Modeling based on Situations

In the following we describe the modeling of appli-

cations and their Situation-Aware Management Pro-

cesses of our approach in detail (See Figure 3).

A Situation Recognition Deployment Model de-

scribes an application that enables to observe situa-

tions of relevant entities in the context of a system.

The recognized situations are exposed in so-called

Situation Descriptions (See left-hand side in Figure

3). A Situation Description contains a unique identi-

ﬁer for a single speciﬁc Situation Type (e.g. Situation

Template in SitOPT) and also a set of unique identi-

ﬁers for Thing Types. While a Situation Type speci-

ﬁes what kind of situation the Situation Recognition

Model is able to observe, the set of Thing Types spec-

iﬁes what kind of things, e.g., a sensor, Raspberry Pi

or people, are needed to observe the situation. A Situ-

ation Description basically deﬁnes what kind of situa-

tion can be detected by a Situation Detection Deploy-

ment Model. While Situation- and Thing Types are

used to deﬁne the type of situations and things at run-

time a description additionally speciﬁes the runtime

identiﬁer of a situation as a Situation Id and for things

a set of Thing Ids (e.g. a MAC address of a Pi)for

which a situation detection is executed, i.e., a Situa-

tion Description is always bound against a concrete

set of physical or virtual objects. When an applica-

tion is deployed, each Situation Reference is bound

against a concrete set of things and therefore a situ-

ation detection is started. The binding of things and

situation against a reference can be achieved by differ-

ent methods such as binding by an input value from

the runtime at instantiation time of applications (indi-

cated by an [SetByRuntime] for SituationId and Thing

Ids in Situation Descriptions) or methods that try to

automate the binding such as the work of Hirmer et

al. (Hirmer et al., 2017).

To enable the triggering of processes we de-

ﬁne Situation-Aware Process Triggers that model the

binding between observed situations and management

logic (See right-hand side in Figure 3). This binding

is based on the references to Situation Descriptions

and a Management Process used by Situation-Aware

Process Triggers. A Situation-Aware Process Trigger

has at least one reference to a Situation Description

and exactly one reference to a Management Process.

At runtime a set of referenced situations is evaluated

in a conjunction, i.e., all of the observed situations are

interpreted as a binary value which are then evaluated

with an AND-function over the values.

To deﬁne on which Management Process is started

we deﬁne the Process ID attribute (See right-hand

side in Figure 3) on Situation-Aware Process Triggers.

A Process ID references a Management Process by

its identiﬁer inside its application package. As there

are different management tasks to be executed some

may inﬂuence the availability of an application, e.g.,

a backup, update or test of an application component

may directly inﬂuence the performance of the overall

CLOSER 2019 - 9th International Conference on Cloud Computing and Services Science

554

Situation(Detection Layer

Situation-Aware(

Management(Layer

Fetch new

Version

Install

new Version

Update((

Relations

…

v1.0

v1.1

Repository,..

v0.1

v2.1

v1.1

2 3

✔

✗

Figure 4: Details of adapting an application instance by Management Process in a Situation-Aware manner.

application. To control the execution of multiple in-

stances of Management Process, e.g., because the sit-

uations change often and force the triggering of pro-

cesses, we deﬁne the Single Instance attribute for Pro-

cess References. This forces the runtime to allow the

execution of a trigger only when there is no instance

of a Management Process already running, enabling

to control the number of executions of a trigger.

3.3 Using Situations at Runtime

In this subsection we describe the runtime aspects

(See Figure 4), such as, registration of situations

at the Situation Detection Layer, the observation by

Situation-Aware Process Triggers and how Manage-

ment Processes are invoked and adapt a running ap-

plication. Before the Situation-Aware Management

of applications is possible the Situation Recognition

Deployment Models must be deployed and instanti-

ated (See 1 in Figure 4), i.e., the Deployment and

Situation-Aware Management System creates an in-

stance of the models by creating, conﬁguring and

starting components deﬁned inside the Situation De-

tection Deployment Models, e.g., installing packages

and applications on a Raspberry Pi. However, the

components that are responsible for the detection of

the situations are conﬁgured to be bound against the

Situation Detection Layer of the system to enable the

observation of the current state of the deﬁned situa-

tions. Note, that the binding between the Situation

Detection Components of these Deployment Models

must be able to communicate with the Situation De-

tection Layer, i.e., these detection components must

use the available protocols, data formats and a have

network connection at runtime, which in different sce-

narios may be a challenging technical issue, e.g., a

pulling protocol from the cloud inside a Smart Home.

Another aspect of the instantiation of Situation De-

tection Deployment Models is the binding of concrete

things. The used identiﬁers must be unique for each

thing observed, e.g., a MAC address and credentials

identifying a Pi, a URI that speciﬁes a software arti-

fact, a name and birth date for persons. These identi-

ﬁers can be given as input to the instantiation or use

methods such as those by Hirmer et al. and Urbieta et

al. (Hirmer et al., 2016; Urbieta et al., 2017).

After the deployment and instantiation, and

therefore starting the observation of situations, the

Situation-Aware Management Layer can use the

observed situations to bind initially and trigger

Situation-Aware Process Triggers (See 2 in Figure

4). The binding of a Situation-Aware Process Trig-

ger against concrete situations, i.e., the observation of

things and the possible situations their are in is done

at instantiation time of the application that should be

managed in a situation-aware manner. At instantia-

tion time the concrete identiﬁers of the needed sit-

uations that are deﬁned by the referenced Situation

Descriptions of each Situation-Aware Process Trigger

can be given, e.g., as input to the instantiation pro-

cess or derived by more sophisticated methods such

as semantically binding the situations to the applica-

tion. After binding Situation-Aware Process Triggers

to concrete situations the Situation-Aware Manage-

ment Layer is responsible for observing the situations

with the help of the Situation Detection Layer an ﬁre

triggers as speciﬁed, i.e., a Situation-Aware Process

Trigger only starts a process if all of its situations are

active. This means if a Situation-Aware Process Trig-

ger is speciﬁed to observe, as in our motivational sce-

nario, the availability of an update, of enough energy

and users are not present, it will only trigger the up-

date process when all of the situations are active.

The last part enabling the Situation-Aware Man-

agement of applications are Management Processes.

These are triggered by the Situation-Aware Pro-

cess Triggers that are actively observed inside the

Situation-Aware Management Layer. A Management

Situation-Aware Management of Cyber-Physical Systems

555

Apache'ODE

Situation'API

Management'Bus

SitOPT

Situation Handler

Situations

….

Raspbian

Python''App

Light

Fetch new

Version

Install

new Version

Update''

Relations

Energy

Detector

User'

Detector

OpenTOSCA Runtime

Situation-Aware'Management'Layer

Situation'

Detection

Layer

Situation'

API

OT'

Runtime

Raspbian

Python'App Light

Energy Sit

User'Sit

…

BPEL

Fetch..

Install..

Update..

…

TOSCA

V1.1

Update'Sit

Winery

Update'

Detector

Winery

….

Situation'Detection Deployment Model

TOSCA

…

Deployment Model

Situation-Aware'Management'Processmodels

…

TOSCA'Extension

Figure 5: Overview of our prototypical implementation within the OpenTOSCA Ecosystem.

Process can implement any kind of management task

in any kind of language that is able to alter the con-

ﬁguration of applications at runtime. We propose the

use of Workﬂow Technology that is proven in indus-

try enabling properties such as transactional execution

and compensation, parallel execution, recoverability,

error handling or traceability (Leymann and Roller,

2000). For example, the update process of our mo-

tivational example can fetch the newest version of a

component, install it and reconﬁgure needed compo-

nent relations of application (See 3 in Figure 4).

4 PROTOTYPICAL

IMPLEMENTATION

In this section we describe our prototypical im-

plementation based on the OpenTOSCA Ecosys-

tem(Binz et al., 2013)

enabling the modeling and

deployment of applications based on the language

TOSCA(OASIS, 2013b; OASIS, 2013a; OASIS,

2015), which was originally created for Cloud Appli-

cations but also was used for IoT applications (Franco

et al., 2017).

The motivating scenario was prototypical imple-

mented based on different Python scripts that are de-

ployed and started on a single Raspberry Pi (See up-

per and lower left-hand side in Figure 5). For the

Light Control application we used a simple script that

can periodically switch a power socket On and Off

that was connected to a light. The Energy Moni-

toring Python application was prototypically imple-

mented by checking whether the Pi is connected to a

power outlet which implies that there is enough en-

https://www.github.com/OpenTOSCA/

ergy, hence, over 50%. To check the situation that

there is an update ﬁle available a Python script contin-

uously checked a repository of OpenTOSCA Winery

whether an archive with a new version of the Light

Control is available. The AtHome check was simu-

lated by altering the situations state periodically every

minute, we plan to implement this situation recog-

nition with real GPS values received from a Smart-

phone. The Update Process was implemented in the

workﬂow language BPEL, which would check for the

latest version of the light controlling Python script,

fetch it, upload it to the Raspberry Pi and exchange it

with the old script.

After implementing the necessary scripts to con-

trol the light and observe the necessary situations

we modeled a TOSCA application for the situation

recognitioning and application itself and extended

the Runtime OpenTOSCA Container

with the Situ-

ation Detection Layer and Situation-Aware Manage-

ment Layer to be able to hande the applications. The

TOSCA applications used newly created generic Sit-

uation Detection Component as a TOSCA Node Type

(i.e. Component Type) that can register Situations

based on Situation Description and modeled proper-

ties such Situation Type, Thing Types, Situation Id,

Thing Ids and receive an endpoint to the Situation De-

tection Layer. Each Python Script is able to receive

endpoint data from the modeled Situation API com-

ponent inside their deployment models (See black-

bock in the left of Figure 5) and would receive the

endpoint to send the current state of the situation they

are observing. The Situation Detection Layer was im-

plemented by the Situation API which allows to store

Situation Descriptions and manipulate the state of the

https://projects.eclipse.org/projects/soa.winery

http://opentosca.github.io/container

CLOSER 2019 - 9th International Conference on Cloud Computing and Services Science

556

registered situations (See middle in Figure 5). To en-

able the triggering of processes based on situations we

implemented the Situation-Aware Management Layer

on top of the already available Management Bus of

the runtime which already could invoke Management

Process implemented in BPEL. The Situation-Aware

Management Layer was implemented by integrating

the already available Management Bus of the Open-

TOSCA Runtime with the Situation Handler compo-

nent of the SitOPT project (Wieland et al., 2015) (See

middle in Figure 5). In SitOPT the Situation Han-

dler was responsible for enabling the registration of

notiﬁcations when situations changed or invoke ser-

vices based on situations, i.e., invoking different ser-

vice implementations when different situations were

active. Based on this integration the Situation-Aware

Process Triggers, which were mapped as TOSCA ap-

plication properties, are registered as notiﬁcations to

the Management Bus of OpenTOSCA which can in-

voke the processes speciﬁed in the TOSCA applica-

tions. These processes are implemented in the work-

ﬂow language BPEL (OASIS, 2007) and are deployed

on and executed in the workﬂow engine Apache ODE

(See upper right in Figure 5). The necessary runtime

information, such as, Situation Ids are requested by

the extended OpenTOSCA Runtime when an applica-

tion is instantiated by reading it from the input.

5 RELATED WORK

In this section we present related work on the domains

of CAS (Baldauf et al., 2007), application provision-

ing and management, and adaptation. There are mul-

tiple surveys on adaptability (Mens et al., 2016; Da

et al., 2012; Kakousis et al., 2010; Muccini et al.,

2016) and describe different methods for adapting ap-

plication at runtime, but in the following we focus on

(Context-Aware) adaptation of applications.

The domain of Adaptation Systems has broad ap-

plication areas because of the wide-range of factors

that inﬂuence a system to adapt itself. According Da

et al. (Da et al., 2012) there are three types of adap-

tations: Reactive Adaptation, Evaluative Adaptation

and Adaptation for Integration. Reactive Adaptation

is used to react on changes in the environment, such

as, network changes or user preferences. Evaluative

Adaptation is the category of adaptations that inﬂu-

ence the functionality, performance and error han-

dling of a system. The last adaptation type is called

Adaptation for Integration that tries to overcome the

issue of incompatible components of software and

hardware, e.g., by changing implementations or pro-

tocols between components. All of the three types

can be implemented based on the proposed approach

inside Management Processes.

Baldauf et al. (Baldauf et al., 2007) present

a survey about Context-Aware Systems focusing on

architectures and design principles, followed by an

overview of Context-Aware Middlewares. They in-

troduce a layered conceptional architecture that has

sensors on the lowest layers, which are read by the

next layer of data retrieval. Raw data is then passed to

the Preprocessing layer where the results are stored in

the Storage/Management Layer, that can be used by

the last layer called Application layer. Our proposed

approach can be categorized according to Baldauf et

al. as our approach has the Situation Detection Layer

and the Situation-Aware Management Layer on top.

Muccini et al. (Muccini et al., 2016) present a

Systematic Literature Review on Self-Adaptation of

CPS. They investigated the use of adaptation tech-

niques in CPS, such as, concerns, on which area these

are applied or their domains. One of the insights given

by Muccini et al. is that most approaches are used

for performance optimization and increased ﬂexibil-

ity. Most of the techniques targeted the application

layer instead of the infrastructure. In the investigated

works the used techniques used different feedback

loop mechanisms, with MAPE (Monitor, Analyse,

Plan and Execute) functions being the most used ones.

From the found works and analysis a layered adapta-

tion model consisting out of an Application layer on

top of Context Management Layer that uses the un-

derlying Physical Layer is proposed. Our approach

can be categorized into the same layers, although we

don’t use on the MAPE technique, as used in most

approaches according to Muccini et al.

Saller et al. (Saller et al., 2013) present an ap-

proach for the context-aware adaptation of dynamic

software product lines based on extended feature

models. A feature model enables to specify a set of

features and relations among each other, e.g., a feature

is an alternative to another, a feature requires another

feature or is optional. Based on such feature models

Saller et al. extend them based on a Context Model

where a mapping between the features and context en-

tities is deﬁned to state whether a feature can be used

under a certain context. These models are used to

adapt applications at runtime by monitoring the con-

text and adapting the currently active features. In con-

trast to our approach Saller et al. adapt the application

model directly while our approach uses Management

Process that also allow to execute management logic

that is not limited to reconﬁgurations of the applica-

tion but also enables tasks, such as, storing backups.

Breitenb

ucher et al. (Breitenb

ucher et al., 2015)

present an approach to enable the modeling of work-

Situation-Aware Management of Cyber-Physical Systems

557

ﬂow models in a situation-aware manner. The basic

idea is to enable the modeling of events and areas

in the control ﬂow of a workﬂow model that either

start the execution of activities or enable the execu-

tion of activities only when certain situations occured

or are active. This approach is build on so-called Sit-

uation Events and Situational Scopes. A Situation

Event is an event trigger inside a workﬂow model that

can be connected to other activities inside the con-

trol ﬂow and when activated, i.e., a situation is ac-

tive, triggers the execution of the connected activities.

To enable the execution of a group of activities only

when a certain situation is active, Breitenb

ucher et al.

introduce Situation Scopes that enable to specify a

set of activities inside the workﬂow models’ control

ﬂow. These concept enable to model workﬂows to

be situation-aware and therefore enable modelers to

add adaptation logic directly into their models. The

main difference to our approach is that the Situation-

Aware Adaptation is focused on the control-ﬂow of

applications, while our approach is focused on adapt-

ing application structures. A combination of both

approaches could make the Management Processes

within our approach adapt at runtime.

The ACCADA framework introduced by Gui et al.

(Gui et al., 2009) targets the context-aware deploy-

ment and adaptation of software components. These

software components are monitored in a continuous

loop by an Event Monitor that informs a Structure

Modeler responsible for composing the different com-

ponents in the system on a functional level, such as,

binding the components according to their dependen-

cies. As the Structure Modeler is only responsible

for composing the components based on this func-

tional level a set of Context-speciﬁc Modelers are

responsible for adapting the structure of the compo-

nents and relations based speciﬁc context-related con-

straints. These Context-speciﬁc Modelers build there-

for Context-Speciﬁc Architecture/Deployment Mod-

els based on the current context. After determining

such a context-speciﬁc model these are send to an

Adaptation Actuator that is responsible for changing

the current system structure according to the deter-

mined model. Our approach is similar to the approach

of ACCADA in the way that we adapt the application

structure based on changes in the environment, but

additionally we enable to execute Management Pro-

cess enabling activities, such as, backing up data in

the cloud instead of only enabling structural changes

of software components.

Anthony et al. (Anthony et al., 2009) present

their Context-Aware Adaptation techniques in their

system called DySCAS. The conceptual parts of their

approach is based on so-called Decision Points that

are embedded in the software components and conﬁg-

ured by loading Policies into the components. These

policies are responsible for subscribing to context in-

formation and adapt the software component they are

loaded in by using a sandbox environment inside the

components themselves. The supporting DySCAS

Middleware is responsible for monitoring and man-

aging the overall system while the software compo-

nents themselves are responsible for the reconﬁgura-

tion based on context. The main difference to our

approach is the point of adaptation while, DySCAS

adapts single components our approach enables to

adapt the whole structure of the system, and addi-

tionally, doesn’t force the software components to be

altered to enable the loading of policies, i.e., our ap-

proach allows the use of Off-the-Shelve components.

La et al. (La and Kim, 2010) present a frame-

work for the context-aware provisioning of services

for mobile devices. The main goal of their frame-

work is to adapt the binding between mobile appli-

cations and services on the cloud based on the current

context of the user and their mobile device. In their

framework a Context Collector running on a mobile

device gathers data to determine the current context,

such as, device, service or user preference context.

When the context changes the framework from La et

al. adapts the binding of a mobile application and the

used cloud services by either simply rebinding it or

using different adapters to adapt the binding to the

used services. These adaptation are needed for ex-

ample when the QoS of the different services change

or certain functionalities are not available by a service

in the current context, and therefor must be extended

by adapters. In contrast to our approach the presented

framework is only used to adapt the binding between

components based on the current context.

Alcarria et al. (Alcarria et al., 2017) present an

approach to enable Context-Aware CPS to enable a

seamless service provisioning. This is achieved by

modeling an abstract process, e.g., in BPEL (OA-

SIS, 2007), that contain activities invoking various

services based on their service description. The se-

lection of a concrete service running on a device is

based on situations in the context of the possible de-

vices and therefore enables the Context-Aware Adap-

tation of the running process. In contrast to our ap-

proach Alcarria et al. focus on the adaptation of Man-

agement Processes itself, while our approach focuses

on executing processes at the right time.

Bucchiarone et al. (Bucchiarone et al., 2012)

present an approach to enable the dynamic adaptation

of context-aware business processes. The approach

uses a high-level business process where its abstract

activities are annotated with goals, and based on

CLOSER 2019 - 9th International Conference on Cloud Computing and Services Science

558

these goals concrete and ﬁner-grained business pro-

cess fragments are selected in a context-aware manner

to implement the abstract activities. This approach

allows even the integration between lower-level frag-

ments as these can also contain abstract activities that

can be implemented by a fragment at runtime through

a context-aware selection. In contrast to our approach

it is possible to generate process from the fragments

to implement various management tasks based on de-

ﬁned goals, while we reused already available Man-

agement Processes.

6 CONCLUSION

We presented an approach to enable the Situation-

Aware Management of Cyber-Physical Systems. The

basic idea of the approach was to reuse concepts of

Context-Aware Systems and Management Processes

enabling processes to be executed when certain situa-

tions occur inside the context of an application. Situ-

ations encapsulate low-level context data into higher

level knowledge, easing the modeling of Context-

Aware, i.e., Situation-Aware Systems as ﬁne-grained

states inside the application context don’t need to be

speciﬁed on the application level. The high level sit-

uations are observed by instances Situation Detec-

tion Deployment Models to recognize situations in the

context of applications and making the information

available to Situation Detection Layer of the Deploy-

ment & Situation-Aware Management System. In

the system these situations are observed by Situation-

Aware Process Triggers that are observed and ﬁred

inside the Situation-Aware Management Layer. A

Situation-Aware Process Trigger references a certain

set of situations that it reacts to when situations are

either active or not. When the set of situations are

in a state that ﬁt the speciﬁcation of a Situation-

Aware Process Trigger a referenced Management Pro-

cess is started. These Mangement Processes are bun-

dled within the Application Packages and are able

to change the structure, conﬁguration and execute

mangement tasks of the application at runtime, there-

fore implementing a wide range of management func-

tions. Hence, these processes enable the adaptation

of applications at runtime and with the combination

of the Situation-Aware Trigger are executed in certain

situations, hence, enable the Situation-Aware Man-

agement of applications.

In the future we want to extend the presented ap-

proach with concepts of timing and compensation,

e.g., to predict when a situation will change and c

changes of a Management Process. To properly adapt

a CPS the role of time is crucial as certain situa-

tions can change often and therefore starting Mange-

ment Processes and their compensation can lead to

unwanted errors, such as, aborting a ﬂashing process

of an embedded system. Therefore incorporating the

prediction of situations, i.e., predicting when a situa-

tions occurs or not can be beneﬁcial to a more timely

execution of Management Processes.

ACKNOWLEDGEMENT

This work was funded by the DFG project DiStOPT

(252975529).

REFERENCES

Alcarria, R., Bordel, B., and Jara, A. (2017). Flexible ser-

vice provision in context-aware cyber-physical sys-

tems. In International Conference on Innovative Mo-

bile and Internet Services in Ubiquitous Computing,

pages 873–883. Springer.

Andr, C., Quijano, N., and Mojica-nava, E. (2011). A Sur-

vey on Cyber Physical Energy Systems and their Ap-

plications on Smart Grids. 2011 IEEE PES Confer-

ence on Innovative Smart Grid Technologies (ISGT

Latin America).

Anthony, R., Chen, D., Pelc, M., Persson, M., and

Torngren, M. (2009). Context-aware adaptation

in DySCAS. Communications, 19(Context-Aware

Adaptation Mechanism for Pervasive and Ubiquitous

Services (CAMPUS)).

Atzori, L., Iera, A., and Morabito, G. (2010). The Internet

of Things: A survey. Computer Networks.

Baldauf, M., Dustdar, S., and Rosenberg, F. (2007). A sur-

vey on context-aware systems. International Journal

of Ad Hoc and Ubiquitous Computing.

Binz, T., Breitenb

ucher, U., Haupt, F., Kopp, O., Leymann,

F., Nowak, A., and Wagner, S. (2013). OpenTOSCA

- A Runtime for TOSCA-based Cloud Applications.

In Proceedings of the 11

International Conference

on Service-Oriented Computing (ICSOC 2013), pages

692–695. Springer.

Breitenb

ucher, U., Hirmer, P., K

epes, K., Kopp, O., Ley-

mann, F., and Wieland, M. (2015). A situation-aware

workﬂow modelling extension. In Proceedings of the

17th International Conference on Information Inte-

gration and Web-based Applications & Services, ii-

WAS ’15, pages 64:1–64:7, New York, NY, USA.

ACM.

Bucchiarone, A., Marconi, A., Pistore, M., and Raik, H.

(2012). Dynamic adaptation of fragment-based and

context-aware business processes. Proceedings - 2012

IEEE 19th International Conference on Web Services,

ICWS 2012, pages 33–41.

Da, K., Dalmau, M., and Roose, P. (2012). A Survey of

Adaptation Systems. International Journal on Inter-

net and Distributed Computing Systems, 2(1):1–18.

Situation-Aware Management of Cyber-Physical Systems

559

Dey, A. (2001). Understanding and using context. Personal

and ubiquitous computing, 5(1):4–7.

Franco, A. C., Breitenb

ucher, U., Hirmer, P., K

epes, K.,

Kopp, O., Leymann, F., Mitschang, B., and Steinke,

R. (2017). Internet of Things Out of the Box : Using

TOSCA for Automating the Deployment of IoT Envi-

ronments. Proceedings of the 7th International Con-

ference on Cloud Computing and Services Science.

Gubbi, J., Buyya, R., Marusic, S., and Palaniswami, M.

(2013). Internet of Things (IoT): A vision, architec-

tural elements, and future directions. Future Genera-

tion Computer Systems.

Gui, N., De Florio, V., Sun, H., and Blondia, C. (2009). AC-

CADA: A framework for continuous context-aware

deployment and adaptation. Lecture Notes in Com-

puter Science (including subseries Lecture Notes in

Artiﬁcial Intelligence and Lecture Notes in Bioinfor-

matics), 5873 LNCS:325–340.

Gunes, V., Peter, S., Givargis, T., and Vahid, F. (2014). A

survey on concepts, applications, and challenges in

cyber-physical systems. KSII Transactions on Inter-

net and Information Systems.

Guo, Y., Hu, X., Hu, B., Cheng, J., Zhou, M., and Kwok, R.

Y. K. (2017). Mobile Cyber Physical Systems: Cur-

rent Challenges and Future Networking Applications.

IEEE Access, XX(c):1–1.

Haque, S. A., Aziz, S. M., and Rahman, M. (2014). Re-

view of cyber-physical system in healthcare. In-

ternational Journal of Distributed Sensor Networks,

10(4):217415.

aussermann, K., Hubig, C., Levi, P., Leymann, F.,

Siemoneit, O., Wieland, M., and Zweigle, O. (2010).

Understanding and Designing Situation-Aware Mo-

bile and Ubiquitous Computing Systems. World

Academy of Science, Engineering & Technology.

Hirmer, P., Breitenb

ucher, U., da Silva, A. C. F., K

epes, K.,

Mitschang, B., and Wieland, M. (2016). Automating

the Provisioning and Conﬁguration of Devices in the

Internet of Things. CSIMQ, 9:28–43.

Hirmer, P., Wieland, M., Schwarz, H., Mitschang, B., Bre-

itenb

ucher, U., S

aez, S. G., and Leymann, F. (2017).

Situation recognition and handling based on executing

situation templates and situation-aware workﬂows.

Computing, 99(2):163–181.

Kakousis, K., Paspallis, N., and Papadopoulos, G. A.

(2010). A survey of software adaptation in mobile and

ubiquitous computing. Enterprise Information Sys-

tems, 4(4):355–389.

Knappmeyer, M., Kiani, S. L., Reetz, E. S., Baker, N.,

and Tonjes, R. (2013). Survey of context provision-

ing middleware. IEEE Communications Surveys and

Tutorials, 15(3):1492–1519.

La, H. J. and Kim, S. D. (2010). A Conceptual Frame-

work for Provisioning Context-aware Mobile Cloud

Services. In 2010 IEEE 3rd International Conference

on Cloud Computing.

Leymann, F. and Roller, D. (2000). Production Workﬂow:

Concepts and Techniques. Prentice Hall PTR.

Mens, K., Capilla, R., Cardozo, N., and Dumas, B. (2016).

A taxonomy of context-aware software variability ap-

proaches. Companion Proceedings of the 15th Inter-

national Conference on Modularity - MODULARITY

Companion 2016, (March):119–124.

Muccini, H., Sharaf, M., and Weyns, D. (2016). Self-

adaptation for cyber-physical systems. In Proceed-

ings of the 11th International Workshop on Software

Engineering for Adaptive and Self-Managing Systems

- SEAMS ’16.

OASIS (2007). Web Services Business Process Execution

Language (WS-BPEL) Version 2.0. Organization for

the Advancement of Structured Information Standards

(OASIS).

OASIS (2013a). Topology and Orchestration Speciﬁcation

for Cloud Applications (TOSCA) Primer Version 1.0.

Organization for the Advancement of Structured In-

formation Standards (OASIS).

OASIS (2013b). Topology and Orchestration Speciﬁcation

for Cloud Applications (TOSCA) Version 1.0. Organi-

zation for the Advancement of Structured Information

Standards (OASIS).

OASIS (2015). TOSCA Simple Proﬁle in YAML Version

1.0. Organization for the Advancement of Structured

Information Standards (OASIS).

Perera, C., Zaslavsky, A., Christen, P., and Georgakopoulos,

D. (2014). Context Aware Computing for The Inter-

net of Things: A Survey. Communications Surveys

Tutorials, IEEE, 16(1):414–454.

Saller, K., Lochau, M., and Reimund, I. (2013). Context-

aware DSPLs: model-based runtime adaptation for

resource-constrained systems. Proceedings of the 17th

International Software Product Line Conference co-

located workshops, pages 106–113.

Shrouf, F. and Miragliotta, G. (2015). Energy management

based on Internet of Things: Practices and framework

for adoption in production management. Journal of

Cleaner Production.

Urbieta, A., Gonz

alez-Beltr

an, A., Ben Mokhtar, S., An-

war Hossain, M., and Capra, L. (2017). Adaptive

and context-aware service composition for IoT-based

smart cities. Future Generation Computer Systems.

Wieland, M., Schwarz, H., Breitenb

ucher, U., and Ley-

mann, F. (2015). Towards situation-aware adaptive

workﬂows: SitOPT - A general purpose situation-

aware workﬂow management system. In 2015 IEEE

International Conference on Pervasive Computing

and Communication Workshops, PerCom Workshops

2015.

YIN, Y., Zeng, Y., Chen, X., and Fan, Y. (2016). The inter-

net of things in healthcare: An overview. Journal of

Industrial Information Integration, 1:3 – 13.

Zorzi, M., Gluhak, A., Lange, S., and Bassi, A. (2010).

From today’s INTRAnet of things to a future INTER-

net of things: A wireless- and mobility-related view.

IEEE Wireless Communications.

CLOSER 2019 - 9th International Conference on Cloud Computing and Services Science

560