Daili Zhang, Santiago Balestrini, Dr. Yongchang Li, Dr. Neil Weston, and Dr. Dimitri Mavris

A MULTI-AGENT-BASED CONTROL SYSTEM FOR THE INTEGRATED ENGINEERING PLANT ABSTRACT This paper outlines a formal procedure to establish a Hierarchical Multi-Agent-Based Control (HMABC) system for a large-scale complex system and its integration with other systems in an Integrated Engineering Plant (IEP) simulation environment. It also provides a method to test and evaluate the HMABC system’s efficiency and robustness by integrating a visualization tool in IEP simulation environment which displays the real-time states of the controlled system and helps debug the control algorithm. Finally, a case study is performed on a reduced-scale chilled water system to investigate the capability of the HMABC.

INTRODUCTION In the recent decades, there has been a strong interest in control of large-scale complex system, especially in the area of autonomous intelligent control methods. Classical control systems based on feedback techniques and central control methods generally cannot manage computational complexity, nonlinearity, significant uncertainty and heterogeneity. Especially for the control methods that attempt to design point-design systems, it is hard to deal with situations that deviate considerably from nominal conditions and may lead to catastrophic results. Moreover, it is almost impossible to predict or list all possible damage scenarios and store the corresponding strategies in memory to reconfigure the system. For a dynamical system with significant degree of uncertainty, robustness of the control system is highly desired, especially for weapon and space systems. The usual way to do that is to integrate extra copies for some critical components. This is called block redundancy. In contrast, a method that makes the system capable of achieving the same goal by using © 2007 by Zhang, Balestrini, Li, Weston, and Mavris.

different methods with different components is called functional redundancy (Kurien 2001). Choosing either of these two methods, the control system must determine the current configuration and states of the system and change to another configuration automatically. The identification of the system states is usually through the sensors on board. However, it is not practical and affordable to install sensors in every potential location of the system, and the sensors as well as the components may fail time over time, therefore the observations from sensors may be incomplete and uncertain. Using one controller for the whole system as the central control method does makes the controller design extremely complicated and its reliability may be reduced considerably. Moreover, techniques for large-scale complex systems are being developed and upgraded constantly, which means more components and/or data, have to be added and upgraded as these are made available. In order to increase the affordability of the control system, the control system needs to be easily modifiable, adaptable and expandable as parts of the system are changed or more data/components are integrated. The HMABC method has been the focus in recent decades as a possible solution to solve such problems discussed above. Basically, HMABC is implemented by decomposing a complex system into smaller subsystem; each subsystem is treated as a relatively isolated part; all of the parts work interactively by communications through their interfaces (inputs and outputs). HMABC systems have many advantages in controlling large-scale complex systems. First, it divides a big task into smaller and more manageable pieces, making it easier to implement many modern control methods such as neural nets control, fuzzy logic control etc. Second, it separates the controller from the physical model and the controller is designed as software that can handle computational

complexity. Third, it makes the system more robust to uncertain and dynamical environments. Fourth, it makes the system more flexible and adaptable as time passes, especially, when agent designs for some similar problems are standardized. A multi-agent-based control system includes many agents that are working interactively. It is easy to predict the responses under certain situations for a simple agent. However, it is very difficult to theoretically evaluate the integrated effects of a multi-agent-based control system – whose control behaviour emerges from the concerted activities of many agents. The autonomy of the agents and the fact that interactions occur for unforeseeable reasons leads to the unpredictability of the overall behaviour of the runtime system (Vrba and Mařík 2005). Extreme situations may cause the whole system to crash due to logical errors in the interactions among agents, so testing and evaluating the agent-based control systems is as important as designing the controllers. Testing the control system is an iterative process, so using the real physical system to test the control system is highly costly and ultimately unrealistic. Using a simulation model instead of real physical system is the most effective way to do that. The control system is separated from the physical controlled system. They are connected to each other by inputs and outputs. The inputs of the control system are from the sensors of the physical system and the outputs are given to the actuators of the physical system. Experts for designing the control system and experts for building the model of real physical system can work in their own fields respectively. More important, some existing models of real physical systems can be used if they are suitable to extract and accept information from simulation environment.

