Based Control Systems
2.5. Control Based Self-Adaptive Systems Models and Architectures
Some control based self-adaptive system models and architectures have been proposed in the recent years. For instance, [email protected] is a causally connected
self-representation of the associated system that emphasizes the structure, behavior, or goals of the system from a problem space perspective [46]. On the other hand Accord enables the development of autonomic elements and the formulation of autonomic applications as the dynamic composition of autonomic elements, where the runtime computational behavior of the elements as well as their compositions and interactions can be managed at runtime, using dynamically injected rules [47].
In the following subsections we will describe in a more detailed way the Rainbow framework [48], the MAPE-K blueprint [49], and the Adapta framework [50].
These three proposals have been selected for a detailed description because the match some of the expected requirements for this dissertation. The Rainbow architecture framework uses common adaptation mechanisms in a cost-effective way for a wide range of systems and multiple objectives. This allows fitting some self-adaptation capabilities for particular systems. The MAPE-K architectural blueprint is aimed to systems that deal with changing environments. And the Adapta framework is designed for self-adaptive distributed applications.
2.5.1. Rainbow
The Rainbow framework uses software architectures and a reusable infrastructure to support self-adaptation of software systems [48]. The goal of the Rainbow framework is to offer a generic architecture for building self-adaptive systems such that the various components can be reused across a family of systems [51], [52].
The architecture of the Rainbow framework consists of three layers, as shown in Figure 10: a system specific infrastructure layer, an architectural layer, and a translation layer.
Figure 10: Rainbow framework [48]
The system-specific infrastructure layer offers low-level probes for measuring all kinds of properties such as response time of connections and loads of servers, effectors for performing changes, and other infrastructural services such as resource discovery services.
At the architectural layer, the Rainbow framework includes in its run-time system an architectural model of the executing system. This architectural model typically represents the executing system as a set of components, connectors, properties (attached to components and connectors) and constraints (to restrict the components, connectors and properties within certain well-defined configurations). The model manager component gives access to this architectural model. Gauges will then aggregate events from the probes and update the architectural model. The constraint evaluator will periodically evaluate the constraints of the architectural model. In case of constraint violations, adaptations will be triggered. The adaptation engine will then determine the course of action depending on the circumstances.
The translation layer is responsible for bridging the abstraction gap between the system layer and the architectural layer. In order to apply the framework to a specific system, the framework must be populated with specific adaptation knowledge about the system. This includes the architectural style of the system, the rules for evaluating constraints, the adaptation strategies and finally the specific action operators that can be performed on the system’s elements. The authors show that reuse of this system-specific adaptation knowledge across a family of systems is also possible. The extent to which this reuse is possible depends on whether these systems share the same architectural style and system concerns to be achieved.
Rainbow provides an engineering approach and a framework of mechanisms to monitor a target system and its environment, reflect observations into the system’s architecture model, detect opportunities for improvements, select a course of action, and effect changes. The framework provides general and reusable infrastructures with well-defined customization points, a set of abstractions, and an adaptation engineering process, focusing engineers on adaptation concerns to systematically customize Rainbow to particular systems. To automate system self-adaptation, Rainbow provides a language, called Stitch [53], to represent routine human adaptation knowledge using a core set of adaptation concepts.
2.5.2. MAPE-K
Autonomic computing is a computing environment with the ability to manage itself and dynamically adapt to change in accordance with business policies and objectives [49]. According to the description provided by IBM in [49], self-managing environments can perform such activities based on situations they observe or sense in the environment rather than requiring human interaction to initiate the task. In their proposal, they define a blueprint for developing autonomic computing. The main component of this blueprint is called an Autonomic manager. It is an implementation that automates some management function and externalizes this function according to the behavior defined by management interfaces. Therefore the autonomic manager implements a control loop. And to be self-managed, it must have an automated method to collect the details it needs, to analyze them, to create a plan accordingly, and to execute it. When these functions can be automated, an intelligent loop is formed.
Figure 11 shows the architecture that divides the loop into four elements:
• Managed elements representing any software or hardware resource that is given autonomic behavior by coupling it with an autonomic manager.
• Sensors that collect information about the managed element.
• Effectors, also known as actuators in other environments, are responsible for carrying out the changes to the managed elements.
• Autonomic manager is, as previously defined, responsible for monitoring the environment, analyzing the measures obtained, defining a plan, and executing it if required. An autonomic manager can manage one or many elements, as required by the system.
Figure 11: The architecture blueprint for autonomic computing
Figure 12: The functional details of the autonomic MAPE-K manager [49]
The functional details of the autonomic manager are illustrated in Figure 12. We can see five differentiated components that give the name to the architecture: Monitor, Analyze, Plan, Execute and Knowledge (MAPE-K). The monitor function provides the mechanisms that collect, aggregate, filter and report details collected from a managed element. The analyze function provides the mechanisms that correlate and model complex situations. These mechanisms allow the autonomic manager to learn about the environment and help predict future situations. The plan function provides mechanisms that construct the actions needed to achieve goals and objectives. The execute function provides the mechanisms that control the execution of a plan with considerations for dynamic updates. The knowledge is shared and exchanged among the four components.
2.5.2.1. Guide for the implementation of MAPE-K
In his Ph.D. thesis, H.A. Muller published a brief set of questions aimed to aid engineers and developers in the implementation of a MAPE-K based system [54].
These questions are summarized here for convenience:
a) What aspects of the environment should a self-adaptive system monitor?
b) How should a self-adaptive system react if it detects changes in the environment?
c) What are the conditions that trigger adaptation?
d) Should the system be open-adaptive or closed-adaptive?
• With open-adaptive systems, new behaviors can be introduced at run-time.
• With closed-adaptive systems, all adaptive behavior is fixed at design-time.
e) What type of autonomy must be supported?
f) Under what circumstances is adaptation cost-effective?
g) How often should adaptation be considered?
h) What kind of information must be collected to make adaptation decisions?
2.5.3. Adapta
The Adapta framework is a reflective middleware built on CORBA that provides the means to develop self-adaptive component-based distributed applications, separating the business concerns from adaptation concerns [50]. The application adaptable elements and reconfigurable actions are described using a XML-based language. This code is interpreted during the application startup, and can also be modified and re-interpreted at runtime.
The reconfiguration actions provided by the Adapta core are updating application parameters and replacing algorithms using a state transfer mechanism.
Anyway experienced developers can extend the provided reconfiguration mechanisms with their own contributions.
What Adapta provides is the application adaptation engine and a periodical observer to monitor the availability of resources, and to notify environmental changes to subscribed components. Figure 13 illustrates Adapta main components and their interactions.
Figure 13: The Adapta Framework [50]
The Monitoring Service (MS) collects information from the system resources in a periodical loop, and notifies to de Local Event Service (LES) any meaningful change it detect on the operation range of a property. The Local Event Service notifies the events to subscribed components when a resource availability condition occurs. The Event Processing System (EPS) does the same for distributed composite events from different sources. And finally, the Dynamic Reconfiguration Service (DyRes) is the adaptation engine that applies reconfiguration actions to the application in response to environmental changes.
As we can notice, the Adapta framework is essentially a publish-subscribe mechanism with a reconfiguration module. This reconfiguration module, the DyRes, consists on a dynamic table containing events and strategies, and a reference to its associated Adapta Component Configurator (ACC) responsible for applying the reconfiguration actions. The ACC introduces three adaptive mechanisms: update of application parameters, replacement of interchangeable algorithms, and synchronization among distributed components.
2.6. Summary
In this chapter we have introduced the concept of adaptation in section 2.2, with an overview of the mathematical background that models adaptation and self-adaptive systems, whether they are biological entities or artificial systems like computers and other devices with processing capabilities. Section 2.3 described the basic concepts of a control system, and introducing the concept of a feedback control loop. In section 2.4 we provided a small introduction to decision making models and methods that can be used for the controller block of a control system. A detailed description of fuzzy based decision making functions has been included in section 2.4.1. Finally, in section 2.5 we have introduced some frameworks and architectures for the development of control based self-adaptive systems. A particular consideration has been paid to the MAPE-K architectural blueprint, as it provides a well-defined methodology for the development of self-adaptive control systems, and therefore it will be used for the description of our fuzzy control based self-adaptive system proposal in next chapter.