1. Emergent, Autonomic and Self-adaptive computation Richard Anthony University of Greenwich

2. Introduction Autonomic / Self-managing systems comprise fundamentally two types of entity: the controlling part and the controlled part. The closeness of coupling between these parts varies. Controller Controlled system Higher level system SensorsEffectors Richard Anthony CMS Research Seminar October 2006 1

3. Characteristics Many characteristics identified as requirements of an Autonomic system, including: Self-Defining,Self-Protecting,Self-Optimising, Self-Healing,Self-Configuring,Context awareness, Openness,Anticipatory actions, Self-Stabilising. ‘IBM model’ for autonomic computing Focuses on just four of these qualities (the self-CHOP model). A system can be made to adapt to its environment in very useful ways whilst only exhibiting a few of these qualities (perhaps only partially). Self- C onfigure Self- H eal Self- O ptimise Self- P rotect Richard Anthony CMS Research Seminar October 2006 2

4. Engineered Emergence Emergence:- ‘Structure’ arises from the interaction of numerous autonomous components, -The whole is more than the sum of the parts. Key Advantages- Can be highly scalable, no coordinator, robust, - Behaviour of each entity is simple, - Actions based on local view of system, - Can avoid traditional ‘negotiation’ (→ low latency), - Can automatically accommodate new agents. Disadvantages- Non-deterministic, - Confidence / testing can be problematic, - Need to ensure stability over entire behaviour range. Richard Anthony CMS Research Seminar October 2006 3

5. Employing ‘Emergence’ in an Election Algorithm The Emergent Election Algorithm enables low-latency selection of a master node with low communication complexity and time complexity. Algorithm is completely distributed. Nodes are completely autonomous. Messages individually low-value – algorithm tuned for stability in high-loss conditions. Mimics interaction in natural systems (ant colonies specifically). Algorithm operates in two-stages: First stage ‘continuously’ allocates nodes into a small active group and a much larger passive group. Passive group only eavesdrop, never send. First stage is non-deterministic W.R.T the size and composition of the active group. Second stage deterministically elects / maintains a single master from the active group – low cost because active group is small. Richard Anthony CMS Research Seminar October 2006 4

6. Employing ‘Emergence’ in Graph-colouring algorithms The communication strategy is inspired by natural systems stigmergic mechanisms such as pheromone exchange. An implicit-negotiation model is used, in which nodes observe the state and behaviour of their neighbours by monitoring messages received from them. The low interaction complexity model in turn yields very low communication complexity: No direct negotiation, No acknowledgement of messages, Each node simply broadcasts its state at a pseudo-periodic interval which includes a small random symmetry-breaking component. Based on its local determination of the state of its neighbours, a node acts cooperatively, by attempting to colour itself such that it will not clash with one of its neighbours. Richard Anthony CMS Research Seminar October 2006 5

7. Accumulated-Weight model in use (Example: A 1000-node simulation has converged) Configuration settings: 6 available colours, Diameter adjacency model, minimum overlap enforced, node overlap maximum = 50%. Richard Anthony CMS Research Seminar October 2006 6

8. Utility Functions Utility Functions (UF) provide dynamic, context sensitive selection from Alternatives based on the instantaneous merit of each option. Key Advantages- Relatively low implementation complexity, - Can combine many contextual factors into one decision, Disadvantages- Criteria are typically pre-configured, - Options are typically closed group, - Restricted opportunities for ‘learning’. Richard Anthony CMS Research Seminar October 2006 7

9. UF Example #1 – Configuration and routing in ad-hoc / sensor networks UF at A Send direct (cost more power) Vs send via neighbour (but could refuse) ? UF at B Altruistic- forward messages for A, - extend system range*time product (coverage) but shorten own life. Vs Greedy- preserve power, only send own messages. To decide, both take context and current system goals into account, such as: - Remaining battery life, - The extent of potential savings (inter-node distance), - Importance of coverage Vs survival of individual nodes. A B Destination Richard Anthony CMS Research Seminar October 2006 8

