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

2. 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

3. Example Application 1234 unlock lock loadlock unload unlock LockedØLoaded ˄ Locked Operations: lock unlock Locker Comp Operations: load unload Loader Comp Domain Model Description

4. Implementation & Goal Change Executer Loader Locker Connector New Executer 1234 unlock lock loadlock unload unlock LockedØLoaded ˄ Locked GOAL 4 New GOAL 1

5. PLAN StateAction 1unlock 2load 3lock 4DONE PLAN StateAction 4unlock 3unload 2lock 1DONE Planning 1234 unlock lock loadlock unload unlock LockedØLoaded ˄ Locked GOAL 4 New GOAL 1 Executer Loader Locker Connector

6. Change of Requirements 1234 unlock lock loadlock unload unlock LockedØLoaded ˄ Locked 5 loadadjust Misplaced Operations: lock unlock Locker Comp Operations: load unload Loader Comp Operations: adjust Adjuster Comp

7. Change of Requirements Executer Connector New Executer 1234 unlock lock loadlock unload unlock LockedØLoaded ˄ Locked GOAL 4 5 loadadjust Misplaced Loader Locker Adjuster

8. Policy-based Adaptation Executer Connector 1234 unlock lock loadlock unload unlock LockedØLoaded ˄ Locked GOAL 4 5 loadadjust Misplaced Loader Locker Adjuster Policy: If (state=“Misplaced”) Instantiate(Adjuster); Add(Adjuster); Connect(Adjuster, Connector); Replace(Executer); New Executer

9. Policy-based Self-Adaptive Systems Current Policy-based systems (e.g. PBAAM [Georgas&Taylor08]) Puts lots of burden on system architect Manually created policies: time-consuming, error-prone Only handle foreseen situations

10. Plan-based Self-Adaptive Systems Current plan-based self-adaptive systems (e.g. [Sykes08]) Manual system requirement definition Cannot handle change in system requirements Cannot handle goal change at runtime Are not used to change the structure of the software

11. 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(C1) Remove(C1) Add(C1) Remove(C1) Add(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) Ø 5 Architecture C1 C2 5 7 7 8 8

12. Software Adaptation Domain (Planning) 5 Architecture C1 8 Architecture C1C2 GOAL INITIAL Adaptation PLAN StateAction 5Add(C2) 7Connect(C1,C2) 8DONE

13. 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(C1) Remove(C1) Add(C1) Remove(C1) Add(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) Ø Operations: Inst(C); Kill(C); Add(C); Remove(C); Connect(C1,C2); Distconnect(C1,C2); Admin Comp

14. PLASMA Our Solution to Self-Adaptation A Plan-based Layered Architecture for Software Model-driven Adaptation (PLASMA)

15. PLASMA vs. Current Self-adaptive Methods Policy-based self-adaptivePLASMA Architect captures different situation which requires adaptation PLASMA decides when adaptation is required Architect creates the policies manually Adaptation plans are created automatically Error-prone adaptation policiesError-free adaptation plans Plan-based self-adaptivePLASMA Architect provides the domain model PLASMA creates the domain model from component models automatically Can not handle change in domain model (system requirements) PLASMA handles changes in domain model Plans for application (not for software adaptation) PLASMA plans for both application and software adaptation

16. Our Solution: PLASMA Application Component Models Application Domain Model Adaptation Component Models Adaptation Domain Model Adaptation Goal Application Goal Application Plan Adaptation Plan Modeling Planning Adaptation Architecture Application Plan Executer Adaptation Plan Executer

17. 1. Adaptive Layered Style PLASMA Ingredients 2. Architecture Description Language 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); } prov opunLoad:{ pre (loaded)\and(\not(locked)); post \not (loaded); } …. } 3. Planning MBP Plan 1234 unlock lock loadlock unload unlock GOAL 4

18. 1. ADAPTIVE LAYERED STYLE

19. 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 2Component 3 CollectorAnalyzerAdmin Meta Layer Application Layer Architecture EventReference

