Automated runtime management of embedded service systems based on design-time modeling and model transformation

Abstract

The management of distributed and embedded service systems is a complex task as the services are exposed to changing environments which have to be reflected by the services' configurations. These configurations are commonly based on abstract management policies. Embedded devices usually lack the resources to perform the necessary computations to derive an actual configuration from an abstract policy. Thus we developed a two phase management approach that splits up the management process into a design-time and a runtime task. At design-time a model of the managed system is created. This model is augmented by high-level, environment-aware management policies that are automatically refined to low-level service configurations using graph-transformation techniques. This phase is based on the concepts of model-based management and on parts of the generalized role based access control model to handle the modeling of the environment-aware policies. The runtime phase covers the enforcement of the environment-aware management policies by a set of management services responsible for the setting of suitable service configurations.

Full text

Page 1

1

Abstract — The management of distributed and embedded
service systems is a complex task as the services are exposed to
changing environments which have to be reflected by the ser-
vices’ configurations. These configurations are commonly
based on abstract management policies. Embedded devices
usually lack the resources to perform the necessary computa-
tions to derive an actual configuration from an abstract policy.
Thus we developed a two phase management approach that
splits up the management process into a design-time and a run-
time task. At design-time a model of the managed system is
created. This model is augmented by high-level, environment-
aware management policies that are automatically refined to
low-level service configurations using graph-transformation
techniques. This phase is based on the concepts of model-based
management and on parts of the Generalized Role Based Access
Control model to handle the modeling of the environment-
aware policies. The runtime phase covers the enforcement of
the environment-aware management policies by a set of man-
agement services responsible for the setting of suitable service
configurations.

Index Terms — model-based management, automatic &
adaptive management, embedded service systems
I. INTRODUCTION
The automotive, industrial, home, and telecommunica-
tion domains perceive an increasing demand for embedded
real-time applications which rely on cooperating networked
devices. A plethora of devices is arising covering small and
specialized devices with restricted computing power as well
as well-equipped servers and workstations. Stationary and
mobile devices cooperate in dynamically varying associa-
tions and utilize a wide variety of supporting services. Mo-
bility, changing tasks, as well as fluctuating supportive ser-
vice costs and availabilities demand that the frequently
needed adaptations of application configurations are ac-
complished by automated application management func-
tions. The work presented in this paper is part of the ITEA
SIRENA [1] project, which has the goal to develop a uni-
versal service infrastructure for real-time, networked and
embedded devices, which can be utilized in the industrial,
home, telecommunication and automotive domain.
Our work focuses on the automated adaptation and re-
configuration of services in reaction to changes in the envi-
ronment. As embedded systems are addressed, the time
spent for necessary configuration changes on the devices
should be low, so no expensive computations can be done
to accomplish this.
Our approach to solve this problem is to divide the adap-
tation process in two parts. At design time, a model of the
managed system is generated and configurations for the ser-
vices are created. At runtime, configuration changes confine
to selecting and activating a suitable configuration. The en-
forcement of management policies is done by a separate
management process at system runtime.
The design time task, the creation of appropriate envi-
ronment related service configurations, is supported by a
graphical modeling tool which allows the automated deriva-
tion of low-level configurations from high-level policies.
The outline of the paper is as follows. First, we introduce
the concept of model-based management. The elements
which are used in modeling are explained in more detail in
section III. The automated generation of policy elements by
means of graph transformation techniques is subject of sec-
tion IV. The details of how the overall policy is enforced at
runtime are given in section V.
II. MODEL BASED MANAGEMENT
The model-based management approach utilizes an ob-
ject-oriented model of the managed system to ease the crea-
tion and modeling of complex management policies. The
graph-based modeling of a system is supported by a graphi-
cal modeling tool. Common policy-based management ap-
proaches [2] apply low level policies to describe manage-
ment demands. Systems created using the model-based ap-
proach ([3], [4]) use much more abstract high-level policies
to describe the desired behavior, from which concrete ser-
vice configurations are automatically created.
Basically a model is build up of some common and ap-
plication domain specific model nodes like Service or De-
vice and edges connecting these nodes. Each connection be-
tween two nodes expresses a specific dependency or rela-
tionship between these nodes.
In common the model is divided into different abstrac-
tion layers ranging from a very abstract enterprise view, in-
cluding the high-level policies to be enforced, to low-level
system elements like specific hosts, devices, and network
protocol stacks. This approach was successfully applied for
the creation of firewall [4], VPN [5] and Kerberos V con-
figurations.