10. UF Example #2 - Colour-utility function Used in Emergent Graph Colouring algorithm to escape local deadlock when no legal colouring scheme can be found. Utility value for a given colour is as the sum of several components: Multi-node premium: If more than one node have the colour add 5 for each additional node. Embeddedness premium: For each node that has the colour add the value of its NumberOfNeighbours. Legal state premium: For each node that has the colour add 2 if its state is Legal. NoColour state premium: For each node that has the colour add 1000 if its state is NoColour. ForceMessage premium: For each node that has the colour, Add an amount that is determined by the age of its ForceMessageLastSentTimestamp. The amount ranges from 50 for recent Timestamp values to 0 for age-depreciated timestamp values. Neighbours having the Lowest utility colour are forced to change their colour. Richard Anthony CMS Research Seminar October 2006 9

11. Policy – Based Computing Key Advantages- Policy external to (compiled) run-time mechanism, - Relatively simple to develop, and test (low risk and cost), - Low resource needed at run-time, - Policy is high-level (usable by non-autonomics-expert), - Wide general applicability. Disadvantages- (Current practice) restricted to simple adaptation scenarios. Richard Anthony CMS Research Seminar October 2006 10

12. Current State-of-Practice in Policy-based Autonomics Three distinct levels of sophistication: 1.Policy rules are statically embedded. The template configuration is exposed and can be modified between executions. 2. Policy updates are open-loop. An external entity (usually a human) identifies, or is alerted to, potential configuration optimisations, which can be applied between executions. 3. Closed-loop adaptation, where the policy dynamically and automatically adapts its own rule-base or template settings during execution. (Few schemes target this level at present). Richard Anthony CMS Research Seminar October 2006 11

13. (a) P (b) T P T P (c) T T T P (d) M P P P P (e) M T P (f) PM T T T T P P P Manual configurationPolicy (rule based)Library of templates Template configurationMeta policyLibrary of policies Direct configuration / control Controlled systemPersisted state Feedback / monitoring / updateState propagation Pictographic representation of policy life-cycles found in current practice Richard Anthony CMS Research Seminar October 2006 12

14. T P (g) T P (h) P P P P (i) M T T T P P P P (j) M T P M T T T T P P P Manual configurationPolicy (rule based)Library of templates Template configurationMeta policyLibrary of policies Direct configuration / control Controlled systemPersisted state Feedback / monitoring / updateState propagation Advanced policy configurations beyond the current state of practice Richard Anthony CMS Research Seminar October 2006 13

15. The AGILE Policy Expression Language Hierarchical support for three levels of ‘policy’: 1. Templates provide configuration parameters which are used to initialise the other types of policy. 2. Normal policies contain the low-level autonomics logic. 3. Meta-policies provide higher-level adaptation. Easy integration with legacy code Powerful API - simple interface to application code, - deals with rule conflicts etc. internally. Supports use by non-autonomics-experts Policy language is highly expressive, supports self-adaptation, yet simple to use API. Richard Anthony CMS Research Seminar October 2006 14

16. Differential between existing approaches and AGILE Some governance delegated to a meta-policy. Dynamic reconfiguration at the level of policies, and their components such as rules. Controlled component Manager Policy Controlled component Manager Policy Meta- Policy State of Practice ? Proposed / Targeted Policy Richard Anthony CMS Research Seminar October 2006 15

17. Integrating Policy-based control with application code Application / Component AGILE Policy Run-time Library Load Policy Script Load Template(s) Persist State Save run-time trace Pass in environmental values Read return values Richard Anthony CMS Research Seminar October 2006 16