issues messages to the rest of the system (Van 2000). More generally, each agent has a clear interface and boundary to interact with other agents, such as what inputs it needs and what outputs it offers; each agent has its own logic to decide the behaviour of itself according to its environment which is determined by its inputs. Each agent affects the other agents’ behaviors by its outputs. Note that inputs are not necessarily from the sensors and the outputs are not necessarily to the actuators. Usually, there are multiple layers for a HMABC system of a complex system, so there are many middle level agents who get information and send commands for some intermediate level agents which are neither sensors nor actuators. How to establish agents for a large-scale complex system and how to make all of the agents operate interactively and smoothly are not easy questions. There is no single absolute answer for various complex systems. In the literature, many methods used to establish agent-based-control systems are usually suitable for some specific systems. A two-tier system to divide the decision scope between the Open Autonomy Kernel (OAK) agents and Rockwell Automation (RA) agents was used by Maturana et al. (2005). OAK agents were placed in the upper level and these include ship and subsystem agents. RA agents were placed in the lower level to represent the physical components. A more detailed description is given by Scheidt (2002). A threelayer architecture using multi-agent based control for power system is provided by Jung and Liu (2001) and is as shown in FIGURE 1.

FRAMEWORK A system consists of many agents. An agent has a basic functional architecture. They take in sensor data as well as data from other agents, and provide data to their neighboring agents as well as commands to actuators. Internally, a decision making module processes sensor information and incoming communications and © 2007 by Zhang, Balestrini, Li, Weston, and Mavris.

FIGURE 1. The Hybrid SPIDMAS Architecture (Jung and Liu 2001)

The lowest layer is the reactive layer, which is located in every local system and gives immediate responses. The middle layer is the coordination layer which uses a knowledge base to trigger events/alarms and update the current model of the power system. The deliberative layer attempts to give a general plan for the whole system according to the information from the middle level agents. The multi-agent-based control architecture for the distributed energy resource microgrids is given by Jiang (2006). The proposed agent framework in this paper is described as the following: each energy resource and load in the microgrid is represented as an autonomous agent that provides a common communication interface for all the different components in the system; agents register themselves to a common directory through a directory service and self-organize their activities. Wang (2005) outlines an agent-based control approach for operation and management of network-enabled devices that exhibit intelligent behaviors. A functional hierarchy structure of three levels: agent organization level, agent coordination level and agent execution level is used in this paper. In the recent decades, hierarchical structure has been gradually accepted as a means for establishing agent based control for large-scale complex systems. Hierarchical control architectures provide effective control of complex systems that have multiple hierarchical goals, multiple sensors and a need for robustness (Scheidt 2002).

connected through “frequent interaction” links, and interactions between components are expressed through “infrequent interaction” links (Jennings and Bussmann 2003). Based on the characteristics of large-scale complex system, Jennings and Bussmann (2003) argued that there were five reasons for using hierarchical multiagent-based control for a complex system: 1. the relationships between agents are made more clear and they assist in understanding; 2. complexity frequently takes the form of a hierarchy, which is as shown as in FIGURE 2; 3. which components in the system are the primitives is a relatively arbitrary choice and is defined by design objectives; 4. hierarchical systems evolve more quickly than non-hierarchical ones of comparable size; 5. using this approach, it is possible to distinguish between the interactions among subsystems and those within subsystems. It is important to keep in mind that the quantities of the layers for hierarchical control design depend on the structures of the physical model and the requirements of the control systems. Three fundamental steps: decomposition, abstraction and organization instituted by Booch (2003) and Brooks (2003) originally designed for object-oriented programming can be used to establish agent-based-control system. In this paper, one additional step, combined with these aforementioned three steps, is used as a formal procedure to establish hierarchical multi-agentbased controllers for large-scale complex systems.

Step 1: Decomposition

FIGURE 2. View of a Complex System (Jennings and Bussmann 2003)

A canonical view of a complex system is as shown in FIGURE 2. The system’s hierarchical nature is expressed through the “related to” links; components within a subsystem are © 2007 by Zhang, Balestrini, Li, Weston, and Mavris.

The purpose of this step is to divide the large complex system into smaller, more manageable pieces and address each piece in a relatively isolated manner. A system can be decomposed spatially, by its components’ spatial positions, or using function analysis, or both of them simultaneously, which depends on the structures of the physical system and the objectives of the control system. For example, it is reasonable to

divide a government’s department into several bureaus using function analysis. However, a power system of a building would be better divided according to the positions of its components. For a ship’s chilled water system, considering its highly distributed components, both the spatial positions and functions of its components should be used to give a clear decomposed structure. In this step, it is important to have the control system designer work closely with the experts who are familiar with the physical system model. Using pictures to show the decomposition and rough interactions among different pieces for the controlled system will give a clear view for the following two steps. Each piece from the decomposition can be addressed relatively independently, which makes the logic of each portion clearer, easier to understand and provides a result that is closer to the actual system.

