MODULAR SUPPORT SYSTEM FOR DESIGN OF CONTROL SYSTEM

MODULAR SUPPORT SYSTEM FOR DESIGN OF CONTROL SYSTEM

IFAC MCPL 2007 The 4th International Federation of Automatic Control Conference on Management and Control of Production and Logistics September 27-30,...

201KB Sizes 0 Downloads 83 Views

IFAC MCPL 2007 The 4th International Federation of Automatic Control Conference on Management and Control of Production and Logistics September 27-30, Sibiu - Romania

MODULAR SUPPORT SYSTEM FOR DESIGN OF CONTROL SYSTEM Frankovič B., Budinská I., Oravec V., Sebestyénová J. Institute of Informatics, Slovak Academy of Sciences, Dúbravská cesta 9, 845 07 Bratislava, Slovakia {frankovic, budinska, viktor.oravec, sebestyenova}@savba.sk

Abstract: The paper describes architecture of the support system for modeling, simulation, and control system design, based on the user’s requirements. The system integrates some modeling, simulation, and control design tools. A generic block built on the multi-agent basis is used for the integration, which is responsible for managing the activities of all agents, providing the cooperation among agents and interfaces and among the system and users. The generic block contains two methods; the first method is based on the similarity degree between arbitrary situations, the second is built on inductive reasoning. It enables users to model a real system, to design control system and then to simulate results. Copyright © 2007 IFAC Keywords: modelling, control, simulation, agents, reasoning, decision systems.

1. INTRODUCTION

can be a good tool for finding the best conditions, which ensure the fulfillments of user requirements. In the paper a modular decision support system with the acronym MARABU is described (Frankovic et al. 2005). It is a modular multi-agent system for modelling, control design and simulation of different production, economic, information etc. systems. It is intended for experts and technical staff from manufacturing enterprises, as well as for students of technical schools for learning and training technical staff and students of technical universities. The paper contains the general description only. The main attention will be focused to the description of the decision rules used in the design phases.

The new production, economic, social and informatics contexts require considerable flexibility. For many products, managers vary lot sizes in order to respond to demand in a just in time manner while keeping the inventories as low as possible. The performance facility configuration can add or delete resources and links, on an as required basis. The network nodes may be, for example, workstation, equipments, special crews, subcontractors, handling equipment or any specific resources required to complete a particular task. Given the network and processors flexibility, hundreds or even thousand of potential combinations of workstations, manufactories, enterprises, economic, social etc. elements are conceivable to complete a particular task (Wilkins, Myers, 1998).

2. CHARACTERISTICS OF THE MARABU SUPPORT SYSTEM Design of system control includes three phases: the model of the system has to be designed; then a control algorithm has to be suggested, and finally the proposed solution should be simulated and verified. This procedure determines the basic architecture of MARABU.

It is evident that the solution of all this problems is imperative to develop a modular support system for design of planning, modeling and control tools. For building of such system it is required to generate the virtual network in which many variables and constraints have to be considered. The virtual manufacturing network using the intelligent algorithms, knowledge systems and agent technologies in the form of agent coalition systems

There are many problems connected to the system development. First, knowledge has to be represented in such a form that is either human or computer

559



readable. Second, all data and knowledge about specific domains have to be stored, archived and organized for future reuse. The scope of the paper is to present a multi-agent architecture to handle knowledge and to provide decision support for modelling, control and simulation (Figure 1). The decision has three levels: • The process level includes: energetic processes, chemical engineering processes, gas company processes, manufacturing and transport processes, food technology processes, • The process model level includes: continuous, discrete, hybrid, linear, event driven, nonlinear, deterministic and stochastic processes, • The synthesis method level includes: event driven control, process control, supervisory control. The system works in two models: 1. finding an appropriate tool, method, or algorithm searching in a case-base, 2. connecting an external application. Therefore the database is organized as a structured database. The database for tools, algorithms and methods stores metadata for each item.







AF Functions of attributes

NUM Model design

AM Attributes for modeling

ALM

User’s aget

Modeling agent

Database

Modeling tools

AM MA

Questionnaire: Users specification of the process

AC Attributes for control

2.1. MARABU Architecture



Design UCS

Sim M



Sim CS

ALC

P Sim

Control agent

Agent for simulation

CA NUM AF NUM UCS AF

Control design tools

Simulation tools

Generic block