18. The Policy Expression Language Extends the state of the art in policy languages: Explicit support for dynamic self-adaptation of policies over both short and long term through persisted configuration changes. Policy suites, in which a particular type of policy can have many differently-geared instances (e.g. cautious and aggressive versions). Suites of templates for a given policy-type allow different initial configurations to be used, depending on circumstances. Meta-policies can be used to select amongst many policy-instances and templates at run-time. Features to support bounded behaviour and enhance stability. Facilitates policy-object reuse. Richard Anthony CMS Research Seminar October 2006 17

19. Time The ‘Compare Against’ parameter represents the goal state, which may itself be dynamic. The ‘Tolerance’ parameter configures the width of the Deadzone, either side of the goal state. A B C Trajectory of value of ‘Check’ variable, representing the ‘controlled’ system, or its environment, at three points in time: At point A the TRC evaluates to Outside-High-Zone, At point B the TRC evaluates to Outside-Low-Zone, At point C the TRC evaluates to In-Zone. Total width of Deadzone Some measured characteristic of system or environment Stability enhancement encapsulated into a special rule object - TRC Richard Anthony CMS Research Seminar October 2006 18

20. Case Example: A multi-policy stock trading scheme (1) Conforms to configuration (i) in the policy taxonomy (beyond current state of practice). Illustrates the use of a meta-policy and the advantage of dynamic switching between instances of business policies. The stock system is representative of many real-world problems that have: Highly complex behaviour, Sensitivity to several sources of environmental volatility, Non-linear sensitivity to some environmental parameters, Many dimensions of freedom. For a system with any of these characteristics, it is not realistic to closely track the system over its entire behaviour range with a single policy. Richard Anthony CMS Research Seminar October 2006 19

21. Case Example: A multi-policy stock trading scheme (2) Trading decisions are subject to influences such as price behaviour trends, the rate of change in traded volumes and the rate of change in price, etc. A single, generalised (and thus coarse) policy could lead to significant sub-optimality across a wide spectrum of behaviours. One solution is to divide the application behaviour space into several zones. Each zone requires a stock-price-based trading strategy, contextualised by a given range of rate of change in traded volumes and in price. Zone # 2 Zone # 3 Zone # 1 Zone # 4 Rate of Volume Traded change Rate of Price change The policies have different configuration but are of the same ‘type’ since they address the same business decision (but arrive at their decisions differently). Richard Anthony CMS Research Seminar October 2006 20

22. Case Example: A multi-policy stock trading scheme (3) Each policy is configured such that its operational envelope (that over which it guarantees safe and desirable behaviour) is tuned to map closely onto its ‘zone’. A self-adaptive policy may adjust its own thresholds over time, or these might be supplied externally. Richard Anthony CMS Research Seminar October 2006 21

23. Case Example: A multi-policy stock trading scheme (4) Individual policies need not be aware of the delimitation of their zones. A MetaPolicy is employed to select between the different business policies. The MetaPolicy monitors the behaviour of the target system and determines which policy should be employed at any given moment. Richard Anthony CMS Research Seminar October 2006 22

24. Case Example: A multi-policy stock trading scheme (5) There is a risk of instability if simple cut-off points are used to determine the policy selection. If the behaviour of the monitored system is close to one of the cut-offs there is a possibility that the policies will be switched to and fro, causing extra work for the system. The ToleranceRangeCheck language object facilitates easy configuration of dead-zones, enhancing stability (localised oscillatory behaviour in the target system is not mirrored in the behaviour of the MetaPolicy). Richard Anthony CMS Research Seminar October 2006 23

25. Stock-trading multi-policy example Script part 1 Richard Anthony CMS Research Seminar October 2006 24

26. Script part 2 Richard Anthony CMS Research Seminar October 2006 25

27. Script part 3 Richard Anthony CMS Research Seminar October 2006 26

28. Script part 4 Richard Anthony CMS Research Seminar October 2006 27

