manAge: an agent architecture for manufacturing control Tapio HEIKKILÄ VTT Automation, Machine Automation, PO Box 13023, FIN-90571, Oulu, Finland e-mail :
[email protected] Martin KOLLINGBAUM University of Cambridge, Department of Engineering, Institute for Manufacturing, Mill Lane, Cambridge, UK CB2 1RX e-mail :
[email protected] Paul VALCKENAERS Katholieke Universiteit Leuven, Department of Mechanical Engineering, Celestijnenlaan 300B , B-3001 Leuven, Belgium e-mail :
[email protected] Geert-Jan BLUEMINK VTT Automation, Machine Automation, PO Box 13023, FIN-90571, Oulu, Finland e-mail :
[email protected]
Abstract In this paper we introduce agent concepts to implement control algorithms and application architectures for flexible control in manufacturing. We list requirements for the implementation of the agent itself, assess existing concepts of agent architectures, and give a more detailed overview about the building blocks of an adequate agent system architecture by describing the “manAge” agent system implementation.
1. Introduction There is a variety of manufacturing control paradigms, which are investigating solutions for systems of high flexibility, from the point of view of operating the system (systems operation aspects) as well as maintaining the system structures and configurations (systems engineering aspects). According to Dilts et. al. (1990) flexibility is an essential property of systems, which follow the concept of distributed or partly distributed architectures. From this point of view it is understandable that agent technologies are adopted to design and implement flexible systems in manufacturing. Agents provide the structural and operational flexibility as a built-in property. In this paper we therefore describe a specific agent architecture, “manAge”, which provides generic specifications and structures for agents in manufacturing applications. As the “manAge” concept is intended to be used in real-world environments, we are considering reliability as an important aspect. For this we include persistent data management facilities into the agent architecture, which allows an agent to handle information and
knowledge in a persistent way. This should enable agent-based control applications to recover from fatal system failures. Guilfoyle and Warner (1994) list following properties, which comprise an agent architecture and must be tackled in a development process: • agent organisation (span of control, roles, chain of commands) • agent roles (different roles during problem solving, e.g. managers, workers, disputees) • agent coupling (balance between interacting and problem solving), e.g. loosely coupled (low interaction, high problem solving), tightly coupled (high interaction, low problem solving) • agent communication (organisation, common languages), e.g. low level protocols (send, receive), high level protocols (contract net, speech acts) • agent interaction (how effect to each others, change common environment), e.g. cooperation, competition, hostility • agent complexity/sophistication (problem solving ability), e.g. coarse grained (few, clever agents), fine grained (many simple
agents), cognitive (model of itself and others), non-cognitive (no internal model) We use agents in application environments, where agents have to control and (at least partly) plan their local operations, cope with uncertainty by reacting to unforeseen events (disturbances), and have to recover from such situations without disturbing global goals like throughput maximisation. Planning is here considered to cover all the calculations to prepare a control strategy before execution. We therefore add additional requirements for agent architectures to those above. We distinguish between requirements, which are related to the agent system and those, which are purely agent related. In terms of agent-system related requirements we identify following aspects: • different categories of agents, specialised in ways characteristic to the categories • knowledge or access to knowledge on types of agents and availability of them to the other agents • communication of manufacturing knowledge, e.g., product knowledge (BillOfMaterials) and production knowledge (process plan) • communication of process knowledge (resource eligibility, production plans/programs, etc.) between agents • communication of process execution knowledge between agents (goals, state & load level of resources, etc.) As agent-related aspects we list the following: • planning/decomposition of global goals (orders) to local goals (local orders) within the resources (accept changes) • management of local goals (orders), plans (production programs) and state information (load levels) • connection to physical equipment within resource agents • detect disturbances by observation of abnormalities on-line (accept external events or events from the physical resource) • manage the plan execution by receiving/accepting process execution events from other agents and equipment
2. Existing Concepts Architectures
of
Agent
In terms of agent architectures, our intention is to use potentials of existing approaches. Aspects of
“Agent-oriented Programming” (Shoham, 1993) (AGENT-0, ABS, JAFMAS), the BDI architecture (Belief/Desire/Intention) (Rao and Georgeff, 1995), the PEM concept (Planning, Execution, Monitoring) (Heikkilä and Röning 1992), (Rannanjärvi and Heikkilä 1998), and procedural knowledge representation, as described in PRS (Georgeff and Lansky, 1986) shape our development activities. Reviews of existing agent architectures and development environments like (Wooldridge and Jennings 1995, Nwana 1996) give an excellent overview about this technology. For our purpose an agent architecture must provide concepts and structures to support designing the agents in details. In general three types of agent architectures are identified: • Deliberative architectures: agents have explicit symbolic representations of the world, plans and goals, and use this information to decide upon their behaviour • Reactive architectures: those agents show perception-driven reactions, where events from the agents environment trigger specific behaviour • Hybrid architectures: a combination of both Reactive architectures can produce fast responses to incoming events. This is especially welcome to get a fast response to a disturbance situation in manufacturing environments. But it lacks reasoning capabilities to assess more accurate disturbance handling/recovery procedures that pursue production goals (like throughput maximisation) in a proactive way. Therefore deliberative aspects are welcome as well. We think that a hybrid approach will serve our needs best.
3. Distributed System Architectures for Implementations The design process of an agent-based manufacturing control system results in a set of manufacturing agents that provide the required behaviour with their own processing and their interactions. The implementation of such a system relies on the implementation of the agents themselves. For this purpose a specific “agent architecture” or “implementation architecture” must be provided, that enables the implementation of agents according to the requirements, which arise from the functional specifications of the manufacturing agents, and also general requirements arising from industrial control system environments themselves. In general, agent
applications need a kind of “host environment,” which provides execution and communication facilities for agents and enable the implementation of agent applications. In particular, we can distinguish between elements, which should be included in agent architectures, and general required properties of such environments. Agent architectures contain: • a general event communication mechanism from agent to agent (goals, execution events) • dynamic agent data structures like goals, plans, or execution events • beliefs to represent state information of an agent (local models) • operation specific methods/algorithms/ functions • communication protocols (covered by the state behaviour of the agents) The applicability and deployment of an agent application is affected by the availability and generality of the implementation tools (environments, languages, compilers, hardware). This leads us to following general requirements, which should be supported: • main stream compatible • distributed (e.g., local area network or fieldbus) • light-weight multi-threaded • (run-time) configurable, update-able • integrate-able within next generation PLC's • real-time abilities For the implementation activity itself we have to deal with processes, threads, inter-process communication (cf. TCP/IP sockets), inter-thread communication (cf. tables with synchronised read/write methods, tables with Java-events), protocols, events (Java events, signals, ...), classes, objects, attributes, methods, functions, associations, relationships, variables, data structures (arrays, vectors, hash tables...) etc. Aspects of robustness in the developed control applications are of specific importance. We therefore deal with aspects of persistent data management, transaction and recovery concepts on a per-agent basis. The design of agent architectures follows here the object-oriented methodology. The design and implementation models of the OO features (classes, associations) are based on mainstream languages, i.e. Java or C++. On the other hand, designing the implementation of the agent system (aggregate of
agents) distributed throughout computer networks can be approached in different ways. communication network(s)
communication interface
Resource1 Device1
Device2 Device3 application1
Resource2
Resource3
Device4 application a application b
application2 appl. c
appl.3
process
HW/SW impementation architecture: System model
process interface
HW/SW impementation architecture: Device model
Figure 1: The Architecture models of IEC1499 The IEC1499 standard (Diedrich and Neumann 1998) includes an architecture model for distributed applications in industrial environments. It is developed especially for PLC environments, and includes a graphical specification language called 'Function Blocks'. Within the IEC1499 system model, a distributed application is running on several devices (nodes in network), and in one or more resources (processes) in each device. Because IEC1499 is basically developed based on a functional design principle (Function Blocks), its support by object-oriented design is limited. However, as a general system model (Figure 1) it is a relevant model for our purpose. The UML (Unified Modelling Language) also supports architectural and design specifications (Douglas 1998). Deployment and system task models (diagrams) help to capture the architectural aspects in a distributed system. These are comparable to the entities in IEC1499 (node - vs. device; subsystem + package vs. resource).
4. manAge - Agent and Agent System Architecture The requirements for the agent system and internal agent architectures have a close match to BDI and PEM concepts. Both these are considered to be hybrid architectures, which in principle enable both deliberative and reactive task execution. We further specified an architecture called manAge (manufacturingAgents) for modeling agent systems and individual agents for manufacturing applications. For the development of manAge the PEM concept (Planning, Execution, Monitoring) was chosen as the basis. The agent system is a collection of different types of agents. The agents are conceptually in the same name space, but the acquaintance relations between the agents are restricted by the types of agents.
At the agent level, the manAge architecture represents a hybrid agent architecture. Agents are similar within their principal internal structure (PEM). Within that structure they share the general behavioural patterns, i.e. the external communication protocols are the same for all agent categories, as well as the internal organisation, which is based on four actors: operator, controller, executor and monitor. The specialisation of the agent categories is done by extending the set of operations of the agents. manufAgents
/* all agents have their references in a global storage */
/* acquintance to other type of agents: resource-to-product */ specialized AgentType1
specialized AgentType2
...
specialized AgentTypeN
/* acquintance to similar agents: resource-to-resource */
/* acquitance to other type of agents: order-to-resource */
All the active actors (controller, executor, monitor) of the agent architecture have their specific behaviours. A passive actor, the operator, is used for user interface, for example passing goal messages to other agents, or checking the status of the agent. The execution of a task is activated by receiving a goal message from another agent. That triggers a planning operation, which provides the necessary detailed information for executing a proper plan for the goal. The planner creates or acquires plans for actual task execution, but also a plan for monitoring. After the plans have been prepared, the executor and monitor actors start to execute their plans. After the plans have been executed, a reply message will be sent out to the requestor of the goal. An event scenario for executing the task and monitoring plans for a simple transportation task is illustrated in Figure 4. agent1.Operator
agent2.Controller
goal pickPose3
agent2.executor
agent2.driver
agent2.monitor
plan pickPose3 start pickPose3 start pickPose3 goto pose1 goto pose2
general Agent
giveTime giveTime time done goto pose1 done goto pose1
Figure 2. Agent System Architecture.
giveTime giveTime time done goto pose2
The control logic is represented by the plans of the agents, and the operations are comparable to commands or operations on the plans. The architecture is open in this aspect, because new capabilities for agent categories can easily be added (or old removed) by creating a corresponding operation, and adding it to the interpreter function within the executor of the specialised agent class. Additional behaviours, which are based on available sets of operations (sequencing of operations), can be introduced by creating new plans, either hard-coded in advance, completing plan skeletons on-line, or creating completely new plans on-line. /* driver objects are used to maintain data about physical resources of the agent */
driverType1
driverTypeN ...
agentGoal
specializedAgent
goalId
driver
agentMessage
specialized Executor
generalAgent goals plans currentPlanId plan send generalControlStateMachine
specialized Monitor
specializedOper_1 specializedOper_2 ... specializedOper_n
general Executor
watch check
agent Operator
general Monitor
currentPlan currentPlanStep
currentMonitoringPlan currentMonitoringPlanStep
executionStateMachine
monitoringStateMachine
Figure 3. General Agent Architecture (PEM)
done goto pose2 load done load goto pose3 done goto pose3 done all done pickPose3 done goal pickPose3
Figure 4. Event flow in a simple task execution. The agent controller takes care of communication of requested goals between the other agents while the executor and monitor take care of executing a task in details. Knowledge which is more static (process and product knowledge) are stored in global models, and more dynamic knowledge (orders) in local models. The details of the executor and monitor behaviour are determined by their plans. In the execution plans there can be also requests for goals from other agents. The general controller concerns the general behaviour: trigger the planner, create an executor and a monitor, and start execution of a plan. In addition, it is responsible for updating local model knowledge as notified by other agents (belief maintenance). The executor and the monitor consider the execution of the related plans. Currently the agents are behaving in a
straightforward manner by committing to all goals they can do. The plans are described with a specific plan language, the operations of which are special for each specialised agent category. From the point of view of control of flow, the control structures are implemented by the executor of the general agent class. There are some additional control keywords, which the executor and the monitor consider. With these the execution obeys different synchronisation principles. For the executor the control keywords are currently:
the planner algorithm, they can be completed within certain parts by the planner algorithm, or they can be created in advance by human operators and so implement a library of decomposition patterns. The monitoring is more general than the execution. The basic idea behind a separate monitoring module is to have flexible way to make focused monitoring effects depending on the requirements and properties of applications and tasks (the idea behind the PEM models). For the monitor the only control keyword to specify the control of flow in the monitoring plans is:
Synchronised: waits until the previous operation has been done, executes the current operation (with this keyword set), and waits until the current operation has been done before it executes the next operation signalToMonitor: specifies a message which is sent to the monitor when the current operation is started (synchronises the executor and the monitor) doBlockWhileEvent: executes a block of operations concurrently (block = following operations down to ’untilEvent’ keyword) untilEvent: specifies an ending condition for a while loop whenEvent: an event condition for an individual operation in a do-while block end: last plan operation
stepCondition:
Each specified agent class has its own plan language. For example, transportation resources have currently the following operations goto , load, unload An example of a task plan for a transportation task looks as follows: goto goto goto load
pose1 pose2 signalToMonitor done goto pose1 pose3 signalToMonitor done goto pose2 synchronized signalToMonitor done goto pose3 goto pose4 goto pose5 signalToMonitor done goto pose4 goto pose6 signalToMonitor done goto pose5 unload synchronized signalToMonitor done goto pose6 end signalToMonitor done unload
The executor actor executes the plans in a consistent way, i.e., following the synchronisation data of the task plan. It should be noted, that here we do not intend to have an elegant programming language but a feasible and executable plan description language. The plans can be created by
specifies an event, which must be received before the next plan operation is executed
Currently there are two operations for monitoring: watch: reads (sends a report request operation) periodically, and compares the read value to initial constraints (set by the planner) check: same as watch, but is done only once An example of a monitoring plan (comparable with the task plan above) looks as follows: check
giveTime 0 100 stepCondition goto pose1 check giveTime 0 200 stepCondition goto pose2 check giveTime 0 300 stepCondition goto pose3 noOperation stepCondition done load check giveTime 0 400 stepCondition goto pose4 check giveTime 0 500 stepCondition goto pose5 check giveTime 0 600 stepCondition goto pose6 noOperation stepCondition done unload
done done done done done done
The current implementation of the manAge control system is closer to reactive than deliberative approach, because it is using a simple look-up operation to acquire relevant plans to incoming goal events. However, deliberative behaviour is very easily introduced into the system by extending the look-up planner functions to deliberative ones.
5. manAge Implementation architecture Architecture manAge allows the distribution of agent applications over different nodes in a computer network. The proposed agent architecture follows the PEM (planner, executor, monitor) approach. On
each network node a software environment exists, Passing messages from one agent to another via the which incorporates these three architectural network and/or through the process borders is elements as “system actors.” The behaviour of implemented by general service routines for sending agents is driven by plans and goals, the agent and receiving messages between processes and architecture realised in manAge therefore provides dispatching message to agents inside the processes. means to execute plan procedures (procedural For all incoming messages the process creates an knowledge) according to goals. This environment own thread for a message handler, which makes it aggregates different types of agents virtually into possible to use only one general and single address one large cluster. for the agent (hostname & socket port; compares to To support distribution, a “shadow agent” Java RMI call). concept was implemented, where local agents on one computing node have “shadow” representations 6. manAge - Persistence on other nodes. From the point of view of implementation, the agents are classified into A successful implementation of agent based internal agents and external agents. The internal manufacturing control systems will eventually also agent class implements the general agent model, and rely on criteria, how reliable and robust such clusters all the agents instantiated in the same systems are, and how well and easy these systems process. An external agent holds address can be integrated into existing information information of all the other agents running in infrastructures of plants and companies. Persistence different processes. Internal agents and external and reliable data management is therefore raised as agents are maintained in separate name tables. In an important issue here. Agent applications are addition, agent categories are maintained by their distributed software systems, therefore concepts of names. distributed database systems are especially investigated. The goal is to integrate database system concepts directly into agent architectures, so that this technology becomes an integral part of agent architectures and agent execution environments. From the description of our agent environment we can see the “event-driven” nature of agent systems. We therefore also investigate concepts of active database systems and their appropriateness in agent technology. Reliability of data management in agent-based control systems means (among other aspects): • Nearly 100% up-times • Regulation of concurrent access to data • Robustness in case of a system crash Figure 5. Implementation architecture for an agent. • Recovery without data loss Within the internal modules, the agent runs one • Restart ability thread. It reads messages from the agent message queue and dispatches the messages to a In agent terms, we want an agent-oriented control corresponding actor state machine, by calling its system only to degrade in its capabilities and not to message handler (implements the state behaviour of get crashed entirely, if one agent terminates the actor). abruptly. The recovery of single agents should take The classes related to an agent are as follows: place without loosing state information or resourceExecutor: executes a task plan, which has corrupting data. The restart and reintegration of been created by a planner function; agents should be able without disturbing the rest of implements a state machine. the agent system. Complete interactions must be resourceMonitor: executes a monitoring plan, which robust against agent failures (if agents are e.g. has been created by a planner function, and engaged in a negotiation process, and one agent which is (=must be) consistent with the task crashes after its commitment to some actions, these plan; implements a state machine. commitments are normally lost and the complete agent system is in an inconsistent state; recovery internalAgent
agentGoal
goal state lastMessage
putMessage getMessage run handleMessage
requestingAgent requestingActor goalId goalDescription
specializedAgent
driverCode plans
resource Operator
textArea textField
agentMessage
setDriverCode getDriverCode addBuffer handleMessage handleComm ahd
com pleteMessage senderAgent senderActor receiverAgent receiverActor m essage parseMessage
general Executor
previousAction currentAction nextAction doIndex untilEventIndex signalToMonitor m essage state putMessage getMessage run handleMessage
specialized Executor interprete
specialized Monitor interprete
general Monitor
currentOperation stepCondition minValue maxValue state putMessage getMessage run handleMessage
m sgQueue
elem entVector put get
mechanisms should help against this error situation). Distributed transactions, lock concepts and commit protocols are available from database technology and provide robustness, concurrency, and undo/redo of interactions. Manufacturing agents have to handle product and process data. For an agent this is part of the information “sensed from the outside world” and therefore part of its beliefs. This information together with beliefs representing its own internal state and information about other agents comprise the “belief database” of agents. Our intention is to provide a persistent belief management. It is on the one hand a starting point for a robust data management. On the other hand, database facilities directly integrated into an agent architecture are also an aspect of integrating agent systems into the already existing information infrastructure of a company. The important first step is therefore to provide persistent data management in agent architectures. In the following we describe, how a persistent belief management, which will be integrated into manAge, has been implemented.
6.1 A general persistency framework The agent implementation environment, manAge, has specific requirements of information management within the agent architecture. These are: • Access to product and process relevant information and its inclusion in the information management and reasoning process of the agent • A possibility to make the current state of an agent (its beliefs) persistent • Enabling easy data exchange with legacy applications and various other mainstream tools (office applications, data analysis tools etc.) • Preparing further developments of transaction and recovery features for agents and agent communities As a first step a database management package was implemented, which will be integrated into both agent environments. It allows agents to maintain persistent beliefs and access persistent storage facilities. The goals are flexibility in accessing any kind of data source and reliability/integrity in data management. In the following it will be described how beliefs of an agent can be made persistent, and how the management of such data must be done. A Java class framework is provided to allow the interaction of an agent application with SQL
database systems and various other data sources, using JDBC/ODBC technology or proprietary implementations. Agent
Agent
Agent
Agent
Persistency Framework
Agent
Persistency Framework
JDBC
Text Excel Oracle
Access
Proprietary Database
Figure 6. Persistency framework.
Agents are implemented in Java and manage Java objects to represent beliefs. To provide persistency for believes, Java objects must be saved in a persistent storage facility and must be retrievable from there. A persistent belief always exists in two extensions, as a Java object with specific characteristics and as a data structure (table) in an SQL database (or in any other data source). A synchronisation between both representations guarantees persistence (Kollingbaum and Lanner 1997). Beliefs are instantiated from a Belief Type, which is represented by a Java class. This Java class inherits persistence properties from the database management package. To enable the storage of persistent beliefs in a storage facility, their “structure” and “identification” must be specified. Structure is described by a Java class definition, containing a set of attributes and in case of an SQL data source an SQL-create-table statement, which defines a table structure that corresponds with the Java class definition.
Belief Type
Belief
Two Representations
Class MyBeliefs { int beliefAtt1 ; float beliefAtt2 ; char beliefAtt3 ; ... }
CREATE TABLE MyBeliefs ( beliefAtt1 INTEGER, beliefAtt2 FLOAT, beliefAtt3 CHARACTER, primary key ( beliefAtt1) )
Figure 7. Belief model.
A subset of the object’s attributes uniquely identifies such a persistent object. Such a subset is called the “key” of a data item (there can be more than one key). It has been a goal of this implementation to provide a very natural way of implementation for an application programmer. Java
means should be used primarily, hiding unfamiliar issues of relational database technology as far as possible. The abstract class “PersistentObject” is provided for this purpose. A belief type extends this class. Structure and key are meta information that is necessary for the persistence framework to access and manage persistent objects. This must be defined explicitly within the belief type class: public Class MyBeliefs extends PersistentObject { static public String[] schema = {“beliefAtt1”, “int” , “key”, “beliefAtt2”, “float”, “”
,
“beliefAtt3”, “char” , “” } ; public int beliefAtt1 ; public float beliefAtt2 ; public char beliefAtt3 ; }
A static variable “schema” points at an array of strings, which contains the schema information of this class. The most important information here is the item “key,” determining the set of attributes that belong to the key and uniquely identify a belief. This schema description contains all necessary information to access any data source (SQLdatabase, simple data file, proprietary database system). All items must be declared “public.” The corresponding SQL-statement looks like this: CREATE TABLE MyBeliefs ( beliefAtt1 INTEGER, beliefAtt2 FLOAT, beliefAtt3 CHARACTER, primary key ( beliefAtt1) ) ;
With such a persistent belief management normal database functionality of set retrieval and manipulation is available for the management of the agent’s beliefs. An implication of storing beliefs in a database is the possibility to share them among different agents, which concurrently access the database. Transaction mechanism from the database system must be used to serialise manipulations of such shared beliefs.
6.2 Using the Persistent Belief Management within the implementation architectures The implementation architecture of manAge is based on a modular concept. It is intended to integrate the database management package as a separate module into this environment. As agents consist of a set of modules, which can be executed in parallel, this integration requires the implementation of a couple of additional features of serialisation and bookkeeping to support persistent belief management in this modular environment.
6.3 Further Aspects of Persistence Persistent belief management and shared beliefs have couple of implications and opportunities to create agent-based manufacturing control application. Shared beliefs are data objects that are accessible by more than one agent. Because of this fact they are also a possibility to exchange information between agents. The database system can be used as a communication infrastructure. Persistent data management, shared beliefs, and trigger mechanisms for change notification are necessary ingredients to create a complete control system. Using the database system as a middle-ware layer and a means of communication and integration of agents and legacy software system provides a possibility to abstract the “cognitive” layer of the control system from the “shopfloor” layer. We should not forget that software systems, which represent large investments, already exist in manufacturing environments. Agents should be “plugged” into these systems adding “intelligence” rather replacing them. Agent Change Notification with triggers
Retrieve/update Database Database
Update Database
Update Process
Change Notification with triggers
Process Control HW/SW
percept
act
Figure 8. Active database as Middle Layer.
The distributed database system abstracts the actual manufacturing environment completely and represents the production process as a set of data objects in the database. Control software at the shopfloor level delivers data into the database system, the agents are notified about changes and act on these changes. Agents use a database access mechanism (JDBC/ODBC) as their communication facility. It provides them with a kind of “standard” communication interface, because it allows a connection to a large variety of data sources. The abstraction of the production process as a set of data objects allows a replanting of the agent society into a different production environment without any necessary adaptation. This can be used e.g. during the development of an agent-based control application by connecting it to a detailed digital mock-up of the real production environment. For the agent-based control application it should make no difference if connected to the mock-up or the
real plant. Connected to such a simulated plant environment, the agent control system could be trained and prepared for its control tasks and “learn” certain basic strategies in advance.
7. Application Environment
routing logic, AGV logic and so. The organisation of the software is illustrated in Figure 9. goals from user JAVA-agent controllers orders, controls
BUFFER 111
STATION11 CONTROLLER
driver messages
QUEST models
STATION11
AGV1
The manAge framework has been tested in the MASCADA project, in an electronics manufacturing demonstration test system. In electronics manufacturing, there are a variety of changes and disturbances for which the manufacturing control system should contribute. Failures and errors originating prom the process (NC/insertion machines, robots, peripherals (feeders etc.), conveyors, AGVs, ...) may cause redirection of the material flows and re-transportation of the parts to new resources. The control system should maintain and have access to the latest available information about the process resources, and should be able to allocate and re-allocate orders to the available set of available resources avoiding such solutions which result into dead-locks or otherwise drastic reduction of through-put. For example, availability of transportation resources (transportation system) and needs for parts and material transportation (production lines and cells) should be matched together. This should take place within a limited time window ahead, finally depending on the applied production strategies and dominating criteria. Further details about requirements for electronics manufacturing control can be found from (Lassila and Heikkilä 1998) and (Peeters et al 1998). The basic approach for the demonstration test system is to drive the simulation production model directly by the external agent based controls. Here the agent based control is composed of several agents running on one or more Windows NT processes connected in a local area network with TCP/IP protocol. The agent models are implemented in Java language using Symantec's Visual Cafe (2.5) rapid application tools. Those agent controllers which are managing 'physical' machines and equipment (machines, AGVs etc.) are plugged in to the simulator by a specific driver interface (four digit driver codes consistent in both sides). The application software in the simulator implements the simple driver operations (digital mock-up approach). As a production system simulator the QUEST (Quest 1997) simulator software is used. The drivers in QUEST are implemented as different 'logics', i.e. process logic,
LINE1 CONTROLLER
BUFFER 121
AGV1 CONTROLLER BUFFER 122
STATION12 CONTROLLER
STATION12
BUFFER 122
Figure 9. The principal structure of the electronics demonstrator SW system. The demonstrator is used to facilitate running ordinary production lots but with different products, introducing rush orders, and handling disturbances. The rush orders are introduced in arbitrary times by human operators, and disturbances are introduced by disabling one or more resources by disabling their simulator counterparts. In each case the throughput of the whole system is observed.
8. Conclusions This paper outlines an agent architecture for distributed manufacturing control applications. Conceptual and implementation aspects are clearly separated and as such, openness of the system concerning scalability and extensibility is satisfied. To improve deployment, also mapping to implementation details (language constructs, operating system services, persistent data stores, etc.) is explicitly described. The architecture is currently tested within the MASCADA Esprit LTR project.
Acknowledgements This work has been funded by the European Commission and VTT Automation, as part of the MASCADA project (ESPRIT LTR Project 22728), which is greatly acknowledged by the authors. The authors would also like to thank all partners in the MASCADA project for fruitful discussions and cooperation.
References Baker, A.D. (1997) A Survey of Factory Control Algorithms which Can be Implemented in a Multi-Agent Heterarchy, University of Cincinnati, 1997. Baker, A.D. (1998). JAFMAS homepage, http://www.ececs.uc.edu/~abaker/JAFMAS Barbuceanu, M. and Fox, M.S. (1997), The design of COOL: A Language for Representing Cooperation Knowledge in Multi-Agent Systems, http://www.ie.utoronto.ca/EIL/ABS-page/ABSintro.html Diedrich C. and Neumann P. (1998). Standardisation in Automation Systems, IAFC Symposium on Information Control in Manufacturing (INCOM ’98), June 24-26, 1998, Nancy - Metz, France. Dilts, D.M., N.P. Boyd, H.H. and Whorms (1991), The evolution of control architectures for automated manufacturing systems, Journal of Manufacturing Systems, Vol. 10, N. 1. Douglass, B. P. (1998). Real-Time UML, Developing Efficient Objects for Embedded Systems, Addison Wesley, Reading, Massachusetts, 365 p. Georgeff, M.P. and Lansky, A.L. (1986) Procedural Knowledge. Proceedings of the IEEE, Special Issue on Knowledge Representation, 74:13831398, 1986 Guilfoyle, C. and Warner, E. (1994) Intelligent Agents: The New Revolution in Software, Ovum Ltd., London 1994 Heikkilä T. and Röning J.(1992). PEM-modelling: A Framework for Designing Intelligent Robot Control. Journal of Robotics and Mechatronics, Vol. 4, No. 5, October 1992, pp. 437 - 444. Kollingbaum, M. and Lanner, T. (1997) Agentbased Information Management for Industrial Processes, Annual Conference of ICIMS-NOE, ASI'97, Budapest, 1997 Lassila K. and Heikkilä T. (1998). Requirements for Flexible Manufacturing in the Production of Printed Board Assemblies. Proceedings of First International Workshop on Intelligent Manufacturing Systems - IMS Europe 1998. 15 17 April 1998, Lausanne, Switzerland. Pp. 327 340. Nwana, H.S. (1996). Software Agents: An Overview. Knowledge Engineering Review, Vol. 11, No 3, Oct./Nov. 1996 Peeters P., Heikkilä T., Bussman S., Wyns J., Valckenaers P. and Van Brussel H. (1998).
Novel Manufacturing System Requirements in a Highly Automated, Line-Oriented Discrete Assembly Sector. Workshop of the IMS Long Term Research Working Group, Nancy, France, September, 1998, 10 p. QUEST Release Notes Version 3.0. (1997), Deneb Robotics, Inc. Auburn Hills, Michigan, USA. Rannanjärvi L. and Heikkilä T. (1998) Software Development for Holonic Manufacturing Systems. Computers in Industry (37). Pp. 223 253. Rao, A.S. and Georgeff, M.P. (1995) BDI Agents: From Theory to Practice, ICMAS-95, San Francisco, 1995. Shoham, Y. (1993). Agent-oriented programming. Artificial Intelligence, 60(1):51-92. Smith, R.G. (1980), The Contract Net Protocol: High-Level Communication and Control in a Distributed Problem Solver, IEEE Transactions on Computers, Vol. C-29, No. 12. Van Brussel, H., Wyns J., Valckenaers P., Bongaerts L.and Peeters P. (1998). Reference Architecture for Holonic Manufacturing Systems: PROSA, Computers In Industry, Special Issue on Intelligent Manufacturing Systems, Vol. 37, No. 3, pp. 255 - 276, 1998. Wooldridge,M. and Jennings,N.R. (1995) Agent Theories, Architecture and Languages: A Survey. Lecture Notes in Artificial Intelligence, Vol.890, Springer Verlag 1995 Wyns, J. (1999). Reference architecture for holonic manufacturing systems - the key to support evolution and reconfiguration, Ph.D. thesis KULeuven, Leuven, 1999.
