ZESZYTY NAUKOWE UNIWERSYTETU J A G I E L L O Ń S K I E G O

MMCCXLII PRACE INFORMATYCZNE Z. 10 2000

The Agent Conception in the Management Systems

Tadeusz Dyduch
dyduch@icslab.agh.edu.pl
Krzysztof Cetnarowicz
cetnar@uci.agh.edu.pl
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 perfor-

mance, 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 in-
formation (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 re-
quirements,

• 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 pro-
duction demands, can generate the material requirements, compute the ca-
pacity 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

Final Products
Master Stock
Production
Schedule

BILLS OF MRP MATERIAL IM

MATERIAL REQUIREMENTS Material INVENTORY
PLANNING Stock MANAGEMENT

Material
Requirements

Capacity
CRP Exploitation Purchase
CAPACITY Plan Orders
REQUIREMENTS
PLANNING

Production
Orders

PRODUCTION SFC PC
PATHS SHOP FLOOR PURCHASING
CONTROL CONTROL

Fig. 2. Closed-loop MRP class system structure

14

FIRST

AGENT 3
1

AGENT AGENT

A1 2 C1

AGENT AGENT

A2 B1

AGENT AGENT

A3 B2

Fig. 3. Multiagent systems skeleton

Fig. 4. Agent’s goal-loop example

 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 behav-
iour 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, some-
time 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 environ-
ment, 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 sys-

tem),
• Input/output data structure (data bases, special files or/and user ap-
plications),
• 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 man-

agement 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 ex-
ecuted 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 man-
agement 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 implemen-
tation is based on the DIMAS server (Decentralised Intelligent MultiAgent
System). This server was written in Java which gives us platform indepen-
dence 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 re-

quires a DIMAS intervention (Fig. 8) [6]. This server construction gives the
platform independence, network independence and data security.
 21

OPERATING SYSTEM
DIMAS
SERVER
Agent
Agent 2
Agent OUTSIDE
3
1
AGENTS Agent ENVIRONMENT
ENVIRONMENT 4

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 (gen-
erate 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 re-
sents 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 de-
tailed production plan generates capacity exploitation plan). Similarly
as MRP agent, each CRP agent is related with one material/compo-
nent/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) – inte-
grated 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 sys-
tem):

• 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 run-
ning 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 mod-
ules of the closed-loop MRP class system (SHOP FLOOR CONTROL, PUR-
CHASING 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 man-

agement system using agent conception, which are:
• System developing
Adding new a function to the management system is natural and com-
mon 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 in-
crease 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 envi-
ronment 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 sys-
tems 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 prob-
lem 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., Zarza̧dzanie – produkcja
i uslugi, PWN, Warszawa 1995.
[4] Stevenson W.J., Production/Operations Management, IRWIN Mome-
wood 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 Żabińska 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