Dynamic operation environment — Towards intelligent adaptive production systems

Dynamic Operation Environment – Towards Intelligent Adaptive Production Systems

Eeva Järvenpää, Pasi Luostarinen, Minna Lanz, Fernando Garcia & Reijo Tuokko Tampere University of Technology

Department of Production Engineering Tampere, Finland

[email protected]

Abstract—Today’s turbulent production environment calls for adaptive and rapidly responding production systems that can adjust to required changes in products, production volumes and unexpected failure situations. Holonic manufacturing systems aim to offer a solution for changeability requirements by providing self-organizing capabilities. This paper presents a concept of a holonic manufacturing framework and its implementation into a laboratory environment. The adaptivity of the presented holonic system rests on SOA-based communication and negotiation between entities through open interfaces, and matching of resource capabilities against product requirements.

Keywords – Holonic Manufacturing System, adaptive system, capability mapping

I. INTRODUCTION Nowadays production systems are characterized by short

lifecycle times of products, small batch sizes, an increasing number of product variants and fast emergence of new technical solutions. Changing customer orders cause altering requirements concerning the output capacity and processing functions of the production systems. Today’s production systems need to be able to adapt rapidly to the required changes. Different manufacturing paradigms have been initiated in recent years to overcome these challenges. Reconfigurable manufacturing systems (RMS) aim to meet these requirements by offering rapid adjustment of production capacity and functionality, in response to new circumstances, by rearrangement or change in their structure as well as in hardware and software components [1][2][8].

Agent-based and holonic systems take more dynamic approach to cope with the changeability requirements. The holonic concept was originally developed by philosopher Arthur Koestler in order to explain the evolution of biological and social systems. The word “holon” is a combination of the Greek word “holos”, meaning whole, and the Greek suffix “on”, meaning particle or part. Therefore the term holon means something that is at the same time a whole and a part of something greater whole. [7] Translated into manufacturing world the Holonic Manufacturing System (HMS) concept views the manufacturing system as one entity consisting of autonomous modules (holons) with distributed control. The holons are autonomous entities able to fulfil their own goals, as well as communicate with other holons and form set of holons, holarchies, through common interfaces and negotiation

process. The objective has been to attain the benefits that holonic organization provides to living organisms and societies, in manufacturing, i.e., stability in the face of disturbances, adaptivity and flexibility in the face of change, and efficient use of available resources through self-organization ability. [4]

This paper aims to introduce an unique implementation of holonic architecture in a real factory environment. The implementation is based on a DiMS (Distributed Manufacturing System) concept developed by Nylund and Salminen et al. [12] [15]. Since the holons need to be able to describe themselves to other holons, ontologies are used to formalize the knowledge related to the holons and services they provide. Ontologies give a standardized way to present knowledge from different domains and knowledge sources. The CoreOntology by Lanz [10] is used as a basis for describing the product, process and system related information. However, it has been extended for describing the capabilities of the resources and lifecycle information relating to resources and certain processes.

The paper is organized as follows. Section II will introduce the basic theory behind the holonic manufacturing system framework. Section III will discuss about the method to describe and manage the resource capabilities and combined capabilities of multiple resources. Section IV will then describe the practical implementation of the holonic framework to the laboratory environment, including the description of the software system architecture and technical details of the holon implementation. Section V concludes the paper.

II. INTRODUCTION TO THE HOLONIC MANUFACTURING SYSTEM FRAMEWORK

DiMS (Distributed Manufacturing System) concept developed by Nylund et al. [12] [13] and Salminen et al. [15] is based on holonic architecture, where the holons are independently communicating entities. In DiMS the production environment is seen as dynamic and evolving open complex system, where the communication and decision making is based on negotiation process between these entities.

The DiMS is based on the Product-Resource-Order-Staff (PROSA) reference architecture by Van Brussel et al. [17], which describes a manufacturing system with three types of basic holonic entities: resource holons, product holons and