Step 2: Abstraction In this step, the aim is to design the internal logic and interface for each piece. To accomplish this, first of all, the designers need to know the objective and structure of each portion and what information it can supply. According to its objective and the information it can obtain, we must establish a relationship between its inputs and its outputs which at the same time can satisfy its objective. Since each portion is relatively small, it is easy to implement complex control methods in a relative short period of time. For example, the highest layer of the ship chilled water system needs information from the three second layer agents, i.e., the state of the whole chilled water resource, whether it is working, idle or damaged. It does not require information on whether resource 1 or resource 2 is operating nominally or any other detail on either of the two resources as long as one of the two resources is functioning properly. Similarly, the highest layer needs the state of each service load and does not require the state of each valve for a specific load service. More details about the ship’s chilled water system will be provided in the application section of this paper. This portion of the process divides a big and complex task into smaller subtasks, and each subtask can be divided further. This characteristic will © 2007 by Zhang, Balestrini, Li, Weston, and Mavris.

dramatically reduce the complexity of the design of the internal logic for each portion of the system. Here, each section includes two agents: the diagnostic agent and the planning and commanding agent. The diagnostic agent is used to analyze the input data and infer the states of that agent as well as the state of its lower level agents. It then provides that information to its planning and commanding agent to allow it to determine the best configuration under the current circumstances.

Step 3: Organization The objective of this step is to define and manage the interrelationships among various portions of the system. This step is the most challenging part in the procedure. However, if the interactions between the agents are sparse, the difficulty of establishing the relationships among various sections is alleviated considerably. Fortunately, since a complex system frequently takes the form of hierarchy; a component in a subsystem would rarely interact directly with components in another subsystem. Therefore, generally there are just direct relationships between the components within the same subsystem. Subsystems connect to other subsystems at a higher level, which makes the establishment of relationships easier to organize. Each agent has its inputs and outputs from the second step (abstraction). The third step (organization) determines where the inputs come from and where the outputs go. Using an analogy to object-oriented programming (OOP), each agent can be taken as a class. The inputs and outputs for each agent can be listed by using some conventional and understandable naming strategy, which helps to find the interrelationships among the agents. Some guidelines for OOP are similar and can be adopted for the design of agent-based control systems as for example the guidelines provided by Eckel (2003) for OOP.

Step 4: Add Auxiliary Agents This step is not necessary if the first three previous steps produced properly matched interfaces. There are three types of matching to consider when designing an agent-based control system:

1. the interfaces between the different control agents must be matched; 2. the interfaces between the control agents and the physical model must be matched; 3. and the interfaces between the control system and some other systems must be matched, e.g., the controllers for the ship’s chilled water system must interface with the power system since they will be providing it with electric power to operate. However, the control system and the physical system model are designed by different groups, so in most situations, their interfaces do not match accurately and some auxiliary agents need to be included to permit proper transformation of information between the entities. For example, one agent sends out an array of data in a specific order, but another agent will need some elements from the array or need the whole array in a different sequence. In this case, an input transformation agent may need to be used for the second agent or an output transformation agent for the first. This will reduce the complexity of the two interdependent agents and allow the designers to focus on their internal logics. Another example of where auxiliary agents are needed is the preprocessing of data with uncertainty; using a separate agent to store some extreme situations with their corresponding planning to avoid disastrous consequences will help ensure the stability of the macro behavior of the system. Therefore, auxiliary agents can make the control system clearer and more robust. All of the agents that are not shown in the decomposition result can be included under the group of auxiliary agents.

INTEGRATION From the previous step, the multi-agent-based control system is separated from the controlled physical system model. The control system as an all-encompassing agent has its own series of inputs and outputs. The input data are from the sensors which are part of the real physical system model or come from higher level agents. The output data should be sent to the actuator of the physical model or to some lower level agents. As discussed before, the input data and output data may be preprocessed or post © 2007 by Zhang, Balestrini, Li, Weston, and Mavris.

