Variability in Self-Adaptive Systems

1. Variability in Self-Adaptive Systems

2. Variability: the heart and soul of Adaptation • Whatmay be variable? • How to specifyvariability? • When to adapt? • How to adapt (=bind variability)?

3. Variability - when • Variability - need to be planned at design time – may be bound at: • Design time • Production time (compile and load) • Initialization time • Run time • Self-configuring: variability + initialization mechanisms • Self-adaptive: variability + initialization + run time mechanisms (responding to changes) • Dynamic component systems: dynamic life cycle support for components that self-configure and self-adapt: • install, configure, start, run and adapt, stop, uninstall.

4. Case 1: call handling • Key principle: components, dynamic linking and standard interfaces • Vast variability in call structures, networks, devices, protocols, services: anticipated, but not enumerated • Adaptation to the requirements and context of each call • Mobile systems also adapt to moving users: this imply registries and dynamic routing • The global network is a dynamic component system! Each node normally not.

5. Dynamic linking for compositional adaptation Advantages: • Enables huge variability in component and role combinations: k+l+m components/roles gives k*l*m combinations • Is relatively simple • Can be performed as integral part of services Challenges: • Roles are not independent and cannot be arbitrarily combined! • More run-time combinations may occur than explicitly analyzed at design time! • Ensuring interoperability while allowing flexibility: interfaces.

6. Support needed • Addressing and routing mechanisms • Name server, registry. • Dynamic linking and session initiation • Sensing context changes

7. Case 2: Network access in mobile phone • Monitoring network availablility • Dynamic linking to available network(s) based on policy and preferences

8. Case 3: Fault tolerance • Detect and diagnose errors • Reconfigure to mask errors • Hot or cold standby • Load shared or synchronized

9. Case 4: Load adaptation • Monitor load situation • Adapt scheduling • Adapt queue sizes • Adapt timers • Drop fresh traffic • Distribute load

10. Case 5: security adaptation

11. Server Pull {when ...} UTPA {when ...} User Pull {when ...} UoPA {when ...} Compositional adaptation by replacement and insertion usingpolicy rulesevaluated byagentsuponrole requests {when threat level = 0 or location = secure} <<replaces>> or {when threat level > 0 or location not secure} or

12. Controlled locally by actors The actors use policies to decide which role to offer when a role is requested (part of the role binding)

13. More cases • Finding nearby printers – how? • Plugging in USB devices – how? • Loading applications/components – how to bind to context?

14. find-bind: Static and dynamic linking • Find instances (of predefined types) : • Identified instances or instance sets; e.g. Doctors, subscribers • Identified functionalities/services; e.g. Printers; Map servers • Bind by requesting to an allocator or manager • Release by notifying the allocator or manager. • Requires: • Registry to find (map from names to instance sets) • Managers/allocators to bind-release (session initiation) Doctors Patients Registry Patology: ref Hart: ref .... DoctorAgent[m] PatientAgent[n] Object pnp here

15. Now let us consider a HNS system • Fire and burglar alarms • Climate control: heating and cooling • Power control: minimize power costs • Smart metering (AMS) • Access control • Assisted living (well-fare technology) • Entertainment • Cooking • Lighting • Etc.

16. We want as much self adaptation as possible – how? • Every device is networked! • We want to plug in and out devices: heaters, alarm sensors, panels, power meters, appliances, weather stations, ... • We want to connect devices with service providing applications • We want to (buy and) install applications • We want to access external resources and to have remote access

17. Variability dimensions Compatibility is required in both dimensions! • to communicating objects - horizontal • to implementation capabilities - vertical Server App Protocol Term App Protocol Server App Protocol Protocol Term App RTS RTS RTS RTS Middleware Middleware Middleware Middleware Principles: component based design; encapsulation; loose coupling; separation of concerns; layering; metadata

18. Variability: some approaches • Dynamic component systems • Dynamic linking • Software product line approaches • Variability languages • Feature selection - feature diagrams • Versioning and building • Parameterization • Aspects, crosscutting concerns and weaving • Structural alternatives • Behavioral alternatives • Transformations • Goal models, GRL • Policies

19. Variability: different levels of abstraction S1 S2 S1.1 S2.1 Services Services: • Types of services and features • Service compositions Design: • Types of design components and data, • Instance structures, multiplicities and data values • Realization: • Types of HW/SW components and platforms • QoS mechanisms • … S3 S3.1 S2.2 Role binding Designs Deployment binding Realization, Execution Self* mechanisms – what and how?

20. Our focus • Initialization and runtime adaptation mechanisms • How to specify in service models and design models • How to realize

21. Self-adaptive By self adaptive wemean systems and componentsthatconfigurethemselves and dynamicallyadapt to changingenvironmentswith minimal human participation. Differentapproaches: • Pre-structured systems: parameter adaptation and some (limited) compositionaladaptation • Dynamiccomponent systems: compositionaladaptation • Autonomic systems: self* Environment System