Annual Conference of ITA ACITA 2009 Realising Management and Composition of Self-Managed Cells in Body Area Networks Alberto Schaeffer-Filho, Emil Lupu, Morris Sloman Imperial College London A Self-Managed Cell (SMC) consists of a set of hardware and software components that is able to work autonomously, relying on a policy- based feedback loop. Policies can be added, removed, enabled and disabled to change the behaviour of an SMC without interrupting its functioning. Adaptation is realised through the Ponder2 policy framework. A Self-Managed Cell (SMC) consists of a set of hardware and software components that is able to work autonomously, relying on a policy- based feedback loop. Policies can be added, removed, enabled and disabled to change the behaviour of an SMC without interrupting its functioning. Adaptation is realised through the Ponder2 policy framework. Self-Managed Cells Self-Managed Cell Ubiquitous applications are typically formed from multiple interacting autonomous components, which establish peer-to-peer collaborations, federate and compose into larger structures. We present a methodology for designing collaborations between autonomous components, using the Self-Managed Cell (SMC) framework. We focus on the structural, task-allocation and communication aspects of management interactions between SMCs. This provides a better understanding of the relationships across SMCs and allows us to specify the management of large-scale composable systems by reusing building block abstractions. Collaborations between SMCs rely on three elementary exchange mechanisms: Interfaces: to validate remote interactions and mediate access to resources Policies: prescribe how other SMCs must behave within the context of an interaction Events: notify remote SMCs of context changes, possibly triggering adaptive actions We propose the use of architectural styles for systematically specifying reusable abstractions that define how the exchanges of policies, events and interfaces are achieved. Styles are similar in intent to software design patterns, in that they provide standard solutions for recurring problems. Architectural Styles Architectural styles for SMC management interactions Task-Allocation Specifies how policies are exchanged between SMCs and under which conditions these exchanges happen (e.g. hierarchical control, auction) Communication Specifies event-forwarding patterns between SMCs, as events are required for triggering policies (e.g. diffusion, shared bus) Structure Specifies how SMCs are organised and addresses issues such as interface mediation, filtering and encapsulation, as interfaces are required for executing a policy (e.g. composition, peer-to-peer) Case-Study: Soldier Healthcare Monitoring Consider some of the requirements for the healthcare monitoring of a soldier in the field: (1) Personal SMC representing a soldier's body-area network runs on a smart phone hosting SMC management services; (2) Sensors (e.g. heart- rate, blood pressure); (3) Actuators (e.g. defibrillator SMC) activated automatically according to sensor measurements; (4) Medic SMC loads monitoring policies to collect information from sensors attached to each soldier; (5) Sensor data must be handled adequately in soldier's operational environment. The case-study shows a soldier and two sensor SMCs (heart- rate and accelerometer) interacting through a composition structural relationship to encapsulate the sensors and prevent the devices owned by the soldiers body-area network from interacting with other body-area networks. Sensors forward their events (e.g. the heart rate above a threshold) to the soldier SMC through a simple diffusion architectural style where each sensor is a source while the soldier is the target of events. The example can be further elaborated with the specification of the interactions between the other SMCs.