Questionnaire (Q) - is built similarly to expert system, and users follow the steps in the requirements by answering questions. On the basis of answers, the next level of the questionnaire is opened for him/her. Users agent (UA) – provides an intelligent interface between a designer (a user) and the other agents in the system. UA receives designer’s requirements and description of the process to be controlled as inputs for reasoning and decision making and returns suggested solution(s) for the user. Modeling Agent (MA) – after receiving information about the process, it searches for appropriate modeling tools and algorithms on the basis of previous cases, returns suggested algorithms, and asks for more precise information according to a chosen algorithm. The final decision on which algorithm and/or tool has to be chosen is up to the user. Finally, modeling agent returns a model of described production process. Control Agent (CA) - receives the finally chosen model with all necessary attributes defined. On the basis of the model, CA searches for an appropriate control algorithms in the database. Through UA, it negotiates with the user and finally chooses appropriate control algorithms. The user has to choose an algorithm from the suggested ones, and to specify all needed values for that. CA returns control algorithm for the process according to user’s specifications. Simulation Agent (SA) – is responsible for simulation of control for the chosen model and control algorithm with the aim to help the designer assess the proposed solution. Monitoring Agent (MoA) - follows the system behavior after applying the recommended method for designing the control. If all the requirements are satisfied, then MoA updates the database by newly achieved results, i.e. the system stores all solutions for next reuse and application. Otherwise, the MA and CA have to repeat their calculations. Generic Block (GB) - is a multiagent system, which is responsible for managing the activities of all other agents, and provides the cooperation among UA, MA, CA, SA, MoA agents and interfaces among the system, users, and external applications.

3. CASE BASED REASONING METHODS AND TOOLS Because the generic block plays an important role in building and evaluation of the control system designed according to the customer requirements, in the next parts the methods for its solution will be described. Three basic elements for the GB have to be defined:

Figure 1 Architecture of MARABU In the MARABU architecture the following blocks and agents are considered: 560

Attributes –are organized in three groups according to significance to different systems. This significance determines the corresponding value for each attribute; according to these values the suitable method or a tool for the given task can be chosen.

4.

Rules – are defined within an inference engine and serve to find solution for the user on the basis of user’s requirements.

5.

Control strategies – are defined for searching solutions on the basis of the predefined rules. The known control strategies used for Case Based Reasoning (CBR) (Bergman, 1999) are forward chaining and backward chaining. CBR is used within the system to find a solution that matches the user’s requirements best. CBR is used within the system to find a solution that matches the user’s requirements best.

of the model, CA adapts the past solution to the current model and designs the control system. MoA follows the system behaviour after applying the designed control system. If all requirements are satisfied, MoA updates the database by newly achieved results. Otherwise a process is repeated as long as all requirements are satisfied. SA receives mathematical model and design of the control system. Its goal is to simulate and verify the proposed control system.

Model Simulation (servlet)

Server

Adaptive Control (servlet)

GUI (applet)

Agents in a proposed system cooperate to find a solution to satisfy user’s requirements should be tested, and when the proposed adapted solution shows to be good, it is entered to a database as a new case related to a new solution.

Web Server

Tool’s web page

An algorithm for assisting a user in modelling, designing the control system and simulation is as follows: Initialisation: filling database with default data. There are two types of data in the database: description of cases – basic attributes, set of default solutions. There are relations among default cases and default solutions.

Reasoning Modul

Server Database

Input: Users have to fill in a questionnaire, where basic attributes for the current situation (description of production process) are described. After user’s requirements are recorded, search for appropriate modelling tool begins. (Figure 2) 1. MA asks SA to find a similar situation from the database of cases. Requirements: search and data mining algorithms. 2. After finding similar case, related solutions – a method for modelling, are sent to the user. The returned solution(s) may not be the right one(s) for the current situation. It depends on the degree of similarity of current and historical cases. The user has to pick one of proposed solutions and then MA adapts it to the current case, then proposes a solution (model with all necessary parameters) to the user, simultaneously sends it to CA. MoA monitor all these activities. After proposed solution is adapted and the user is satisfied with it, a new case is entered to database with relation to a new solution. Otherwise a new search is executed as long as a solution is found. 3. CA receives a (mathematical) model identified by MA and numerical parameters entered by the user. CA works in the same manner as MA. It asks SeA to find a similar model stored in database. On the basis of numerical parameters

Figure 2 Example of the modules connection The structured database is built independently for all three blocks of the systems; however, all these databases are related to each other. The databases contain a case library, and a set of solutions related to these cases. Objects in the databases are represented by attributes. For an attribute-value representation a couple of methods can be used to measure a similarity degree. A method of weighed attributes is used to asses similarity between a current case (that the user has defined) and a case in the case base. The weights allow expressing the importance of all attributes. Two different methods (Zeng, Sycara, 1995) to evaluate attributes are used: user specific weights, which are given as a part of user’s requirement through the user’s questionnaire; and case specific weights (weights are specified as a part of structured database). The third option is to use combination of user specific and case specific weights to find the solution that fulfils the users’ expectations most and does not neglect any important attributes given by case specific weights. 561

