Maintaining Terminal Integrity and Context-Aware Reconfiguration Johan Muskens (TU/e) Otso Virtanen (HIIT/BRU) Michel Chaudron (TU/e) Ronan Mac Laverty (NRC) Oslo

Change terminal components according to e.g. location or other context information and maintain terminal integrity

Outline Robocop and Space4U Context-Aware Reconfiguration System Integrity Management Scenario

Consortium Robocop ( ): CSEM ESI FAGOR ELECTRODOMESTICOS IKERLAN Nokia Philips Electronics Nederland B.V., SAIA – Burgess Electronics Technical University Eindhoven Technical University of Madrid Visual Tools Space4U ( ): CSEM FAGOR ELECTRODOMESTICOS IKERLAN Nokia Philips Electronics Nederland B.V., Technical University Eindhoven Technical University of Madrid Visual Tools ITEA is a Eureka strategic cluster programme

Robocop’s Aim that enables robust and reliable operation upgrading and extension component trading Define an open, component-based framework for the middleware layer in high-volume consumer devices

Robocop Component Model Robocop component –A set of models –Models can be executable –Models are composable Robocop Component Resource Model Simulation Model Documentation Executable Component Functional Model Source Code … Executable Component Service 1 Service 2 Service Interface Requires Interface Provides Interface  Executable component

Assisting Frameworks Robocop Runtime Environment (RRE) keeps a registry of components available in terminal Robocop Download Process (RCDP) makes it possible to download new components to terminal Resource Management Framework, time requirements and quality of service management Fault Management Framework WIP Power Management Framework WIP Terminal Management Framework WIP Robocop Space4U Context-aware reconfiguration and System Integrity Management done in this subtask

Use existing Robocop mechanisms, mainly Robocop Download Process and RRE Client API for downloading and switching of components Develop a framework to keep the terminal in consistent shape and integrate this with context-aware reconfiguration framework Aim Change terminal components according to e.g. location or other context information and maintain terminal integrity

Our Solution… Context-aware Framework –Context monitoring (e.g. probing the neighborhood for nearby devices) –A placeholder for context data (for depositing relevant information) A blackboard flavoured solution for terminal suits our needs: Consists of following components: 1. The blackboard, 2. Control and 3. Arbitrary number of knowledge sources. What should we deposit here? What should we deposit here?

Models Deposited in Terminal Terminal Management based on a model describing the current configuration of the terminal (self-model) Model of terminal and context in which it is used: C = T x U x  x E c = c  C, where Terminal (t), User (u), Time (  ), and Environment (e). Example: Terminal Model consists of: –Application layer model (bindings between the service instances etc.) –Middleware model (runtime information etc.) –Platform model (operating system etc.)

High level set-up

Integrity Management Terminal Manager Terminal Externalize Self-Model i.e. take a snap-shot of the current state Externalize Self-Model i.e. take a snap-shot of the current state Basic Configuration Facilities Basic Configuration Facilities Monitoring Monitoring Diagnosis Diagnosis Repairing Repairing Script generation Script generation Script execution Script execution Database Provide rules Provide rules Provide solutions Provide solutions Maintaining software integrity using 3 roles !

Two Checks Developed Blacklist of Services –In this case a component with a defect has been deployed to a set of terminals  Solution is to compare the snapshot of terminal models to know faulty components (or services) deposited in database Missing services –Dynamically changing terminal. Problem: how to guarantee that all the services needed by some application X are available?  Solution is to compare the needed services by application X and the available services in the terminal. This information is recorded in the self model of terminal

Scenario 1.User equipped with a Robocop terminal arrives to an airport. The context framework notices the new context 2.A timetable application needed in this context is downloaded via RCDP. This also updates one of the existing components in terminal 3.User executes the timetable application 4.Later on that day the user notifies some strange behavior in the terminal and therefore starts the check terminal status –procedure 5.Snapshot of the terminal models is sent to terminal manager server 6.Terminal manager server notifies that one of the components in terminal is blacklisted (i.e. the one downloaded in phase 2) by a developer 7.Repair script is generated and an updated version of the faulty component is downloaded and registered to the user’s terminal