Stefan Illner, Andre Pohl and Heiko Krumm

FB Informatik, Universität Dortmund
44221 Dortmund, Germany
e-mail: {stefan.illner, andre.pohl, heiko.krumm}@udo.edu
Automated Runtime Management of Embedded Service Systems Based
on Design-Time Modeling and Model Transformation
Ingo Lück, Darius Manka and Thomas Sparenberg

Materna Information & Communications
44141 Dortmund, Germany
e-mail: {ilueck, dmanka, tsparenb}@materna.de
Id: udo-indin05.doc 2005-05-25 17:02:48Z krumm

Page 2

2
Model Structure
The OSI FCAPS framework defines five different areas
of management: Fault-, Configuration-, Accounting-, Per-
formance-, and Security-Management. Previously the
model-based management approach was mainly applied for
the area of Security-Management. In the scope of the
SIRENA project the other areas of management move into
the focus. Moreover the creation of environment aware
policies and the tighter connection to the area of service
oriented architectures require the re-organization of the
main model structure. This new model structure is outlined
in Fig. 1.
The model contains three abstraction layers, namely the
“Roles & Goals” layer which contains the most abstract en-
terprise view, the “Services & Configurations” layer which
deals with the services and abstract configuration relations
between the services and last the less abstract “Devices &
Files” layer containing the hardware devices, which are
hosting the services and the XML configurations describing
the low-level management policies in form of service con-
figuration-descriptions.
The vertical adjustment divides the model into the Sys-
tem, Control, Policy, and the new Environment sections.
The System section contains all model elements which rep-
resent parts of the managed system e.g. application services
like a file- or mail-server, including the hosting hardware
and devices. The Control section contains nothing on the
upper layer, as the policy enforcing components are not
visible above the “Services & Configurations” layer. The
lower two abstraction layers contain the required policy en-
forcement services such as the Management Infrastructure
Services and devices which host these services. Manage-
ment goals are modeled using specific policy objects. These
are arranged in the Policy section of the model and are re-
fined in the lower layers. The most right column contains
the objects required to model the environmental awareness
of given management policies.
III. MANAGEMENT MODEL ELEMENTS
Management models are created for a specific applica-
tion domain, where the components are well known, as well
as the possible relations (connections) between them. These
elements and the information about their connectivity are
subsumed in a so called meta-model. For every node type,
the meta-model contains information to which other node
connections are allowed, and with which cardinality. With
this information, the correctness of the syntax of the model
can be ensured during the model creation process, by check-
ing the constraints each time a new edge is inserted. More-
over each node may contain additional properties which
conform to the properties of the represented real world ob-
ject.
In Fig. 2, one can see a snapshot of a simplified example
model, showing the System, Policy and a compressed Con-
trol section. In the following the basic elements are intro-
duced by means of this example.
An Attribute Set element is used to group attributes of
services. These groups are used by Management Goals to
model specific requirements. In Fig. 2 the element named
Normal Monitoring represents such an Attribute Set. It is
connected to a single Service Attribute and one Service
element. The former connection models that only the “Open
Files” attribute, which contains the number of concurrently
opened files, is part of the set. The latter connection states,
that all attributes, namely the “Max Size” and the “Store
Policy” attributes of this service are part of the Attribute
Set.
Management Goal elements are used to express specific
targets of a management policy. The types of Management
Goals are centered around the FCAPS areas of common
management. Thus these elements may address goals re-
garding e.g. the fault, performance or security management
areas. In the depicted example two goals are defined: the
Monitoring goal defines a specific monitoring policy and
the Load Management goal defines some mandatory con-
figuration tasks in case that the File Service is about to ex-
ceed its storage space capacities. The Load Management
goal is connected to a so called Actual Configuration Chain
which contains the actual reconfiguration information.
When dealing with reconfiguration of services by setting
specific service attributes to new values there have to be
some elements that are able to express such new value set-
tings. Moreover in a reconfiguration phase the managed
service may have to be restarted to activate the new con-

