Modeling Behavior of Self-Adaptive Systems

1. Modeling Behavior of Self-Adaptive Systems Seminar Software Quality and Safety

2. Example scenario • Railcab shuttles are autonomous train systems • Transport goods or people • May form convoys to save energy • Here: Two modes of operation • Energy efficient travelling • Fast travelling to fulfill a pressing deadline http://nbp-www.upb.de/typo3temp/pics/b6345617cd.png

3. Motivation • Autonomous systems operate without human control • Intuitively: Self-Adaptive systems adapt own behavior autonomously • Useful in situations that are • dangerous, e.g. chemical accidents • unpleasantly, e.g. dusty environments • stupid, e.g. manufacturing at assembly-lines • Systems should react to environment changes

4. Self-Adaptive Software • Definition: • „Self-Adaptive Software evaluates its own behavior and changes behavior when the environment indicates that it is not accomplishing what the software is intended to do, or when better functionality or performance is possible.” DARPA Broad Agency Anouncement • Here: • Shuttle must increase speed when deadline might be missed • Shuttle may decrease speed when deadline can be accomplished easily

5. General approach • Self-Adaptation requires • Monitoring of environment • Analysis of monitored state • Knowledge about own architecture and behaviors • Ability to modify architecture and/or load algorithms Observers Architecture editor Observation analysers Adaptation planning and deployment cf. Oreizy et.al. - An Architecture-Based Approach to Self-Adaptive Software

6. General steps in modeling self-adaptive behavior • General modeling approach introduced by Zhang and Cheng: • Specify global invariants • Enumerate domains and conditions under which system is in domain • Specify local properties for each domain • Build state based models for each domain • Enumerate possible domain changes and build adaptation models • Use state-based models to generate test cases. cf. Ji Zhang, Betty H.C. Cheng - Model-Based Development of Dynamically Adaptive Software

7. 1. Specify global invariants Two properties for shuttle scenario (1) Shuttle will eventually reach its target (2) If a deadline exists, the shuttle will fulfill it Properties are specified using temporal logic (1) G F shuttle_atTarget (2) G (existsDeadline => (t(shuttle_atTarget) <= deadline)

8. 2. Enumerate domain and conditions Two modes of operation correspond to two domains Energy efficient travelling In case of no deadline In case of non pressing deadline Fast travelling In case of pressing deadline

9. 3. Specify local properties Local properties must fulfill global properties Properties for energy efficient travelling G( convoy_available => join_convoy) Properties for fast travelling G( convoy_available  speed(convoy) < speed(this) => overtake_convoy)

10. 4. Build state-based models • Models are steady-state models that contain no adaptive behavior • Can be Model Checked against local properties Energy efficient travelling Fast travelling

11. 5. Enumerate domain changes … Domain changes: Energy efficient travelling -> Fast travelling Change if deadline cannot be fulfilled with current speed Fast travelling -> Energy efficient travelling Change if deadline can be reached with efficient speed Adaptation model describes switch from old to new behavior Adaptations can be model checked against global properties

12. … and build adaptation models • Adaptation possible in so called quiescent states • Intuitively: Quiescent states are stateless and therefore equivalent to the initial state • E.g. switch from energy efficient to fast travelling Performs the change, transfers important variables. adaptReq(1) Adaptation Model 1

13. 6. Generate test-cases Use state-based models to generate test-cases Can be done using standard techniques Shall not be treated here.

14. Structure and behavior adaptation Seen so far: pure structure adaptation pure behavior adaptation But: Structure and behavior influence each other! Changing system structure changes system behavior Changing behavior may require new components and links Behavior change may be implemented by loading components New components may introduce new behavior It might not be known how many components are connected at runtime

15. Structure change affects behavior • Example: • Shuttles can build convoys • Build of a new convoy requires one shuttle to coordinate • Needs additional coordination behavior • Change can be executed by loading a new component which provides coordination behavior

16. Comparison • Commonalities: • Allow adaptation only on one hierarchy level • Selection of next algorithm out of fixed set • Differences • States from which adaptation is possible • Approach by Zhang & Cheng allows to jump directly into new behavior • Mechatronic UML starts component behavior from the initial state

17. Limitations • Self-Adaptive systems and modeling of these system is still under research • Some points are still unclear: • How can surprise be handled by the system? • Will the system behave reasonable and find a good solution in all environment situations? • How can self-adaptation be combined with learning algorithms to optimize adaptation decisions at runtime? cf. Laddaga - Self Adaptive Software – Problems and Projects

18. Conclusions • Self-Adaptive systems operate autonomously and adapt to changing environment • Self-Adaptation requires monitoring of the environment and knowledge about own architecture • General approach proposes six steps during the modelling process. • Adaptations can be modelled by adaptation models • Structure and behavior influence each other • Self-Adaptation is still under research

19. Degrees of Self-Adaptation • Conditional expressions • Online algorithms • Parameterized algorithms • Algorithm selection • Evolutionary Programming Low High