Towards Systematically Engineering Ensembles - Martin Wirsing

ASCENS: Towards
Systematically Engineering Ensembles
Martin Wirsing
LMU München
With contributions from Matthias Hölzl, Annabelle Klarl, Mirco
Tribastone, Franco Zambonelli

2Seite
Martin Wirsing
Goals of this Lecture
 Students should be able to understand
 a model-based development process of autonomic systems
 focusing on mathematically based modeling and analysis techniques

3Seite
Martin Wirsing
Autonomic Systems and Ensembles
 Autonomic systems are typically distributed computing systems
whose components act autonomously and can adapt to environment
changes.
 We call them ensembles if
they have the following
characteristics:
 Large numbers of nodes
 Heterogeneous
 Operating in open and non-
deterministic environments
 Complex interactions
between nodes and with
humans or other systems
 Dynamic adaptation to
changes in the environment

4Seite
Martin Wirsing
ASCENS Project
 Goal of ASCENS:
Develop methods, tools, and theories for
modeling and analysing
autonomic self-aware systems
that
 combine traditional SE approaches based on formal
methods with the flexibility of resources promised by
autonomic, adaptive, and self-aware systems
 Partners:
 LMU (Coordinator), U Pisa, U Firenze with ISTI Pisa,
Fraunhofer, Verimag, U Modena e Reggio Emilia, U
Libre de Bruxelles, EPFL, Volkswagen, Zimory GmbH,
U Limerick, Charles U Prague, IMT Lucca, Mobsya
 Case studies:
 Robotics, cloud computing, and energy saving e-
mobility

5Seite
Martin Wirsing
Engineering Autonomic systems
 Self-aware ensemble components are aware of their structure and their
aims
 Goals and models of ensemble components have to be available at runtime
 Autonomous components typically have internal models and goals
 For ensuring reliability and predictability of the ensemble and its
components important properties of the ensemble should be defined and
established at design time and maintained during runtime
 Analysis-driven development and execution
 Autonomic systems have to be able to adapt to dynamic changes of the
environment
 Even if the ensemble components are defined at design time, adaptation of
the ensemble components will happen at runtime

6Seite
Martin Wirsing
Ensemble Lifecycle:
Two-Wheels Approach
 Engineering an autonomic ensemble consists of an iterative agile
lifecycle
 Design time: Iteration of requirements engineering, modeling, validation
 Runtime: Awareness, adaptation, execution loop
 Design time and runtime loops connected by deployment and feedback
 Feedback leads to a better understanding and improvement of the system.
Deployment
Feedback
Design Runtime

7Seite
Martin Wirsing
Outline
For the sake of simplicity we restrict ourselves to a simple example
of autonomic robots and illustrate only the following first
development steps which happen at design time.
 Requirements specification with SOTA/GEM
 Coarse modeling by adaptation pattern selection
 Fine-grained modeling in Agamemnon/Poem
 Adaptation in nondeterministic environments through learning
 Abstract programming in SCEL
 Quantitative analysis of autonomic system behaviour using stochastic
methods
7
Case study
Hölzl & Klarl
Case study
Loreti

8Seite
Martin Wirsing
The Robot Case Study
 Swarm of garbage collecting robots
 Acting in a rectangular exhibition hall
 The hall is populated by visitors and exhibits
 Scenario
 Visitors drop garbage
 Robots move around the hall,
pick up the garbage and
move it to the service area
 Robots may rest in the service area in order
to not intervene too much with the visitors
and to save energy
8
service area

9Seite
Martin Wirsing
Domain and Requirements Modeling:
SOTA/GEM Framework
 An adaptive system can (should?) be expressed in terms of “goals” =
“states of the aﬀairs” that an entity aims to achieve
 Without making assumptions on the actual design of the system
 It is a requirements engineering activity
 SOTA (“State of the Affairs”)/GEM Conceptual framework
 Goal-oriented modeling of self-adaptive systems
 Functional requirements representing the states of aﬀairs that the system has
