1. 22 April 2005EPSRC e-Science Meeting 20051 AMUSE Autonomic Management of Ubiquitous Systems for e-Health Prof. J. Sventek University of Glasgow joe@dcs.gla.ac.uk In collaboration with M. Sloman, E. Lupu, and N. Dulay of Imperial College London

2. The AMUSE Project Imperial College Imperial College University of Glasgow University of Glasgow Start date: February 2004 Start date: February 2004 Duration: 36 Months Duration: 36 Months Funded by the EPSRC under the e-Science Programme Funded by the EPSRC under the e-Science Programme Emil Lupu Joe Sventek Morris Sloman Naranker Dulay

3. Executive Summary Increasing complexity of distributed application systems leads customers to desire automated management of such systems. Increasing complexity of distributed application systems leads customers to desire automated management of such systems. Work at Agilent/Glasgow has yielded an architectural pattern and an hierarchical architecture for closed-loop management of distributed application systems. Work at Agilent/Glasgow has yielded an architectural pattern and an hierarchical architecture for closed-loop management of distributed application systems. Imperial has established itself as one of the premier research groups for policy-based management. Imperial has established itself as one of the premier research groups for policy-based management. AMUSE is focused on integrating these complementary competencies to address automated management of e- Health applications AMUSE is focused on integrating these complementary competencies to address automated management of e- Health applications

4. Policy-Based Management ControlactionsDecisions Managed Objects Monitor Events Manager Agent Events Policies New functionality Policies

5. A Ubiquitous Control Loop PAN Control Home Appliance Control Master Control

6. Self-Managed Cell

7. Layered and Federated SMCs Layered SMCs: application / services / network Layered SMCs: application / services / network Peer SMCs (peer devices, peer networks, SLAs…) Peer SMCs (peer devices, peer networks, SLAs…) … …

8. SMC Composition The enclosing SMC programs the nested SMCs

9. SMC Interactions Layered - Network SMCs interact with application SMCs, the SMC controlling a heart rate monitor reports to a diagnostic management device, … Federated, Peer-to-peer – SMCs for peer devices interact with each other. SMC Composition – Need to be able to compose SMCs into larger structures e.g., home patient monitoring SMCs “program” individual device SMCs

10. Architectural Assumptions Event bus is publish/subscribe using a router Event bus is publish/subscribe using a router The router is content-based The router is content-based We may need to consider different classes of delivery attributes for events We may need to consider different classes of delivery attributes for events A discovery/membership service is concerned with keeping track of which devices and services are “in” a self-managed cell A discovery/membership service is concerned with keeping track of which devices and services are “in” a self-managed cell each device as a unique identifier (e.g. 802.* MAC address of one of the communication interfaces) each device as a unique identifier (e.g. 802.* MAC address of one of the communication interfaces)

11. At-most-once, persistent event delivery No session establishment for Publisher No session establishment for Publisher Subscriber must register ‘filter’ and callback Subscriber must register ‘filter’ and callback Push of event from Publisher to Router (and Router to Subscriber) is synchronous – i.e. exception condition is returned to sender if unsuccessful Push of event from Publisher to Router (and Router to Subscriber) is synchronous – i.e. exception condition is returned to sender if unsuccessful Router attempts to deliver a message until it knows that a Subscriber is no longer a member of the SMC Router attempts to deliver a message until it knows that a Subscriber is no longer a member of the SMC When purge event received, removes ‘filter’ and any queued messages associated with that Subscriber When purge event received, removes ‘filter’ and any queued messages associated with that Subscriber Each Subscriber is guaranteed to receive all messages from a particular publisher in the same order as received by the Router Each Subscriber is guaranteed to receive all messages from a particular publisher in the same order as received by the Router PublisherSubscriberRouter filter purge ‘subscriber’ S S S

