Institute of Computer-aided Product Development Systems

Autonomic Support for Distributed Product Development Systems

D. Roller , E. Stoyanov

During this phase of the project three major milestones were achieved – outlining of architectural elements and the dependencies in product development support systems, definition of a common meta-model for description of distributed systems and development of the prototype which utilizes the meta-model with the help of standard-based management utilities.

Architectural Elements

The architectural elements which are included in software used in complex projects may vary and typically they are developed in isolated environment which is not enough for assuring the stable condition of the system. Such systems include several component technologies with their respective requirements for configuration and maintenance. A middle ware that supports the dynamic verification of dependencies and communication channels across distributed parts provides the possibility to minimize the risk of failure or at least in-advance to notify the respective management staff about possible damages. Figure 1 demonstrates the need of common management and the dependencies between elements of an example RPD system with three different component technologies.

Figure 1: Dependencies in a distributed product development support system

Meta-Model

Management of large systems requires a flexible way to describe their structure and composition. The developed meta-model serves as a basis for description of self-managed systems. It introduces the concept of channel management and dynamic selection of communication interfaces. As a reference model for management it uses the Viable System Model (VSM) and the concept of recurrent management. The following concepts describe the responsible elements through which management detects communication inconsistencies.

Figure 2: CIM-based meta-model for description of distributed component communication

AC_System – represents the system as a whole, containing components and other systems
AC_Channel – represents a dependency or communication channel
AC_Manager – represents a managing system, being itself a system containing managed elements
AC_Operation – represents the communicating endpoints through which components achieve communication (interfaces, event emitter, event handler, message sender, message receiver, etc)
The associations which connect these concepts enable internal and external managed elements to be mapped onto the management model.

Prototype Architecture

The developed in IRIS prototype of a channel management middle-ware uses the meta-model to build the internal semantics and provide the needed interfaces for decision making. It's descriptive mechanism uses the CIM (Common Information Model) for the concrete implementation of the management back-end as an established standard in the domain of system management.
The elements of the prototype are mapped internally in the model repository to enable self-monitoring. Every component container has an integrated sensor which delivers component-related events to the channel management middle-ware. The operation manager is responsible for the storage and provision of relevant and valid for the decision making components information. The whole communication between the elements is achieved through the platform-independent CORBA protocol for maximal interoperability.

Figure 3. Prototype architecture for distributed communication management