Cooperation among CBR agents (Dang, Frankovic, 2003) agents involves exploiting the set of all cases in common memory of all agents and to reason about these cases using similarity-based reasoning. A problem is solved on the basis of knowledge that can be learned by another agent within CBR. Let’s suppose that one agent Ai has to solve a problem. It can ask another agent Aj to find a similar case in database using its own method for evaluation of similarity degree, or it can, together with the case description, send also a method that might be used to retrieve similar case from database. A solution is assigned to a case on the basis of database structure. One or more solutions can be assigned to one case. Case-based reasoning is often used for problem solving where a large amount of historical data exists, or experts can give a large volume of examples, or where a lot of valuable experience is recorded. CBR is also preferred when rules for reasoning cannot be formulated, or when there are a lot of exceptions from formulated rules. CBRs are used when it is difficult to collect historical cases data. CBR process includes a problem description, a new case specification, finding a similar case in database, finding related solutions, adapting proposed solution, testing adapted solution, confirmation of new solution, and learning new case with solution.

3.1. The formulation of logical relations Let re(el1, el2): { EL × EL }  [0,1] be a relation expressing the dependence between two attributes (el1, el2)∈ EL. There are some important properties of this relation(Budinska, Dang, 2004). • re(el1, el2) ≠ re(el2, el1) , resp. ≠ ( 1 – re(el2, el1)), i.e. this relation is not symmetric or inverse. • re(el1, el2) = 1; when the solution proposed for element el2 could be applicable to element el1 without changes. For example, el1 is a linear system with complete information; el2 is a linear system with parametrical uncertainty. • re(el1, el2) = 0 ; when both elements have disjoint domains of effects, i.e. the solution proposed for el1 is useless for element el2. For example, el1 is a discrete event system and el2 is a linear system. • ∀ el∈EL; re(∅, el) = 1 a re( el, ∅ ) ≥ 0 The similarity degree between two arbitrary situations Sim(,) is defined as follows: Suppose a set of cases C of one class – manufacturing system with a discrete or continuous production process represents a case. Each case is described by a set of its attributes A.

C = {c1 , c 2 ,....}

c i = {a i1 , a i 2 ,....a in };

In this paper, two methods proposed to extract information from the database are presented. The first method is based on the similarity degree between two arbitrary situations; the second one is built on the inductive reasoning principle.

(1)

a ij ∈ A

(2)

A is a set of attributes that can be recognized in any case. If an attribute is not related to the case, the value is set to zero. Let’s define a set of solutions:

The first method works on the following principle: the agents calculate the similarity between two arbitrary situations by comparing all their attributes. Relationships among attributes are evaluated by any number (real or fuzzy) that reflects how much a solution of one situation is useful for the second one, with respect to these attributes. The similarity degree is defined by a combination of those partial relationships.

S = {s1 , s 2 ,...}

(3)

s i = {el i1 , el i 2 ,...}

(4)

A Case Base is defined as a space of case descriptions and case solutions: CB = C × S

The second possible method is an inductive reasoning that works as follows: starting with the most important attribute, the agents sort and filter all cases that have the same or to a certain degree the same attribute like the target one. This cycle continues with less important attributes, until only one candidate remains. The remaining case is considered as the most similar to the target one.

(5)

The user defines a case through attributes and the system starts to search for similar cases in a CB. Let a current case be defined as follows:

cci = {cai1 ,..., cain },

(6)

where caij is an attribute j of a current state i. The general problem of similarity assessment is (according to [1]):

All case-based reasoning methods have some common steps: • retrieve the most similar case (or cases) to a current case in the case library; • reuse the retrieved case to try to solve the current problem; • revise and adapt the proposed solution to a current case; • record a new case with a new solution

(

sim (cc1 ,...., ccn )(c1 ,..., cn )

)

= Φ (sim1 (cc1c1 ),..., sim(ccn cn ))

(7)

A traditional similarity measures for individual attributes are measured by a function Φ that is increasing monotonously in every argument. 562

