Erp

ZESZYTY MMCCXLII

NAUKOWE

UNIWERSYTETU

´ SKIEGO JAGIELLON

PRACE INFORMATYCZNE Z. 10

2000

The Agent Conception in the Management Systems

Tadeusz Dyduch [email protected]

Krzysztof Cetnarowicz [email protected]

Institute of Computer Science Technical University of Mining and Metallurgy AGH

Abstract. These papers are aimed at showing the basic virtues of the agent approach to the management system. We will show the logical skeleton of the management system and reasons why the multiagent environment is suitable to implement it. Our research concentrates on creating a complete closed-loop MRP class application. Especially, we would like to show modification and developing perspectives. The following article also gives a short introduction to the M-agent theory. Finally, we will show the features of this approach like calibration, system topology and cooperation with different database systems.

1. The structure of the management systems

At present the companies are sparred to constantly improve their performance, quality of the products, reduce costs, be adaptable to the changing client requirements, etc. To be competitive, modern companies have based their decision procedures on the integrated management systems. It makes all strategy decisions easier and more pertinent because all the required information (history, statistics, current company state etc.) are easy accessible. There are probably many other reasons to implement such a system into the modern company, but let’s take a look at the logical structure of it. Figure 1 shows the developing process of the management systems form simple MRP class to the big ERP class [1].

12

ERP (Enterprise Requirement Panning) MRP II (Manufactory Resource Planning)

DRP (Distributed Requirement Planning)

CLOSED-LOOP MRP MRP (Material Resource Planning)

Fig. 1. Developing process of the management systems The applications usually used are of MRP II or ERP class, but they almost always contain the closed-loop MRP class subsystem. This module is responsible for the production management area. The main structure of this subsystem is shown in Fig. 2. The communication paths in the structure of this system are some kind of a closed loop what explains the name. The modules in the picture are: • MRP – the heart of the system, module which computes the material requirements, • CRP – also very important module which is liable to the capacity requirements, • Both those systems are initialised by the MPS module responsible for the production scheduling [2], • SFC module responsible for the management of the production orders and priorities, • PC module – registration of the purchase realisation, • IM module, responsible for the management of the regulation of the product and material reserves. All these modules basing on the bills of material, production paths and production demands, can generate the material requirements, compute the capacity strain, decide when to start the production to realise the orders, or even decide in which order the production tasks should be done. All those pieces of information are very important in the production planning, being a good example of using integrated information systems for the management problems [3], [4].

13

REAL WORD (MANAGER) OR OTHER MANAGING SUBSYSTEM

Final Product Demand

MPS MASTER PRODUCTION SCHEDULING

Master Production Schedule BILLS OF MATERIAL

MRP MATERIAL REQUIREMENTS PLANNING

Final Products Stock

Material Stock

IM INVENTORY MANAGEMENT

Material Requirements CRP CAPACITY REQUIREMENTS PLANNING

Capacity Exploitation Plan

Purchase Orders

Production Orders PRODUCTION PATHS

SFC SHOP FLOOR CONTROL

PC PURCHASING CONTROL

Fig. 2. Closed-loop MRP class system structure

14

FIRST 1

AGENT

3

AGENT

AGENT 2

A1

AGENT

AGENT

A2

B1

AGENT

AGENT

A3

B2

Fig. 3. Multiagent systems skeleton

Fig. 4. Agent’s goal-loop example

C1

15 2. Introduction to the M-agent idea

M-agent conception bases on the idea of intelligent, autonomous and moveable objects [5]. They are intelligent, because they can make logical decisions on the strength of their state, the state of environment and behaviour of other agents. They are autonomous because they can initialise some action on their own. They are moveable, because the environment allows them to move from one server to another. These are the basic features of the agent, but let’s see how it looks in a real system (Fig. 3). There is a First Agent put into life by the main process. This agent creates three kinds of child agents (A, B, C) which may reproduce their copy. The creation process (marked in Fig. 3 by the double lines) is only one of the many ways to create a skeleton of a multiagent system. There are also communication connections (single lines), which can be set between any two agents. Those agents have now their goal-loops and can execute some actions. Finally, when the agent tasks are solved, it can be killed by an other agent, process or by itself. Some simple goal-loop is shown in Fig. 4.

3. Advantages of using agents in the management systems

