Agent-based Manufacturing Workshop - Autonomous Agents’98 - Minneapolis/St.

Paul, May 9-13, 1998

Agent-based Intelligent Control System Design

For Real-time Distributed Manufacturing Environments
Lihui Wang, Sivaram Balasubramanian and Douglas H. Norrie

Division of Manufacturing Engineering, University of Calgary

2500 University Drive N.W., Calgary, Alberta, Canada T2N 1N4
Phone: (403)220-5787 Fax: (403)282-8406
Email: [lhwang | balasubr | norrie]@enme.ucalgary.ca

ABSTRACT hence reconfiguration of the factory requires physical

This research focuses on development of a generic
agent-based intelligent control system designer for real-
time distributed manufacturing environments. The paper
first describes related research into distributed
manufacturing and real-time control system, then reports
on the intelligent control function design interface and
automatic control code generation.
Keywords: Multi-agent, manufacturing, real-time control,
function block, automatic code generation.
1. INTRODUCTION
Over the last several decades, computer control of
manufacturing systems has been the focus of extensive
research. Advances in microprocessor, computing,
networking and interfacing technologies have improved
capabilities of industrial automation and control systems
substantially over this period. However, these control
systems are proprietary and still have problems in areas
such as interoperability, scalability, and lack of standard
user interfaces. The development of open architecture
control systems addresses some of these problems, in
varying degrees. Open architecture control systems shift
the focus of automation from being hardware centric to
software centric, providing further flexibility. The focus is
now shifting to distributed control systems, which is the
central concern of this research work.
The conventional way to control the complex of
manufacturing machines in a modern factory is to
distribute the control instructions through a hierarchy of
control computers. This hierarchy is hard-wired, and
wiring changes and manual reprogramming of controllers.
The era of present day manufacturing systems with its
hard-wired interconnection of manufacturing cells is
passing and will be gradually phased out, because these
conventional manufacturing systems are insufficiently
flexible due, in part, to their rigid system control structure.
Future manufacturing systems will be required to be agile,
flexible and fault-tolerant. The next-generation intelligent
manufacturing systems (IMS) will be multi-agent systems
containing distributed control and application entities that
dynamically collaborate to satisfy both local and global
objectives. They will be implemented within dynamically
re-configurable factories having decentralized and virtual
organization structure. The constituent resources will be
capable of addressing both the knowledge processing and
material processing requirements simultaneously. In such
a real-time distributed manufacturing environment, the
control relationships among resources will be ever-
changing, and the control codes will need to be updated in
real-time due to the changes of control relationship.
The presently reported research focuses on
development of a generic agent-based intelligent control
system designer for real-time distributed manufacturing
environments. This paper first describes related research
into distributed manufacturing and real-time control
system, then reports on the intelligent control function
design interface and automatic control code generation.
2. BACKGROUND
When considering the design of a manufacturing
control system, one of the main goals is to achieve a design
that is flexible enough to adapt to changes in the

1998 University of Calgary – Reprint of original paper - 152 -