to achieve or maintain
 Utilities are non-functional requirements which do not have hard boundaries
and may be more or less desirable.
 GEM is the mathematical basis of the SOTA framework
9

10Seite
Martin Wirsing
SOTA/GEM:
Domain and Requirements Modeling
Domain modeling:
 State Of The Affairs Q = Q1 x … x Qn
 represents the state of all parameters that
 may affect the ensemble's behavior and
 are relevant to its capabilities
 Example: Robot Swarm State Of The Affairs

11Seite
Martin Wirsing
Ensemble and its Environment
 Environment
 For mathematical analysis we distinguish often between the ensemble and its
environment such that the whole system is a combination of both
 Adaptation Space
 The ensemble should work in a number of different environments
 The characteristics of all environments are described by the adaptation space
 Example Robot Swarm
 The state space of the robot ensemble is given by the state spaces all robots
where QRobot is given by the position and state of the robots
 The state space environment is given by the exhibition area, the list of
garbage items, and the value indicating whether the exhibition is open
 The adaptation space of the ensemble may be given by varying the size of the
arena, the dropping rate of garbage items, etc.

12Seite
Martin Wirsing
SOTA:
Requirements Modeling
 Goal-oriented requirements
modelling
 Goal = achievement of a given state
of the affairs
 Where the system should eventually
arrive in the phase space Qe,
 represented as a confined area in that
space (post-condition Gpost), and
 the goal can be activated in another
area of the space (pre-condition Gpre)
 Utility = how to reach a given state of
the affairs
 “maintain goal”: constraints on the
trajectory to follow in the phase
space Qe
 expressed as a subspace Gmaintain in
Qe