Fig. 1: Overall model structure



Fig. 2: System, Control Services and Management Goals

Page 3

3
figuration settings, so the service’s life cycle management is
also in charge. The model element which deals with these
issues is named an Actual Configuration Chain (cf. Fig. 2,
right side). This element is built up of two other model ele-
ments, an Actual Value and a Lifecycle Management Com-
mand, which are connected by directed edges to enable the
modeling of precedence of configuration settings. The Ac-
tual Value element itself is connected to the Service Attrib-
ute which should be set to the actual value. The Life Cycle
Management Command element is connected to the service
for which it should be invoked. In the example the Actual
Configuration Chain contains reconfiguration tasks for the
File- and Mail Service. The Mail Service’s attribute “Max
Size” for the definition of the maximum size of an accepted
incoming E-mail is set to the value of 500 kilobytes. After
that the value of the “Store Policy” attribute is set to
“cache” which means that the received E-mail should be
cached locally and should not be saved using the existing
File Service. After setting these two attributes a “Restart”
Life Cycle Management Command is issued to activate the
new configuration. Finally the File Service is put into a
Read-Only mode by setting the attribute “Read Only” to
“true”. Without the possibility of modeling configuration
precedence the reconfiguration may have led to errors in the
Mail Service as it might have tried to write to a read-only
file system if the File Service would have been reconfigured
already.
Another model element is the Service element which rep-
resents a real world (SIRENA) service. It is characterized
by its name and the attributes and operations it provides. In
the example there are two services, a File Service and a
Mail Service which both have two defined attributes that
may be used for monitoring and reconfiguration issues. For
readability reasons the service operations are omitted.
Dependencies between services are modeled using di-
rected edges. In the example above the Mail Service de-
pends on the File Service as this is used to store the mail-
data.
A Device is a model representation of a physical re-
source, hosting a service. In the example there are two de-
vices, which host the File- and Mail-Services and an addi-
tional device that hosts the services of the Runtime Man-
agement Infrastructure.
The communication links between devices are modeled
using the Link element. A Link is a representative for any
arbitrary network connection.
In Fig. 3 you can see the right side of the model, also in-
cluding parts of the policy and control section.
The model described so far includes no information re-
garding the environmental state of the modeled system. This
state information is now added by the introduction of Pro-
files. A Profile defines a specific environmental state, e.g.
Working Hours or a specific fault state like Power Fault.
The environmental state itself is defined using a logical ex-
pression over the activation state of so called Environment
Roles. The notion of an Environment Role is adopted from
the Generalized Role Based Access Control (GRBAC)
model [6], an extension of the well known Role Based Ac-
cess Control model [7]. In original GRBAC the environ-
mental information was used to compute environment re-
lated access control decisions. We apply this scheme to
model the environmental awareness of management poli-
cies. An Environment Role is defined by a logical expres-
sion e.g. a role named Weekend is defined like (Sat ∨ Sun).
At runtime this expression is evaluated by a special Envi-
ronment Role Activation Service (cf. section V). If the ex-
pression evaluates to true the role is considered to be active.
Supplied with a set of different types of Environment Roles
one can easily model special system states by combining
these roles using logical operators (e.g. ∧, ∨ or ¬).
The elements introduced to this point have to be mod-
eled by hand; the last two elements described herein are
created automatically by the modeling tool based on the in-
formation supplied by the model. The details of this deriva-
tion process are outlined in the next section.
The first item that is generated automatically is the Con-
figuration Set. This element contains less abstract informa-
tion about the configurations to be enforced in certain situa-
tions and about the affected services including managed as
well as management services.
From the information gathered by the automatic deriva-
tion of the Configuration Set elements, from the information
about the devices by which the services of the managed
domain are hosted, and from the underlying network infra-
structure specific XML Configuration File elements are cre-
ated. These elements are directly related to real XML ser-
vice configuration-descriptions which can be deployed on
the Runtime Management Infrastructure.
Besides using the above outlined approach for the mod-
eling of common management policies we also apply it for
modeling security policies as we already presented in [8]
and [9].
IV. MODEL TRANSFORMATION
After modeling the system and the abstract policy ele-
ments, the concrete configurations for the management ser-


