Hossein Tajalli, Joshua Garcia, George Edwards, and Nenad Medvidovic Computer Science Department University of Southern California

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


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


GOAL4New GOAL 1

Executer

LoaderLocker

Connector

Change of Requirements

1 2 3 4

unlock

lock

load lock

unload unlock


5

load adjust

Misplaced

Change of Requirements

Executer

Connector

New Executer

1 2 3 4

unlock

lock

load lock

unload unlock


GOAL4

5

load adjust

Misplaced

LoaderLocker Adjuster

Policy-based Adaptation

Executer

Connector

1 2 3 4

unlock

lock

load lock

unload unlock


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)




˄ ArchIncludes(C1)


˄ ArchIncludes(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)



˄ Connected(C1,C2)




˄ ArchIncludes(C1)


˄ ArchIncludes(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


Application Layer

Adaptation Layer


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


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

?!

Documents

Hossein Tajalli, Joshua Garcia, George Edwards, and Nenad Medvidovic Computer Science Department University of Southern California