processed by input or output transformation agents that give a clearer common interface between the physical system model and the control system. A variety of integration software packages can be used to integrate the control system with the physical system model, as well as with different control systems or controller levels. Currently, plenty of commercial integration software tools are available, such as Phoenix Integration’s ModelCenter (Bigley et al. 2006), Engineous’ iSIGHT (Engineous Software, Inc. 1999), USC’s Virtual Test Bed (VTB) (Broughton et al. 2003), etc. In this paper, the implementation of the ship’s control system is built using ModelCenter. This environment is a prototype of the IEP simulation environment. More information on the IEP environment is given by Hughes et al. (2006).

TEST Each agent is relatively isolated and has its own internal logic between its inputs and outputs, so each agent should be tested individually before the organization step to ensure that each agent as a relatively independent entity works correctly. However, as discussed before, it is extremely difficult to theoretically evaluate the integrated effects of the HMABC systems – whose control behaviour emerges from the concerted activities of a myriad of agents. Even for a deterministic system, it is not practical to run all possible scenarios. For example, the ship’s chilled water system has 72 valves, 2 chillers, and 4 pumps. Assuming each valve, pump and chiller has four states respectively: open, closed, stuck open and stuck closed. Using Full Factorial Design (FFD), 478 experiments would have to be conducted to obtain all the required information. This number is more than 1045. If each case took one second to run, it would take over 3×1037 years to run all possible combinations. It is important to keep in mind that even this extremely complex problem does not consider the uncertainty in the system. A more appropriate way is to use a Monte Carlo Simulation (MCS) to run a large number of random cases, track the failed cases and analyze these in an attempt to debug and improve the control algorithm. There are two methods to select random scenarios. The first uses the initial conditions to control the damaged states of the components; the second controls the components

damage states as the simulation progresses. Since the damage scenario cannot be predicted, sufficient information to obtain statistical significance must be collected. If the first method is chosen, the initial condition should be changed in a probabilistic manner. If the second method is chosen, a certain failure rate should be assigned to each component. Both of these two methods have their own advantages and disadvantages. The first one is easy to be implemented, and it is straightforward to see the results with its corresponding damage scenario. However, the scenarios should be chosen carefully to be consistent with the situations the real system will face. The second approach requires accurate estimates for the failure rate of each component. At each simulation step, the damage scenario is different, so it is hard to collect the data and use it to calculate the required statistics. In this paper, the first method is adopted, but it is a considerable challenge to initialize the system with all of the possibilities with which is consistent with the real situations. Ensuring that a large number of outputs are correct is not only a tedious task, but it is also easy to get lost in the overwhelming amount of information. If a visualization tool can be used to display the states of the controlled system, it immensely helps the control system designers to debug and improve the designs. The role of this visualization tool is to detect the state of the physical model and display these data vividly for the designers. For this reason it does not need to send any interaction (feedback) back to the control system, since the purpose is to visualize the behavior of the system and not necessarily to interact with it.

Application Introduction The ship’s chilled water system is a very complex system that supplies chilled water to heated electronics, weapon systems, crew spaces, etc. If one is to consider a combat situation, it is easy to realize that the environment is extremely uncertain. It is almost impossible to predict all possible damage scenarios and derive and store the corresponding strategies in memory to reconfigure the system. © 2007 by Zhang, Balestrini, Li, Weston, and Mavris.

Furthermore, the chilled water system spans the entire ship, so it is a widely distributed system. Currently, this system is primarily operated and managed manually. Since manning is a considerable portion of the ownership cost of US Navy ships, manual control of these highly complex systems directly impacts the cost of supporting these assets in a significant manner. For this reason, automating the control of the chilled water system and empowering the sailors to be able to operate it more efficiently is an important goal if one is to attempt to reduce ownership costs of Navy ships. An existing Flowmaster2 model based on the Chilled Water Reduced Scale Advanced Demonstrator (CW-RSAD) model was used to test the control system developed in this study. CW-RSAD is a scaled-down version of a real ship developed by the Naval Surface Warfare Center Carderock Division (NSWC-CD) in Philadelphia. FIGURE 3 shows the layout of the CW-RSAD in the Flowmaster2 model.

FIGURE 3. Flowmaster2 CW-RSAD Model (Hughes et al. 2006)

In the model, there are 2 chilled water resources and 16 service loads. The 2 chilled water resources are identical in structure. When one resource fails, all of the service loads can obtain water from the other one by controlling the configuration of the valves. The 16 service loads are connected to both of the two resources by pipes. The route by which the service load receives chilled water from a resource is controlled by the cross valves between the service load subsystems and chilled water resource subsystems.

