Interoperating Standards in Multiagent Agile
Manufacturing Scheduling Systems
Ricardo J. Rabelo
Federal University of Santa Catarina, Department of Automation and Systems,
Florianópolis (SC), Brazil (rabelo@das.ufsc.br)
Abstract: This paper presents an implemented framework that deals with the high-level of
heterogeneity that a multi-agent scheduling system should tackle when the legacy systems and
component-based approaches are considered. Perspectives from different natures of information
sources to the scheduling system are taken into account, namely the information that come from the
supply chain and from the internal / heterogeneous planning and shop floor supervision systems. The
utilization of standards for inter-tools communication, information exchange and information
modeling ascends in significance within this context. They are seen as a base for an agile and lean
reaction of the enterprise both in its normal operation and in the presence of unexpected events. The
framework and the system prototype developed – called HOLOS – comprise what can be called as an
“interoperation among standards”, and it is discussed and illustrated with some examples.
Keywords: Multiagent Systems; Integration; Communication Standards; Scheduling Systems.
Reference to this article should be made as follows: Rabelo, R. J. (2000) „Interoperating Standards in
Multiagent Agile Manufacturing Scheduling Systems‟, Int. J. of Computer Applications in
Technology, Vol. xx, No. y, pp. ww-zz.
1 INTRODUCTION The utilization of standards for inter-tools communication,
information exchange and information modeling ascends in
The current scenario of industrial environment can be significance within this context. They are seen as a base for
basically characterized by an effort to produce an ever an agile and lean reaction of the enterprise both in its
increasing variety of products, in lower quantities, with normal operation and in the presence of unexpected events.
higher quality, lower costs and within shorter production This paper is organized as follows: Chapter 2 points out
times. From the external point of view, industries are the need for integration, Chapter 3 summarizes the
exposed to a very competitive, demanding and global multiagent technology, Chapter 4 gives a general view
market. From the internal point of view, industries have to about the HOLOS framework / scheduling system, Chapter
efficiently accommodate both changes in the external world 5 presents some examples on how a diversity of protocols
and disturbances in their shop floors. One of the can be integrated into a common manufacturing
contributions to face that dynamic reality is to provide the environment, Chapter 6 presents some aspects on
industries with agile manufacturing scheduling systems. information modeling, and Chapter 7 presents some
Agility is an emergent requirement for advanced conclusions.
manufacturing scheduling systems. Scheduling is generally
defined as the activity of assigning orders to manufacturing
resources during a certain period of time. An agile 2 THE NEED FOR INTEGRATION
scheduling system is one that supports [1]:
Dynamic scheduling: reaction and dynamic adaptation Regarding the current scenario of globalization of the
of the current schedule in the presence of unexpected economies, the companies have been facing tough
events, both from the shop floor (like machine failure, challenges to increase their efficiency and hence to keep
tool unavailability and operation lateness) and from the competitive. The need to face the new market values -
planning level (like changes in order priority and orders namely the rapid response time to the customers, the
cancellation), and; shortening of the products‟ life cycle and the seek for lower
Agile adaptation: flexible adaptation of the whole production costs and better quality and services - has been
production structure to the given order‟s requirements. demanding a deep reorganization and re-engineering in the
Agility is related to flexibility in terms of the internal companies. In practical terms, these actions aim to provide
routing and virtual production areas. the companies with the agility to react and to adapt
themselves in a coordinated, fast and flexible way,
according to the characteristics of two sources of input:
external: the requests and requirements come from the control, production management and information
market / customers; management [8].
internal: the unexpected events come from the shop With the increasing of software solutions, technologies
floor or other sectors. and hardware particularities, the industrial environment has
become too heterogeneous. Supporting the integration of
In fact, the concept of agile manufacturing impacts a existing systems considering this heterogeneity in an
company in a wide variety of aspects, such as costs efficient way is also too complex and it involves the aspect
production, lead time, environmental cares, stock levels and of interoperation among systems. The CIM-OSA project
cooperation level with the suppliers. [9] identifies three levels at which interoperation occurs
Several technologies, philosophies and paradigms have (which can be viewed as corresponding to three classes of
been developed and are being used by the enterprises to interoperation) within an enterprise. This view separates
support the concept of agility. Nowadays most of them take low level mechanisms required to realize interoperation
the CIM (Computer Integrated Manufacturing) philosophy (i.e. in physical runtime systems) from progressive abstract
as the base for their essential functioning. The intrinsic idea means of achieving interoperation between applications and
of CIM assumes that the main obstacle for the enterprises business processes. Characteristics of these differing types
to reach a more efficient way of working is focused on the of interoperation, as defined by CIM-OSA are [10]:
lack of integration among their departments / activities / Physical Systems: the key characteristic of this type of
tools. CIM is then based on the use of the information integration is in its ability to provide mechanisms for
technology as the way to carry out such integration. the interchange of information between the so-named
Therefore, the use of the CIM philosophy by the enterprises "islands of automation”.
is directly related to information integration. The Application: the concentration is on providing an
importance of this kind of integration is related to the fact infrastructure that permits the control and integration
that it provides the base for the reaction and hence for the of system wide information regardless of where the
enterprise agility, in the sense that: data reside.
the information from the shop floor can be constantly Business: the concentration here is on the integration
collected, allowing the company to make operational, of those functions that manage, control and monitor
tactile and strategic decisions based on reliable and business processes (BP). It includes the BPs that are
updated information; carried out by the suppliers, then creating a virtual
existing isolated subsystems and individual environment where distributed business processes
manufacturing resources can have their cooperation arise [11].
with the other systems supported or increased.
Much of the previous standardization activities have been
CIM Information Systems (CIM-IS) have been gradually made at the physical systems and application interoperation
adopted by the enterprises as the logical repository of levels but there is an increasing activity in the area of
integrated information from their activities, using some business interoperation standardization. An interoperation
already stable supporting technologies, such as databases within a virtual enterprise, for instance, can be expected to
(centralized or distributed/federated) and Web-servers. occur at all three levels but generally should be peer-to-peer
Considerable research effort has been put on information- in nature, as problems may occur when entities from
based integration by several international projects and by differing levels are integrated [12]. The work presented in
other initiatives. Some examples are CIMPLATO [2], this paper describes an integrated approach for a multiagent
CIMTOFI [3], CIMFACE [4], PEER [5], PRODNET-II scheduling system whose implementation goes in the
[6], and MASSYVE [7]. Efficient CIM Information System direction of those three interoperation levels, showing how
provides the enterprise activities with the capability to manufacturing resources (CNC machines, robots, etc.) can
access the right information, at the right time, at the right interoperate and can be integrated and supervised by both
place, in the right way and in an inter-operable format, intra and inter-organizational higher-level systems.
which are crucial enabling aspects to support the enterprise
agility and rapid decision-making.
However, in spite of the relative popularity of the CIM 3 THE MULTIAGENT TECHNOLOGY
idea and of its potentialities during the 80s, quite a few
enterprises could really apply it or even got the expected The Multiagent System (MAS) paradigm represents one of
results. First because it is a complex, very hard and usually the most promising approaches to build complex and
long task to be pursued, often provoking the need for a flexible advanced intelligent systems. The application of a
complete reorganization of the enterprise. Second because MAS approach in agile scheduling is based on the idea that
it demands advanced information technology in several the scheduling agility can be extremely improved once it is
areas, requiring specialized people to implant it. And third based on the following key points: i) distributed and
because it normally costs a lot. In order to deal with these autonomous systems instead of the centralized and non-
problems, the enterprises have rather been doing the autonomous solutions; ii) negotiation-based decision
integration in a gradual way, starting with the integration of making instead of the totally pre-planned processes; iii) use
isolated manufacturing cells towards a wide factory of different problem-solvers in the same environment
automation level, integrating the shops and global quality
instead of only one fixed problem solver; and iv) Each agent has its graphical user interface, giving to the
concurrent execution instead of the sequential processing user the possibility to both supervise the system and to
[13]. In summary, a multiagent scheduling system is intervene in some situations. In the case of the
composed of a set of “processors” (software nodes in a manufacturing resources agents, they are linked to the
network of manufacturing resources), each one with its own physical resources they are associated to. For instance, a
particular capabilities (typically heterogeneous), that have particular resource-agent (identified as “Robot_Scara”) can
to exchange and process information in order to contribute establish a communication with the corresponding physical
to finding a solution to the global scheduling problem. entity existing in the shop floor. The communication with
In spite of the lack of a common definition in the the CIM-IS is made using a subset of the STEP/SDAI
literature, a processor is considered as an agent when it (STEP Data Access Interface) protocol [17]. The inter-
possesses at least the following three essential properties: i) agent communication is supported by a specific high-level
a certain degree of autonomy to reason about and to make negotiation protocol [18]. The communication between the
decisions by itself; ii) the capability to interact with other resource-agents and the manufacturing resources uses a
agents; and iii) the knowledge to solve a part of the global subset of the MAP/MMS (Manufacturing Message
problem independently. An agent can play several roles and Specification) protocol [19], supported by a wrapper [20].
behave in many different ways when it shows these More details on how this comprehensive integration is
elementary properties. One role it can play is to act made as well as how it deals with other information sources
cooperatively, that is the essential HOLOS agents‟ are explained in the next chapter.
behavior, instead of acting destructively or selfishly.
Cooperative scheduling ascends in significance in the
complex manufacturing environments, while it is usually
highly constrained. This means that a feasible and robust
multiagent scheduling can only be generated and executed
with the dynamic, flexible and intelligent relaxation of the
constraints within the distributed agents, i.e. with real
cooperation. The more efficient this cooperation process is,
the more efficient the agile reaction of the entire production
structure will be, and hence a better information quality is
provided to support a rapid decision-making. However,
when the manufacturing process is extended towards a VE
environment, for instance, this cooperative assumption
cannot be necessarily guaranteed. Figure 1 A HOLOS multi-agent scheduling system.
4.1 Negotiation in Scheduling
4 THE HOLOS SYSTEM
Several problems can arise during the schedule generation,
HOLOS is a framework specially developed to derive after its generation, and during its execution, such as the
“instances” of agile scheduling systems [1]. A particular temporal, capacity, or technologic conflicts. These
HOLOS scheduling system is represented by agroup of problems come from the planning, scheduling or execution
agents configured for a target shop floor and that process supervision activities. There are several methods that can
and exchange information about production orders in order be applied for the conflict resolution in a multiagent
to generate, execute and supervise a schedule. In this system. HOLOS uses the Contract-Net Protocol
framework an instance of a scheduling system is coordination mechanism [21] to support the task
interactively and semi-automatically derived using the assignment among the agents, and the Negotiation [22]
MASSYVE Kit tool [14] and based on a reference model – method to overcome conflicts occurred during one of the
The HOLOS Generic Architecture [15] – supported by a three above mentioned scheduling phases. Figure 2
specific agent-oriented methodology – the HOLOS illustrates how the negotiation approach is used in HOLOS.
Methodology [16]. Figure 1 illustrates a global view of a Notice that the main function of a scheduling system is to
particular HOLOS multi-agent scheduling scenario. The assign tasks (production orders) to production resources
scheduling system is viewed as an application that receives (robots, CNC machines, workers, etc.) during certain
/ feeds data from / to a CIM Information System (CIM-IS), periods of time. The manufacturing resources are
receiving / providing information from / to other represented by agents. Thus, the procedure is to (i)
applications. announce a task (an object representing one process plan
Differently from classical systems, HOLOS is not a operation) through the MAS network and then making the
unique and comprehensive system, but rather a collection agents exchange information about it with the other agents
of distributed processes with some autonomy, so that (ii) one of them is selected to perform such task at
independence and communication capabilities: the agents. the end of this process [20]. Therefore, a schedule is
A HOLOS system is constituted by a set of instances of the generated and supervised via a cooperative and tight
HOLOS agents‟ classes. coordinated information exchange among agents, supported
by the HOLOS high-level negotiation protocol.
Figure 2 Negotiation in scheduling.
supervision pursued. During its execution the user can
The information flow among the several CIM activities interact with it, both to evaluate the schedule quality and to
should also respect the integrated framework, where the intervene in the case of abnormal deviations. In the case of
scheduling activity is not seen as an isolated activity, but abnormal situations, a Consortium has autonomy to try to
rather one with a stronger interaction with the other solve the problem locally, including the replacement of a
activities, mainly with the (several levels of) planning and failure resource-agent. In a given production plan, once the
the execution supervision. Therefore, the communication BP is executed (i.e. a part / its operations is produced, for
semantics / type of protocol should be accomplished instance) the respective Consortium dismantles itself after
according to the level of responsibilities of each of these generating some log information for auditing purposes. A
activities, i.e. the recognition of the set of conflicts and Consortium can comprise both intra-organizational
events that can occur - and that should be solved - in their resource-agents and inter-organizational ones.
scope of actions. A framework for agile scheduling that
comprises the definition of the CIM activities boundaries is
presented in [23]. This framework aims at supporting the 5 LEVELS OF INTEGRATION
(cooperative) autonomy and local / decentralized
supervision, two key features in intelligent manufacturing Five integration levels are usually necessary to be
systems. considered to integrate a multiagent scheduling system
One of the most important classes of agents in HOLOS within a complex/real industrial scenario: between the
is the Consortium. A Consortium represents a temporary agents and the information systems; between the agents and
agent created to supervise a virtual cluster of resource- other “traditional” systems; among the agents; between the
agents dynamically selected (via negotiation) to execute a agents and the user; and between the agents and the
given intra-organizational Business Process (BP). There manufacturing resources. This highly heterogeneous
will be as many consortia as planned BPs to be scheduled scenario is illustrated in the figure 4, and demonstrates the
(Figure 2). need for an approach that supports an interoperation among
(standard) communication protocols at the application level.
end-product
part production plan
User part’s operations
Consortium
s
nt
ge distributed schedule
e-A
rc
ou
R es
or
flo
op
Sh
Figure 3 The Consortium concept.
In HOLOS, there is no unique global schedule, but
rather a collection of distributed and inter-related
“local”/distributed schedules, each one associated to one
Figure 4 Integration levels of an industrial multi-agent
Consortium/BP. Therefore, the Consortium concept is
system.
viewed as the main enabler for the local and decentralized
5.1 Agents Information Systems 5.2.1 Agents Traditional systems
This level aims at allowing an agent to exchange
This level aims at allowing an agent to have access to information with other non-multi-agent system application
existing information systems. It is assumed that an (“traditional” systems). There are two approaches that
information system is the one which stores (some of) the could be used here. The first one – and that was the applied
information required by a certain agent, and that its in this work – is to consider that every application should
information models are accessed under a client-server feed the CIM-IS with relevant information for further
philosophy. High-level, dedicated or basic protocols can be access by the other applications. The second approach is
used, which also depends on the technology used in the that an agent has to know which are the “exportable
information system implementation (such as database or services” that a given application puts available and how it
web-server, for instance). can communicate with them, including the messages‟
The information system‟s “exportable services” should format and their semantics. From the application side, it
then be “linked” to the agent‟s code so that it can call them should be prepared to receive request messages about some
when necessary. This call can be made via DLLs (Dynamic specific information, which requires sometimes the need
Link Library) at one level, for instance, and via sockets, for a “re-engineering” of the application‟s interface. In this
RPCs (Remote Procedure Calls), CORBA (Common case, an agent can interact with another application via
Object Request Broker Architecture) [24] or HTTP (Hyper DLLs or even CORBA, for instance.
Text Transfer Protocol) at the other level, for instance. This
“link” depends on the characteristics of the services‟ API
5.2.2 Agents Multi-agent systems
(Application Program Interface). In order to leave the agent
This level aims at allowing an agent to exchange
leaner only the actually required services should be
information with other multi-agent system applications.
incorporated into the agent.
The same considerations from the previous type are also
In the HOLOS system [1], a centralized information
valid to this one. However, due to the last developments in
system was originally utilized, and a client-server SDAI
the multi-agent field, more advanced and “standard”
(STEP Data Access Interface) high-level protocol was
protocols to support the communication between two
implemented as illustrated in the figure 5. Other works
multi-agent (or blackboard-based) systems have been used.
using distributed/federated database (one per agent) and
The KIF (Knowledge Interchange Format) [26]
web-server (http protocol) can be found in [7] and [25],
initiative was one of the first attempt to cope with the
respectively.
systems heterogeneity in terms of knowledge exchange. By
means of a known format, two systems can exchange
information and knowledge via a “standard”.
The more recent initiative is KQML (Knowledge Query
Manipulation Language) [27], which is becoming the “de
facto standard” for multi-agent applications (or any
cooperative intelligent system). It is a very generic protocol
that can be “instantiated” for a specific application /
domain, when particular syntaxes, contexts and languages
can be defined / used (such as KIF, for instance), which in
turn are “encapsulated” by KQML performatives:
information entities that defines the permissible operations
that agents may attempt on each other's knowledge and
goal stores.
5.3 Agent Agent
Figure 5 Integration HOLOS agents and a SDAI server.
This level aims at allowing an agent to exchange
information with the other agents from the same
5.2 Agents Other Systems system/community. The same considerations applied to the
previous case are also valid here and KQML is one of the
This level aims at allowing an agent to directly exchange most common approaches. However, in this case, another
information with other system applications. This approach approach is widely utilized as well, which is the
is usually applied when the enterprise does not have an development of particular protocols to support the required
information system or even does not have some communication. The main advantage of this approach is its
information from that application stored/available in a normal lightness if compared with the KQML “weight”.
database. The main point here is that the agents should spend more
time reasoning about the information come via a message
than with communication and/or message content
decodification. Examples of specific protocols can be found
in [28] [29] and [1]. Its main drawback is that it does not should be hidden to the non-agentified agents. An agent
benefit from using a standard, hence allowing the should “simply” see the other agents as “services
proliferation of different protocols when the system needs providers”, independently of how they perform the services.
to exchange information with other multi-agent systems.
Therefore, this approach seems to be more adequate for
closed-world systems, which is the case of the HOLOS
protocol / scheduling system. The HOLOS protocol has 26
messages and comprises all the necessary interactions
among the HOLOS agents in the contract-net framework
[18]. It was implemented with sockets, under the TCP/IP
philosophy.
5.4 Agents End-user
This level aims at providing the user to interact with an
agent and vice-versa. It is useful especially in non- Figure 6 Agentification process.
autonomous multiagent systems, whether the agent needs
do get some complementary information from a user in In fact, this general integration / agentification should
order to accomplish a given task. By the side, it is also be made, in fact, through three layers: between the local
useful to allow some user intervention in the system in the controller and the manufacturing resource; between the
case he/she detects some deviation and/or bad quality in the manufacturing resource and the server; and between the
current results. Considering the advances in the current server and the agent itself. In other words, the main issue of
programming environments, this level is implemented via this multi-layered integration approach is to provide an
graphical interfaces, usually using the same language than agent with a so-called front-end [9] with a manufacturing
the one utilized to implement the agent itself, like C++ and resource. Figure 7 illustrates these three integration layers,
Java. The system designer should foresee special with four possible situations in terms of architectures to
mechanisms to avoid the possibility that the entire support them. In the first case, each manufacturing resource
multiagent system gets crashed due to a crash in the (an “equipment”) has its local PLC/controller (layer 3),
interaction with one individual agent and its interface. which in turn is virtualized by a respective server (layer 2).
In the second case, each manufacturing resource has its
PLC, but all of them (or some clusters of) are virtualized by
5.5 Agents Manufacturing Resources one server. In the third case, the manufacturing resources
are virtualized by their respective servers. Nevertheless, one
This level aims at allowing manufacturing resources to be PLC (or groups) centralizes the connection with them. In
represented into a multi-agent community, i.e. that its the fourth case, the manufacturing resources (or groups) are
services can be invoked from an agent / higher-level connected to just one PLC, which in turn is virtualized by
application “directly”. This level of integration is especially one server as well. The basic restrictions for those four
suitable for real-time applications. This is one of the more architectures can be of three types: number of input and
complex integration levels to be accomplished, as the output channels of the PLCs; complexity of the PLCs
hardest perspective of the heterogeneity in the industrial programming; and response and execution time. In the
equipments is concentrated at this level. integration layer 1, an agent can be linked to just one server
One of the most representatives approaches for dealing (case a), to groups of servers (cases b or c) or, eventually,
with this complexity is the “agentification”. Agentification with one that covers all the servers (cases b or d). Of
aims to “recover” the manufacturing resources as they are, course, hybrid situations can exist in a shop floor.
and to “transparently” integrate them into a global
architecture, i.e. into a multi-agent community. The 5.5.1 Local controller Manufacturing Resource
integration is provided by means of their virtualization,
This layer means to connect/control a given manufacturing
with more abstract and intelligent control software layers
resource(s) (or group of) (such as a CNC machine, a robot
[28] [20] [30] [31]. This virtual “encapsulation” process is
or a sensor) to a local controller (a Programmable Logical
normally called as wrapping. Figure 6 illustrates the
Controller - PLC, or other local controller). This layer is
wrapper developed for the HOLOS scheduler.
illustrated as the layer 3 in the figure 7.
The agentification process usually involves two steps:
Although this connection / PLC programming is usually
- building an adapting layer around the existing
made when the equipment is bought and installed, it does
controllers in order to transform them into normalized
not happen in more complex facilities where a group of
servers, and;
sensor, meters, etc., should be also integrated in the local
- building an agent manager, i.e. a high level “mirror”
controller. Besides that, it should be considered that the
of the resource‟s functionalities.
PLC‟ program may be altered when a given manufacturing
It is important to note that, from the multi-agent system resource‟s functionality is altered, added or extracted. In
design point of view, the agentified part of the agents resume, it could be said that, at a lower level, a PLC
“virtualizes” the services of one or of a group of been considered as the most representative standard
manufacturing resources. At this level, Fieldbus [32] has protocol.
Figure 7 Integration Layers.
enterprise that has many manufacturing resources to be
5.5.2 Local controller Server integrated. To face this problem, some initiatives, like the
MMS, have tried to establish a common and uniform
This layer means to virtualize the functionalities of a (group “chain” to provide a high-level application to “directly”
of) PLC / local controller in a higher-level, making them exchange information with a manufacturing resource by
available to a Server. It is illustrated as the layer 2 in the means of a standard protocol.
figure 7. Thus, these services can be accessed by any The problem is, however, that the legacy systems keep
external application (like an agent), without knowing the running with their own proprietary solutions / software /
particular characteristics and PLC‟s “low level” protocols. hardware, i.e. they were not designed to work under the
By virtualizing them it is possible to integrate and to MMS‟s philosophy. In order to overcome this problem, the
homogenize the existing / heterogeneous local controllers, MMS model conceived a kind of intermediate interlocutor
facilitating their access by a higher-level application called “Virtual Manufacturing Device” (VMD). Thus, a
tremendously. VMD virtualizes a given manufacturing resource‟s
Depending on the topology, functionality and type of a controller functionalities, and hence they act as the
given group of manufacturing resources, a unique PLC can “representatives” of the controllers for the client
control more than one resource. This means that the Server applications. The client applications need, in turn, to have
should also include the services of the group (cases c and the MMS protocol to communicate with the VMDs, i.e.
d). It is interesting to note that this last situation comprises they need to have a “MMS Interface” (MMSI). Considering
the one represented by a PC that supervises a cell or FMS, the general approach shown in figure 6, figure 8 illustrates
i.e. a local supervisor can be designed so that another the same scenario using the MMS.
application can have access to the services it puts available.
Agent Agent
5.5.3 Server Agent Client Knowledge
This layer means to allow an agent (i.e. an external MMS
MMS
application) to have access to the server‟s services, services
Interface
independently of the manufacturing resources it virtualizes. VMD
It corresponds to the more abstract level of the
agentification process, with the agent “encapsulating” an (subset of) MMS
Manufacturing
services
existing server. Resource
Server
The client-server philosophy should also be applied in Controller
this case. The communication between an agent and its Functionalities
server(s) can be supported by the MMS (Manufacturing
Message Specification) standard communication protocol
Figure 8 Agentification using the MMS Protocol.
[19] at the application level, for example. At a lower level,
it can be supported by RPC or sockets, for instance, with
A main drawback of MMS is that it was not designed to
UDP/IP or TCP/IP, depending on the characteristics of the
work with the de facto standard, which is the TCP/IP, even
current (or planned) server implementation.
considering that the TCP/IP does not have a good
Analyzing the three general integration levels described
performance in real-time applications. In the HOLOS
above, one can note that one level works as a “bridge” for
system, a practical MMS implementation was carried out,
the next level. From another perspective, that each server
which follows the general approach illustrated in figure 9.
represents a (different) interface with which an agent, at
From the legacy system point of view, another problem had
last, should use to communicate with a given
to be faced. In fact, there was already some basic level of
manufacturing resource. This can be a hard task for an
virtualization of the manufacturing resources before the
development of the multi-agent system. Thus, the agents implemented) MMS services and the existing server‟s
had to communicate with (existing) servers, but not with services. Figure 8 illustrates the implementation model
MMS servers as it would ideally desired. In order to used, picking the case of the “mm_AEActivation” MMS
overcome this problem, a kind of “meta-server” was service, designed to turn on a manufacturing resource. To
developed, acting as an intermediate process between the do that in the very specific manufacturing resource‟s server,
agents themselves (i.e. their MMS interfaces) and the two of its legacy services (procedures) should be called to
heterogeneous servers. A VMD module, instead of execute the required MMS service: “initiate” and “start”.
“implementing” the manufacturing resource‟s
functionalities, offers a mapping between a (subset of the
Figure 9 Example of implementation model of a MMS server.
manufacturing resources). Results from some international
The heterogeneity of the systems a given (multi)agent research projects have been taken into account in the
has to communicate with implies the use of different information models design, such as CIMPLATO [2],
protocols and communication levels. In this sense, the FLEXPLAN [33], IMPPACT [34] e STEP [35]. Some
architecture of a multi-agent system should allow that all additional information was aggregated to some models in
the necessary protocols “live” together in the same order to support the negotiation process among the agents.
integration environment. Even so, more than this, the In the HOLOS framework the information models are
communication should use, as much as possible, designed under three perspectives: the enterprise structure,
international standards, i.e. support an interoperation the “dynamic” behavior of the enterprise and the
between standards. information models themselves. Concerned to the first
perspective, an enterprise in modeled in a hierarchical /
multilevel way, seeing it as a holding that has, at last,
6 INFORMATION MODELING several shop-floors and then physical equipments, with
some functional / virtual views applied on them. The
Information modeling is one of the key points to support an second perspective is responsible to model the
effective agility of the scheduling system. The enterprise manufacturing orders themselves. For that, the CIM-OSA‟s
should be modeled in an adequate way so that its concepts of business processes, enterprise activities (and
production structure can react in time and with reliable their four classes of implemented functional operations)
information both to normal business processes and to face and procedural rule sets have been used. However,
unexpected problems. The use of some standards or considering the objective of this paper, the emphasis will be
information reference models facilitates enormously the put on the third perspective only.
information exchange among the CIM activities within an There are a lot of information models used in the
enterprise (and among enterprises) as mappings and HOLOS framework, namely the models of client orders,
analysis of different semantics are not necessary. industrial orders, product, part, assembly, inventory,
As already explained in the section 5.1, this work uses a process plan, shop packet and manufacturing resources, all
CIM-IS when “all” applications get / put (potentially of them stored in the CIM-IS. Figure 10 shows a partial
complete, shareable and updated) information from / in it. view of an “instance of” a (manufacturing) resource-agent
This means that the HOLOS multiagent scheduler assumes called work-center Sony, which comprehends (real) six
that most of the required information come from the CIM- workstations, such as the robot Scara Sony. In fact, a
IS and some come from the resource-agents (linked to the manufacturing taxonomy had to be conceived [1], hence a
resource-agent‟s model is basically composed of two main is associated to one (physical) work-center, which in turn
“entities”: workstations (representing individual can involve one or several workstations.
manufacturing equipments) and work-centers (representing
a set of workstations). In other words, each resource-agent
wc_Sony wc_Sony_services wc_Sony_planning
is_work_center_of dee_assembly_cell contains_services_of wc_Sony plan_view_of wc_Sony
work_center_id wc_Sony path 'x/x/x/x/physical_cell.h' setup_cost_rate 1
has_work_stations [ scara_Sony, host_name 'spica.uninova.pt' availability yes
feeder1_Sony, host_IP '172.16.18.1' …
feeder2_Sony, services [ init_cell, manufacturing_cost_rate 2
fixture_Sony, robot_set_speed, planned_utilization 1
worker_9, robot_move, efficiency_factor 1
pc_Scara_Sony ] robot_open_gripper, planned_lead_time 2
work_center_description 'Work Center Sony' robot_close_gripper, wp_weight_max 20
has_planning_view wc_Sony_planning robot_attach_tool, x_wp_dim_max 0.8
mms_services wc_Sony_services robot_release_tool, x_wp_dim_min 0.15
feeder_feed_part ] y_wp_dim_max 1.5
…
scara_Sony
is_ws_of wc_Sony
ws_id scara_Sony scara_Sony_topology
type scara is_topol_view_of scara_Sony
sub_class programmable essenciality yes
class assembly hierarchy main
super_class assembly layout_position [5,4]
behavior active_resource main_resource_id nil
has_techno_view scara_Sony_technological precedence_order 0
has_capab_view scara_Sony_capability
has_topol_view scara_Sony_topology
scara_Sony_technological
is_techno_view_of scara_Sony scara_Sony_capability
control_name sony is_capab_view_of scara_Sony
dof 5 applic 'mov low vol'
ngrippers 3 disad 'relat. slow'
gripping_system automatic space_required 3
gripper programmab space_unit cb_mt
wp_weight_max [15,kg] processes assembly
feed [1500,0,mm] prod_rate 250
tolerance 0.001 prod_rate_unit hour
x_wp_dim [300,0] rel_equip_cost medium
y_wp_dim_max [200,0] size_workpiece 1000
z_wp_dim_max [1,0] size_wp_unit lbs
zero_position [0,212]
dim_unit mm
Figure 10 Example of an agent-resource model.
by putting in place fast track development or by
defining fairly rigid timeframes;
7 CONCLUSIONS - Change process: upward compatibility is a problem, as
the standards process does not ensure that it gets it
This work presented a wider and integrated approach for right first time;
integrating different communication protocols – standards - Emerging requirements: often new requirements
and de facto – so that they can live in the same industrial emerge during the process and to accommodate them
environment in a real multiagent agile scheduling system. would put back the expected date.
One of the most important aspects covered in this work
is related to the legacy systems, i.e. how they can be Some other limitations are:
incorporated into advanced automation architectures. The - Lack of an overall picture: each of the standardization
legacy systems comprised in this work involve information makers usually works alone. They may appoint liaisons
systems, manufacturing resources, among others. to other groups but in most cases that is the extent of
Regarding the several ongoing initiatives of standards, the liaison;
some evaluations found in the literature and thr results - Uncontrolled growth: the majority of the
obtained in this work, it can be said that there are some standardization makers have a reference model to base
limitations yet to be overcome, from different natures: their development work on. Unfortunately as work
- Time to market: in general, the standardization process continues and the number of standards in the domain
takes a number of years to complete, by which time the increase, the reference model is not usually the right
relevance to the market place has diminished. Most of way to manage the growth;
the standards-making consortia have responded to this
- Technological advancement: most of the 2 Bernhard, R., editor - CIM Systems Planning Toolbox -
standardization makers would state they are Project Survey and Demonstration, Proceedings of
technologically independent. Unfortunately with the CIMPLATO Workshop on CIM Planning Tools, Karlsruhe
advancement of technology, standards can become University, Germany, pp.45-56, 1992.
3 Gonçalves, R.; Barata, M.; Vital, Miguel, Sousa, P., Gartion,
outdated before they get implemented due to paradigm A.S. - Manufacturing Information System Integration: A
shifts. Proposal using SIP, Symposium on Advanced Product Data
Management Supporting Product Life Cycle Activities,
According to [12] what is required is an overall picture that American Society of Mechanical Engineering (ASME),
allows the positioning of enterprise related standards. Atlanta, EUA, 1996.
Whilst some examples of classification try to demonstrate 4 Osorio , A. ; Camarinha-Matos, L.M. - Information based
the overall picture, still more is required. One important control architecture for CIM, Proceedings IFIP Conference
initiative in that direction is GERAM (the Generic Towards World Class Manufacturing, Phoenix, USA, 1993.
Enterprise Reference Architecture and Methodology), 5 Afsarmanesh, H.; Wiedijk, M.; Hertzberger, L. - Flexible and
Dynamic Integration of Multiple Information Bases,
which takes the results of other reference works into Proceedings 5th IEEE International Conference on Database
account (CIM-OSA, PERA and GRAI-GIM). It is proposed and Expert Systems Applications DEXA'94, Springer-
that GERAM be used as a starting point but that emphasis Verlag, pp.744-753, 1994.
is shifted away from enterprise modeling to more definitive 6 Afsarmanesh, H.; Garita, C.; Ugur, Y.; Frenkel, A.;
identification of the other parts of the overall picture. This Hertzberger, L. – Federated Information Managemrnt
will help to coordinate individual standardization efforts, Requirements for Virtual Enterprises, in Infrastructuers for
leading to reusable components and common infra- Virtual Enteprises – Networking Industrial Enteprises, Eds.
structural elements which support rapid and effective Luis M. Camarinha-Matos and Hamideh Afsarmanesh,
interoperation in the levels of business integration, Kluwer Academic Publishers, pp.31-48, 1999.
7 Rabelo, R. J.; Afsarmanesh, H.; Camarinha-Matos, L. M.,
application integration and physical systems integration Applying Federated Databases to Inter-Organizational
[36]. Multi-agent Scheduling, Proceedings IFAC MAS‟99 –
Considering the MAP and MMS protocols, for instance, International Workshop on Multi-Agent System in
they are considered too heavy to be implanted in full, as it Production, Vienna, 2-4 Dec 1999.
can be “proven” via the Mini-MAP and Micro-MMS 8 Verissimo, P.; Melro, S.; Casimiro, A.; Silva, L. –
“alternative” initiatives. Besides that, a very important Distributed Industrial Information Systems: Design and
aspect to be evaluated is the need of a very particular Experience, em Balanced Automation Systems II –
enterprise for a standard. In fact, in most cases they only Implementation challenges for anthropocentric
need a very small subset of the standard “services”. manufacturing, Eds. L.M. Camarinha-Matos and H.
Afsrmanesh, Chapman&Hall, pp. 175-190, 1996.
Therefore, when a standard is going to be implemented, it 9 AMICE - CIM-OSA : Open Systems Architecture for CIM.
is desirable to deeply analyses its actual needs firstly. More 2nd revised and extended version, Springer-Verlag, Berlin,
than that, due to the usual high cost and implantation time, 1993.
a trade-off analysis between the benefits and costs are 10 Santos, J.; Ferreira, J.; Mendonça, J. – Integrating
viewed as essential for the implantation success. Infrastructures for Manufacturing: a Comparative Analysis,
Another aspect about the standards, which reinforces em Re-engineering for Sustainable Industrial Production,
the previous statements about the lack of a global picture, is Eds. L.M. Camarinha-Matos, Chapman & Hall, pp.308-321,
that some standards are not compatible with others. For 1997.
instance, the MMS is not designed to work together with 11 Rabelo, R.J.; Camarinha-Matos, L.M. - Towards Agile
Scheduling in Extended Enterprise, em Balanced Automation
the de facto TCP/IP standard, which creates a tremendous Systems II - Implementation Challenges for Anthropocentric
problem if a global standardized solution is to be implanted Manufacturing, Eds. Luis M. Camarinha-Matos e Hamideh
[37]. Afsarmanesh, Chapman & Hall, pp. 413-422, 1996.
12 Clements, P. - Standards support for the virtual enterprise,
http://www.mel.nist.gov/workshop/iceimt97/pap-
cle2/stdspt2.htm.
ACKNOWLEDGEMENTS
13 Bond., A.; Gasser, L. - An Analysis of Problems and
Research in DAI, Readings in Distrib. Art. Intelligence, pp.3-
The author would like to thanks CNPq (The Brazilian
35, Morgan Kaufmann, 1988.
Council for Research and Scientific Development) for the 14 http://www.gsigma-grucon.ufsc.br/massyve/mkit.htm.
financial support of this work under the grant 380248/99-9. 15 Rabelo, R.J.; Camarinha-Matos, L.M. - A Holistic Control
Architecture Infrastructure for Dynamic Scheduling,
Artificial Intelligence in Reactive Scheduling, (eds. Roger
REFERENCES Kerr e Elizabeth Szelke), Chapman & Hall, pp.78-94, 1995.
16 Rabelo, R.J.; Camarinha-Matos, L.M. - Deriving Particular
Agile Scheduling Systems using the HOLOS Methodology,
1 Rabelo, R.J. - A Framework for the Development of em International Journal in Informatics and Control, Volume
Manufacturing Agile Scheduling Systems – A Multiagente 5 Número 2, pp.89-106, Junho 1996, Romênia.
Approach [in portuguese], Ph.D. Thesis, New Universidade 17 Fowler, J. - Proposal for the STEP Data Access Interface
of Lisbon, Portugal, 1997. Specification, STEP Implementation Specifications
Committee, NIST, Janeiro, 1992.
18 Dionisio, R. – The HOLOS Protocol: a proposal for agents and Design Methods, Eds. L.M. Camarinha-Matos and H.
communication in scheduling manufacturing systems, Tese Afsrmanesh, Chapman&Hall, pp.241-252, 1995.
de Mestrado, Universidade Nova de Lisboa, Portugal, 1997.
19 Mackiewicz, R. - An Overview to the Manufacturing
Message Specification, in http://litwww.epfl.ch/~mms, 1994.
20 Rabelo, R.J.; Camarinha-Matos, L.M. - Negotiation in BIOGRAPHICAL NOTES
Multiagente Based Dynamic Scheduling, International
Journal on Robotics and Computer Integrated Ricardo J. Rabelo took his Ph.D. in Robotics and
Manufacturing, Volume 11 N 4, pp.303-310, Pergamon, Computer Integrated Manufacturing at New University of
December 1994. Lisbon, Portugal, in 1997. He is coordinator of the
21 Davis, R. - The Contract Net Protocol: High-Level GSIGMA – Intelligent Manufacturing Systems Group, and
Communication and Control in a Distributed Problem currently teaches in the Department of Automation and
Solver, IEEE Transactions on Systems, Man, and Systems of the Federal University of Santa Catarina,
Cybernetics, 29, pp.1104-1113, 1980. Brazil. His main areas of current research include: virtual
22 Davis, R.; Smith, R. - Negotiation as a Metaphor for
enterprises, enterprise modeling, systems and information
Distributed Problem Solving, Artificial Intelligence, 20, pp.
63-109, 1983.
integration, multi-agent scheduling systems, shop-floor
23 Rabelo, R. J.; Camarinha-Matos, L. M.; Afsarmanesh, H.; supervision and decision support systems. He has
Generic Framework for Conflict Resolution in Negotiation- participated in several Brazilian projects and international
based Agile Scheduling Systems, Proceedings IFAC IMS‟98 projects with Europe (ECLA, CYTED, INCO, KIT,
– International Workshop on Intelligent manufacturing ESPRIT and IST Programmes). He is the Brazilian
System, Gramado, Brazil, 9-11 Nov 1998. representative in the IFIP WG 5.3 subgroup, consultant ad
24 http://www.acl.lanl.gov/CORBA. hoc of the CNPq and Capes Brazilian agencies and other
25 Keller, A. – Getting Data from a WWW Server, UFSC / governmental institutions, and has been involved in the
GSigma Technical Report, 1999.
organization and program committees of national and
26 Genesereth, M.; Singh, N. - A Knowledge Sharing Approach
to Software Interoperation, Technical Report RL-94-6, Logic
international conferences.
Group, Department of Computer Science, Stanford
Universidade, 1994.
27 Finin, T.; Frizson, R. - KQML - A Language and Protocol for
Knowledge and Information Exchange, Technical Report
CS-94-02, Computer Science Department, University of
Maryland.
28 Wittig, T. (editor) - ARCHON: An Architecture for Multi-
agent Systems, Ellis Horwood, 1992.
29 Ramos, C. - An Architecture and a Negotiation Protocol for
the Dynamic Scheduling of Manufacturing Systems,
Proceedings IEEE Conference on Robotics and Automation,
USA, pp.3161-3166, 1994.
30 Jennings, N. - Cooperation in Industrial Multi-Agent
Systems, World Scientific Series in Computer Science (Vol
43), 1994.
31 Adlemo, A.; Andréasson, S. - A Generic Control System for
Transparent Legacy System Migration, em Balanced
Automation Systems II - Implementation Challenges for
Anthropocentric Manufacturing, Eds. Luis M. Camarinha-
Matos and Hamideh Afsarmanesh, Chapman & Hall, pp.277-
288, 1996.
32 Pleineveux, P. - MicroMMS: A Compact Abstract Syntax for
MMS, ETFA„94, Tokio, 1994.
33 FLEXPLAN Deliverable - Esprit Project 2457, 1992.
34 Gielingh, W.; Suhm, A. (Eds.) - IMPPACT Reference Model:
An Approach to Integrated Product and Process Modelling
for Discrete Parts Manufacturing, Vol 1, Springer-Verlag,
Research Reports ESPRIT Project 2165, 1993.
35 Industrial Automation Systems - Product data Representation
and Exchange / ISO 10303 / Part 41: Fundamentals of
product description and support, International Organization
for Standardization, 1993.
36 Bernus, P.; Nemes, L. – Enterprise integration: engineering
tools for designing enterprises, em Modelling and
Methodologies for Enterprise Integration, Eds. P. Bernus and
L. Nemes, Chapman&Hall, pp.3-11, 1996.
37 Castori, P.; Pleinevaux, P.; Vijayananda, K.; Vamparys, F. –
Interoperabilidade testing in an implementation of ISO/OSI
Protocols, em Balanced Automation Systems – Architectures