Let’s take a look at the traditional, human management structure in an exemplary company. • There must be a manager, who gives some tasks to the subordinates. • The way to execute those tasks is usually the subordinate’s problem. • It is quite often that the subordinate also has a few workers who can solve some subproblems and so on. • Every worker in the company has some autonomy in his decision processes. • The workers must usually communicate with the other workers, sometime go to another unit, ask some workers for information, and finally solve the problem. When the task is done, the worker may be used once again in the same job, may be fired or may be promoted. In traditional, computerised management systems, most of those features must be reduced or changed. One of the most important problems is the autonomy of the single unit. The centralised system works correctly when

16 the decisions are realised in 100%. But if some person decides to change it or some problems occur, the system hardly adapts to the new situation. This causes that the managing of a company must be subordinated to the system. This is not natural, because the system is to help in managing the company, not to limit the possible decisions. When we use a multiagent environment in the same exemplary company, we just put a single agent or group of agents in the place of the worker. The behaviour of the agent is very similar to the real worker. It may communicate with other agents, go to another unit (move from one server to another), ask other agents for some information or to solve subproblems, and execute some algorithms to generate final results. When the job is done the agent may be re-used, may be killed or may be reproduced. The agent’s life cycle is a simulation of the real worker’s behaviour. This natural transfer of the worker’s behaviour into the computer management system is one of the most important virtues. The topology of the agent system may be similar to a topology of the company: the same units (servers), the same communication procedures (communication between agents), the same tasks (fulfilled by agents). There are also many other advantages that will be shown in next chapters, describing the basic steps in creating a management system.

4. The agent structure of the management system

The first step is to create a skeleton of the system – some kind of environment, where the managing agent population may execute their goal-loops. In our system we need to create: • Supervisor agents (agents to manage other agents working in the system), • Input/output data structure (data bases, special files or/and user applications), • Access agents (agents to tend access to the input data structure). The second step is to create some functional modules of the system. In our case this is: • Create managing agents (for example, MRP agents), • Test them at some exemplary data, • Set the necessary environment data,

17 • Ask supervisor agents to make our new agents alive. “MRP agent” is the agent (usually group of agents) responsible for the same tasks as MRP module in the management model structure mentioned at the beginning (Chapter 1). Lets take a look at the system now (Fig. 5).

Fig. 5. Simple management system The next steps should be creating and adding other “functional” agents to the system. In our case, to create a complete closed-loop MRP class system, we should add MPS, CRP, IM, SFC and PC agents, equivalent to the same way named modules in the management structure. We just repeat the second step for every new kind of agent. Finally, when we have all “functional” agents running, we might see that some functions don’t work correctly. In a traditional system we would have to stop whole system and make the necessary changes (maybe in many different places). But in our case, we have a much simpler task – look at Fig. 6. We have to find the agent responsible for this function and: • Create a new model of the existing agent (for example, IM agent), • Test a new agent model on exemplary data, • Ask supervisor agents to save the state of the existing IM agent (Fig. 6 line 1) and kill it (Fig. 6 line 2), • Ask supervisor agents to set the new IM agent into the state of the previous one and make it alive in the running system (Fig. 6 line 3).

18

Fig. 6. Changes in the running system The changes are much simpler because: • The system might be changed without stopping it, • You don’t need to analyse the whole system to make small changes (agent’s body is usually short), • You can simply test a new agent model on exemplary data, • It is easy to add the new agent to the system. If you decide to change the input data structure, you may do this without serious changes in the system – just replace the access agent. This is an important advantage over the traditional systems, because you might use concurrently different kinds of databases. You only have to create suitable access agents. It is very important in the case of a changing system, when you want to use a data structure of some previous one, and also a new database. Fig. 7 shows this case.

19

Fig. 7. The parallel use of two different kinds of databases in a multiagent system Now, let’s take a look at the possibility of developing the system. The agent conception makes it possible to evolve the management system in any directory and in any scale. Try to imagine that one day your company grows up and the producer also becomes a distributor and vendor. Your company requires many serious changes, reorganisation and modification. • In the agent management system, you just add a few new servers with new agent type, link them with the existing management network and allow them to co-operate. • In traditional system you would usually have to change the system or have the extended version from the very beginning (and pay for unused modules from the very beginning). Finally, we have to mention the computational problems. In a big management system, proportionally big computational possibilities are required. • If the system is centralised, it may require very strong computer units, which are not resistant to breakdowns. • But in the agent system, you have a possibility to naturally distribute the computational tasks in the company network.