order holons. Resource holons are responsible for controlling and consuming resource capabilities. Knowledge of products, as well as processes needed to manufacture the products, are the responsibilities of product holons. Order holons hold the information on how to perform the right manufacturing task at the right time. [17]

Products represent what is offered to customers and resources are static entities of a manufacturing system, for example, machines, tools, and devices. Orders are instances of products, the dynamic entities of a manufacturing system that appear in the system, flow through the system and finally disappear. The entities are connected with the process, production, and business domains. The process domain offers the manufacturing capabilities and the production domain uses the resources efficiently to manufacture the right orders at the right times. The business domain is responsible for markets. [12]

The holonic entities (see Fig. 1), despite being involved in different manufacturing activities, have generally similar structures [15]. Each of the entities possesses self-description and capability for self-organization and communication [17][15]. The entities have internal structures consisting of digital, virtual, and real parts. The digital part contains the information and knowledge, which can be presented digitally, whilst the real part represents what exists in the real manufacturing system. The virtual parts usually present the physical parts as simulation models. While the digital, virtual, and real parts present the autonomous nature of a manufacturing entity, the communication part is the capability of the entity to collaborate in the system together with other entities. [12] [13]

Figure 1. Entities of a holonic system from different viewpoints (modified

from [13]).

III. CAPABILITY MODELING METHOD In a holonic system, resources need to describe their

capabilities to other holons in order to organize the production. Automatic mapping of available resources against product requirements requires formalized and structured representations of the functional capabilities, properties and constraints of the resources. It is evident that computer representation of capabilities of systems and their components can significantly ease the system design, integration, adaptation and operation allowing automatic methods to find suitable system components and to build alternative scenarios during early phases of system design and adaptation planning. However, presenting a simple capability of an individual resource is not enough when designing or adapting complete systems and describing the capabilities of holarchies composed

of multiple holons. Therefore a way to describe the combined capability of multiple co-operating resources is also desired.

The capability modeling method was described in detail in [6]. Capabilities are functionalities of the resources, such as drilling, milling, moving and grasping. Technical properties of the devices are directly linked to these capabilities in the ontology with capability parameters, like speed, torque, payload and so on. In other words the concept name of the capability indicates the operational functionality (behavior) of the device, whereas the parameters of the capabilities distinguish between capabilities having the same concept name. The capability parameters allow to determine which device has the capability that best fits to the given product requirement. [6]

Combined capabilities are combinations of simple capabilities, usually formed by combination of devices, such as robot and gripper. The presented approach manages the high level combined capabilities by implementing rules directly into the ontology as capability associations indicating which simple capabilities are needed for the combined capability to emerge. In the resource ontology, the devices are assigned simple capabilities that they possess. When multiple devices are combined, the simple capabilities form combined capabilities. For example robot alone has only the ability to move its joints within a workspace. When combined with a suitable gripper, together they are able to transport pieces. [6]

IV. IMPLEMENTATION OF THE CASE SCENARIO The holonic framework is implemented into TUT heavy

machining laboratory, consisting of DMG multifunctional lathe, Makino milling center, robot unit including Fanuc parallel kinematics robot and Suhner machining spindle, and FinnPower sheet metal cutting machine as a virtual resource (see Fig. 2). A detailed description of the laboratory environment is given in [14].

Figure 2. Holonic entities in the demonstration.

The main character of the built holonic system is that the status of the production system and desired goal (defined as order connected to product model) are known, but the steps for reaching the goal, in this case the routing order of the parts in the factory floor, is not predefined. The holonic system follows service oriented architecture (SOA), where the resources provide services based on their capabilities. When an order enters to the holonic framework, the system will search for those resources, which can alone, or with some other resource, satisfy the requested service. The holons will then negotiate to

determine the best resource for the given situation or the part is directed to first available resource combination that has the capability to produce the part or specific feature. The operation logic, including the reasoning phases starting from the feature recognition, is introduced in the Figure 3.

Product features (Type, dimensions,

materials, tolerances)

Required capabilities

(Concept name, parameters)