Fig. 3: Control Services, Management Goals, Profiles and derived
Configuration elements

Page 4

4
vices are generated automatically. There are two different
ways to conduct this automatic generation.
Either, a meta-model contains transformation methods
which describe the relevant graph structures to look for and
the alteration function which should be applied to the graph
in case that such a structure is found. The disadvantage of
this approach is that these methods are hard-coded into the
meta-model and a user may not simply extend or alter the
functionality of the given methods.
The other approach is the graph transformation approach
[10] which we have chosen for our modeling tool. The idea
of this is as follows: As stated above, the model is described
by a graph. Therefore it is possible to define a graph trans-
formation system consisting of single transformation rules
which alter the graph in a specified way. One such rule con-
sists of a left-hand side L and a right-hand side R, and on
detection of a L in the model, this occurrence is replaced
with an instance of R. L and R are graphs also, consisting of
elements of the same meta-model as the model graph does.
The rule elements can be specified using the tool in the
same way the model is specified. So this approach fits very
well in the concept of model-based management and users
are given the ability to easily extend the transformation sys-
tems provided by the meta-model.
After having modeled both sides of a rule, some nodes in
L are identified with nodes in R, while others are not. The
same applies to the edges in L and R. The algorithm to ap-
ply a rule r to a model graph M is roughly outlined by the
following sequence:
1) Find an occurrence of L in M
2) Remove all components in M which occur in L, but
do not have an identity component in R
3) Insert all components into M which occur in R, but
do not have an identity component in L
The application of a rule r transforms the graph G to a
Graph G', denoted by
'
GG ⇒
vation, and G' is directly derived from G.
For a better control over the application of a rule, every
rule can be augmented with two additional components. A
condition allows to specify certain constraints which must
. This is called a direct deri-
be met by the detected sub graph L’ in order to match the
defined pattern in the search. These constraints can refer to
all attribute values of elements in L’. An effect function is a
function which is applied to the inserted graph elements,
and describes how the attribute values of the inserted ele-
ments are computed from the attributes of the elements of
L’.
The meta-model classes are designed in an object-
oriented manner. If inheritance is used in the meta-model,
by using either base classes or derived classes in a rule, this
rule can be made more general or more specific, as needed.
The first step also introduces non-determinism into the
transformation process, because a left-hand pattern may
match multiple times in the given model graph. Therefore
the resulting graph may depend on the order in which the
occurrences are found.
The automated, repeated application of a rule holds the
risk of infinite recursion. Just imagine the case where L con-
sists of one node nL, and in R this node has an identity node
nR, plus one more node mR. After the application of the rule,
the node still remains in the model, and so this rules remains
applicable. To circumvent this recursion, we use inhibiting
graph components. An inhibiting component can only be
part of a left hand graph L. Considering the use of inhibiting
graph components, Step 1 of the transformation algorithm
becomes:
1') Find an occurrence of the non-inhibiting elements of
L in G and make sure that the inhibiting elements of
L do not appear in G the same way
In the example above, to prevent recursion, one would
introduce an identity node mL for mR in L and give it the in-
hibiting state. After the first direct derivation, 1') will not
find any more valid occurrences of L, and terminates.
Applying a rule r to a Graph G several times will result
in a sequence
GG
⇒⇒⇒
L
1
applications is called derivation, and Gn is derived from G.
Usually, there will not be a single rule r, but a set P of
rules
nrr
,,
, where each rule serves a specific purpose.
The set P is called a graph transformation system. Systems
can lead to another kind of non-determinism: There may be
several rules r for which Lr is identified in G, with all asso-
ciated conditions fulfilled. The resulting graph G' depends
on the rule chosen for transformation. If the order of prece-
dence does matter, rules can be assigned a priority.
For the example model given in figures 2 and 3, the ap-
plication of a simple rule is depicted in Fig. 4. The left-hand
side of the rule describes the situation that a Configuration
Set exists, covering a specific attribute of a specific service,
but no XML Configuration File exists which carries the
configuration information for this service. The absence of
this file is expressed by inserting this file with its connec-
tions into the left-hand side of the rule, but then setting
these elements inhibiting, which is visually expressed by the
dashed lines in Fig. 4a.
In such a case, we know that there must be an XML con-
figuration file inserted into the model, which is expressed
by the right-hand side of the rule. The newly introduced
elements appear with a bold border.
n
G
. The result of several rule
1K