20 For example, the agents which are solving production problems are executed on the server in the manufactory unit. The agents responsible for selling are executed on the servers placed in a vendor’s unit, and so on. The communication and agents migration goes through the company network. This makes the system resistant for the local emergency, allows using many small computers (instead of one big machine), gives the natural image of the company in the management system topology.

5. The implementation of the multiagent management system

As we have shown, there are many reasons to use agents in solving management problems. But usually the practical implementation gives some additional pieces of information, which are unnecessarily fit in the theory. Our research started in 1997, from creating a very simple MRP class system. Next, we developed the MRP agents’ functions and created CRP and MPS agents. This also required creating some functions to set the input data. This was done in a separate application. The whole code was generated using Java compilers, therefore the test could be done on a different machine and system platforms. There are many M-agent servers, designed for a different purpose, based on C++ codes, Java or one of the many other compilers. Our implementation is based on the DIMAS server (Decentralised Intelligent MultiAgent System). This server was written in Java which gives us platform independence so important in the distributed application. The DIMAS server also supports: • making agent alive, • giving computational possibilities to the agent, • data security, • controlling the agent’s goal-loop, • communication, • agent migration, • killing agent. Every interaction with the outside environment or system callback requires a DIMAS intervention (Fig. 8) [6]. This server construction gives the platform independence, network independence and data security.

21

OPERATING SYSTEM DIMAS SERVER Agent 1

Agent 2

OUTSIDE

Agent 3

AGENTS ENVIRONMENT

Agent 4

ENVIRONMENT

Fig. 8. DIMAS server Right now we have implemented three groups of agents: • MPS agents generating master production schedule basing on received orders and product stack state. Each final product has an MPS agent, which computes the master production plan for this part. • MRP agents which are solving the material requirement problems (generate a detailed production plan and material requirements plan). They are related with the components of the final product (one MRP agent with one component). MRP agent gets the order from the higher BOM level MRP agent, generates the production order for his part and resents it to the lower level agent or (when this the last level) it generates the material order. • CRP agents responsible for the capacity exploitation (basing on the detailed production plan generates capacity exploitation plan). Similarly as MRP agent, each CRP agent is related with one material/component/final product. It computes the requirement for the machines time (machine resetting time and production time). The group of the agents creates some kind of tree structure. This tree is determinated by the material structure of the product: each material, subpart, part or final product has assigned one of MRP and CRP agents. In the case of the MPS agent, they are assigned to the final product only. Figure 9 shows the group of MRP agents responsible for one final product. The differences between MRP agents are only in the logical model that is a projection of the bill of material (BOM). In a real implementation they are built the same, the difference is in these behaviour. If they are “Final Product AGENT” or “Subproduct AGENT” they just send an order to the lower level MRP agent. If they are “Material AGENT” they generate the material requirement.

22 The groups of managing agents and access agents are the kernel of the system. But there is a need for some useful tool to edit the data for those agents. Therefore, we have created ESP (Production Scheme Editor) – integrated data editor.

Fig. 9. The MRP agents structure In current system version, this editor allows the user to: • create BOM (bills of material) for the new product, • set the material and product stock, • set the available size of product packets, • set the received orders and planned demand, • set the time required for the production of any element, • set the time required to reset machines for the new kind of production, • set the time required to produce the single element on the machine. Those data are stored in the files, which are analysed by the access agents (so far we don’t use database systems).

23 Additionally there are some data to set( they are parameters of the system): • the horizon (how long plans are supposed to be created), • the step period (the system may work in the period of hour, day, week, etc.), • current period (to edit plans starting from any chosen period), • machine park (all accessible company machine resources). The current system version doesn’t allow us to set all of those parameters but it is not necessary at this test stage. We may show three basic functional system parts (application modules): • mentioned data editor with input data files, • mentioned agents (supervisor agents, managing agents and access agents), • agent and output data viewer, which should be connected with data editor, but also should have some separate functions (listing of the running agents, system load monitor, resources and material requirements listing etc.). This part has been implemented in a very small area so far: there is only the agent listing function. The current state of our management system comprises about 50% realisation of the management functions in a closed-loop MRP class system. This state is shown in Fig. 10. The figure above shows the logical built of the system, but without the supervisor agents. They are removed because in current state of the system they are used at the beginning only (to create MRP, CRP and MPS agents). There are no access agents, but instead there are access objects. They do the same things, but don’t have the agent’s properties like: • auto-transport function (they are generated for one kind of data only, storage at the same server), • goal-loop (they are generated to read the data only), • multiplication (out of use in this case). There is also one more group of agents – “PRODUCTION AGENTS”, but they are only solving some subproblems of the MRP module. So we can trade these agents as a part of the same as MRP agents group, but responsible for production commission.