Scheduling(Resource availability on the factory floor)

Adaptation rules & user defined criteria

(Machine condition, preferred machines,

cost/speed/sustainability requirements, …)

Matching resources(Matching capability concept name and

parameters)

Suitable resources

Simulation(Testing the selections made in digital world

in virtual world)

Define

Look for

Check availability

Compare with

Digital level

Virtual level

Real level

Test

Select

FeedbackFeedback

Figure 3. Workflow in the interoperating system.

A. Software System Architecture In this demonstration the existing technologies resulted

from different projects are integrated into one operation environment utilizing holonic manufacturing paradigm for operation concept, simulation environment and actual factory floor. The whole system architecture, illustrated in Figure 4 has several different interoperating software modules each providing one or two essential functions for the whole holonic manufacturing system. The architecture is designed in such way that each of the modules can be replaced with a new module if needed. The connection of the modules is mainly based on the shared information model, the Core Ontology, described in detail in [10]. In the following chapters the developed software modules and their role in the holonic framework is discussed.

KBRDF/OWL (DL)Digital Part

MachineDBResource behavior log

Machine UI

CapabilityEditor KB Client

Measured values (F mean, F max, AE mean, AE max, g max,and g sdev, T process time)

UI/Control Holon(scheduler unit)

ProFMA Extended(Main UI)

Decision Making ToolOrdering Tool

Not Visible to usersVisible to users

Simulation

RDF/OWL (DL) RDF/OWL (DL)RDF/OWL (DL)

XML-RPC

XML-RPC

XML-RPC

XML-RPC

Simulation Scenario

ResourceKBTemplate Devices Individual Devices

Validation

Figure 4. Software system architecture.

1) KB and KB Client The Knowledge Base (KB) was designed to be a system

where data can be stored and retrieved from by different applications varying from product and process design to simulation. To achieve this design the following tools were used to facilitate the approach [9]: Apache Tomcat web server, Apache axis 2 web service engine, Jena semantic web framework, Pellet reasoner, and Postgre database. In the KB the information related to products, processes as well as systems and their capabilities is saved in a form of formal ontology, CoreOntology, modeled with Protége ontology editor. The other systems, by which the user can interact with and manipulate the information, stored into the KB, connect to the KB via Web Services. The KB Client was developed to allow viewing and light updating of the information stored into the KB through a web browser.

2) Pro-FMA Extended Pro-FMA (Professional Feature Modeling and Analysis

Tool), described in detail in [3] is used to define the product requirements from the product model given in VRML or X3D format. Product requirements are those product characteristics or features which require a set of processes in order for the product to transform towards finished product. These processes are executed by devices and combination of devices possessing adequate functional capabilities. The product requirements can be expressed by the required capabilities and their temporal and logical order. [5]

Pro-FMA has been developed in several versions. In this research Pro-FMA Extended is an extension from Pro-FMA and it is dedicated for the recognition of the features from the product model (Fig. 5) and creation of pre-process plan (Fig. 6). The pre-process plan is a generic recipe on how to manufacture the part or product. Each feature contains its characteristics – shape, type, material, tolerance and geometric dimensions – based on which the pre-process plan can be generated. [3] The pre-process plan is an ordered graph of generic activities referring to specific levels on the capability taxonomy stored in the KB. Naturally also the capability instances refer to a certain level in the capability taxonomy enabling the link between products requiring and resources providing the capabilities.

Figure 5. ProFMA Extended UI – Feature analysis.

Figure 6. ProFMA Extended UI – Pre-process plan.

3) Capability Editor In order to ease the device and capability adding process to

KB, a capability editor (Fig. 7) was developed. It allows user to add devices to the ontology and assign them capabilities and capability parameters. The capability editor allows also adding new capabilities to the ontology and enables creating associations between the capabilities, in other words creating rules about which simple capabilities are needed to form combined capabilities.

Figure 7. Capability Editor UI – adding capabilities for devices.

4) DeMO Tool DeMO Tool (Decision Making Ordering Tool) combines