manufacturing environment. A brief review of the
background and the approaches that have been taken will
be discussed in this section.
2.1 Holonic Manufacturing Systems
In the last decade, the change in market requirements
towards a larger variety of products in smaller batch sizes,
has lead to the concept of next generation intelligent
manufacturing systems (IMS) being an integrated network
of distributed resources simultaneously capable of
combined knowledge processing and material processing.
The control relationships among these distributed
resources need to be reconfigured on the fly according to
the changing requirements. Earlier research in the area of
IMS has established that such resources can be realised
through the concepts of the holonic paradigm [1-3]. Based
on holonic concepts, the next-generation of IMS could
form distributed re-configurable virtual factories, in which
humans, machines and control modules interact in
dynamically formed virtual clusters. Such a system could
be built from intelligent, autonomous and cooperative
elements or holons [2-4].
A holon is defined as an autonomous and cooperative
building block within a manufacturing system for
transforming, transporting, storing and/or validating
information and physical objects [3]. A holon has the
autonomy to create and control the execution of its own
plans, and can cooperate with other holons to develop
mutually acceptable plans for achieving system goals.
Cooperation among holons is accomplished through an
evolutionary self-organizing holarchy (a system of holons).
A holarchy which integrates the entire range of
manufacturing activities (e.g. order booking, design,
production, and marketing, etc.) is defined as a holonic
manufacturing system (HMS).
Figure 1 illustrates the major functional elements and
interfaces of a holon. A holon exchanges information,
material, or resources with other holons via its interfaces.
It can also form a part of another holon.
Inter-Holon Negotiation/Cooperation
System
Human Inter-Holon
Engineering
Interface Interface
Interface
Intra-Holon Coordination
Intelligent Sensors/Actuators
Process/Product
Fig.1 Holonic elements and interfaces
1998 University of Calgary – Reprint of original paper
In an HMS, the constitution of holons change and the
functional elements evolve over time according to system
level requirements. For instance, a turning center holon
may be augmented with certain milling operations or a
holonic robot may be provided with additional vision
system capabilities. Hence the ability to reconfigure on
demand is an important requirement for holonic systems.
This and related capabilities of holonic systems will
largely be dependent on their Intelligent Control Systems.
2.2 Intelligent Control in HMS
In a holonic manufacturing system, the objective is to
achieve a complete spectrum of manufacturing control
functions ranging from production planning and control at
the highest level, to process/machine control at the lowest
level. Intelligent control involves not only the achievement
of these control functions, but seamless integration of them
as well. A holon-based decentralized and distributed HMS
uses autonomy and cooperation as the primary means to
achieve system wide integration of control functions. In
other words, the control objectives which need to be
achieved at the individual holon level need also to be
achieved at the system level. Obviously, the ability of a
holon to achieve these control functions is directly
dependent on its control system. An intelligent control
system (ICS) in next generation of HMS has been
identified to be comprised of four major components [3] as
shown in Fig.2.
Inter-Holon
Interface
Human Process/Machine
Interface Control
Process/Machine
Interface
Fig.2 Major components of ICS in HMS
1) Process/Machine Control:
Responsible for execution of the control plan for the
process being controlled.
2) Process/Machine Interface:
Representing the physical and logical interfaces
(sensors and actuators) to the process being controlled.
3) Human Interface:
Representing the interfaces to the human resources.
4) Inter-Holon Interface:
Providing for the exchange of information, negotiation
and cooperation with other holons in the system.
- 153 -
2.3 Metamorphic Control Requirements
A holonic system is inherently distributed and
metamorphic, which has important implications for its
control system. As shown in Fig.3, a typical distributed
control system of this nature makes use of a real-time
network for communication among spatially distributed
controller nodes. The centralized application level control
program that previously would have been executed on a
single CPU is now distributed among the controller nodes.
The distributed programs synchronize by communicating
through message passing under real time constraints to
meet application requirements. The microcomputer serves
to program, configure and monitor the distributed control
system. Metamorphic control requires numerous changes
in form, substance and allocation to be accommodated
within system lifetime. Its control requirements are the
unique combination and interaction of those of real time
control, distributed control, event-driven control as well as
intelligent control.
Microcomputer
Real Time Network Distributed I/O
Control Controller Controller
Program Node 1 Node 2
Fig.3 Holonic distributed control
An industrial process/machine control system is the
“sense and brain for the muscle” behind any automated
manufacturing equipment. Its functions are that of
periodically comparing sensory process/discrete input
variables with setpoints/logic states, computing the outputs
according to a predefined control algorithm/logic and
communicating the output signals to the final control
element for actuation. Realization of these functions poses
significant problems due to the conflicting requirements of
control functions at various levels in hierarchy. The higher
level functions require complex information processing on
a relatively small volume of filtered data. On the other
hand, the lower level control functions require processing
of large amounts of raw data under real-time constraints.
In the real world, autonomous and cooperative control
systems often operate under real-time constraints and are
inherently distributed and dynamic. Traditional static and
hierarchical control system structures do not suffice for
1998 University of Calgary – Reprint of original paper
such situations. A new generation of real-time distributed
intelligent control systems is required. The control system
under development in this research is aiming at meeting
these metamorphic requirements by adopting the partial-
dynamic control hierarchy [4] and IEC-1499 function
block architecture [5].
3. CONTROL ARCHITECTURE
3.1 Partial Dynamic Control Hierarchy
When considering the design of a control system, one
of the main goals is to achieve a design that is flexible
enough to adapt to the changes under a real-time and
distributed manufacturing environment. Ideally, the
control system will have this flexibility embodied in its
design. When changes do occur on the shop floor (e.g., the
addition or deletion of equipment), changes do not have to
be made to the control software, or the changes that have
to be made are minimal. Although the decentralized
approach that involves the use of a number of interacting
decision-makers in place of a single centralized one is the
solution to this requirement, how to choose the appropriate
control architecture still remains as a question.
Decentralized controls have three typical architectures,
which are hierarchical decomposition, oligarchical and
Controller heterarchical approaches [4]. Generally, the hierarchical
Node 3 decomposition to large-scale control systems involves
decomposing the overall system into small sub-systems
that have weaker interactions with each other and also
lower degree of cooperative autonomy. On the other hand,
the heterarchical approach supports higher degree of
autonomy but it may take much more time during
decision-making, especially when a large number of agents
(holons) are encountered.
Control architectures for real-time and distributed
manufacturing systems often need to meet a number of
requirements, such as autonomy, reliability, fault-tolerant,
interoperability, re-configurability, and other real-time
functionality. For example, for a stage of batch production
on a shop floor, one set of machines is needed, but for the
next batch there may be a need to drop some machines and
add others. The functional group of machines and other
manufacturing resources will become a ‘virtual cluster’
only for the period necessary. Large clusters will hence
become a ‘virtual factory’. There may be several virtual
factories within a given physical factory at any one time
and these will be re-configured on the fly as needed. These
changing requirements lead to the concept of a partial
dynamic control hierarchy. The partial dynamic control
hierarchy hybridizing both hierarchical and heterarchical
architectures has been here adopted for the system
implementation. The use of partial dynamic hierarchies
assists reconfigurability and can provide a better system
performance than either single control approaches [4].
- 154 -
3.2 Function Block Architecture
Currently, there are growing interests in new
technologies and architectures for creating the next
generation of distributed control systems for industrial
automation. These technologies will reduce the time to
bring new systems on stream, and leverage the integration
of business and industrial systems [6]. Also, a control
system needs to use a specification model that is the
standard across various manufacturing applications. The
fusion of the partial dynamic control hierarchy with IEC-
1499 function block architecture meets such a requirement
and will facilitate distributed control systems being created
by the interconnection of software components.
The IEC-1499 function block architecture [5] is an
emerging standard for distributed industrial process
measurement and control systems. It uses an explicit event
driven model and also provides for data flow and finite
state automata based controls. As shown in Fig.4, an
industrial process measurement and control system
(IPMCS) is modeled in this IEC-1499 standard as a
collection of controller devices interconnected and
communicating with each other by means of one or more
communication networks that may be organized in a
hierarchical manner. The control functions performed by
an IPMCS are modeled as applications. An application
may reside completely in a single controller device or may
be distributed among several devices.
Communication network(s)
Device 1 Device 2 Device 3 Device 4
Application A
Application B
Appl. C
Controlled process
Fig.4 Specification model of IPMCS
In industrial control systems, the function block is a
well-established concept for defining robust, reusable
software components. A function block can provide a
software solution to a small problem, such as the control of
a valve, or to control a major unit of factory, such as a
complete production line. As an atomic distributable
control function unit, a function block instance is a
functional unit of software comprising an individual,
named copy of the data structure specified by a function
block type, which persists from one invocation of the
1998 University of Calgary – Reprint of original paper - 155 -
function block to the next. As shown in Fig.5, a function
block consists of a set of event inputs and outputs, a set of
data inputs and outputs, a set of internal variables and state
information, an execution control function, and a set of
algorithms. The execution control function, the
algorithms, and the internal variables and state
information which persist between invocations of
algorithms, are invisible outside of the function block.
Event inputs Event outputs
Instance identifier
Event flow Event flow
Execution
Control
(hidden)
Type identifier
Data flow
Algorithms
(hidden) Data flow
Internal data
(hidden)
Data inputs Data outputs
Resource capabilities
(Scheduling, communication mapping, process mapping)
Fig.5 Function block model
A distributable control application usually consists of a
network, in which nodes are function blocks and branches
are data and event connections. Figure 6 illustrates an
application defined by function block diagrams with event
and data flows among function block instances. The event
flow determines the scheduling and execution of the
operations specified in function block’s algorithms. Events
and data are always shown flowing into the left side of
each function block; outputs and generated events are
depicted on the right of the function block.
In the near future, since industrial controllers and
instruments will either provide function blocks as part of
the device firmware or provide function block libraries
from which function blocks can be selected and/or
downloaded [6], system design based on IEC-1499 will
become the accepted process of function block selection,
configuration and interconnection.
Event flow
∗ ∗ ∗
Data flow
Fig.6 Control application model
4. SYSTEM IMPLEMENTATION
An agent-based intelligent control system is being
implemented for PC or other platforms. The system is
designed to be able to provide flexible and generic
interconnection between agents to facilitate distribution,
coordination, and cooperation. It is also required to be able
to cope with the reconfiguration of its manufacturing
environments and to generate updated control programs in
real-time whenever the control relationships are changed.
4.1 Functional Requirements
An intelligent control system is a real-time control
system executing both intelligent and distributed control
tasks. It should be intelligent enough to automatically
adapt to the ever-changing requirements of the controlled
system. The functional requirements of a distributed
intelligent controller (DIC) and its reference architecture
are summarized and shown in Fig.7.
High Level
APPLICATION
PCEH * Planning
Execution
Logical
Control Program
Holons
Library
SYSTEM
Physical OS
Controller
Holons Hardware
WORLD
I/O Sensors, Actuators & Com. Media
External
World
Environmen Machine/Process
* High Level Planning, Coordination, and Execution Holons
Fig.7 Reference functional architecture
This architecture can be divided as shown into four
different groups of entities: a) External world, b) Physical
controller holons, c) Logical control holons, and d) High
level planning, coordination and execution holons (PCEH).
What is the advantage of separating the logical control
layer from the physical controller layer? This is of vital
importance in distributed control function design because
logical control holons do not need to be mapped to
physical controller holons to achieve a one-to-one
correspondence. For instance, one logical control holon
can be mapped across to two or more physical controller
holons, and two or more logical control holons can also be
mapped to one single physical controller holon, etc. If
there is the capability of mirroring or shadowing the
physical controller holon’s states, it is possible to have
other physical controller holons pick up the responsibility
and carry out the work of physical controller holons that
fail, for the purpose of fault recovery. On the other hand, at
the logical control level, the design emphasis in control
function can be put on intelligent capabilities.
1998 University of Calgary – Reprint of original paper
This reference functional architecture has multiple
functional levels. Each level in turn consists of multiple
layers. A DIC interacts with the low-level machine/process
environment and with other DIC’s through external
physical I/O interface devices such as sensors, actuators
and communication media.
The hardware layer is comprised of modular hardware
entities that serve as the physical platform for agents. The
distributed operating system layer agents provide a number
of services to the agents of higher layers to interact with
the lower hardware elements and the external world. They
provide services to assist higher layers to create, maintain,
and destroy agents. They also help in separating hardware
dependencies and provide location transparency. The
library layer agents are comprised of reusable software in
the form of standard control function blocks and provide
services to agents of higher layers.
The program layer agents consist of user-defined
control agents that are local components of distributed
V
S O
L
C
O control applications. The program layer agents also
U M
S/H
T
M
E
A
G
P provide services for higher level agents facilitating
L
E
H/S
I
M O N
E
X
information gathering and reconfiguration of operational
E F C
Y
I
T strategies. The execution layer agents are involved in
D Y
H A control tasks such as executing intelligent control
H
A
strategies, fault diagnostics, fault recovery, data
Legend
acquisition, scheduling, and decision making. The optional
Hardware
planning layer (if presents) would consist of agents that
Dependency
will be involved in strategic long term planning.
Soft Real
S Time
H Hard Real The lower layers, namely, OS, Library and Program
Time
layers are predominantly hard real time since they have to
respond immediately to internal/external events. On the
other hand, the Execution and the Planning layers are
predominantly soft real time involving high variance
execution periods. As one traverses down the multiple
layers, the following can be noted. The available time to
respond, the complexity of operations and hence the
processing time increase with higher layers, while the
volume of raw data to be processed decreases. The notion
of agency, i.e. the amount of intelligent responsibility
delegated by the agents, increases progressively.
4.2 System Architecture
The structure of this control system at the higher level
is based on partial dynamic hierarchies, which can
dynamically organize multi-agent decision-making using
task decomposition. Heterogeneous intelligent agents, used
in the system development, are dynamically grouped into
virtual clusters that can be created and destroyed as needed
within the dynamic hierarchy. Overall coordination of the
system is accomplished by high-level mediator agents,
which ensure that partial local solutions to decision
problems are integrated into the overall global decision
problems. Current research is being conducted into also
- 156 -
implementing partial dynamic hierarchies at the lower 4.3 High Level Interactions with DCOS
process/machine control level where real-time control Based on the reference functional architecture shown
constraints must be met. in Fig.7, high-level control applications need to interact
Figure 8 shows the reference architecture for the real- with low-level intelligent sensors/actuators via the DCOS.
time control system, which is comprised of four major They also require the DCOS-based infrastructure on each
physical components: microcomputers, primary factory intelligent controller to provide services for the transfer of
control networks, distributed intelligent controllers and data and events between distributed function blocks.
secondary control networks. However, since the DCOS is a protected operating
system for security reasons, it imposes a strict system-
Microcomputer Microcomputer application barrier. The user tasks cannot access system
Factory Control
agents or objects directly. To circumvent this situation,
Network dummy objects are used. As shown in Fig.9, these dummy
objects correspond to system agents on the application side.
The result is returned to the dummy objects after
execution, and passed to the user task for continuation.
Intelligent Intelligent Intelligent Intelligent
Controller Controller Controller Controller
System O b jects

