A Component Model for Dynamic Adaptive Systems Holger Klus
Dirk Niebuhr
Andreas Rausch
Clausthal University of Technology Clausthal University of Technology Clausthal University of Technology P.O. Box 1253 P.O. Box 1253 P.O. Box 1253 38670 Clausthal-Zellerfeld, Germany 38670 Clausthal-Zellerfeld, Germany 38670 Clausthal-Zellerfeld, Germany +49 (0) 5323-72-7192 +49 (0) 5323-72-7163 +49 (0) 5323-72-7177
[email protected]
[email protected]
ABSTRACT Dynamic adaptive systems are systems which change their behavior according to the needs of the user during runtime based on context information. Since it is not feasible to develop these systems from scratch every time, a component model enabling dynamic adaptive systems is necessary. Moreover, an infrastructure is required which is capable of wiring dynamic adaptive systems from a set of components in order to provide a dynamic and adaptive behavior to the user. In this paper we present such kind of infrastructure called DAiSI (Dynamic Adaptive System Infrastructure) and the underlying component model. We will present an example scenario illustrating the adaptation capabilities of the introduced component model.
Categories and Subject Descriptors D.2.10 [Software Engineering]: Design, D.2.11 [Software Engineering]: Software Architectures, D.2.12 [Software Engineering]: Interoperability, D.2.13 [Software Engineering]: Reusable Software
General Terms
and the evolution in communications technology, especially in the wireless sector, contribute to embedding software services in nearly every commonplace and industrial object. To produce these IT components like a cup detecting if an elderly person does not drink enough or an intelligent refrigerator detecting spoilt food component-based development approaches have been developed and successfully applied over the past years changing the predominant development paradigm: Systems are no longer redeveloped from scratch, but composed of existing components [1, 2]. Nowadays, these IT components are being more and more used within an organically grown, heterogeneous, and dynamic persuasive environment. Users expect them to collaborate autonomously with each other and thus to provide a real added value to the user. On the other hand, we depend more and more on these organically grown systems. These dynamic adaptive systems (called Dynaptive Systems in the following) •
are distributed applications.
•
consist of a changing – even organically grown – set of collaborating dynamic adaptive IT components.
•
have the ability to dynamically attach and detach dynamic adaptive IT components during runtime.
•
detect and avoid possible resulting incorrect system configurations during runtime.
Design
Keywords Component Composition, Component Componentware, Component Container
Model,
Adaptation,
1. INTRODUCTION The continuing progress of all IT domains towards "smaller, cheaper, more powerful" is the main driver towards the trend “everything, every time, everywhere”: the Internet can now be accessed using mobile phones. Electronic assistants, so-called “information appliances” like network-enabled PDAs, WAPcapable cell phones, and electronic books are available in stores all over the country. Moreover, new developments in the field of materials science like midget sensors, organic light-emitting devices or electronic ink, Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. ESSPE ’07, September 4, 2007, Dubrovnik, Croatia. Copyright 2007 ACM ISBN 978-1-59593-798-8/07/09…$5.00.
[email protected]
IT components can be attached to a system at any time. Attached IT components can be removed from the system respectively they can fail as the result of a defect. We call these IT components dynamic adaptive IT components. As a shortcut we will use the notion Dynaptive Components. They share the following characteristics: •
They are independent IT elements consisting of hardware and software.
•
They provide software services with specific functionality and appropriate non-functional properties.
•
They are capable of processing information and have the ability to communicate.
•
They support the overall dynamic adaptive system to enable runtime attachment and detachment with respect to the required guarantees.
Providing Dynaptive Systems is a great challenge in software engineering [3, 4, 5, 6, 7, 17]. In order to provide Dynaptive
Article Number 3
Systems activities of “classical” development approaches have to be partially or completely moved from development-time to runtime. For instance, for Dynaptive Systems the system integration takes place during runtime. Consequently system testing also has to be performed during runtime [8].
In this paper we will focus on a component model for Dynaptive Components to support Dynaptive Systems. This component model is part of the formal system model for Dynaptive Systems, which is again part of the overall software systems engineering method for Dynaptive Systems as shown in Figure 1.
To sum up, providing Dynaptive Systems requires an overall software systems engineering methodology for dynamic adaptive IT systems. Such a methodology should at least incorporate the parts shown in Figure 1(cf. [7]):
Instead of presenting the component model in a formal way, which would fill a whole paper and can be found in [7, 9], we will present it here in an informal way in Section 3. We will illustrate the component model based on an example from the Assisted Living domain which shows its capabilities. We will show how the component model enables three different types of adaptation. The example itself is introduced in Section 2. Finally we will present the sample implementation of the component model in a runtime environment and sketch the implementation of Dynaptive Components in Section 4.
2. SAMPLE CASE STUDY
Figure 1. Basic building blocks of a software systems engineering method for Dynaptive Systems.
Society is aging continuously. According to estimates in [10] the number of people in Germany who are older than 70 will increase from 10% at present to 18% by the year 2040. In the United States, the population in institutionalized elderly care home is 34% with community services providing for “aging in place”. This number will double by 2020 as the “baby-boom” generation begins aging [11].
•
A well-defined conceptual framework of dependable adaptive IT systems is required as a reliable foundation. It consists of a mathematical formal system model which is used to unambiguously express the basic notions and their relations, like for instance Dynaptive Components and integration of those within a Dynaptive System.
Due to this phenomenon of the aging societies in the western hemisphere, care for handicapped and elderly people creates continuously growing social and financial burdens. It is obvious that society has to react to this dramatic process. Therefore, innovative solutions for Living Assistance Systems must be envisioned in order to cope with this development.
•
Description techniques for Dynaptive Systems are required to describe the systems as well as the components. The used description techniques have to be formally founded using the formal system model as the descriptions will be interpreted during runtime, like for instance to verify the required guarantees during runtime system integration.
•
To organize system growing neither a pure top-down nor a pure bottom-up development approach is sufficient. Usually, an iterative system evolution process is more appropriate. Thereby not only the development activities are organized, but also the complete life-cycle of the dynamic evolutionary systems under consideration is captured, like for instance analysis on the impacts of changes to the system's architecture.
•
Dynaptive Systems are open for attachment and detachment of Dynaptive Components, which were not known at the development-time of other parts of the system. Such an open and dependable system can only be realized based on a shared and open standard domain architecture designed from domain requirements. This domain architecture serves as a common blueprint for all valid system configurations.
2.1 Dynaptive Home Care System Home Care Systems are a promising approach to Living Assistance Systems focusing on the support of handicapped and elderly people. The essential benefit of a Dynaptive Home Care System is that the elderly person does not need to move into a specialized flat. All of the Dynaptive Components are hidden within equipment which is already present to provide a most natural way of human interaction. For that reasons most of the functionality of the Dynaptive Home Care System has been integrated into already present devices like for instance a television, a refrigerator, a watch, a walking stick, and a cup. A home can be equipped with Dynaptive Home Care Components step by step in this way.
Particle
Wall Display
RFID Reader
•
All aspects should be empowered by tool support. The formal system model may be realized by an execution platform for Dynaptive Systems. Tools should be able to generate complete or partial implementations of a system or components as well as corresponding documentation.
AmICA-Components
LCD Display
Figure 2. A Home Care System including a Food Control System.
Article Number 3
For instance, on the one hand you can imagine, that a cup is equipped with a sensor tracking the consumption of liquids and warning if the elderly person does not drink enough. On the other hand we can equip a refrigerator with an RFID reader monitoring the contents of the refrigerator and the expiry dates of the food inside. We can imagine that the whole equipment of an elderly persons flat as sketched in Figure 2 could be equipped with additional home care functionality in that way in order to support her or him in daily life. The resulting Dynaptive Home Care Components could then be integrated into a Dynaptive Home Care System which realizes several Home Care Scenarios assisting the elderly person. Several Home Care Scenarios have been developed and evaluated by us within a Home Care System called AmICA deployed at the Assisted Living Lab which is part of the BelAmI project [12]. In the following we will present a single home care scenario – the Dynaptive Food Control System:
2.2 Dynaptive Food Control System Although elderly people usually store their food in a refrigerator it may nevertheless get spoilt. Since they do not remember how old the food is and their taste is not good enough anymore to recognize spoilt food, the situation may occur that they eat it. Since this causes health problems, the consumption of spoilt food should be prevented. Therefore, a warning in case of spoilt food is important for a Home Care System. Within the AmICA Home Care System this warning is generated and presented by the Dynaptive Food Control System. Since there are many reasons why food becomes spoilt like for instance it exceeded the expiry date or it has been stored at high temperature due to a broken refrigerator the Dynaptive Food Control contains two features: On the one hand it monitors, whether the refrigerator is broken by checking the temperature inside the refrigerator, on the other hand it monitors the expiry dates of the food content inside the refrigerator. Additionally it may provide some comfort functions like offering a set of recipes based on the fridge contents. Since the elderly person may only require some of these features, the Dynaptive Food Control System is a Dynaptive System which can be (re-)configured at runtime. Therefore, the Dynaptive Food Control System should be able to adapt to its environment during runtime. To implement those kinds of systems, we developed a component model which enables the realization of a dynamic adaptive system supporting three different types of adaptation. In the following we give a short overview of these adaptation types. In section 3 we will then introduce our component model motivated by these adaptation types.
2.3 Types of Dynamic Adaptation The three adaptation types supported by our component model are the following. Component Service Usage Adaptation: During runtime a component CA using a service offered by another component CB switches to use another service provided by a component CC where both services implement compatible interfaces. They may for example only differ in quality of service properties. For example you can imagine an optical output service and an acoustical output service which both may implement the same interface providing different implementations.
Component Service Implementation Adaptation: During runtime the behavior and thus the realization of a service offered by a component is changed. For example a service providing a list of recipes adapts itself in order to return the list of recipes in a user preferred order based on user feedback. This adaptation is local to a component, and so the service interface does not change. System Configuration Adaptation: During runtime for some reasons at least one new type of service is available or one type of service is not available anymore due to a component failure or an explicit component detachment. In contrast to component service usage adaptation this adaptation does influence other components since they need to reconfigure in order to use this service respectively stop using the service. Thus this adaptation type is not longer local to a component.
3. DYNAPTIVE COMPONENT MODEL We will now introduce the component model which enables the realization of a Dynaptive System. Therefore, we will first of all provide an overview of our component structure and afterwards introduce how this component structure supports the three presented adaptation types.
3.1 Overview of the Component Model We start with an overview of our component model and will then provide a detailed view at the different aspects and features of this component model concerning adaptation. The component model defines how a component has to be structured so that dynamic adaptation can be provided by the runtime environment – the implementation of the component model. Figure 3 shows our component model as an UML 2.0 class diagram. It can be divided into two parts, namely the Instance Model which you can see on the right side, and the Type Model which is depicted on the left side of the Figure. The root interface of each Dynaptive Component is the interface InstanceComponentIf which is part of the Instance Model. Each adaptable component following our component model has to implement this interface. This interface defines among others methods for starting and stopping the execution of a component. The second important interface is the interface InstanceComponentConfigurationIf. Each component can have one or more instances of classes which implement this interface. These instances can be added to a component using appropriate methods defined in the interface InstanceComponentIf. An instance of a class which implements InstanceComponentConfigurationIf can be seen as a mapping between required and provided services within one component, both represented by two further interfaces. The interface InstanceComponentServiceIf is the root interface of all services for which a component provides an implementation and thus a service to other components in the system. If a component wants to provide a service to other components, an appropriate interface has to be defined which has to inherit from InstanceComponentServiceIf. This interface is used to distinguish between provided and required services. The interface InstanceComponentServiceReferenceIf represents required services in our component model. Each component can define which services are required in order to provide certain
Article Number 3
TypeComponentIf
TypeOf
1
*
1
1
Offers {Ordered} 1..*
1..*
1 TypeOf
*
TypeOf
1
*
1 Provides
Contains *
Imports
0..1
InstanceComponentConfigurationIf 1..*
Declares
1..*
Current {Subset supports} 1..*
1
1..*
Exports
1
0..1
Supports {Ordered}
TypeComponentConfigurationIf
TypeComponentServiceIf
InstanceComponentIf
1..*
*
TypeComponentServiceReferenceIf
TypeOf 1
TypeOfUses
*
InstanceComponentServiceReferenceIf
Uses
*
0..1
*
InstanceComponentServiceIf * {Ordered}
Figure 3. An overview of the component model for Dynaptive Components. services. The mapping between required and provided services is done by InstanceComponentConfigurationIf. Both, InstanceComponentServiceIf and InstanceComponentServiceReferenceIf can therefore be added to an instance of InstanceComponentConfigurationIf by calling methods defined in that interface.
These interfaces describe the instance view of an adaptable component. On the other hand, we also provide a type view of an adaptable component. Each interface on the right side (the instance view) has a corresponding interface on the left side (the type view). The Type Model is used by the runtime environment to determine which types are currently available in the system. This information has to be derived from the instances by reflection at runtime or defined separately in advance. The infrastructure for Dynaptive Systems can manage all the type information and may use it for calculating the dynamic configuration of the system. This information is required to perform the dynamic adaptations supported by the runtime environment. In order to illustrate the structure of an adaptable component, we use the notion as depicted in Figure 4. The blue rectangle represents an implementation of the interface InstanceComponentIf. Yellow bars represent instances of classes which implement the interface InstanceComponentConfigurationIf and its belonging to the component. The green circles represent instances of classes which implement the interface InstanceComponentServiceIf and the red semicircles represent the interface InstanceComponentServiceReferenceIf.
Figure 4. Illustration of the component structure. In the following we will show how this component structure allows the adaptation of components. Therefore, we will present how we realized the three adaptation types introduced before using the proposed component structure. In order to illustrate the adaptation types we will use the scenario presented in section 2.
3.2 Component Configuration Adaptation The first kind of adaptation we examine is the component configuration adaptation. We will motivate this adaptation type using the following scenario from the assisted living domain.
3.2.1 Example of Component Configuration Adaptation In a first adaptation scenario we consider, that the elderly person has a refrigerator at home. Since his refrigerator is not tidy all the time, he sometimes buys things in a store, which are already inside his fridge. Therefore, he wants to have a list of what food is inside the fridge. He just heard about the METRO Future Store Initiative [13], which began to provide meat with RFID chips in 2004 to establish a so called Meat Supply Chain. Therefore, he decides to equip the fridge with a RFID reader component, which will enable him to view the contents of the refrigerator without opening it. When the RFID reader component is attached to the refrigerator, dynamic adaptation of the Dynaptive Food Control System is required to integrate this component. The refrigerator component should reconfigure itself in order to provide a better component service for the user using the component service provided by the RFID reader component, too. The refrigerator component now can cause a warning of the user if spoilt food is inside or taken out of the refrigerator. For this purpose each product in the fridge is tagged with an RFID chip which stores product-specific information, and among others the date of expiry. Moreover it is now possible that the refrigerator component offers the contents of the refrigerator as an own service to other components. In order to provide the extended capabilities, the refrigerator component has to reconfigure itself so that it now can take into account the new type of input data provided by the service hosted at the RFID reader component. We call this type of adaptation System Configuration Adaptation. The fridge component now internally has to switch to another configuration dynamically in order to use the newly available service and provide its enhanced service for other components within the Dynaptive Food Control System.
3.2.2 Configuration Adaptation at the Component Model In the first configuration of the Dynaptive Food Control System we have only the FoodMonitoringRefrigerator component connected to the LcdDisplay component to give an alert whenever
Article Number 3
the temperature exceeds a certain temperature. On the application layer this looks as depicted in Figure 5. You can see the two components (blue boxes), which are running in a configuration (yellow bars) and are connected by the GraphicalOutputIf component service interface.
FoodMonitoringRefrigerator
GraphicalOutputIf TemperatureIf
LcdDisplay 1 (best configuration)
3
Figure 5. The initial configuration of the Dynaptive Food Control System. When the elderly person now attaches an RFID Reader to the refrigerator the system will dynamically adapt in a way that this RFID Reader is used as well to enable the FoodMonitoringRefrigerator component to offer its content by the FoodContentIf component service interface. You can see the configuration which is established at runtime in Figure 6. FoodMonitoringRefrigerator
RfidReader RfidReaderIf
FoodContentIf
2
TemperatureIf
3
1 (best configuration)
LcdDisplay 1 (best configuration) GraphicalOutputIf
Figure 6. The Dynaptive Food Control System after System Configuration Adaptation. In our component model, these configurations are represented by the interface InstanceComponentConfigurationIf. The switch between different configurations is done using a method defined in the interface InstanceComponentIf. The infrastructure will call the method, if all required interfaces, defined by implementations of InstanceComponentServiceReferenceIf. If all of these required interfaces are available, the infrastructure activates the appropriate configuration automatically. To do this, the infrastructure queries for service interfaces a component requires in order to provide service interfaces itself. In the example above, the infrastructure discovers a new service interface called RfidReaderIf provided by the RfidReader component. It also detects that the component FoodMonitoringRefrigerator requires this interface. The system now sets a reference in the FoodMonitoringRefrigerator to the instance of the RfidReader component. In the following the FoodMonitoringRefrigerator component now can use the service using the reference.
In our case this means that the refrigerator component may now use the wall display as well to output its information. This is especially reasonable in the case of elderly people, since the information can now be presented using a larger screen and will therefore be much better readable by the elderly person. The wall display component can be used to show further information like the content of the fridge or a warning because of expired food in a much more intuitive way than it would have been possible on a small LCD display. Therefore, the component service usage has to be adapted in a way, that the refrigerator component will use the output service provided by the wall display component instead of the output service provided by the LCD display component, which was used before. We call this type of adaptation Component Service Usage Adaptation. In order to realize Component Service Usage Adaptation, various kinds of context information and quality of service aspects have to be taken into account influencing the decision which device to use. If you think of a blind person for example always choosing the largest screen size won’t help, instead the Dynaptive Food Control System should adapt to use speech services or a Braille display for output in this case. Finally, not only components providing respectively using output services are affected by Component Service Usage Adaptation, but also components which encapsulate computational logic. For example there might be two emergency recognition components reasoning about the physical constitution of the elderly person. One of these might be more precise but will consume twice energy than the other one. In this case it might be necessary to adapt the component service usage to use the more precise or the lower power emergency recognition component depending on the current situation of the Dynaptive Food Control System. As discussed in section 2 the elderly person could have bought a wall display to watch TV in the kitchen. This results in an alternatively available component service for the Dynaptive Food Control System. As a result the overall Dynaptive Food Control System needs to be reconfigured, since now a component is available, which offers a better component service for the GraphicalOutputIf (see Figure 6). The result is shown in Figure 7. The corresponding component service of the wall display is now used for displaying the temperature and the contents of the refrigerator. Note that the LCD Display is not in use anymore. It just remains as an available component but is not integrated in the Dynaptive Food Control System anymore. RfidReader
FoodMonitoringRefrigerator
1 (best configuration) RfidReaderIf
3.3 Component Service Usage Adaptation
FoodContentIf
2
TemperatureIf
3
The second type of adaptation we consider here is the so called Component Service Usage Adaptation.
WallDisplay 1 (best configuration) GraphicalOutputIf
GraphicalOutputIf
LCDDisplay 1 (best configuration)
3.3.1 Example of Component Service Usage Adaptation For the second adaptation scenario we imagine that the elderly person wants to watch TV in the kitchen as well. Therefore, he buys a wall display and installs it in the kitchen as depicted in Figure 2. The Dynaptive Component Services offered by this wall display will then become available for all Dynaptive Systems, in particularly for the Dynaptive Food Control System.
Figure 7. The Dynaptive Food Control System after Component Service Usage Adaptation. When the elderly person now has a book containing a Particle microchip storing recipes as motivated in before, the system will adapt in order to use this component as well. Note that one cannot really see the Component Service Implementation which occurs in
Article Number 3
this scenario since it only affects the internal realization of the RecipeIf implementation and therefore cannot be made visible with our notion.
3.3.2 Component Service Usage Adaptation at the component model The Component Service Usage Adaptation is basically realized in the component model by the interfaces InstanceComponentServiceReferenceIf and InstanceComponentServiceIf. If the infrastructure detects a new component in the system, it detects the types of the provided service interfaces of this component and tries to match them to required service interfaces. If there is more than one instance of one type available, the system has to make a decision which instance to use, that is, which instance is the best in the current usage situation. At the moment we assume that the service interface which comes last is the best one. Currently we are working on an integration of Quality of Service properties into the decision making process.
3.4 Component Service Implementation Adaptation Finally we present our third type of adaptation supported by the component model.
3.4.1 Example of Component Service Implementation Adaptation In the last adaptation scenario we consider that the elderly person becomes diabetic. Since he must not eat his favorite meals anymore he buys a cookbook with recipes for diabetics. This cookbook is shipped together with a small Particle [14] microchip storing all recipes in alphabetical order. In the following we will refer to this microchip as the RecipeParticle component. If this component is integrated into the Dynaptive Food Control System, it enables the refrigerator component to access all recipes and reason about which recipes are currently applicable regarding the refrigerator contents. Therefore, System Configuration Adaptation as motivated before is necessary in order to enable the refrigerator component to use the RecipeParticle component and provide additional features. The refrigerator can now present a list of recipes to the elderly person, where he can select a recipe and it will be presented in more detail to guide him during cooking. The component now can implement a feedback loop in order to learn from the user’s behavior. After some weeks for example, some trends may show up, since the elderly person will have some favorite recipes which he will choose more often than other ones. To provide more comfort to the elderly person it makes more sense to present the particle recipes in a user specific order. Therefore, the service implementation within the recipe particle component has to adapt its implementation towards the user preferences. Due to this so called Component Service Implementation Adaptation the recipes are no longer stored in alphabetical order but in a user preferred order. This enables the elderly person to keep his favorite order even after replacing the refrigerator by only keeping the small recipe particle component. Moreover, Component Service Implementation Adaptation in this case could enable the elderly person to change the spices of recipes in a way, so that they will taste better. Note that this adapted component service implementation is available to all components of the Dynaptive Food Control System after this adaptation.
3.4.2 Component Service Implementation Adaptation at the component model The Component Service Implementation Adaptation is an adaptation of the implementation of the interface InstanceComponentServiceIf. This kind of adaptation is not directly addressed by the component model. It has to be implemented individually for each adaptable component based on relevant context information which it may receive from other components.
4. DAiSI – DYNAMIC ADAPTIVE SYSTEM INFRASTRUCTURE In order to build a Dynaptive System following our approach two parts need to be available: on the one hand we need all of its basic building blocks – the Dynaptive Components. On the other hand infrastructure components have to be available, which enables the automatic reconfiguration of a Dynaptive System by exploiting the capabilities of the component model introduced before. For the demonstrators we have implemented, like for instance the AmICA Home Care System (cf. [12,16]), we have realized such a runtime environment called Dynamic Adaptive System Infrastructure (DAiSI). In the following we will first of all describe shortly, how a component developer is supported by DAiSI during the development of Dynaptive Components. This is followed by a description of the infrastructure components themselves.
4.1 Component Developer’s View Our approach is that a developer does not have to implement a whole system on his own. Instead the developer may only develop a single component or some components for a specific domain. This is only possible if a domain architecture is available as claimed in the introduction of this paper. This architecture has to define interfaces between Dynaptive Components for Dynaptive Systems from the specific domain. Based on this, the developer can develop even a single component and define which interfaces from the domain architecture are required respectively provided in the different configurations of this component. Moreover he can develop mock-up components providing the required interfaces in order to test the new component during development. To support the component development DAiSI comes along with two implementation frameworks. These frameworks provide several helper classes enabling a quick implementation of Dynaptive Components in Java as well as in C++ concentrating on the functional features of the component to be developed. For components developed in Java this implementation framework provides access to all DAiSI features. The developer therefore does not have to deal with infrastructural issues like for instance service discovery. The C++ implementation framework still has some restrictions like for instance components can only provide component services; they cannot require any component services from other components by using the current C++ implementation framework. The implementation of Dynaptive Components for DAiSI is described in detail in [16]. In order to monitor and debug a Dynaptive System during development of a component, the developer may use the so called “Configuration-Component Browser”. This allows him to view the internal structure of the Dynaptive System in a graphical tree view.
Article Number 3
Figure 8. A running Dynaptive System visualized in the Configuration Component Browser. Moreover it provides a view on the component sets (like for example all running components or all registered components) known within the Dynaptive System in a graphical visualization similar to the one, which was used in Section 3 for the visualization of components and their wiring. The component developer cannot change the system configuration since our idea is that the configuration process is handled automatically by the infrastructure. The developer is not responsible for component wiring anymore. Instead of involving the component developer in future versions of the automatic reconfiguration process, the process will be supported by user feedback later. Anyhow the component developer can use the Configuration-Component Browser to get a quick overview of the system configuration or to trace bugs in the component structure during development. For the application example introduced in this report a view on the system using the Configuration Component Browser looks like it is depicted in Figure 8. This shows the state of the Dynaptive Food Control System directly after the integration of the RFID Reader Component as it had been introduced in Section 3 and shown in Figure 6 to explain the Component Configuration Adaptation.
4.2 Infrastructure Components DAiSI provides several Infrastructure Components enabling Dynaptive Components which are structured according to the Component Model introduced in Chapter 3 to form a Dynaptive System easily. They include components like the Node Component, the Configuration Component, and the Device Bay Component, which are introduced in the following. At each hardware node a Node Component is responsible for the lifecycle management of all Dynaptive Components belonging to this node. This includes especially the initial setup meaning which Dynaptive Components have to be started when the hardware node starts up. Moreover the Node Component starts up the other Infrastructure Components. Some infrastructural components like the Configuration Component introduced in the following do not need to be started at every node but may be accessed remotely at other nodes instead. The Node Component therefore tries to access these components remotely before starting up a new Infrastructure Component locally. Moreover not all infrastructure components need to be started up, since they are optional like for example the Device Bay Component. The specification, which Dynaptive Components and which infrastructure components need to be started up when the node initializes, needs to be specified in a small XML document. Next to the Node Component a Dynaptive System needs at least one Configuration Component. Its task within DAiSI is to determine, which components can form a Dynaptive System and how
they can be interconnected. Therefore, all components have to register at the Configuration Component. The Configuration Component checks for all registered components whether they contain a runnable1 configuration and which component services this configuration provides. This is done by querying their structure according the component model introduced before. If the Configuration Component determines a runnable configuration, it will set all component service references pointing to specific component service providers. In the following it will set the configuration for this component and notify the component that the Dynaptive System is starting up. All methods, which need to be called by the Configuration Component on the Dynaptive Components are specified in the Component Model introduced in Chapter 3.1 in the interfaces InstanceComponentServiceReferenceIf respectively InstanceComponentIf. If the component already had been running a reconfiguration becomes necessary. Therefore, the Configuration Component will stop the component (and all components, which use a component service provided by this component), set the new uses relation and the new configuration and then start it again. Components only need to interact with the Configuration Component on their own, if they want to be detached for some reasons from a running system. The initial registration at the Configuration Component is already handled by the Node Component starting up the specific Dynaptive component. The Configuration Component itself is currently designed as a singleton, therefore it should be started only once in a Dynaptive System. Currently it is automatically started up together with the first Node Component of a system. However, future versions of DAiSI may provide a decentralized Configuration Component as well. Moreover the Configuration Component does not monitor the Dynaptive Components after registration anymore. Therefore, it does neither realize changes in their supported configurations nor does it realize when a component crashes. These changes in the Dynaptive System are currently only supported, if the Dynaptive Components explicitly unregister (and register again in cases of changes within their supported configurations). Moreover the Configuration Component needs to check the system configurations regarding their dependability during reconfiguration which is not done yet. As you could see in our example Dynaptive Systems are not only equipped with personal computers, workstations, or laptops. They are more and more realized using small, resource-limited devices like various kinds of sensor nodes, or devices like PDAs for example. Components located on these low capability devices are integrated through a so called Device Bay Component within DAiSI. The design is based on the Surrogate Architecture [15], referencing to a Device Bay as a computer connected to DAiSI which is able to act as a proxy for several homogeneous kinds of hardware nodes. The main task of the Device Bay is to locate new devices and to set up their component implementations. This means that all necessary information for this process has to be stored in a component proxy and as far as possible on the device itself. This information has to take the dynamic nature of Dynaptive Systems into account, where an arbitrary appearance of different components and even different implementations of the 1
A configuration is marked as runnable whenever each of the required component service types is provided by at least one component in a runnable configuration.
Article Number 3
same component service may occur. Therefore, the type and instance model of components as proposed in chapter 3 has to be represented in a form that allows the Device Bay to bridge calls to various kinds of components and vice versa.
Proceedings of the Workshop for Building Software for Pervasive Computing, 19th Conference on Object-Oriented Programming Systems, Languages and Applications (OOPSLA). November 2004.
The Device Bay approach currently supports the integration of devices based on serial communication and the integration of components realized on Particle microchips. In future we would also like to integrate various kinds of other devices like devices based on Bluetooth communication for example. Moreover there is still a lack of tools supporting the automatic generation of the Proxy components as well as a general body for the component implementation on the low capability devices based on a model describing the specific Dynaptive Component to be deployed on the low capability device.
[6]
Dirk Niebuhr, Christian Peper, Andreas Rausch. Towards reliable self-integrative IT systems. In: Proceedings of the Tenth International Workshop on Component-Oriented Programming, 19th European Conference on ObjectOriented Programming. July 2005.
[7]
Andreas Rausch. Towards a Formal Foundation for Dynamic Evolutionary Systems. In: Proceedings of the Workshop on Architecture-Centric Evolution (ACE 2005), the 19th European Conference on Object-Oriented Programming (ECOOP 2005). July 2005.
5. CONCLUSION
[8]
Christian Bartelt, Thomas Fischer, Dirk Niebuhr, Andreas Rausch, Franz Seidl, Marcus Trapp. Dynamic Integration of Heterogeneous Mobile Devices. Proceedings of the Workshop on Design and Evolution of Autonomic Application Software at ICSE 2005. 2005.
[9]
Andreas Rausch. DisCComp - A Formal Model for Distributed Concurrent Components. Workshop on Formal Foundations of Embedded Software and Component-Based Software Architectures (FESCA 2006), Vienna, Austria (Satellite workshop of ETAPS 2006). March 2006.
Dynaptive Systems are getting more and more important in our days. In this paper we therefore presented DAiSI which is an infrastructure for these systems. We introduced a component model and its implementation within an infrastructure by means of a running example. That example has illustrated how the component model supports different types of adaptation. Another example which illustrates the universal applicability of the component model within the Assisted Sports domain has been published in [8]. We have also developed a formal model as a basis for the realization of a dependable infrastructure [9]. Currently we are working on an integration of concepts concerning dependability like runtime-testing based on the formal model into DAiSI. This is a very important step, since one of the key challenges of Dynaptive Systems is to guarantee the correct wiring of components during runtime. However, a big step has already been done by realizing an infrastructure for dynamic adaptive systems which enables the automatic integration and adaptation of components during runtime with minimal effort for the developers of Dynaptive Systems based on our component model.
[12] Bilateral German-Hungarian Collaboration Project on Ambient Intelligent Systems. http://www.belami-project.org
6. REFERENCES
[13] METRO Group Future Store Initiative, http://www.futurestore.org
[1]
Clemens Szyperski. Component Software. Addison Wesley Publishing Company. 2002.
[2]
Klaus Bergner, Andreas Rausch, Marc Sihling, Alexander Vilbig. Putting the Parts Together – Concepts, Description Techniques, and Development Process for Componentware. Proceedings of the 33th Annual Hawaii International Conference on System Sciences, IEEE Computer Society. 2000.
[3]
Peter Feiler, Richard P. Gabriel, John Goodenough, Rick Linger, Tom Longstaff, Rick Kazman, Mark Klein, Linda Northrop, Douglas Schmidt, Kevin Sullivan, Kurt Wallnau. Ultra large scaled software systems: The Software Challenge of the Future. ISBN 0-9786956-0-7. July 2006.
[4]
Position paper of Gesellschaft für Informatik (GI) and Informationstechnische Gesellschaft im VDE (ITG). Organic Computing, Computer- und Systemarchitektur im Jahr 2010. 2003.
[5]
Dirk Niebuhr, Christian Peper, Andreas Rausch. Towards a development approach for dynamic-integrative systems. In:
[10] Population of Germany until 2050, Statistisches Bundesamt, Wiesbaden, 0140111-03900, June 2003. http://www.destatis.de/presse/deutsch/pk/2003/Bevoelkerun g_2050.pdf [11] Atchley, R. C., and Barusch, A. S.: Social Forces and Aging: An Introduction to Social Gerontology. Thomas Wadsworth Inc. Belmont, CA. 2004.
[14] Christian Decker, Albert Krohn, Michael Beigl, Tobias Zimmer. The Particle Computer System. http://www.teco.edu/~krohn/spots.pdf [15] The JiniTM Technology Surrogate Architecture Overview, https://surrogate.dev.java.net/doc/sa.pdf [16] Dirk Niebuhr, Holger Klus, Michalis Anastasopoulos, Jan Koch, Oliver Weiß, Andreas Rausch. DAiSI - Dynamic Adaptive System Infrastructure. Technical Report Fraunhofer IESE, to appear in 2007. [17] J.P. Sousa and D. Garlan. Aura: An architectural framework for user mobility in ubiquitous computing environments. In: Proceedings of the 3rd Working IEEE/IFIP Conference on Software Architecture. 2000.
Article Number 3