virtual simulation with data coming from factory and line level. DeMO Tool has the ability to read excel file format, filled with factory or line level information, and create a virtual simulation based on that file. The simulation is created with virtual models of the resources on the factory floor, each of which is considered as a holonic element in the simulation. DeMO Tool has the capability to produce statistics and graphical data results from the ran simulation, such as production time, machine utilization rate, and more. Figure 8 shows a GUI of DeMO Tool line level simulation.

Figure 8. DeMO Tool UI – Line level simulation.

With the DeMO Tool the product orders are sent to the holonic system. Part ordering is a “TabPage” in the DeMO Tool containing controls for ordering a product from the factory floor through web services. From the order tool the user can select the product to be produced and desired area on the production floor. The tool also lists the resources on the selected area. The feature list to be manufactured is got from the Knowledge Base, where the products and their analyzed features are saved. Figure 9 shows the ordering tool GUI.

Figure 9. DeMO Tool UI – Part ordering.

5) Machine DB and Resource KB Manufacturing environment is constantly changing and the

condition and capabilities of the resources change during their usage. Therefore it is important that the description of the resource is updated over time. Machine DB is meant for storing the measured values from the factory floor. This raw data will be then filtered and relevant lifecycle key figures, such as Mean Time Between Failure (MTBF), Mean Time to Repair (MTTR), maintenance costs, reliability, operating time, estimated remaining lifetime, will be saved to the resource KB. This information can be used in the planning process of reuse and adaptation. The capability information of the individual resources is also updated based on the measured values from the factory floor.

6) UI/Control holon The UI/Control holon is the interface through which the

other software modules can communicate with the holonic manufacturing system. Users can pass requests to the holarcy through the control holon. These requests are formally defined and documented. The control holon exposes a XML-RPC interface that any UI can use to control the holon.

The control holon sends the orders to the process holon, which breaks down the product recipes into individual process steps. The process steps are machine specific routines, which can then be ordered from the machine holons in the real manufacturing environment. Figure 10 illustrates how the orders are passed from the control holon to actual machine holons.

DMG-holon Fanuc-holon Makino-holon

XML-RPC API

UI/Control-Holon

Main UI

Process-Holon

Query for RecipeSend Order

Orders* Orders** Orders***

Figure 10. Holon communication.

B. Holonic Reasoning The adaptation of the holonic manufacturing system is

resting on the capability-based mapping of product requirements and system capabilities. The mapping is based on capability taxonomy [6] connecting the product and resource domains together. Taxonomy, included into the CoreOntology, is used to make a crude search that matches the resources with required capabilities. Based on the defined capability associations, the device combinations, contributing to certain combined capability, can be identified and queried with SPARQL RDF query language. The detailed reasoning with the combined capabilities and their parameters is based on holonic negotiation process. The rules how to combine capability parameters are programmed to specialized software that follows holonic principles. This program takes the crude search results as an input, combines and filters the results and gives a list of machine-capability pairs that matches to the request at hand as an output.

Each different machine on the factory floor has its holon representation that presents that specific machine in a digital world. Detailed rules about the capabilities and their parameters are programmed to each holon. When the preliminary matches are found using ontology queries, these scenarios are tested with each holon to make sure that it can actually produce the item in question. Since the holons gather the actual lifecycle data of the machine, it can be used in the decision making process. For example, if the accuracy of the machine has not been as good as promised in the data provided

by the manufacturer, the holon can adapt new values from the history data and use those for the reasoning.

The holons require rules in which the reasoning can be based on. There are three types of rules currently under development [6]:

• Combined capability rules: Rules, which determine how the parameters of combined capabilities can be formed from the parameters of individual capabilities. The aim is not to provide detailed analysis of e.g. workspace or kinematics of the device, but to perform scenario modeling of possibly suitable devices and device combinations.

• Domain expert rules: Rules, which define how the capability and its parameter information are applied in each domain when matching with the product requirements. These rules include, e.g. in machining process domain, how the achieved feature depends on the tool shape and type.