13Seite
Martin Wirsing
Robot Ensemble Goals and Utilities
 Example requirements:
 Goal G1
 Maintains < 300 garbage items
 as long as the exhibition is open
 i.e. (ob => g# < 300 until not ob)
 Further (adaptation) goals
 Keep energy consumption lower
than predefined threshold
 In resting area allow sleeping time
for each robot
 Adaptation Space
 Size of arena x garbage dropping
rate

14Seite
Martin Wirsing
Towards Design
 Further requirements modelling steps
 Check consistency of requirements
 Model the autonomic system in Agamemnon/Poem
 Select suitable adaptation patterns for ensemble design (see also lecture 08
on patterns)
 Model each component and the ensemble in Agamemnon
 Implement each component in Poem
 Provide abstractions for controlling adaptation
 e.g., by learning behaviours or reasoning

15Seite
Martin Wirsing
Adaptation Patterns
Component Patterns Ensemble Patterns
 Reactive Environment mediated (swarm)
Reactive
Component
Environment Environment
Event, pheromone, …
Internal Feedback
Goal
Action
Environment
 Internal feedback loop Negotiation/competition
 Further patterns: External feedback loop, norm-based ensembles, …
Interaction
between
components

16Seite
Martin Wirsing
Robot Ensemble Adaptation
 Reactive component pattern for implementing a single robot
 Environment mediated (swarm) pattern for the ensemble of
ineracting components
Reactive
Component
Environment Environment

17Seite
Martin Wirsing
What is Agamemnon?
Agamemnon is a modeling language based on the situation calculus
supporting the specification of domain theories and accompanying partial
programs.
 Domain models in UML class diagrams with the Aga-UML profile
 identification of components and the environment together with their
properties (=fluents) and actions
 Axiomatisation of the dynamic evolution of the world as a result to
action execution with a textual DSL based on the situation calculus
 introduced by John McCarty 1963: representing knowledge, actions with their
preconditions and effects, and dynamic domains in first-order logic.
 extended by concurrency, probability, time by Reiter 2001
 Behaviour specification in UML activity diagrams with the Aga-UML
profile
 stereotypes for the specification of partial programs and their computation via
learning or planning

18Seite
Martin Wirsing
AGAMEMNON Model: Domain Model
Model of components together with their properties (=fluents) and actions
Deterministic axiomatization of effects of actions e.g.
action Robot::stepNorth {
pre: true;
effects {
self.position.y := self.position.y@pre + 1;
}
}
precondition
effect:
move one cell to north

19Seite
Martin Wirsing
AGAMEMNON Model:
Robot Ensemble Behavior

20Seite
Martin Wirsing
AGAMEMNON Model: Robot Behaviour
non-deterministic choice

21Seite
Martin Wirsing
What is Poem?
[more in case study of Hölzl & Klarl]
 Poem is a LISP-like modeling/programming language that allows
developers to
 Define an adaptation space (i.e., possible worlds) in situation/fluent calculus
 Markov Decision Processes (MDPs) for probabilistic worlds
 Specify behaviours using partial programs
 Define mechanisms for state abstraction
 Iliad is an implementation that provides
 First-order reasoning
 Constraint solving
 Evaluation of partial programs using hierarchical reinforcement learning
[more in case study of Hölzl & Klarl]
 Reduces state space using state abstraction techniques
 Exploits locality and compositionality to keep search space manageable
 Poem/Iliad can be used to implement Agamemnon models

22Seite
Martin Wirsing
POEM Implementation
(defun waste-removal (robot)
"Repeatedly pick up waste and drop it off or sleep."
(loop
(choose choose-waste-removal-action
(call (pickup-waste robot))
(call (drop-waste robot))
(action sleep-action 'SLEEP robot))))
non-deterministic choice of behaviour
(can be learned)

23Seite
Martin Wirsing
Dealing with Nondeterministic
Environments
 But not always in the intended way
 E.g. with prob. 0.9 move to the intended direction
 In the failure case,
 remaining at same position has prob. 0.05
 any other possibility has prob. 0.025
 Environments are often non-
deterministic
⟹ Environment represented as
Markov Decision Problems
(MDPs)
 MDPs can be seen as abbreviations
for specifications in situation/fluent
calculus
 Components operate on the MDP
by performing actions
 Actions change the state of the MDP

24Seite
Martin Wirsing
Rewards
 Goals from the SOTA specification
are represented as numeric
rewards
 Each action performed by the
ensemble leads to a reward
 Positive reward for bringing an
item into the rest area,
 Negative -0.1 reward for each
move
 0 reward for sleeping
 A behavior is “good” if it achieves a
high reward over the ensemble’s
lifetime
 For ensembles with unbounded
lifetimes discounted rewards can be
used

25Seite
Martin Wirsing
Partial and Complete Behaviours
 Behaviour of components is represented
by so-called partial programs containing
 Non-deterministic choices
 Action executions
 The completion of a partial program
specifies how non-deterministic choices
are resolved
 Nondeterminism my arise at different
levels;
 E.g. pickup-waste is non-deterministic in
the MDP
 But appropriate completions can often
provide a deterministic high-level view of a
component’s behaviour

26Seite
Martin Wirsing
Planning/Learning
 Can we always find a completion of a program?
 Yes, any selection of non-deterministic choices leads to a completion. But
many completions do not reach the specified goals or perform well.
 Can we always find a good completion?
 One that maximizes the aggregated reward of a partial program in a given
environment.
 In certain cases: yes
 When we have a model of the environment’s dynamics (logical or MDP):
planning, dynamic programming can compute a maximal completion
 When we can explore the environment or a simulation of the environment and
obtain information about the reward of our actions: reinforcement learning
techniques provide a sequence of completions that converge to a maximal
completion
 But for many realistic problems these techniques are intractable
 Explosion of state and action spaces, slow convergence towards a solution
⟹ Abstraction of states and actions, compositional techniques
Approximation of the true solution

27Seite
Martin Wirsing
Learned Behaviour
 In the case study by Matthias & Annabelle you will learn to use POEM
and the Iliad system to find the following deterministic program of the
robot system using machine learning:

28Seite
Martin Wirsing
What is SCEL?
[More in case study of M. Loreti]
 The Service Component Ensemble
Language (SCEL) provides an abstract
ensemble programming framework by
offering primitives and constructs for the
following programming abstractions
 Knowledge: describe how data,
information and knowledge is manipulated
and shared
 Processes: describe how systems of
components progress
 Policies: deal with the way properties of
computations are represented and
enforced
 Systems: describe how different entities
are brought together to form components,
systems and, possibly, ensembles
SC SC
SC
SC
SC
Service component
Service component ensemble

29Seite
Martin Wirsing
The SCEL Syntax (in one slide)
 SCEL
 Parametrized by the knowledge tuple space and policies
 Predicate-based communication
 Processes interact with the tuple space by query and put actions

30Seite
Martin Wirsing
Robot Ensemble SCEL Design
 n robots Ri interacting with environment Env and other robots
R1 || … || Rn || Env
 Env is abstractly represented by a component
Ienv[.,., m]
keeping track of the total number of collected items
 Environment mediated robot ensemble
Environment
R1 R2 R3

31Seite
Martin Wirsing
Robot Ensemble SCEL Refinement
 Each robot Ri is of form Ri = I[.,.,pick[col[t]] ] where
 pick monitors the reactive robot behavior (searching for waste)
 col detects collisions,
 t controls the sleeping time
 E.g. monitoring the reactive behavior pick of a robot Ri for
performance analysis
 If Ri is picking up waste then
 if it encounters another robot or a wall, it changes direction and continues exploring
(“normal” moves and direction change abstracted in SCEL)
 if it encounters an item, the robot picks it up (abstracted in SCEL), informs the
environment env and starts returning to the service area
pick = get(collision)@self.pick + get(item)@self.inform
inform = get(items,!x)@env.inform1
ínform1 = put(items,x+1)@env.drop
. . .
Parallel
processes
Nondeter
ministic
choice

32Seite
Martin Wirsing
Validating Requirements:
Quantitative Analysis
 Validating the adaptation requirements includes the following steps:
 Ensemble simulation
 jRESP [see Michele Loreti‘s case study]
 or SCELua
 Study timing behaviour by abstracting SCEL models to
 Continuous-time Markov chains
 Ordinary differential equations
 Statistical modelchecking
 Validate performance model by comparing to simulation and
 Validate the adaptation requirements by sensitivity analysis

33Seite
Martin Wirsing
Sensitivity Analysis for Validating the Adaptation
Requirements
 Adaptation requirements
 Keep area clean (< 300 garbage items) while allowing sleeping time t (e.g.
<= 1000) for each robot
 Energy consumption lower than predefined threshold
 Sensitivity analysis of throughput
 where throughput = frequency of returning garbage items to service area
Martin Wirsing
Model prediction:
 Adaptation requirement is
satisfied
 Maximum allowed rest
time (whilst achieving the
maintain goal): 1580

34Seite
Martin Wirsing
Summary
 ASCENS is developing a systematic
approach for constructing Autonomic
Service-Component Ensembles
 A few development steps for a simple
example
 Iterative ensemble lifecycle
 Requirements specification with SOTA/GEM
 Selection of adaptation patterns
 Modeling and reasoning with
AGAMEMNON/POEM
[case study by Matthias and Annabelle]
 Unreliable environment represented as MDP
 Learning and reasoning for controlling
adaptation
 Abstract programming and simulation of
adaptive ensembles in SCEL
[case study by Michele ]
Deployment
Feedback
DesignRuntime

35Seite
Martin Wirsing
And More Research
 Modeling and formalising ensembles
 Knowledge representation and self-
awareness
 Adaptation and dynamic self-expression
patterns and mechanisms.
 Correctness, verification, and security of
ensembles
 Tools and methodologies for designing and
developing correct ensembles
 Experimentations with case studies

Towards Systematically Engineering Ensembles - Martin Wirsing

More Related Content

Similar to Towards Systematically Engineering Ensembles - Martin Wirsing (20)

More from FET AWARE project - Self Awareness in Autonomic Systems (20)

Recently uploaded (20)

Towards Systematically Engineering Ensembles - Martin Wirsing