Hossein Tajalli, Joshua Garcia, George Edwards, and Nenad Medvidovic Computer Science Department University of Southern California
Jan 18, 2016
Hossein Tajalli, Joshua Garcia, George Edwards,and Nenad Medvidovic
Computer Science DepartmentUniversity of Southern California
Introduction
Modern Software Requirements•High reliability•High availability•Run-time support for
• Alter/extend functionality• Handle failure• Update (e.g. to fix bugs)
Architecture-Based Autonomic Systems•Self-aware, self-adapting, and self-healing•Low complexity•High scalability•Builds on existing work
Example Application
1 2 3 4
unlock
lock
load lock
unload unlock
Locked Ø LoadedLoaded ˄ Locked
Domain Model Description
Implementation & Goal Change
Executer
LoaderLocker
Connector
New Executer
1 2 3 4
unlock
lock
load lock
unload unlock
Locked Ø LoadedLoaded ˄ Locked
GOAL4New GOAL 1
PLAN
State Action
1 unlock
2 load
3 lock
4 DONE
PLAN
State Action
4 unlock
3 unload
2 lock
1 DONE
Planning
1 2 3 4
unlock
lock
load lock
unload unlock
Locked Ø LoadedLoaded ˄ Locked
GOAL4New GOAL 1
Executer
LoaderLocker
Connector
Change of Requirements
1 2 3 4
unlock
lock
load lock
unload unlock
Locked Ø LoadedLoaded ˄ Locked
5
load adjust
Misplaced
Change of Requirements
Executer
Connector
New Executer
1 2 3 4
unlock
lock
load lock
unload unlock
Locked Ø LoadedLoaded ˄ Locked
GOAL4
5
load adjust
Misplaced
LoaderLocker Adjuster
Policy-based Adaptation
Executer
Connector
1 2 3 4
unlock
lock
load lock
unload unlock
Locked Ø LoadedLoaded ˄ Locked
GOAL4
5
load adjust
Misplaced
LoaderLocker Adjuster
Policy:
If (state=“Misplaced”)Instantiate(Adjuster);Add(Adjuster);Connect(Adjuster, Connector);Replace(Executer);
New Executer
• Domain of software adaptation can be modeled• Model can be used to plan for adaptation
Software Adaptation Domain
1
2
3
4
5
6
7 8
Inst(C1)Add(C1) Add(C2
)
Inst(C2)
Inst(C1)Inst(C2)Kill(C2)
Kill(C2)
Kill(C1)
Kill(C1)
Remove(C1
)
Add(C1)
Remove(C1)Add(C2)Remove(C2)
Remove(C2) Connect(C1,C2)
Disconnect(C1,C2)
Exist(C1)˄ Exist(C2)
˄ ArchIncludes(C1)˄ ArchIncludes(C2)
˄ Connected(C1,C2)
Exist(C1)˄ Exist(C2)
˄ ArchIncludes(C1)˄ ArchIncludes(C2)
Exist(C1)˄ Exist(C2)
˄ ArchIncludes(C1)
Exist(C1)˄ Exist(C2)
˄ ArchIncludes(C2)
Exist(C1)˄ Exist(C2)
Exist(C2)
Exist(C1)
Ø
5Architecture
C1 C2
5
7
7
8
8
Software Adaptation Domain (Planning)
5
Architecture
C1
8
Architecture
C1 C2
GOALINITIAL
Adaptation PLAN
State Action
5 Add(C2)
7 Connect(C1,C2)
8 DONE
Software Adaptation Domain (Implementation)
1
2
3
4
5
6
7 8
Inst(C1)Add(C1) Add(C2
)
Inst(C2)
Inst(C1)Inst(C2)Kill(C2)
Kill(C2)
Kill(C1)
Kill(C1)
Remove(C1
)
Add(C1)
Remove(C1)Add(C2)Remove(C2)
Remove(C2) Connect(C1,C2)
Disconnect(C1,C2)
Exist(C1)˄ Exist(C2)
˄ ArchIncludes(C1)˄ ArchIncludes(C2)
˄ Connected(C1,C2)
Exist(C1)˄ Exist(C2)
˄ ArchIncludes(C1)˄ ArchIncludes(C2)
Exist(C1)˄ Exist(C2)
˄ ArchIncludes(C1)
Exist(C1)˄ Exist(C2)
˄ ArchIncludes(C2)
Exist(C1)˄ Exist(C2)
Exist(C2)
Exist(C1)
Ø
Our Solution: PLASMA
ApplicationComponent
Models
ApplicationDomainModel
AdaptationComponent
Models
AdaptationDomainModel
AdaptationGoal
Application Goal
ApplicationPlan
AdaptationPlan
Modeling Planning AdaptationArchitecture
ApplicationPlan Executer
AdaptationPlan Executer
1. Adaptive Layered Style
PLASMA Ingredients
1 2 3 4unlock
lock
load lock
unload unlock
GOAL4
1. ADAPTIVE LAYERED STYLE
Adaptive Layered Style Overview
• Each layer manages and adapts the layer below it• Meta-layer architecture• Specialized meta-components
• Collector, Analyzer, and Admin
• Arbitrary number of layers
Component 1
Component 2
Component 3
Collector Analyzer Admin
ArchitectureEventReference
PLASMA Layered Architecture
• PLASMA is a 3-layer instance of the adaptive layered style
Component 1
ExecuterComponent
2
Collector Analyzer Admin
Application Layer
Adaptation Layer
Collector Analyzer Admin
Planning Layer
Application Planer
AdaptationPlaner
Component 3
2. ARCHITECTURE DESCRIPTION LANGUAGE
Architecture Description Language
• ADL• A notation for modeling a software architecture
• SADEL• Adapted from C2SADEL• Models components, connectors, and topology• Component behavior in terms of operation
pre-conditions and post-conditions
component Admin is{state {
Connected : Component , Connector -> Boolean;ComponentExist : Component -> Boolean; ...
}interface{
prov ConnectInterface: Connect(comp:Component; conn:Connector);
prov instantiateCompInterface: instantiatComponent(comp:Component); ...}operations{
prov opConnect:{ let conn:Connector; comp:Component; pre ((ConnectorExist(conn)) \and
(ComponentExist(comp)) \and (\not(Connected (comp,conn)));
post Connected(comp,conn);}prov opInstantiateComponent:{ let comp:Component; pre (\not(ComponentExist(comp))); post ComponentExist(comp);}...
Component Models
component loader is{state {
loaded : Boolean;locked : Boolean;
}interface{
prov loading: load();prov unloading: unload();
}operations{
prov opLoad:{pre (\not(loaded)) \and (\
not(locked));post (loaded) \xor (misplaced);
}prov opunLoad:{
pre (loaded) \and (\not(locked));post \not (loaded);
}}...
• PLASMA only needs component models• PLASMA calculates the architecture topology
SADEL for PLASMAA
pplic
atio
nA
dapt
atio
n
PLASMA
PLASMA
3. PLANNING
Planning
• Model-based planner • Planning as model checking technique
• Check the correctness of formulas to find a plan
• Goals • Reachability• Maintainablity• …
• Plans• State-action sets
• PLASMA uses planning • Behavior of application• Software adaptation
PLASMA Architecture
Plan Executer
Loader
CollectorAdaptationAnalyzer
Admin
Collector Analyzer Admin
ADL Model Parser
ADL ModelParser
Application Planner
Adaptation Planner
Locker
Adjuster
CASE STUDY
Case Study
• Robot convoy application • One leader IRobot
• Waypoint following
• Several follower IRobot• Camera following• IR following• GPS following
• Goal : IsFollowing ˄ ¬BehindAnObstacle
Case Study Deployment
Desktop Computer
Planning Layer
Robot 1
Adaptation Layer
Application Layer
Plan Executer
ColorFollower
Camera Robot Actuators
RoleNegotiator
Robot 4
Adaptation Layer
Application Layer
Plan Executer
ColorFollower
Camera Robot Actuators
RoleNegotiator
Situation
Application Plan Length
(# State-Actions)
Application Planning
Time (Sec)
Adaptation Plan Length
(# State-Actions)
Adaptation Planning Time
(Sec)
Initial deployment
790 0.3 1353 1.59
Chang of req. & goal
2318 1.2 4390 5.89
Camera failure
856 0.4 3110 3.74
Case Study Evaluation
• Initial deployment • 15 components
• Change requirements and goal• Add a Charger component • Change goal to: IsFollowing ˄ ¬BehindAnObstacle ˄ ¬BatteryIsLow
• Failure• Camera fails
Conclusions
• Automated adaptation• Component failure• Goal change• System requirement change
• Automated planning for adaptation • Adaptation plans are generated automatically
• Less burden on system architect• Architect only provides component models and system goal • Architect does not need to design the application topology• Architect does not need to design the adaptation policies
?!