September 7-10, Š. Kozák, M. Huba (Eds.), 6 pages, on CD Frankovič, B. (2003) New Approach in Computational Cybernetics for Intelligent Adaptive Control of Non-linear Systems, In: Proceedings of 1st Slovak Hungarian Joint Symposium on Applied Machine Intelligence SAMI 2003, Herlany, Slovakia, February 12-14, 2003, ISBN 963 7154 140 Liguš, J.; Laciňák, S. and Gábor, D. (2003) Analyze of adaptive control and design of reference model. In: Proceedings. of the 1st Slovakian – Hungarian Joint Symposium on Applied Machine Intelligence SAMI 2003. Herľany, Slovakia, February 12-14, 2003, ISBN 963 7154 140 Zeng D. and Sycara K.: Using Case Based Reasoning as a Reinforcement Learning Framework for Optimization with Changing Criteria; In: Proceedings. of. Seventh International Conference on Tools with Artificial Intelligence; Virginia USA, 1995; Dang T.T., Frankovič B. and Budinská I. (2003) Case-based reasoning applied for CAS-decision system, In: Proceedings of the 2nd IFAC Conference: Control Systems Design, Š. Kozák, M. Huba (Eds.), Bratislava, September 2003, 6 pages, on CDROM. Wilkins D. E. and Myers K. L. (1998) A Multi Agents Planning Architecture, In: Proceedings of the Fourth International Conference on AI Planning Systems, pp. 154-163, 1998. Durfee Edmund H. and Montgomery Thomas A. (1990) A hierarchical protocol for coordinating multiagent behaviors. In: Proceedings of the Eighth National Conference on Artificial Intelligence, pages 86--93, July 1990. Tamma, V. and Capon, J.M. (2002) Attribute metaproperties for knowledge sharing. In: Proceedings 15th ECAI conference Workshop Ontologies and semantic interoperability Lyon 2002 p. 51-60 Wooldridge M. and Jennings N. R. (1995) Intelligent Agents: Theory and Practice, Knowledge Engineering Review 10(2) Frankovic, B., Budinská, I., Sebestyenova, J., Dang, T., Oravec, V. MARABU – Multiagentový podporný systém pre modelovanie, reiadenie a simuláciu dynamických systémov. In: AT&P Journal, Roč. XII., No. 4, s.57-59, 2005 Budinská I. and Dang T.T. (2004) Ontology Utilization in MARABu – a Support System for Modelling, Simulation and Control Design, In Proceedings. of the International Conference on Intelligent Engineering Systems, INES 2004, U. T. PRES, ISBN 973-662-120-0, pp. 301-306 Dang T. T. (2004) Improving plan quality through agent coalitions, In: Proceedings of IEEE International Conference on Computational Cybernetics – ICCC’04, 6. pages

Inductive reasoning method extracts the desired situation by performing a search of a decision tree, which involves all possible historical cases satisfying certain conditions. A decision tree is generated as follows: starting with the most important attribute – say it is el1, all cases that satisfy the following condition are added to the decision tree.

re(el1 |( si ) , el1 |( sicurrent ) ) ≥ α

(8)

where coefficient α is a low bound that is used to restrict a set of candidate situations. The classification process continues with less important attributes, until only one candidate solution remains. After finding a similar situation to the current one, the agents extract the solution that was used in this case (a method for modeling, designing the control system and simulation), and retrieve it appropriately to a solution for the current situation. The user accepts the recommendation and applies it into practice. The last step that the CAS-Decision System has to do is to observe the real behavior of the system after the user has applied all the methods proposed by the agents. The results achieved by an observation are intended to evaluate the selected methods and for later use.

4. CONCLUSION The paper describes a multi-agent support system MARABU, which is dedicated to serve in modeling, control system design and simulation of manufacturing system, either continuous or discrete. That is why, the system handles with a lot of knowledge about methods, tools, and algorithms for modeling, control and simulation, and continuous and discrete systems as well. The system also integrates works from many fields of control theory and artificial intelligence. In the future, the main interest is to focus on cooperation among agents, because there are many different kinds of agents situated in that system, developed by different teams, with different architecture, behavior, and knowledge. The problem that has to be solved in the nearest future is to find how suggested solutions can be adapted to user’s requirements. ACKNOWLEDGEMENT This work was supported by Science and Technology Assistance Agency under the contract No. APVV LPP-0231-06; VEGA 2/7101/27 REFERENCES Bergmann, R. 1999 Special issue on case-based reasoning. Engineering Application of AI, No. 12, pp. 661-759. Dang, T.T.; Frankovič, B. and Budinská, I. (2003) Case-based reasoning applied for CAS-decision system, In: Proceedings. of 2nd IFAC Conference: Control Systems Design, Bratislava, 563