SELF- RECONFIGURABLE SOFTWARE ARCHITECUTRE: DESIGN AND IMPLEMENTATION Jungtae Mun∗, Kwangyeol Ryu, and Mooyoung Jung Advanced Product & Production Technology Center Department of Industrial Engineering Pohang University of Science and Technology (POSTECH) Hyoja San 31, Pohang 790-784, Korea
ABSTRACT: To respond quickly to the rapidly changing manufacturing environment, it is imperative for the system to have such capabilities as flexibility, adaptability, and reusability. The fractal manufacturing system (FrMS) is a new manufacturing paradigm designed to meet these requirements. Through its dynamic restructuring process (DRP), the FrMS is able to reorganize the system’s configuration by its definition. To facilitate a dynamic reconfiguration of system elements (i.e., fractals), fractals as well as software modules should be self-reconfigurable. Embodiment of a selfreconfigurable manufacturing system is achieved by using self-reconfigurable software architecture. In this paper, therefore, self-reconfigurable software architecture is designed by conducting the following studies: (1) analysis of functional requirements of a fractal and environmental constraints, (2) design of reconfigurable software architecture, (3) selection of proper techniques to implement software modules, and realization of software architecture equipped with self-reconfigurability. To validate this approach, the designed architecture is applied to the FrMS. KEY WORDS: Fractal Manufacturing Systems (FrMS), Self-reconfigurable, Reconfigurable Agent, Software Architecture
1. Introduction Today’s manufacturing systems need to adapt to the rapidly changing environment that reflects customers’ demands, unpredicted situations, incessant evolution of software and hardware, advances in infrastructures, etc. To quickly respond to the rapidly changing manufacturing environment, it is imperative for the system to have such capabilities as flexibility, adaptability, reusability, etc. Ryu & Jung (2003a) proposed the FrMS architecture that could satisfy the requirements for future manufacturing systems. The FrMS is based on the concept of autonomously cooperating agents referred to as fractals. A fractal has fractal-specific characteristics (e.g., self-similarity, selforganization, self-optimization, goal-orientation, and dynamics), and the characteristics of an agent (e.g., autonomy, mobility, intelligence, cooperation, and adaptability) at the same time. Each fractal is a set of self-similar and self-reconfigurable agents, and it interacts with other fractals to achieve individually assigned goals (Shin, Cha, Ryu, & Jung, 2003). For this reason, reconfigurability is one of the main concerns in the FrMS. The reconfiguration issues have been discussed in many areas. In computer science, Edwards & Jozwiak (2003) defined the term “reconfigurable system” to be designated to any system whose subsystem configuration can be changed or modified after fabrication. Reconfigurable systems focus on programmable hardware, and thus they have been applied to pattern recognition, image processing, signal processing, etc. A reconfigurable system deals with reconfigurability on unit levels, therefore, * All correspondence should be addressed to: Jungtae Mun, Department of Industrial Engineering, Pohang University of Science and Technology, Hyoja San 31, Pohang 790-784, Korea. Tel) +82-54279-2858, Fax) +82-54-279-5998, E-Mail)
[email protected]
they might seem to be inappropriate for manufacturing systems. In the manufacturing domain, however, a Reconfigurable Manufacturing System (RMS) is vigorously researched by a National Science Foundation (NSF) Engineering Research Center for Reconfigurable Manufacturing Systems (ERC/RMS) (Mehrabi, Ulsoy, & Koren, 2000). By definition, an RMS is designed at the outset for rapid changes in its structure, as well as in hardware and software components, to quickly adjust production capacity and functionality in response to sudden, unpredictable market changes and also to new products or new process technology introduced (Asl, Ulsoy, & Koren, 2000). Even though the RMS deals with system-level design, machine-level design, and ramp-up and calibration, the researchers in that part seem to focus on machining tools for cost-effective system. They consider CNC machines and Reconfigurable Machine Tools as the main components of the RMS. However, the FrMS is focusing on the architectural issues rather than hardware or software. This paper presents self-reconfigurable software architecture for the FrMS through: (1) analysis of functional requirements of a fractal and environmental constraints, (2) design of reconfigurable software architecture, (3) selection of proper techniques to implement software modules, and realization of software architecture equipped with self-reconfigurability. To validate this approach, the proposed architecture is applied to the FrMS. 2. The FrMS Each fractal has a self-similar functional structure composed of functional modules, which are an observer, an analyzer, a resolver, an organizer, a reporter, and a miscellaneous. Figure 1 shows a fractal in the viewpoint of both mobile agents and stationary agents, which are classified into several functional modules. All the fractals in the FrMS are connected via TCP/IP, and some of them serve as controllers. Ryu & Jung (2003a) defined 18 kinds of agents necessary to operate a system and specified fractal agents by modeling each agent with several kinds of modeling tools including IDEF0, Petri-nets, and the UML. Among them, System Agent (STA) and Knowledge Database Agent (KDA) play important roles in the dynamic restructuring process (DRP), such as agent generation, overall reconfiguration, agent installation, initiation, etc. Their functions are as follows. Fractal A
Miscellaneous
Analyzer
STA
NTA
Fractal B
REA
RSA SEA
Travel
Organizer
FSM
DRA
FAM
Fractal C
Resolver DMA
NEA
NEA
GFA
KDA
KDA
SGA
Observer
TCP/IP TCP/IP
TGA
Reporter
NMA EMA
NCA
Knowledge DB
Fractal D
ECA
Abstract function layer High level function layer Low level function layer
Mobile Agent Machine
Robot
Sensor
Stationary Agent
Figure 1 Agents of a fractal z
STA: The STA performs two main functions in its life cycle. The primary function is managing both system resources and device hardware. Secondly, it participates in agent- and module-install process. It can receive messages from all agents in the fractal. If there is a
z
request for agent generation or modification, the STA creates a vacant agent. With the help of the KDA, the STA assigns system resources and authorities to the agent and executes it to be autonomous. If the fractal serves as a controller, the STA installs or updates function layers related to control of the equipment. KDA: The KDA invokes knowledge data from the knowledge database to make decisions. It accumulates new knowledge and updates existing knowledge. If there is a request for codes to be found from the STA, it starts code-search from the fractal to all fractals by making a clone. It also delivers the ontology of agent roles in the knowledge database to the STA. When the STA creates a vacant agent, the KDA helps the agent to build the inner structure including modules necessary to perform its roles.
Figure 2 illustrates an activity diagram of the STA. At first, the STA stays in the idle state until it receives a request message of install process. If the STA receives equipment install message (e_install) it modifies its layers. When the STA receives module install message (m_install), it interrupts current process related to modules, and completes defined install process. After finished its install process, the STA starts all interrupted process again. start
Idle_STA no
msg?
[msg = e_install]
Get equipment info.
Verify repository correspondence?
yes
Install/Update layer function
Busy_STA
no
Cancel install proc.
yes Check system resources, status, environment.
Update repository [msg = m_install]
Get target module info. exist? no
Get msg
Install the module
Start the process
yes Stop the process
Figure 2 Activity diagram of the STA 3. Self-reconfigurable software architecture It has recently been recognized within the software engineering community that when a system is constructed of many components, the organization or architecture of the overall system presents a new set of design problems. Ryu & Jung (2003b) proposed self-reconfiguration methodology at the architecture level which changes or modifies overall configuration through the DRP, assuming agents and their modules are reconfigurable. Therefore, it is necessary to design fractal agents having selfreconfigurability. In many studies on reconfigurable issues, it is widely accepted that architecture comprises, mainly, two entities: components and connectors. Components act as the primary units of computation in a system and connectors specify interactions and communication patterns between components. Based on that idea, many configuration and dynamic-reconfiguration languages (or paradigms) have been developed. DURRA (Barbacci, Weinstock, Doubleday, Gardner, & Lichota, 1993) is a language and runtime support system for developing distributed applications. PCL (Sommerville, & Dean, 1996) has been designed to model the architecture of multiple versions of computer-based systems. MANIFOLD (Papadopoulos, & Arbab, 2001) is a control-driven coordination language for dynamic reconfiguration. Those are quite splendid approaches in realizing reconfigurable software; however, it is difficult to directly apply those languages to the embodiment of the FrMS because there is no way to use and combine the existing facilities yet.
An agent in the FrMS has not only agent-specific characteristics but also fractal-specific characteristics such as self-similarity, self-organization, dynamics, and vitality. When created, it has goals to achieve during its life cycle as well as abstract modules as a means to perform the goals. There are many layers in an agent structure determined by its circumstances. Modules in the high level layer call the modules in the low level layer by using information in the knowledge database referred to as roles. The roles let a module know what modules in the low level layer it can use, what modules it can communicate with, and what the task information of each module is. The main advantages of using this architecture are: (1) easy to modify or change its modules and whole configurations, (2) easy to design and implement an agent, (3) easy to add newly defined agents. However, before applying this architecture to manufacturing systems, the ontology and standards should be defined in advance. It is a quite complex and time-consuming work to build those kinds of standards and the ontology. We assume that those kinds of works are done already. In the FrMS, an agent of a fractal is quite different from that of another fractal even though two agents have the same functions. When an agent is created, it has only communication modules and decision making modules. However, as the STA endows it with specified roles, it evolves into a unique agent through the agent generation process. Figure 3 demonstrates an example of the agent generation process. When the STA receives a request for creating an equipment control agent (ECA), the STA creates a vacant agent and generates basic roles of the agent. The STA prepares system resources for the ECA, assigns them to the ECA, and then executes the ECA. After fabrication, the ECA requests the KDA modules that are necessary in performing its roles. The KDA gathers the codes (mainly modules), which satisfy the requirements of the ECA until it completes code-finding. During the codefinding process if the KDA cannot find appropriate codes, it makes a clone and lets the clone travel into the fractals for code-finding. As shown in Figure 3, module B in the ECA for the Mercury has an abstract layer similar to that in the ECA for the Conveyor, but the composition of lower level layers in the two modules are completely different. Role and knowledge in the ECA let higher level modules know what lower level modules are available. While working, each agent communicates with other agents by using its output module and input module. When created, lists of collaboration agents are stored in its knowledge space. After fabrication, the agent updates its knowledge by communicating with other agents in the lists. For example, the ECA for the Mercury updates its knowledge such as, task completion time of each control function, workspace information (share region, exclusive region, etc.), and related agents of each module. Based on the role and abstract modules, an agent can easily modify its configuration and modules. Furthermore, if new roles are assigned to the agent, it reorganizes its inner structure (referred to as self-reconfiguration) by adopting new modules which are necessary for performing given roles. Message Create
Module B for Mercury
Create Vacant Agent Request for creating ECA
Fractal C
Role
STA
Request for proper modules
KDA
Fractal X
Load Unload
Abstract Modules
Input Module Travel
Execution
Knowledge
Module A
Module C
Module B
Module D
Output Module
Module B for Conveyor Execution
UpStem RotateCW GoFront ... Grip … UnGrip
OnBlock StretchArm LowerArm … Grip … UnGrip
GetDeviceResponse(…) …
SetOuputBit(…) …
Module E Knowledge DB
Figure 3 Agent generation for the ECA
Abstract layer
Load Unload
High level layer
Low level layer
4. Exemplary Implementation A factory has many kinds of machines and controllers, which are produced by different vendors. As a result, variability becomes an important problem to be solved. Figure 4 illustrates equipment included in the FrMS test bed, the PosTROL system, located in CIM Lab. at POSTECH (visit http://cim.postech.ac.kr if additional information of equipment belonging to the PosTROL system is needed). Each piece of equipment directly interfaces with its PC-based controller equipped with PMAC card. A PC-based controller (easily adopting advanced technologies of computer networks, software engineering, web services, IT, etc.) is connected to the equipment with auxiliary devices including I/O ports, I/O interface board, motor drivers (when motors are used), and so on. By using PMAC cards, each controller can be redesigned with layer architecture, guaranteeing its selfreconfigurability. In this research, we use Java Native Interface (JNI) to make interfaces between native method libraries (usually vendor specific drivers built in C or C++) and java applications. The main operating system in a PC is the Microsoft Windows 98, for maintaining the existing control systems. Due to the FrMS based on agent technologies, we develop the main system of the FrMS with Java2 (J2SE SDK 1.4.2). It is more convenient to develop a system operating in Windows with Visual C++ but the Java language is more ideal to adopt agent technologies. Furthermore, it facilitates platform-independent systems by using virtual machine.
AS/RS TRIAC (CNC)
Buffer_2
CENTARI (robot, dof = 5)
AGV
BCS
MERCURY ORAC (Lathe)
L/U station
(robot, dof = 2.5)
Conveyor
Buffer_1
FARA A1-U (robot, dof = 6)
Figure 4 Configuration of equipment in the test bed The configuration of fractals as software for controllers is illustrated in Figure 5. All modules are developed by using the Java language, modules for stationary agents by the Java2, and those for mobile agents by the Java with the AgletsTM. The AgletsTM is one of the development tools for mobile agents, which is a Java-based platform developed by IBM Research Laboratory in Japan. When a controller manages equipment, it has a control module (a part of the ECA), including PMAC libraries, dynamic linking libraries, and JNI modules as shown in the configuration of the Controller-A in Figure 5. On the other hand, when a controller does not manage equipment, it is not equipped with the control module like the Controller-B. Stationary agents are located in the Java2 application, while mobile agents are located in the Aglets server referred to as Tahiti. Java2 application and Aglets use XML (eXtensible Markup Language) database, which contains the roles of the agents, the ontology, communication protocols, configuration information, etc. Using the XML database can ensure the efficient transfer of data to any application on any platform so that it can facilitate the development of a platform-independent system. However, most previous works on architecture for the manufacturing system has taken place in isolation, with little regard for integration with methods of ontology. Thus we assume that those kinds of information are stored in XML database except the arbitrary ontology defined by us, which is essential for operating the equipment in the test bed. We define layers and develop modules for each piece of equipment as we describe before. As a result, any controller in the FrMS can change its configuration by modifying its roles and the inner modules.
Controller-A
Controller-B
OS (Windows)
OS (Windows)
Java2 Application
Java2 Application
TCP/IP Java Native Interface (JNI) `
Aglets
Aglets
XML
XML
`
Dynamic Linking Library (C++)
PMAC Library
Figure 5 Configuration of software for fractal controllers 5. Conclusions We have briefly described the architecture of the FrMS, which is a new paradigm for evolving manufacturing environment. The FrMS can reorganize its configuration in architecture level through the DRP, which is capable of changing not only the whole structure but also the functions of each agent. Therefore we propose a software architecture of self-reconfigurable agents evolved from the module interconnection languages. In the proposed architecture, roles of an agent are important because they determine the evolution of the agent. To realize the proposed software architecture equipped with self-reconfigurability, we develop the system with the Java language using module techniques and the agents with the Aglets. Finally it is applied to the test bed at POSTECH. Acknowledgements This work was supported by grant No. 2001-1-31500-005-1 from the Basic Research Program of the Korea Science & Engineering Foundation. The authors would like to express their gratitude for the support. Reference Asl, F. M., Ulsoy, A. G., & Koren, Y. (2000). In: Proceedings of the 2000 Japan-USA Symposium on Flexible Automation (pp.1-8). Michigan. Barbacci, M. R., Weinstock, C. B., Doubleday, D. L., Gardner, M. J., & Lichota, L. W. (1993). Durra: a structure description language for developing distributed applications. Software Engineering Journal, 8(2), 83-94. Edwards, M., & Jozwiak, L. (2003). Special-issue on reconfigurable systems. Journal of Systems Architecture, 49(4), 123-125. Mehrabi, M. G., Ulsoy, A. G., & Koren, Y. (2000). Reconfigurable manufacturing systems: Key to future manufacturing. Journal of Intelligent Manufacturing, 11(3), 403-419. Papadopoulos, G. A., & Arbab, F. (2001). Configuration and dynamic reconfiguration of components using the coordination paradigm. Future Generation Computer Systems, 17(7), 1023-1038. Ryu, K., & Jung M. (2003a). Agent-based fractal architecture and modeling for developing distributed manufacturing systems. International Journal of Production Research, 41(17), 4233-4255. Ryu, K., & Jung M. (2003b). Self-reconfiguration via Dynamic Restructuring Process in Fractal Manufacturing System. Shin, M., Cha, Y., Ryu, K., & Jung M. (2003). In: Proceedings of the 8th Annual International Conference on Industrial Engineering (pp. 1034-1039). Las Vegas. Sommerville, I., & Dean, G. (1996). PCL: a language for modelling evolving system architectures. Software Engineering Journal, 11(2), 111-121.