• Adaptation planning rules: Rules defining how other criteria, such as availability and scheduling, device condition and lifecycle, as well as user and company specific defined criteria relating for example to costs, eco-efficiency or speed, is used in the final resource selection and configuration generation.

C. Technical Implementation of Holons The holons organize themselves in a hierarchical manner.

This hierarchy is called holarchy. The upper “owner” holon is responsible for arranging the holons in such a way that the desired task can be accomplished. Figure 11 gives an example of the holon organization in case of the demonstrated factory.

Figure 11. Example holarchy.

In the presented implementation the holons are running processes on an operating system and communication between the holons is done by using normal TCP/IP transport protocol. Holons communicate in a purely hierarchical way, which means that every holon creates single communication connection to the host holon. Host holon acts as an actual implementation of a specific solution as well as a message broker that relays the messages between holons connected to it.

The messages are encoded using BEncode serialization method, which is a lightweight, semi-human-readable

serialization format. It serializes strings, lists, maps and integers. Message type determines the actual fields inside the BEncoded data. However, some fields that are common in every message, like type that determines the type of the message, for example ping or mill, have also been defined. When the type of the message is known, then fields are got from documentation. For example ping has to have the return address and destination fields.

Holons will sense the world around them by using Kademlia [11] protocol implementation. Kademlia is distributed hash table that stores key - value pairs. Kademlia ensures the robustness of the system in a way that new holons and holarchies can join and leave the system without disturbing the whole system. Since every holon has globally unique id (GUID) this id can be stored as a key and IP address and port as a value. Every message type also has a GUID and some holons can answer to them. Holons are programmed to answer only small subset of questions and if holon can not answer it, it passes the question forward or discards it. In a same manner as previously, these message type GUIDs are stored as key and holon GUIDs as value. When a holon would like to have an answer for some question (request) it uses this distributed hash table to find GUIDs of the machines that can answer the question. Then it uses it again to find the port and IP where the holon can connect using normal TCP/IP protocol and send BEncoded request.

V. CONCLUSIONS The operation and business environment changes rapidly.

Ability to quickly adapt itself to new requirements has become a crucial enabler for the industry to gain operational flexibility. In order to achieve adaptability, companies and systems must be able to learn. The learning is achieved via gaining and understanding the feedback of the change. However, in order to gain and understand this feedback, the company or system must be able to compare the past status with the new status of operations. Unfortunately, in the traditional operation environments the knowledge of neither the past nor the present status is in a computer interpretable and comparable form. Therefore automatic adaptation through learning is practically impossible. Until now, the adaptation has relied on human experience and knowledge, and has therefore been highly subjective.

This paper presented a concept and case implementation of a new kind of dynamic operation environment based on holonic framework. The presented approach enables the step towards more intelligent and adaptive production systems by applying four technical solutions: service oriented architecture allowing the customers to place their orders and resources to advertise their capabilities; open interfaces; common language and structure for the communication based on the ontology; and holonic negotiation process allowing to make the match between requests and offerings and utilize other criteria for the final decision making.

ACKNOWLEDGMENT The authors would like to thank Tekes, Finland’s National

Funding Agency, KIPPcolla project and project’s consortium for support and feedback during this research.

REFERENCES [1] EIMaraghy, H.A. 2006. “Flexible and reconfigurable manufacturing

systems paradigms”. International Journal of Flexible Manufacturing Systems, Vol. 17, No. 4, pp. 261–276.

[2] ElMaraghy, H.A. (Ed.) 2009. “Changeable and reconfigurable manufacturing systems”. Springer Series in Advanced Manufacturing. 405 p.

[3] Garcia, F., Lanz, M., Luostarinen, P. & Andersson, P.-H. 2011. “Process planning based on feature recognition methods”. International Symposium of Assembly and Manufacturing (ISAM), 25-27 May 2011, Tampere, Finland, (in publication).

