bayesian artifical intelligence for tackling uncertainty in self-adaptive systems
DESCRIPTION
Nelly Bencomo, RAISE 2013TRANSCRIPT
Bayesian Ar+ficial Intelligence for Tackling Uncertainty in Self-‐Adap+ve Systems: the Case of Dynamic Decision Networks
2nd Interna*onal NSF sponsored Workshop on Realizing Ar*ficial Intelligence Synergies in So=ware Engineering
(RAISE2013)
San Francisco May, 21 2013
Nelly Bencomo Aston University, UK Inria, France hKp://www.nellybencomo.me/
Amel Belaggoun Inria, France
Valerie Issarny Inria, France
Agenda
• Mo+va+on – Role of non-‐func+onal requirements in the decision making for self-‐
adapta+on – Impact of architectural decisions on the sa+sficement of non-‐
func+onal requirements (NFRs)
• Dynamic Decision Networks to support decision-‐making under uncertainty
• Case Study • Conclusions and Future Work
SoUware of the Future
Increasingly self-‐managing
Requirements-‐aware Systems: a Research Vision
SoUware of the Future Will need to adapt to changing environmental condi+ons Uncertainty: these changes are difficult to predict and an+cipate, and their occurrence is out of control of the applica+on developers
!!
Requirements-‐aware Systems: a Research Vision
Let’s focus on
• Impact of architectural decisions (configura+ons) on the
sa+sficement of non-‐func+onal requirements
Costs Reliability Performance
Configura*on 1 + + -‐
Costs Reliability Performance
Configura*on 2 + -‐ +
• func+onal requirement “collect data about a volcano”
• Non-‐func+onal requirements (NFRs)
B : “conserve baOery power” C : “collect data frequently”
• 2 contexts: quiescent and erup*on
– “conserve baKery power” priori+zed during a quiescent context – “collect data frequently” priori+zed during erup*on
• Decisions to make: – Network design
• Decision 1: Shortest path (SP) (less efficient but may conserve baKery) • Decision 2: Fewest Hops (FH) (more efficient but may drain baKery faster)
Mo+va+ng Example: a sensor network of a volcano
ß SP
ß HP
quiescent
erup*on
Goal model for the example
collect data
Shortest path (SP)
Fewest Hops (FH)
energy efficiency
collect data frequently
++
-‐-‐
++
-‐-‐
goal goal realizaAon
strategy soBgoals (NFRs)
Goal model for the example
collect data
Shortest path (SP)
Fewest Hops (FH)
energy efficiency
collect data frequently
++
-‐-‐
++
-‐-‐
goal goal realizaAon
strategy soBgoals (NFRs) design assumpAon
(claim)
C1
C1: SP is too risky
False
During execu+on
collect data
Shortest path (SP)
Fewest Hops (FH)
energy efficiency
collect data frequently
++
-‐-‐
++
-‐-‐
goal goal realizaAon
strategy soBgoals (NFRs) design assumpAon
(claim)
C1
C1: SP is too risky
False
During execu+on
collect data
Shortest path (SP)
Fewest Hops (FH)
energy efficiency
collect data frequently
++
-‐-‐
++
-‐-‐
goal goal realizaAon
strategy soBgoals (NFRs) design assumpAon
(claim)
C1
C1: SP is too risky
True
Claim Refinement Model
Faults Likely SP is less resilient than FH
SP is too risky
AND
Non-‐func+onal Requirements:
• Not easy to reason about their fulfillment – "tension" between them – tensions need to be iden+fied and resolved in an op+mal way
• Measurement of sa+sfac+on of NFRs is difficult – NFRs are vague or fuzzy – NFRs may not be absolutely fulfilled (they can be labeled as sufficiently sa+sficed)
NFR1 Performance
NFR2 Cost
not easy guys to deal with
Non-‐func+onal Requirements:
• Not easy to reason about their fulfillment – "tension" between them – tensions need to be iden+fied and resolved in an op+mal way
• Measurement of sa+sfac+on of NFRs is difficult – NFRs are vague or fuzzy – NFRs may not be absolutely fulfilled (they can be labeled as sufficiently sa+sficed)
NFR1 Performance
NFR2 Cost
not easy guys to deal with
All is exacerbated in the case the running
system needs to make such decisions by itself during run+me
Uncertainty about the environment makes it difficult to predict the effect of the impact of architectural decisions on the sa+sficement of non-‐func+onal requirements
Non-‐func+onal Requirements: fuzzy guys
• Should we use probability theory to describe the lack of crispness and the uncertainty about the sa+sfiability nature of NFRs?
Given an architectural decision dj that requires a certain configura+on, the sa+sficement of a NFRi can be modeled using probability distribu+ons
P(NFRi saAsficed | dj)
Probability to express the lack of crispness of NFRs.
collect data
Shortest path (SP)
Fewest Hops (FH)
energy efficiency (E)
collect data Frequently (D)
++
-‐-‐
++
-‐-‐
P(D|FH)
P(E|FH)
Use of Bayesian Networks to support decision-‐making in self-‐adapAve systems
P(D | FH) = P ( D saAsficed / architectural decision FH) P(E | FH) = P ( E saAsficed / architectural decision FH) P(D|FH) > P(E|FH)
• Extension of Bayesian Networks to support decision-‐making • Directed Acyclic Graph (DAG) associated
• Types of nodes: • Chance nodes: labeled by random variables Xi that
represent the states of the world • Decision nodes: with the set of choices • UAlity nodes: that state the preferences
about the states of the world • Evidence nodes: to denote the observable variables
The condi+onal probabili+es quan+fy the effects of decisions on states of the world
Tackling Decision-‐making with Dynamic Decision Networks for Self-‐adapta+on
Random X2 Random X1
Decision D1 D2
U
Evidence E
P(X1|dj) P(X2|dj)
EUj = EU(dj | e) = P(xii∑ | e,dj )U(xi | dj )
j =1,2
X1(t) X(t+1)
D(t) D(t+1)
U(t+1) U(t) E(t) E(t+1)
Evidence depends on state
X2 X2
….
….
….
Time t Time t+1 Time t+n
Dynamics Decision Networks (DDNs)
Characteris+cs of decision-‐making problems addressed by DDNs:
• Environment changes over +me
• Informa+on is available to the DDN (as a decision maker) based on data provided
by monitorables and also by human-‐made reports (monitorable: en+ty in the environment and the system itself that can be monitored)
• The DDN can be prompted to make a decision at specific +mes (known or
unknown before the DDN is built)
• These decisions are best characterized as choices associated with mee+ng a goal
Crucially, the above are characteris*cs exposed by self-‐adap*ve systems
U
Evidence
Collect Data Frequently (D)
Energy Efficiency (E)
Decision SP FH
22
Dynamic Decision Networks for the example
Decisions (goal realizations) SP: Clean when Empty SH: Clean at Night
Chance node) (Softgoals - non functional requirements) M : Minimize Energy Cost A : Avoid Tripping Hazard
collect data
Shortest path (SP)
Fewest Hops (FH)
energy Efficiency (E)
collect data frequently (D)
++ -‐-‐
++
-‐-‐
P(D|SP)
available evidence
the condi+onal probability U+lity (i.e. preferences)
P xi e,dj( )U xi d j( )
e
Dt E
Decision SP FH
U Evidence e
EUj = EU(dj | e) = P(xii∑ | e,dj )U(xi | dj )
j =1,2
The decision made is that with max EUj
Decision P(E| dj)
SP P(E|SP)= 0.8
FH P(E|FH)= 0.4
Decision P(D| dj)
SP P(D|SP)= 0.6
FH P(D|FH)= 0.75
Decision E D Weight SP F F 0
SP F T 75
SP T F 70
SP T T 100
FH F F 0
FH F T 65
FH T F 70
FH T T 80
Preparing the ini+al values of the DDN
Sensor model P( et| Dt)
E : energy Efficiency (E)
Dt : collect data frequently (D)
SP Shortest Path
FH: Fewest Hopes
NFRs
decisions
Remote Data Mirroring (1) Copies of important data are stored at one or more secondary loca+ons
Goal: Protect data against loss and unavailability
Case Study
• Design choices • Remote mirroring protocols e.g. Minimum spanning tree (MST) vs Redundant topology (RT)
(1) “Relaxing claims:Coping with uncertainty while evalua*ng assump*ons at run *me,” A. Ramirez, B. Cheng, N. Bencomo, and P. Sawyer, ACM/IEEE Int. Conference on Model Driven Engineering Languages & Systems MODELS, 2012.
Goal model for the RDM applica+on (1) 3
3
(1) “Relaxing claims:Coping with uncertainty while evalua*ng assump*ons at run *me,” A. Ramirez, B. Cheng, N. Bencomo, and P. Sawyer, ACM/IEEE Int. Conference on Model Driven Engineering Languages & Systems MODELS, 2012.
DDN for RDM applica+on
Decisions: MST: Minimum Spanning Tree RT : Redundant Topology
Non-‐func*onal requirements NFRs: MR_t: Maximize Reliability MP: Maximize Performance MO: Minimize Opera+onal costs
Et: design assump+on Redundancy prevents networks par++ons.
Uncertainty Factors
• When does the DDN is re-‐evaluated to make a decision? When condi+onal probability func+ons and its values (i.e., beliefs) have changed due to learned informa+on
• Environmental and context proper*es that can cause changes on the probability need to be iden*fied accordingly
We call those environmental proper+es: uncertainty factors
Uncertainty Factors 3
Design assump+on C1= “Redundancy prevents networks par++ons” Its validity can be monitored at run+me This assump+on C1 is falsified if two or more network links fail simultaneously
3
How decisions are made? Suppose the chance nodes are MRt, MP,MO and UAlity depends on them, and the evidence node is E
this generates the best decision D that maximizes the expected u+lity
Markov property
ObservaAon/Sensor Model TransiAon Model
Experiments • Tool: Ne+ca development environment
hKp://www.norsys.com Ne+ca is a soUware to model and run Decision and Bayesian Networks
• Generic scenario “C1 = Redundancy prevents the networks parAAons” is monitored. At design +me, C1 has been considered valid (true ) and MST is chosen However, during run+me a change on this value is monitored, specifically at +me slice – t = 3 , the value false is observed, which means that the design assump+on has been falsified.
– t = 7, according to the monitoring infrastructure the design – assump+on C1 is true again
Experiments
• Exp 1-‐ Decision-‐Making • Exp 2-‐ Effects of Weights on Decision-‐Making • Exp 3-‐ Levels of Confidence on the Monitoring Infrastructure
U+lity Table
Experiment 1-‐ Decision-‐Making
Evidence monitored as False
Evidence monitored as True
“C1 = Redundancy prevents the networks parAAons”
U+lity Table
Experiment 2-‐ Effects of Weights on Decision-‐Making
Evidence monitored as False
Evidence monitored as True
Experiment 3-‐ Levels of Confidence on the Monitoring Infrastructure
Design decision “C1 = Redundancy prevents the networks par++ons” is monitored P(e|C1=true) = 0.9 P(e|C1=true) = 0.8 P(e|C1=true) = 0.4
State of the art Approach Model/Formalism
used Design *me
Run*me Learning
GuideArch [Esfahani+FSE1’2]
Possibility theory
[Letier+FSE’04] Probability theory
RELAX [Whittle+RE’09]
Fuzzy logics
REAssure [Welsh+ ASE ’11]
Goal models+ Claims
RELAXing-‐Claims [ Ramirez+MRT’12]
Fuzzy logics
POISED [Esfahani+FSE’11].
Possibility theory +Fuzzy logics
[Liaskos+RE’10]
Goal models
KAMI [Filieri’11] Marcov chains+ Bayesian inference
Our approach DDNs+ Bayesian inference
When Uncertainty is solved
X √ X
√ X
X
X
X X
X
√
√
√
√ √
√
√ √
√
√
√
√ √
√
X X √
Summary
DDN-‐based approach
• Uses Bayesian networks to guide decision-‐making processes
• Defines the uncertainty associated with the current situa+on in terms of the
condi+onal probabili+es
• Balances different conflic+ng sofgoals according to given preferences u+li+es
• Maintains the defini+on of uncertainty over +me as new informa+on arrive in
a consistent way with the past
• Incorporates risk preferences (i.e. rewards and penal+es) that properly
address the current situa+on modeled
Summary
• DDNs can provide a quan+ta+ve technique to make informed decisions due to the arrival of new evidence during either run+me or during a process to explore the opera*ng environment to elicit requirements.
Future Work
Use the DDNs to explore and improve our understanding
of the opera+ng environment and to elicit requirements
Use the DDNs to explore requirements scenarios with the
goal of quan+fy requirements P(Cost <40) > 0.9
More work on how iden+fy uncertainty factors
Claim Refinement Model
Faults Likely SP is less resilient than FH
SP is too risky
AND
Ongoing Work on Bayesian Surprise Theory for SASs
A surprise measures how new evidence affects the models or assump+ons of the world.
The key idea is that a “surprising" event can be defined as one that causes a large divergence between the beliefs distribu+ons prior and posterior to the event that has been observed.
According to how big/small the surprise is, the running system may decide to either dynamically adapt accordingly or to highlight the fact that an abnormal situa+on has been found.
Ongoing Work on Bayesian Surprise Theory for SASs
• the surprise can be measured using the Kullback-‐Leibler divergence (KL), which es+mates the divergence between the prior and posterior distribu+ons
• Among other several ques+ons we want to answer, we have: – how big or small a surprise can be considered given an absolute value?
– are there other alterna+ve ways to measure a surprise?
A bit of reflec+on
• The algorithms applied take +me • We need tools (and we do not necessarily want to construct them from scratch)
• We (soUware engineers) need to create synergies with people of Ar+ficial Intelligence
Thanks
Discussion time