12. At-most-once, persistent, quenchable event delivery Publisher must register ‘Ev type’ and callback Publisher must register ‘Ev type’ and callback Subscriber must register ‘filter’ and callback Subscriber must register ‘filter’ and callback Push of event from Publisher to Router (and Router to Subscriber) is synchronous – i.e. exception condition is returned to sender if unsuccessful Push of event from Publisher to Router (and Router to Subscriber) is synchronous – i.e. exception condition is returned to sender if unsuccessful Router attempts to deliver a message until it knows that a Subscriber is no longer a member of the SMC Router attempts to deliver a message until it knows that a Subscriber is no longer a member of the SMC When purge event received When purge event received  If for a subscriber, removes ‘filter’ and any queued messages associated with that Subscriber  If for a publisher, removes ‘Ev type’ Each Subscriber is guaranteed to receive all messages from a particular publisher in the same order as received by the Router Each Subscriber is guaranteed to receive all messages from a particular publisher in the same order as received by the Router Quench/unquench messages sent to Publisher if the number of subscribers matching event type is zero/non-zero. Quench/unquench messages sent to Publisher if the number of subscribers matching event type is zero/non-zero. PublisherSubscriberRouter filter purge ‘subscriber’ or ‘publisher’ S S S P P Ev type

13. How to incorporate a mote into this structure? S S ProxyMote S S ProxyMote

14. Authentication performed SMC wide (device/service is a member of the SMC) performed SMC wide (device/service is a member of the SMC) what about integrity/confidentiality what about integrity/confidentiality access control – component-specific, done through policies access control – component-specific, done through policies

15. Discovery/Membership Detect new devices within communication range Detect new devices within communication range Vette device for membership Vette device for membership  obtain device profile  perform any required authentication Generate new cell member event Generate new cell member event Determine when device leaves cell Determine when device leaves cell  Generate cell member left event Discovery protocol does NOT use the event system; discovery service uses event service to announce member added/removed Discovery protocol does NOT use the event system; discovery service uses event service to announce member added/removed

16. Discovery protocol Cell is centred around event bus router Cell is centred around event bus router Device that contains router broadcasts its identity message at frequency  R (the identity message has the form “id; type[; extra]”) Device that contains router broadcasts its identity message at frequency  R (the identity message has the form “id; type[; extra]”) Other devices respond to router identity message with unicast device identity message Other devices respond to router identity message with unicast device identity message Router device and other device carry on vetting protocol (obtain profile[; authenticate]) Router device and other device carry on vetting protocol (obtain profile[; authenticate]) After other device knows that it has been granted membership, it unicasts its identity message at frequency  D After other device knows that it has been granted membership, it unicasts its identity message at frequency  D If router device misses n D successive device identity messages, it declares the device to have forfeited its membership in the cell If router device misses n D successive device identity messages, it declares the device to have forfeited its membership in the cell If the other device misses n R successive router device identity messages, it inferds that it is no longer a member of that cell If the other device misses n R successive router device identity messages, it inferds that it is no longer a member of that cell Must think through ramifications of  R ≠  D and n D ≠ n R Must think through ramifications of  R ≠  D and n D ≠ n R

17. Communication primitives required Event bus is only used for communications between cell management elements Event bus is only used for communications between cell management elements Basic communication primitives are required to implement the event bus communications, required protocols, and general communication between application components Basic communication primitives are required to implement the event bus communications, required protocols, and general communication between application components  broadcast, asynchronous messaging  unicast, asynchronous messaging  remote method invocation

18. What about services? Devices are discovered by the discovery service. Devices are discovered by the discovery service. When a device becomes part of the cell, it generates events announcing active services that it provides/hosts When a device becomes part of the cell, it generates events announcing active services that it provides/hosts While a member of the cell, each device generates an event whenever another service that it provides/hosts becomes active or if such a service is deactivated While a member of the cell, each device generates an event whenever another service that it provides/hosts becomes active or if such a service is deactivated

19. Where do the new device/service events go? The system must be primed with obligation policies that listen for these events The system must be primed with obligation policies that listen for these events Upon receipt of one of these events, the action enters the device/service into appropriate domain[s] Upon receipt of one of these events, the action enters the device/service into appropriate domain[s] A particular obligation policy will be interested only in particular types of devices or services; new device/service event may trigger several such obligation policies A particular obligation policy will be interested only in particular types of devices or services; new device/service event may trigger several such obligation policies  if can specify event type and filter expression upon subscription, then only the particular obligation policy that is interested in that particular device/service type will be notified  if cannot specify filter expression to event bus, than all such policies will be invoked; only those for which the condition is true will perform actions