[4] Giret, A & Botti, V. 2004. “Holons and agents”. Journal of Intelligent Manufacturing, Vol. 15, No. 5, 2004, pp. 645-659.

[5] Järvenpää, E., Lanz, M., Siltala, N. & Tuokko, R. 2011a. ”Activities and corresponding information flows for production system adaptation planning’. Swedish Production Symposium, SPS11 May 3 – 5, 2011, Lund, Sweden, (in publication).

[6] Järvenpää, E., Luostarinen, P., Lanz, M. & Tuokko, R. 2011b. “Presenting capabilities of resources and resource combinations to support production system adaptation”. International Symposium of Assembly and Manufacturing (ISAM), 25-27 May 2011, Tampere, Finland, (in publication).

[7] Koestler, A. 1969. “Ghost in the Machine”. Published by Arkana books. [8] Koren, Y., Heisel, U., Jovane, F., Moriwaki, T., Pritschow, G., Ulsoy, G.

& Van Brussel, H. 1999. “Reconfigurable manufacturing systems”. Annals of the CIRP Vol. 48/2/1999, pp. 527-540.

[9] Lanz, M., Rodriguez, R., Luostarinen, P. and Tuokko, R., 2010. “Neutral Interface for Assembly and Manufacturing Related Knowledge Exchange in Heterogeneous Design Environment”. In: Ratchev, S.M. (Ed.): Precision Assembly Technologies and Systems, 5th IFIP WG 5.5 International Precision Assembly Seminar, IPAS 2010, Chamonix, France, February 14-17, 2010. Proceedings. IFIP 315 Springer 2010, ISBN 978-3-642-11597-4, pp 21-29

[10] Lanz, M. 2010. “Logical and semantic foundations of knowledge representation for assembly and manufacturing processes”. PhD thesis, Tampere University of Technology, Finland. 138 p.

[11] Maymounkov, P. & Mazières, D. 2002. “Kademlia: A Peer-to-peer Information System Based on the XOR Metric”. New York University, 13 p.

[12] Nylund, H., Salminen, K. & Andersson, P.H. 2008. “Digital virtual holons - An approach to digital manufacturing systems”. In: Mitsuishi, M., Ueda, K., Kimura, F. (eds.) Manufacturing Systems and Technologies for the New Frontier, The 41st CIRP Conference on Manufacturing Systems, Tokyo, Japan, May 26-28, pp. 103–106.

[13] Nylund, H, Salminen, K. & Andersson, P.H. 2009. “Simulation of service-oriented and distributed manufacturing systems”. In: Nabhani, F. (Ed.), Proceeding of the 19th International Conference on Flexible Automation and Intelligent Manufacturing, FAIM 2009, Teesside University, Middlesbroug, UK, pp. 1269-1276, 2009.

[14] Ranta, A., Ikkala, K., Nylund, H. & Andersson, P.-H. 2011. “Introduction of the CSM-Hotel Demonstration - An intelligent research and development environment”. International Symposium of Assembly and Manufacturing (ISAM), 25-27 May 2011, Tampere, Finland, (in publication).

[15] Salminen, K., Nylund, H. & Andersson, P. 2009. “Role based Self-adaptation of a robot DiMS based on system intelligence approach”. Flexible Automation and Intelligent Manufacturing (FAIM) 2009.

[16] Ueda, K., Markus, A., Monostori, L., Kals, H.J.J. & Arai, T. 2001. “Emergent synthesis methodologies for manufacturing”. CIRP Annals - Manufacturing Technology, Vol. 50, No. 2, pp. 535-551.

[17] Valckenaers, P., Van Brussel, H., Bongaerts, L. and Wyns J., 1994, “Results of the Holonic Control System Benchmark at the K.U. Leuven”. Proceedings of the CIMAT Conference, Troy, NY, USA, 128-133.

[18] Van Brussel, H., Wyns, J., Valckenaers, P., Bongaerts, L. and Peeters P. 1998. “Reference architecture for holonic manufacturing systems: PROSA”. Computers in Industry, 37: 255-274.