In reality, the pipes in the ship’s chilled water system may be ruptured. In the CW-RSAD model, the rupture is simulated by additional valves which are connected to pipes open to atmosphere. When those valves are opened, the ruptures in the pipes can be simulated. In the CW-RSAD model, there are 10 rupture valves to model the possible ruptures. Since each valve for modeling ruptures has two states: open or close, there are 210 scenarios for modeling ruptures.

The second step is to design the internal logic for each portion of the decomposition. For this problem, each section has two agents: one is named the diagnostic agent which is used to gather, analyze information and give diagnoses to its corresponding agents; the other is named the planning and commanding agent, which is used to reconfigure the system based on its own states and its environmental situation and give its proper commands to the corresponding agents.

Establish HMABC for Ship Chilled Water System

The third step is to add some auxiliary agents and integrate all of the agents. The final model of the HMABC system for the CW-RSAD model was developed in MATLAB Simulink and is as shown in FIGURE 5.

The first step is to decompose the real physical model, and the result is shown in FIGURE 4. For this problem, functional analysis and space positions are used concurrently.

8

Valv eHotS

[OutValveHotS]

Valv eCoolS

Goto [OutValveCoolS]

NLoadValv eState

Goto1 OutLoadValveSta

Valv eState

ValveState

9

PumpState

InputReOrder NResourceValv eState

PumpState

10

6

LoadsCurrentT

7

LoadsRequiredT Diagnose

Goto3 [OutPumpState] Goto4 [OutChillerState]

ChillerState

LoadValv eCom

Goto7

LoadState

Goto5

[OutLoadState]

oadValveOpenessDegre LoadValv eOpenessDegree

Whole System Diagnostic Agent

Goto10 From7 16 ServiceLoads SubSystem

Operator Operator

LoadSubCom ResourceCom

Signal Inputs Transformation Agent

OutLoadValveCom

LoadCom

1 NPumpState

LoadValv eState

From6

State

Operator

Goto2 tResourceValveS

NChillerState

ChillerState

OutLoadValveState]

LoadCurrentT

LoadRequiredT

2

LoadPriority

PumpCom

[OutValveCoolCom]

3

[OutPumpCom] Goto12

ResourceSubCom

LoadPriority

Goto6

LoadReq

[OutPumpState] OutValveCoolCom]

Valv eCoolCom

From OutValveHotCom]

Valv eHotCom

LoadRequirement NValv eCom

3 ValveCom

Valv eCoolCom

4

LoadMaximumGet

From2 tResourceValveCom] From3 [OutPumpCom] From4 [OutChillerCom]

ResourceCap

Valv eHotCom

OutputReorder NPumpCom ResourceValv eCom

[OutLoadState] PumpCom

From12 [OutValveHotS] NChillerCom

LoadSubS

5

ChillerCom

ChillerCom

From9 1

ResourceReq

From11 [OutResourceState]

From13 [OutValveCoolS]

ResourceSubS

From14

ChillerState

ChillerCom

[OutChillerCom]

ResourceState

OutResourceSta

Goto11

Valv eCoolS

Goto13

ResourceReq LoadGet

utResourceValveState]

Valv eHotS

From10 LoadValv eOpenessDegree

From5 Signal Outputs Transformation Agent

tResourceValveC

[OutChillerState]

4

PumpCom

ResourceValv eCom

Goto8

ResourceCapability

LoadValv eCom

PumpState

[OutValveHotCom]

LoadMaximumGet 5

From1 utLoadValveCom]

From8

ResourceValv eState

2

LoadGet tLoadValveOpenessDeg

Goto14 2 Resources Subsystem

Whole System Planning and Command Agent Goto9

FIGURE 5. HMABC of the CW-RSAD Model as Developed in MATLAB Simulink FIGURE 4. CW-RSAD Model Decomposition

In FIGURE 4 we can see that the entire CWRSAD model is divided into three subsystems, including the chilled water resource subsystem, the cross valves subsystem and the service load subsystem. The resource subsystem in turn can be further divided into two relative independent resources. Each resource includes two pumps, one chiller, one reservoir and several valves. The cross valve subsystem can be divided into two groups, one group includes valves in the route for the service loads obtaining chilled water from the resources and the other includes valves in the route for the service loads sending heated water back to the chilled water resources. The service loads can be divided into 16 relatively independent service loads. Each service load includes one component which needs to be cooled down and several valves. Furthermore, there are many flowmeters in the CW-RSAD model which gather information from the model. © 2007 by Zhang, Balestrini, Li, Weston, and Mavris.