Fig. 4: Application of a rule to a model

Page 5

5
In our management model, the following two rules are
the most important ones from the transformation system:
• Every Management Goal must have exactly one asso-
ciated Configuration Set.
• For each service which can be reached via one of the
paths ‘Configuration Set – Goal – Attribute Set – At-
tribute – Service’ or ‘Configuration Set – Goal – Con-
figuration Value Chain – Attribute – Service’, a Con-
figuration Set must be associated to XML Configura-
tions.
After the automated generation of the attributes, the user
can intervene and alter some values, if the necessity should
arise.
The graph transformation also has another valuable
benefit for model checking. It is possible to specify certain
graph patterns that are allowed for the left-hand side of a
rule. For each pattern it is specified whether such a pattern
is mandatory or forbidden. If a mandatory pattern is given,
but no matching sub-graph is found in the model, the model
is invalid. A model is also invalid, if any of the forbidden
patterns is detected in the model graph. This allows the de-
tection of semantic errors, which cannot be caught by the
static analysis of the connection restrictions defined in the
meta-model.
V. RUNTIME POLICY ENFORCEMENT
The policies which are created by the modeling tool are
deployed onto a runtime enforcement infrastructure (cf. Fig.
5). This infrastructure contains the required services to en-
able the automatic and adaptive management of (embedded)
service systems. The infrastructure is build up upon six ser-
vices, each responsible for a special area of service man-
agement. The Fault Management Service in conjunction
with the Poll- and Event-Monitor services is responsible for
the monitoring of service faults and fault-events. Changes in
the values of monitored service parameters and received
fault events are forwarded to the Environment-Role Activa-
tion Service which uses these parameter values and events
to compute the set of active environment roles. The parame-
ters required for a computation of a role activation state are
part of the role-definition which is done at design-time.
Whenever a computation leads to a change in the set of ac-
tive environment-roles, these changes are notified to the
Automatic Adaptation/Dynamic Reconfiguration (AADR)
Service. This service is responsible for the automatic adap-
tation to environmental situations. To accomplish this task
the service looks at the set of currently active environment-
roles and matches all profiles that are active with this set. If
a change in the set of active profile occurs the correspond-
ing service configurations have to be enforced. The AADR
Service determines the related configuration sets and in-
structs the Deployment Management Service to forward the
configuration changes to the Service Control Management
Services which are responsible for the involved services’
control. The Service Control Management Services deploy
the new configurations and may use the Service Life-Cycle
Management Service to activate the new configuration by
restarting the involved services if necessary.
VI. RELATED WORK
Chisel [11] proposes a context-aware, policy-driven
framework for adaptation of services. In this approach, the
services will be adapted to use different behaviors, driven
by a human-readable declarative adaptation policy script.
Furthermore, the chisel framework allows to make mobile-
aware dynamic changes to the behavior of various middle-
ware-services, and it provides the addition of new unantici-
pated behaviors at run-time, without changing the middle-
ware or the application using it.
Similarly, Lymberopoulos et al. [12] investigate dynamic
adaptation of policies in response to changes within the
managed environment. Here, policy adaptation includes
both dynamically changing policy parameters and reconfig-
uring the policy objects. The proposed framework is pri-
marily used to provide dynamic management of services in
Differentiated Services (DiffServ) networks.
VII. OUTLOOK
Currently we are implementing the described meta-
model for specific SIRENA demonstrators from the home,
automotive and industrial domains to demonstrate the appli-
cability of our approach. To ease the creation of further
models, basic model elements have been developed which
are used as a basis for the implementation of the domain
specific models.
The modeling of management policies is supported by
our management tool which allows the graphical modeling
based on arbitrary meta-models. This tool is subject to on-
going development addressing the integration of supporting
modeling features like visualization techniques and the so
called Semantic Zooming that ease the handling of very
large models.
The presented graph transformation algorithm is part of
our graphical modeling tool. This algorithm currently al-
lows the matching of graphically modeled graph patterns,

Fig. 5: Runtime service infrastructure