24

Fig. 10. The current state of the multiagent management system implementation The arrow with number 1 shows the communication process of sending master production schedule. The arrow number 2 shows sending information about master production schedule and production periods (required time). The arrow with 3 shows the process of sending production commission. At the last level there are output data, which are directly generated by the managing agents. This is caused by the future communication tasks with a new kind of agents. This communication will be supported directly by the agents, and most of those output files will be unnecessary. There will be added some output data viewer to monitor the state of the system (listing of the running agents, system load monitor, resources and material requirements listing, etc.).

25 6. Current work and future plans

Right now we are working at the implementation of the next three modules of the closed-loop MRP class system (SHOP FLOOR CONTROL, PURCHASING CONTROL, INVENTORY MANAGEMENT). Those functions require a new kind of agents (SFC, PC, IM). In the close future we are also going to implement access agents co-operating with some exemplary database system (such as INFORMIX, Ms ACCESS). Some additional changes have to be made in the integrated data editor application, to allow the user not only to generate input data, but also to control the behaviour of the system on-line. All these changes should allow us to call this system a closed-loop MRP class system. This will be a closed module of the management system, which could be a good starting point for building the MRP II class or a more advanced application.

7. Conclusions

As we have presented, there are many advantages of implementing management system using agent conception, which are: • System developing Adding new a function to the management system is natural and common behaviour. In the agent system this possibility is supported very efficiently. System’s developing requires creation of a new group of agents, testing them and including into the system. These tests increase the chance that the system will work correctly from the very beginning. • System modification Agent approach is an easy way to make any changes in the system. Modification of the chosen function or modules usually requires making changes in the body of some agent, which is short and simple. It releases programmer analysing the whole system’s code. You can also easily test your new agent on the exemplary data. • Changes in running system Most of those modifications may be done on running system. A new group of agents is moved into the system, it naturally takes over the tasks from the old agents. The same possibility is in developing – adding new agents does not require stopping the system.

26 • Calibration Every new element/task has its own agent, which automatically projects the size of managing business. The number of running agents changes, but not the number of interaction (every agent always communicates with the same number of the agents). So no changes in the agents construction dependent of the system size are necessary. Additionally, agents as autonomous creatures may migrate in the distributed environment and steadily dispose the server load. • System topology Autonomous agents running in the distributed environment, give the clear projection of the information system topology. The company structure may be naturally divided in several units by creating separate subsystems on each of them. The tasks (agents) linked with some company unit may be computed at the local server. This feature makes system managing more natural, enables steady tasks arrangement in the distributed system and reduces the results of possible system damage. • Cooperating with different database systems Very important virtue of the agent approach to the management system is elastic cooperation with different database engines. We can obtain it by creating special access agents, specialised in serving one database or even one table. This system is completely adaptable and independent of database. Any change made in data storage structure requires only creation appropriate access agent (or agents). This feature is very useful when the new management system must also use a data structure of the previous system. As you see the management system based on agent conception has many features that encourage to implement it. Most of the big management systems developers has already understood it and decided to start their own research over this idea. Our investigation has shown that running agents are effective and gives many additional functions inaccessible so far. The problem is that there are no examples of the existing system and development of this idea requires a lot of tests and experiences.

27 8. References

[1] Chase R.B., Aquilano N.J., Jacobs F.R., Production and Operations Management, 1998. [2] Proud J.F., Master Scheduling, John Wiley and Sons Inc., New York 1994. [3] Muhlemann A.P., Oakland J.S., Lockyer K.G., Zarz¸adzanie – produkcja i uslugi, PWN, Warszawa 1995. [4] Stevenson W.J., Production/Operations Management, IRWIN Momewood IL 60430.1990. [5] Cetnarowicz K., M-agent Architecture Based Method of Development of Multiagent Systems, in: Proc. of the 8th Joint EPS-APS International Conference on Physics Computing, ACC Cyfronet Krakow Poland, 1996. ˙ [6] Cetnarowicz K., Nawarecki E., and Zabi´ nska M., M-agent Architecture and its Application to the Agent Oriented Technology, in: Proc. of the DAIMAS’97. International Workshop: Distributed Artificial Intelligence and Multi-Agent Systems, St. Petersburg, Russia, 1997.

Received March 18, 1999

Department of Computer Science Jagiellonian University