System A g ents
Distributed System
Fieldbus : Intelligent I/O Intelligent Fieldbus : Intelligent I/O
to Sensors and Actuators Controller to Sensors and Actuators A p p lication
D u m m y O bjects

Fig.8 Reference system architecture

A p p lication Task
All the four components are soft-wired and can be
dynamically reconfigured on the fly. The microcomputers
Fig.9 System-application interaction
serve the purposes of system engineering interface (SEI)
functions, such as programming, system configuration, In addition to dummy objects, the DCOS also provides
monitoring, data acquisition, and supervisory planning and a system engineering interface (SEI) agent to shake hands
control. The primary communication network serves to with higher-level control and supervisory applications. The
control and coordinate all the distributed intelligent SEI agent, as shown in Fig.10, acts as a remote liaison for
controllers within the factory control system. It also serves its name sake. It is a task (or tasks if multi-threaded) with
as the communication link between the controllers and the super-user privilege that helps the remote commands from
microcomputers. Each distributed intelligent controller any SEI in a distributed control system be turned into local
serves the purpose of controlling an autonomous process/ actions. It provides services to configure the local
machine resource. The secondary communication network components of DCOS from a remote node. It implements
serves not only as the interface between one distributed simple file transfer protocol to download distributable
intelligent controller and its distributed intelligent sensors program units (function blocks) and other data files into
and actuators, but also as a communication link among the local physical controller holons dynamically.
constituent intelligent controllers. Such a controller is, by
nature, a real-time system and it involves prioritized
U ser
execution of both hard and soft real-time control tasks
System System
concurrently.
Engineering Commands Engineering
The above metamorphic control architecture is open, Interface Interface
software centric, and useful for real-time distributed event-
driven control of dynamic re-configurable systems. Using a
behavior based heterogeneous multi-agent system to OS Agents SEI Agent
provide uniform functions for a distributed controller OS
(DCOS), the proposed architecture is being implemented User Tasks
in an Intelligent Control System under development at N ode X
University of Calgary. The key lower layers of it have
already been tested and shown to operate as designed [7]. Fig.10 SEI agent-user interaction

