Dynamic Reconfiguration of Component-based Real-time Software Words February 2005 Sedona, Arizona, USA Andreas Rasche, Andreas Polze and Martin von Löwis

2 Overview Motivation The Distributed Control Lab Reconfiguration Infrastructure Adaptive Application with Adapt.Net Real-time Software Reconfiguration – Application Model – Reconfiguration Algorithm – Reconfiguration and State Conclusions

3 The Distributed Control Lab Web-based laboratory for remote experiment execution Lab infrastructure and physical experiments must be protected from malicious user code Usage of existing Adapt.Net framework for real-time control experiments – Analysis of implemented reconfiguration algorithm for applicability to real-time systems - Reconfiguration to verified safety controller

4 The Need for Real-Time Reconfiguration Modern embedded systems running in unstable environments must adapt to changes in their environment Dynamic reconfiguration provides a powerful mechanism to realize adaptation In real-time systems reconfiguration must be performed without delaying tasks to miss their deadlines Reconfiguration of complex real-time applications to switch between operational modes

5 The Adapt.Net Framework Adaptation framework for distributed, mobile applications Includes reconfiguration infrastructure (CoFRA), monitoring framework, graphical development tools XML-based description of application configurations and adaptation profiles Code generation for configuration / adaptation specific code Deployment infrastructure for distributed applications Standard set of observer components for monitoring environmental conditions

6 Adaptive Applications with Adapt.Net Monitoring – Environmental Settings – Component Parameters – Component State Dynamic Reconfiguration – Addition of Components – Removal of Components – Migration – Parameter Adjustment

7 Application Model Based on a work of J. Magee, J. Kramer, M. Wermelinger Components: Interconnected computational entities – Provide interfaces : in-ports – Require other components: out-ports Components connected by connectors No cycles in application topology graph A transaction virtually combines a number of bidirectional interactions between components – completes in bounded time – Initiator is informed about completion A transaction T1 is dependent on a subsequent transaction T2 (T1/T2) if its completion depends on the completion of this transaction

8 Our Reconfiguration Framework CoFRA

9 Configurable Components Each component has to implement a configuration hook IConfigure: – Start component processing – Block connections – Set properties – Connect/disconnect out-going ports – Initialization / Finalization Implementation for IConfigure can be generated – Integrated into graphical development tool of Adapt.Net

10 Reconfiguration Algorithm 1. Loading of new components 2. Bringing application into reconfigurable state Application consistency must be preserved during reconfiguration Blocking all connections: Wait for all on-going transactions to complete; don’t allow initialization of new ones Blocking must be ordered due to dependent transactions 3. Transferring state of migrated/updated components 4. Setting changed component parameters 5. Reconnecting components (create connectors) 6. Restarting component processing 7. Removing old components

11 Reconfiguration of Real-time Software t r - time between the reconfiguration request and the new configuration to run t b - blackout time - time the application is interrupted t l - time to load and initialize new components t d - time to delete components not contained in new configuration Total reconfiguration time: t r =t b +t l +t d Loading / Initialization can be moved before runtime Time critical phase : blackout period

12 Bounded Blackout Time t e - time required to execute reconfiguration commands t i - maximum timespan to complete transaction i n - number of transactions in the application t state - time to transfer state t ci - time to initialize and start connectors t s - time to restart the application t b =t e + max(t 1,...,t n ) + t state + t ci +t s – t e : number of components, command per component constant – t i: Can be calculated by WCET analysis + OS synchronisation must be predictable (usage of semaphore with priority ceiling required) – T state : considered later – t ci : assignment of one component member per connector – t s : constant OS Synchronisation

13 Blocking a Connection Component Code calls – TransactionBegin: If(blocked) Wait(block_semaphore); processing=true; Wait(proc_semaphore); - TransactionEnd: processing=false; Release(proc_semaphore) BlockConnection of Configuration interface (IConfigure) blocked=true; Wait(block_semaphore) if(processing) Wait(proc_semaphore) Release(proc_semaphore) Start of Configuration interface blocked=false; Release(block_semaphore); } Transaction time t i Responsibility of application developer

14 Reconfiguration and State

15 Reconfiguration in the Distributed Control Lab Observation of user control algorithms during runtime – Detection of component crashes – Monitoring of experiment parameter (pre-defined valid ranges) Safety Controller component runs parallel to user control component; keeps experiment state up to date In case of abnormal behavior: reconfiguration to safe configuration including control of safety controller component Adapt.Net used in Foucault‘s Pendulum experiment Controlled by algorithms implemented in.NET Real-Time Constraints met by hardware buffers Usage of code access security

16 Conclusions Reconfiguration of complex component-based real-time applications without stopping the whole system All deadlines are met during reconfiguration Blackout time during reconfiguration can be calculated before runtime and is bound Adapt.Net framework allows for design and easy implementation of reconfigurable real-time applications Usable for protection of hard real-time control experiments in the Distributed Control Lab