The forth step is to integrate the HMABC system into the modeling and simulation environment. The CW-RSAD model and the visualization tool are both needed to demonstrate the effectiveness and robustness of the HMABC system. The HMABC system of the ship’s chilled water system is a module of the larger IEP system. More detailed information about the IEP simulation environment and how the HMABC was integrated to the environment was discussed in the reference of Hughes et al. (2006).

CONCLUSION This paper presented a formal procedure for establishing HMABC systems for large-scale complex systems and pointed out the challenges for testing and evaluating such systems. The future work will be focused on developing an efficient inference engine to account for uncertainty and incompleteness of the control

system. In a system like a US Navy ship that operates in hostile environments, or steams for extended periods of time, there are many events that can result in uncertain information used by the controllers. For example, incomplete sensor data and noise in the sensor readings are a significant source of uncertainty. At the same time, nodes as components of the communication system may fail and hinder the ability of the controllers to communicate to one another about their situations. This fact further complicates the task of developing a HMABC. It is important to capture uncertainties existing on the spread of damage in combat situation in order to reflect the real conditions that future sailors may encounter to and ensure that the systems will behave appropriately. For these reasons it is important to include a capability for the agents to account for uncertainty in the form of an inference engine. This will involve the majority of the future work.

ACNOWLEDGEMENT This paper is based on a part of research of ASDL IRIS team which is supported by the US Office of Naval Research (ONR). We would like to thank Tony Seman and Frank Ferrese from ONR for their professional support and insightful perspectives.

REFERENCES Booch, G. , “Object-Oriented Analysis and Design with Applications”, Reading, MA: Addison Wesley, 1994. Broughton, E., Langland, B., Solodovnik, E. and Croft, G., “Virtual Test Bed User’s Manual”, University of South Carolina, 2003. Eckel, B, “Thinking in Java”, 3rd edition, 2003. Brooks, F.P., “The Mythical Man-Month”, Reading, MA: Addison Wesley, 1995. Engineous Software, Inc. “Advanced iSIGHT Application Development”, Nov. 1999. http://www.sightna.com/UploadFiles/iSIGHT%2 0Training/advanced.pdf Hughes, R., S. Balestrini, K. Kelly, N. Weston and M. Mavris, “Modeling Of an Integrated Reconfigurable Intelligent System (IRIS) for

© 2007 by Zhang, Balestrini, Li, Weston, and Mavris.

Ship Design”, Ships & Ship Systems Technology (S3T) Symposium, Nov. 2006. Jennings, N.R. and S. Bussmann, “Agent-Based Control Systems: Why Are They Suited to Engineering Complex Systems?”, Control Systems Magazine, IEEE, Jun. 2003. Jiang, Z., “Agent-Based Control Framework for Distributed Energy Resources Microgrids”, IEEE/WIC/ACM International Conference, Dec. 2006. Jung, J. and C.C. Liu, “Multi-Agent Technology for Vulnerability Assessment and Control”, IEEE, 2001. Kurien, J., NASA Ames Research Center, “Model-Based Monitoring, Diagnosis and Control”, PhD Proposal, Brown University Department of Computer Science, 2001. Bigley, M., Nelson, C., Ryan, P. and Mason, W.H., “Tutorials and Examples of Software Integration Techniques for Aircraft Design using ModelCenter™”, Department of Aerospace and Ocean Engineering, Virginia Polytechnic Institute and State University, Jun. 1999. Maturana, F., R. Staron, F. Discenzo, D. Scheidt, M. Pekala, J. Bracy, and M. Zink, “An Interoperable Agent-Based Control System for Survivable Shipboard Automation”, Rockwell Automation, Applied Physics Laboratory, Johns Hopkins University, 2005. Scheidt, H.D., “Intelligent Agent-Based Control”, Johns Hopkins APL Technical Digest, Volume 23, Number 4, 2002. Van Dyke Parunak , H., “A Practitioners’ Review of Industrial Agent Applications”, Autonomous Agent and Multi-Agent Systems, ERIM Center for Electronic Commerce, 2000. Vrba, P. and Marik, V., “Simulation in AgentBased Manufacturing Control Systems”, Systems, Man and Cybernetics, International Conference, IEEE, Oct. 2005. Wang, F. and C. Wang, “Agent-Based Control Systems for Operation and Management of Intelligent Network-Enabled Devices”, Systems, Man and Cybernetics, Oct. 2003.