29. <Rule Name="R_M1" LHS="Current_P_ZoneLOW" Op="EQ" RHS="true" LOp="AND" LH2="Current_V_ZoneLOW" Op2="EQ" RH2="true" ActionIfTrue="A_Policy1" ElseAction="Null"/> <Rule Name="R_M2" LHS="Current_P_ZoneLOW" Op="EQ" RHS="false" LOp="AND" LH2="Current_V_ZoneLOW" Op2="EQ" RH2="true" ActionIfTrue="A_Policy2" ElseAction="Null"/> <Rule Name="R_M3" LHS="Current_P_ZoneLOW" Op="EQ" RHS="true" LOp="AND" LH2="Current_V_ZoneLOW" Op2="EQ" RH2="false" ActionIfTrue="A_Policy3" ElseAction="Null"/> <Rule Name="R_Mode" LHS="Cautious" Op="EQ" RHS="true" ActionIfTrue="I_CautiousAction" ElseAction="I_AggressiveAction"/> <TRC Name="C_P_DZ" Check="E_P_RateChange" Compare="P_DZ" Tolerance="DZ_Tolerance" ActionInZone="A_Set_P_Previous" ActionLower="A_Set_P_LOW" ActionHigher="A_Set_P_HIGH"/> <TRC Name="C_V_DZ" Check="E_V_RateChange" Compare="V_DZ" Tolerance="DZ_Tolerance" ActionInZone="A_Set_V_Previous" ActionLower="A_Set_V_LOW" ActionHigher="A_Set_V_HIGH"/> <TRC Name="C_Trade" Check="E_CurrentPrice" Compare="E_ExpectedFuturePrice" Tolerance="Margin" ActionInZone="A_Hold" ActionLower="A_Buy" ActionHigher="A_Sell"/> Script part 5 Richard Anthony CMS Research Seminar October 2006 28

30. Script part 6 Richard Anthony CMS Research Seminar October 2006 29

31. AGILE V1.1 Run-Time Log Policy: HighLevelPolicy Type: MetaPolicy Load Template - Skipped (already loaded) Action: A_M1 ToleranceRangeCheck: C_P_DZGuard was True: TRC evaluated Variable: E_P_RateChangeValue: 57 Variable: P_DZValue: 60 Variable: DZ_ToleranceValue: 10 TRC evaluated In-Zone: Action=A_Set_P_Previous Action: A_Set_P_Previous Assign: LHS=Current_P_ZoneLOW RHS=Previous_P_ZoneLOW ToleranceRangeCheck: C_V_DZ Guard was True: TRC evaluated Variable: E_V_RateChangeValue: 40 Variable: V_DZValue: 50 Variable: DZ_ToleranceValue: 10 TRC evaluated Outside-Lower-Zone: Action=A_Set_V_LOW Action: A_Set_V_LOW Assign: LHS=Current_V_ZoneLOW RHS=true Assign: LHS=Previous_V_ZoneLOW RHS=Current_V_ZoneLOW Rule: R_M1 Guard was True: Rule evaluated Variable: Current_P_ZoneLOW Value: falseVariable: true Expression 'Current_P_ZoneLOW EQ true' was False Variable: Current_V_ZoneLOW Value: trueVariable: true Expression 'Current_V_ZoneLOW EQ true' was True Rule evaluated False: Action=Null Stock-trading multi-policy example Run-time log - part 1 Richard Anthony CMS Research Seminar October 2006 30

32. Rule: R_M2 Guard was True: Rule evaluated Variable: Current_P_ZoneLOW Value: falseVariable: false Expression 'Current_P_ZoneLOW EQ false' was True Variable: Current_V_ZoneLOW Value: trueVariable: true Expression 'Current_V_ZoneLOW EQ true' was True Rule evaluated True: Action=A_Policy2 Action: A_Policy2Yield: Policy: Policy2 Type: NormalPolicy Action: A_Trade2 Assign: LHS=Margin RHS=15 Assign: LHS=Cautious RHS=true ToleranceRangeCheck: C_Trade Guard was True: TRC evaluated Variable: E_CurrentPriceValue: 78 Variable: E_ExpectedFuturePriceValue: 95 Variable: MarginValue: 15 TRC evaluated Outside-Lower-Zone: Action=A_Buy Action: A_Buy Assign: LHS=I_CautiousAction RHS=A_BuyCautious Assign: LHS=I_AggressiveAction RHS=A_BuyAggressive Rule: R_Mode Guard was True: Rule evaluated Variable: Cautious Value: trueVariable: true Expression 'Cautious EQ true' was True Rule evaluated True: Action=A_BuyCautious Action: A_BuyCautious ReturnValue: Buy_Cautious Run-time log - part 2 Richard Anthony CMS Research Seminar October 2006 31