1998 University of Calgary – Reprint of original paper - 157 -

4.4 Control Function Design
As mentioned in section 4.1, one of the advantages of
separating the logical control layer from the physical
controller layer is that the higher application level control
function design can focuses on intelligent capabilities. This
task is performed via an intelligent programming interface
based on agent technology and function block concepts.
The visual programming interface can facilitate not only
the rapid development of distributable control applications
but also the automatic run-time control code generation.
An agent is defined as an autonomous software entity
that inter-operates asynchronously with other agents
through a well-defined message passing mechanism. It is a
distributed computing entity and possesses autonomous
execution control. (A holon, in contrast, need not only be
software but can also include hardware.)
Since the IEC-1499 function block architecture will
become the industrial standard for distributed control
systems in next generation manufacturing environments,
this visual programming interface adopts it for generating
distributed control functions utilizing both basic function
blocks (BFBs) and composite function blocks (CFBs). The
BFBs are predefined executable and distributable control
units, which use appropriate execution control charts
(ECCs) to control their algorithms. On the other hand, the
CFBs are the combinations of the BFBs and/or other
CFBs. They do not need ECCs for execution control and
have no algorithms for themselves. Since a CFB provides
the mechanisms for specifying complex control behaviors,
it can be extended and designed as a distributable control
application holon. Such a control application holon (agent)
is comprised of one or more CFB(s), each of which in turn
consists of one or more BFB(s).
Figure 11 illustrates the architecture of this intelligent
programming interface. It utilizes a graphical behavior
specification method for better comprehension, facilitates
software reuse, and automatically generates the run-time
control code for cross compilation.
Agent-based Intelligent Visual Programming Interface
UI Control
Library Editor Control Code
Management Control Generation
Editor
DType Func BFB CFB
Editor Editor Editor Editor
Library
DType Func BFB CFB
Lib Lib Lib Lib
Fig.11 Architecture of programming interface
1998 University of Calgary – Reprint of original paper
The architecture can be divided into three functional
components: Library, Editor and UI (user interface)
Control. Each houses some specific functionality. The
library component consists of five types of library (i.e. data
type, function, basic function block, composite function
block, and application) and a shared library of DCOS. The
editor component consists of five types of editors
associated with appropriate library types. At highest level,
the UI control component provides the functionality such
as library management, editor control, control code
generation, and cross compilation.
It should be noticed that function blocks are different
from functions in basic concept. A function is used to
define the algorithm of a given basic function block and is
designed based on IEC-1131-3 standards [8] by using its
graphical function block diagram (FBD) language. It is a
subroutine that creates one output from one or more inputs.
A function cannot maintain state information between
calls, i.e. it should produce identical output for the same
input(s) on every call. However, function blocks, especially
basic function blocks, are atomic units of distribution.
They may have multiple outputs and can maintain internal
state information. Therefore, a function block can generate
different output(s) even if the same inputs are applied. The
BFBs are implemented as agents involving atomic unit of
concurrency (i.e. having single independent thread of
execution control). The CFBs are also atomic units of
distribution, but their complexity of event flows requires
multi-threaded concurrent execution models. Figure 12
shows simple examples of the BFB and the CFB.
EI variables EO variables Event inputs Event outputs
Execution
Control
Chart
Type identifier Type identifier
Algorithms
Internal
variables
Cross
Compilation Input variables Output variables Input variables Output variables
(a) BFB (b) CFB
App
Editor
Fig.12 Definitions of function blocks
App DCOS
Based on the architecture shown in Fig.11, the visual
Lib Lib programming interface is being implemented as an iconic
GUI system. The state machine of a basic function block is
specified through event inputs, event outputs, state blocks,
interconnections and transition conditions. Combining
- 158 -
BFBs properly, a user can design a composite function
block that provides convenient control over related tasks.
As a result, an intelligent distributable control application
can finally be designed by assembling these pre-defined
BFBs and CFBs properly into a network of function
blocks. Since the control application is designed and
organized as sets of co-operating function blocks rather
than as the interconnection of large units of software,
many function blocks can be reused in other applications.
The function block based control application design
methodology not only benefits the integration of
distributed software components but also facilitates the
control code generation, because most function blocks are
reusable. The reuse of function blocks means that their
control codes can be embedded or linked to the main
control application in object-oriented languages where
each function block is considered as an instance of certain
pre-defined function block class. The codes of these
function block classes should be generated and preserved
in an appropriate function block library whenever they are
newly designed by using the visual programming interface.
Once the control application design is completed simply by
drag-and-drop, its run-time control code can be generated
automatically.
5. CONCLUSIONS
This research proposes a new design methodology for
metamorphic control systems that require the control
functions to meet the real-time and distributed constraints.
It has been tested in a proof-of-concept prototype based on
agent technology and function block concepts, and shows
promise for improving manufacturing system performance
under real-time distributed environments. Full intelligent
functionality of the system is still being implemented.
1998 University of Calgary – Reprint of original paper - 159 -
REFERENCES
[1] A. Koestler, The Ghost in the Machine, 1971, ISBN 0-
14-019192-5.
[2] J.H. Christensen, D.H. Norrie and C. Schaeffer,
“Material Handling Requirements in Holonic
Manufacturing Systems,” Proceedings of second
International Conference on Material Handling
Research, Michigan, pp.1-22, 1994.
[3] J.H. Christensen, “Holonic Manufacturing Systems:
Initial Architecture and Standards Directions,”
Proceedings of 1st European Conference on Holonic
Manufacturing Systems, Germany, pp.1-20, 1994.
[4] R.W. Brennan, S. Balasubramanian, and D.H. Norrie,
“A Dynamic Control Architecture for Metamorphic
Control of Advanced Manufacturing Systems”,
Proceedings of Intelligent Systems & Automated
Manufacturing, pp.213-223, 1997.
[5] IEC Technical Committee, “Function Blocks for
Industrial-Process Measurement and Control Systems,
Part-1: Architecture”, IEC-TC65/WG6 Committee
Draft, June, 1997.
[6] R. Lewis, “Design of Distributed Control Systems in
the Next Millennium”, Computing & Control
Engineering Journal, pp.148-152, August, 1997.
[7] S. Balasubramanian, Doctoral Dissertation on
Intelligent Control, University of Calgary, 1997. (not
yet publicly available)
[8] IEC Technical Committee, “Revised Final Draft –
Application and Implementation of IEC 1131-3 (Type
3 Technical Report)”, IEC-SC65B/WG7/ TF3 Revised
Final Draft, June, 1995.