20. PLASMA Layered Architecture PLASMA is a 3-layer instance of the adaptive layered style Component 1 Executer Component 2 CollectorAnalyzerAdmin Application Layer Adaptation Layer CollectorAnalyzerAdmin Planning Layer Application Planer Adaptation Planer Component 3

21. 2. ARCHITECTURE DESCRIPTION LANGUAGE

22. 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

23. 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

24. SADEL for PLASMA Application Adaptation PLASMA

25. 3. PLANNING

26. 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

27. Application Planning 27 Plan MBP (define (domain example) (:predicates (loaded) (misplaced) (locked) ) (:action load :precondition (and(not(loaded))(not(locked))) :effect(loaded) ) (:action unload :precondition(and(loaded)(not(locked))) :effect (not(loaded)) ) (:action unlock :precondition (locked) :effect(not(locked)) ) (:action lock :precondition (not(locked)) :effect (locked) ) (define (plan generated_plan) (:domain test) (:problem simpleProblem) (:body (repeat (switch (case (and (= (locked) 1) (= (loaded) 1)) (done)) (case (and (= (locked) 1) (= (loaded) 0) (= (misplaced) 1)) (action (adjust))) (case (and (= (locked) 1) (= (loaded) 0) (= (misplaced) 0)) (action (unlock))) (case (and (= (locked) 0) (= (loaded) 1)) (action (lock))) (case (and (= (locked) 0) (= (loaded) 0) (= (misplaced) 1)) (action (lock))) (case (and (= (locked) 0) (= (loaded) 0) (= (misplaced) 0)) (action (load))) (else (fail)) )) ) (define (problem simpleProblem) (:domain test) (:init (and (unknown(locked)) (unknown(loaded)) ) (:goal (and (locked) (loaded) )

28. Adaptation Planning Plan MBP

29. PLASMA Architecture Connector Plan Executer Loader Collector Adaptation Analyzer Admin CollectorAnalyzerAdmin ADL Model Parser ADL Model Parser Application Planner Adaptation Planner Planning Layer Adaptation Layer Application Layer Locker Adjuster

30. CASE STUDY

31. Case Study Robot convoy application One leader IRobot Waypoint following Several follower IRobot Camera following IR following GPS following Goal : IsFollowing ˄ ¬BehindAnObstacle

32. 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

33. Situation Application Plan Length (# State-Actions) Application Planning Time (Sec) Adaptation Plan Length (# State-Actions) Adaptation Planning Time (Sec) Initial deployment 7900.313531.59 Chang of req. & goal 23181.243905.89 Camera failure 8560.431103.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

34. 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

35. ?!

36. References [Giunchiglia&Traverso99] F. Giunchiglia and P. Traverso. Planning as model checking. In ECP, pages 1-20, 1999 [Medvidovic99] N. Medvidovic, D. S. Rosenblum, and R. N. Taylor. A language and environment for architecture-based software development and evolution. In ICSE '99: Proceedings of the 21st international conference on Software engineering, pages 44-53, New York, NY, USA, 1999. ACM. [Edwards09] G. Edwards, J. Garcia, H. Tajalli, D. Popescu, N. Medvidovic, G. Sukhatme, and B. Petrus. Architecture-driven self-adaptation and self- management in robotics systems. In Software Engineering for Adaptive and Self- Managing Systems (SEAMS'09), pages 142-151, 2009. [Sykes08] D. Sykes et al. From Goals to Components: A Combined Approach to Self-management. In Int. Workshop on Software Engineering for Adaptive and Self-managing Systems, 2008. [Georgas&Taylor08] J. C. Georgas and R. N. Taylor. Policy-based self-adaptive architectures: A feasibility study in the robotics domain. In Int. Workshop on Software Engineering for Adaptive and Self-managing Systems, 2008. 36

37. Details of planning 37 Application Component Models ADL Model Parser Planner Problem Generator Code Generator Domain Model Application Problem Plan Executer (.class) Problem