33. Dynamically Self-Configuring Automotive Systems (DySCAS) - Overview Overall goal – develop new dynamic middleware to support the needs of environment aware / context aware automotive control systems. To support ambitious objectives including: Post-deployment configuration and upgrade, Automatic self-diagnosis and in some cases self-healing, Dynamic connection to external devices and services Primary focus is on ‘infotainment’. The target systems:are resource-constrained,are heterogeneous, have dynamic behaviour,must be reliable, must be predictable. Due to the systems’ characteristics, need to incorporate services such as: Device discovery, Service negotiation, Diagnostics. Our role within the project is to devise, implement, test and demonstrate techniques for embedding self-management into the new middleware. Richard Anthony CMS Research Seminar October 2006 32

34. DySCAS – Generic Use Case: New device automatically attached to car A newly detected device is automatically attached to the vehicle IT systems. This can be a mobile device (e.g. PDA, smart phone), or a wireless hotspot. The new device opens access to external services, or extends the functionality of the system by increasing computing resources (memory, computing capabilities etc.), or it may act as a new source of data (e.g. an MP3 player). Specific use-case examples include: Accessing a navigation system on mobile devices, Incorporating the sensor systems a connected trailer is hosting, Internet access via an attached smart phone, Sending / receiving traffic data via an attached mobile phone, Streaming of entertainment data (MP3, video) from a portable device to the vehicle’s entertainment system, Extracting the destination from the calendar application of the mobile device, Vehicle connecting to a wireless network hotspot, Determination of location, affecting context. Such as detecting the vehicle has entered the proximity of the owner’s workplace. Richard Anthony CMS Research Seminar October 2006 33

35. DySCAS – Generic Use Case: Integrating new software functionality Software includes application software as well as operating software. The system must integrate new software patches and ensure that the new configuration works properly, or restore the previous software configuration. This must be done as seamlessly as possible for the driver and it must not interrupt or impact driving in any way. Specific use-case examples include: Software download from hotspots, Software download from storage media (DVD), Replace system functionality, Replace / upgrade applications (e.g. navigation, MP3 software players). Richard Anthony CMS Research Seminar October 2006 34

36. DySCAS – Generic Use Case: Closed re-configuration To detect re-configuration opportunities: - All components of the system must be monitored. - Free devices or those which do not show expected behaviour must be detected, - Well-working configurations must be identified, - Migration must be planned and executed. Specific use-case examples include: Graceful degradation in case of power problems, Efficient usage of redundancy, e.g. ECUs which are used temporally, such as the (normally dedicated) security / immobilizer ECU, unused once the vehicle has been started. Migration of software services in the case of hardware failure. Richard Anthony CMS Research Seminar October 2006 35

37. Conclusion Key goals of my current work: Emergence - Investigation of synergies between natural systems and distributed computing. Policy-based computing - Enhance power and flexibility of policy-based computing (genuine self-managing behaviour within a policy framework). - Facilitate Policy-based computing for legacy applications. - Empower non-experts in self-management to be able to deploy self-managing features into applications. Real-world context provided by DySCAS project: Embedding self-management into automotive management and control systems. AGILE Library and documentation available at: www.PolicyAutonomics.net Richard Anthony CMS Research Seminar October 2006 36