Abstract
When building a 3D printing cloud manufacturing platform, self-sensing and collaboration on manufacturing resources present challenging problems. This paper proposes a peer-robot collaboration framework to deal with these issues. Each robot combines heterogeneous additive manufacturing hardware and software, acting as an intelligent agent. Through collaboration with other robots, it forms a dynamic and scalable integration manufacturing system. The entire distributed system is managed by rules that employ an internal rule engine, which supports rule conversion and conflict resolution. Two additive manufacturing service scenarios are designed to analyse the efficiency and scalability of the framework. Experiments show that the presented method performs well in tasks requiring large-scale access to resources and collaboration.
1. Introduction
Additive manufacturing (AM) is the “process of joining materials to make objects from 3D model data, usually layer upon layer” [1]. It has the ability to produce parts with complex geometry that are difficult to obtain using conventional manufacturing techniques. This type of manufacturing is currently changing economic models of manufacturing in terms of prototyping in medical, electronic and various civilian areas [2]. However, the technology is developing rapidly in the AM domain, leading to the need for rapid upgrading of AM equipment. Companies need to continuously train employees in order to adapt to technical updates. In addition, the AM device itself is also extremely expensive. These costs have hindered the application of AM technology in enterprises.
Cloud manufacturing [3] is used to integrate distributed manufacturing resources, design abilities and manufacturing capabilities into a virtual services pool. This enables customers to easily access manufacturing related services, thereby cutting back on equipment updates, management and personnel training costs for the enterprises.
Compared to conventional manufacturing, AM technology is a highly integrated and automated manufacturing system. Using AM, a design in the form of a computerized 3D model can be directly transformed into a finished product without the use of additional fixtures and cutting tools. Furthermore, it combines the characteristics of a simple manufacturing process and highly integrated manufacturing crafts, which facilitates building cloud manufacturing services that connect customers and manufacturers.
AM continues to develop alongside the progress of technology and features a variety of manufacturing crafts and modelling methods [4]. The production process of AM constitutes a complex manufacturing environment, combining a large number of heterogeneous equipment and software from different vendors, as well as the manufacturing process itself. In order to virtualize AM resources (e.g., 3D printers), software (e.g., CAD and CAM) and provide an extensible mechanism for resources management, the cloud manufacturing platform must meet the following requirements:
It must feature dynamic perception during the process of accessing resources.
It must be able to automatically allocate resources based on the current resource situation within service processing.
It must be possible to resolve policy conflicts in cases where different resources have different management rules.
It must ensure the scalability of manufacturing resources.
In order to deal with these issues, this paper proposes a multi-robots system that manages the cloud platform, where each robot combines the heterogeneous AM hardware and software connected to it, acting as an intelligent agent. This design creates a dynamic and scalable integration manufacturing system through the collaboration of peer-robots.
2. Related Work
In the field of manufacturing resource (MR) access, common techniques include the use of an adapter and a wireless sensor [5], or an intelligent embedded sensor [6] and other technologies to achieve access to tools, machining centres, and other hardware MRs. Koshizuka et al. [7] used RFID and two-dimensional codes to identify object information, and used network sensors to collect surrounding environmental data for adjusting logistics service information. Tudor [8] proposed a human robot interaction-based system that allows a human operator to interact with an industrial robot in a natural way through hand gestures. In a similar manner, other researchers [9] developed an interactive prototype for controlling the loading station of a factory automation system. In this context, gesture-based interaction has the potential to free users from tedious physical controls, but it must also account for safety considerations and user perceptions.
Framework of resource integration
Subsequently, the accessed MRs should have a formalized description in order to allow the system to perceive its manufacturing capacity. Yao et al. [10], by extending the open source cloud computing platform CloudSim [11], mapped physical resources into virtual resources and published these cloud services on a service registration centre for cloud manufacturing resource users to find and use. In this domain, an ontology-based approach is also a common technology [12]. Cheng et al. [13] proposed a resource description and virtualization approach, and established a MR ontology model, using ontology information to formalize the description of MRs.
In the field of industrial MR integrated management, Kaynov [14] presented an advanced control system for a humanoid robot. The main advantage of this control architecture is the use of standardized, frequently used solutions and commercially available hardware components in the automation industry. The system takes advantage of the scalability, modularity and application of standardized interfaces and shifts the design of a complex control system of a humanoid robot from a closed laboratory setting to an industry environment. Others [15] have proposed a plug-and-play architecture; this is one of the most interesting service-oriented architectures (SOAs) available and exhibits characteristics that are well-adapted to industrial robotic cells. Furthermore, OPC UA technology has been used to build a centralized management system through the integration of lower-level equipment [16]. In a few cases, researchers [17] have adopted web services to combine low-level production resources with high-level applications, which were used to aggregate and manage MRs. For large-scale cases, Liu et al. [18] virtualized manufacturing resources using the multi-granularity method and created an aggregation algorithm to choose the most suitable MRs for complex manufacturing tasks. For manufacturing process management, Hai et al. [19] proposed the creation of a management business model, a data model and a multi-resource scheduling mechanism, along with its production management system. These were subsequently used to handle production contract management, production planning, online issues and adjustment, dynamic production scheduling, MR balance & allocation, production tracking and other functions. Additionally, Puttonen [20] proposed a method of updating domain OWL (web ontology language) models at runtime in factory automation systems.
Multidisciplinary data play an important role in manufacturing processing. Many researches have attempted to analyse and manage production systems via the technology of data-mining [21] and data dimension reduction [22,23]. In order to promote the practical application of cloud manufacturing platforms, consistent knowledge representation and big data processing must be taken into account.
In addition, there are several cloud manufacturing frameworks for resource integration that can be referenced. Ren et al. [24] proposed a cloud manufacturing resource virtualization framework and generally suggested associated methods and processes. Fan et al. [25] proposed a cloud manufacturing federation integration architecture and execution infrastructure that provided effective integration for various heterogeneous cloud manufacturing platforms. It not only realized sharing and collaboration among platform resources, but also maintained the autonomy of the system. Currently, these methods focus on researching the conceptual framework; however, a few implementation methods and mechanisms for specific applications have been proposed, especially in the field of AM.
3. Method
This paper proposes a resource integration method for AM by adopting autonomic computing based on an agent method [26] and applying management based on a rule engine. The autonomic computing system built on the agent can support large-scale open and distributed information systems to achieve dynamic service integration and cooperation [27]. The rule engine based on management is able to separate business logic from application code, thus forming an independent part, which allows for the modification, dynamic addition and removal of management strategies.
In this paper, the overall framework proposed for resource integration and management method for AM is shown in Figure 1. We used peer-robots that have the same structure and function for accessing AM resources, and use the internal rule engine to achieve the self-management and optimization of the MRs. During the configuration of resources, any robot can be upgraded to be a master robot and initiate collaboration with the neighbouring peer robot in order to complete the optimum allocation of resources. Through this mutual collaboration and interconnected access among peer robots, the role of the robots dynamically switches between master robot and collaboration robot, which forms a robot-based management system for dynamically extensible integration manufacturing. Sections 3.1 and 3.2 will detail the construction process of resource access and collaboration among robots.
3.1. AM resource access
AM is a highly-integrated and directly digitally-driven manufacturing process, where the various physical elements needed in its full life cycle constitute a set of AM resources. AM resource discovering, matching and its service requests are based on the resource description. Firstly, AM resources are divided into manufacturing equipment and its related software, according to the type of service requests. Since AM technology is in a stage of rapid development, there are many diverse and heterogeneous equipment and software available. However, many closed systems are difficult to directly access and can only be indirectly used via manual operation. Some manual operations are added in the framework as user interface elements. In addition, in order to achieve a real-time dynamic understanding of the working status of the equipment and product information, we also define a monitoring service. All AM resources are divided into AM equipment, software tools, manual processes and environmental monitoring. They are all described by an ontology model, shown in Figure 2, and which consists of status information and capability information.
AM resource information model
AM resources are described uniformly and accessed by the manufacturing system through the “resource management robot”. Its design structure is shown in Figure 3. In the resource management robot, four categories of MRs are connected to the system in the form of a resource plug-in. In specific implementations, we can make use of open source systems, OLE embedding processes and independent ways to form a resource plug-in. We use XML to describe AM resource information and the software control interface in the plug-in; internally, the plug-in uses a different technology to achieve connection to resources, eventually forming the virtual services of a robot-based manufacturing system and unified management by the virtual resource manager within the robot. In system implementation, the resource plug-in can be realized as a dynamic link library. In this way, the resource management robot maps physical resources to AM virtual resources and realizes access to resources.
AM resource management robot
3.2. Robot collaboration
AM resource integration means that any resource can be dynamically perceived and complete allocation of resources through rule-based reasoning and collaboration among robots can be achieved. To this end, we introduce two different mechanisms, one through self-management and the other through collaboration, both of which rely on the resource management robot. The former uses the self-managed resource robot through a rule engine to form a basic unit for deploying integrated MRs. The latter, through the mutual collaboration and interconnection among the peer robots, forms a rule-based management and dynamically extensible manufacturing system.
The design structure of the self-managed robot is shown in Figure 4. From a functional point of view, it consists of three parts. The first part is monitoring, which is used to sense environment changes around the robot. The second part is the event manager, which is utilized to process events and call the other auxiliary function modules. The third part is a set of auxiliary function components, which include the rule engine, knowledge base, the translator and the executor. These components work together to construct the mapping between the events and the virtual manufacturing services.
Self-managed robot
The self-managed robot starts to work by beginning with the monitoring function. The monitoring service of the self-managed robot is the foundation for achieving MR access and dynamic self-perception. The robot's monitor cyclically reads feedback information from the sensor and the resource status monitoring program. When it perceives access to available resources, it reads the corresponding resource description and updates its information in the knowledge base from the resource plug-in, and thus renders the manufacturing system aware of the resource as an accessed virtual service. When the monitor senses a change in the robot's status, it submits the change events to the event manager. The change events may be a web request from a client, the status and rule update from the client manager, or a collaboration request from other robots. All of these events will be managed under the control of the event manager. The rule engine infers and allocates resources according to current requests and the robots’ resources status, which are submitted by the event manager. At the same time, the knowledge base stores the property and status information, which is updated by the monitor. The event manager and the translator receive service requests from the application layer, and translate them into model objects that can be understood by the rule engine. Eventually, business decisions will be generated by the inference of the rule engine according to the service requests, and the executor will invoke the appropriate MRs, and then feed the request results back to the event manager.
All robots connect with each other via the local area network. When receiving a service request from the client application layer, any self-managed robot can be upgraded to a master robot and allocate service resources under the guidance of the rule engine. When a master robot cannot allocate the appropriate resources, collaboration mechanisms will be initiated, which involve sending a collaboration request to other network robots and supervising them until they complete their task. Thus, for each robot in the implementation process of self-managed tasks, there is a dynamic role conversion between master robot and collaboration robot. Eventually, this forms an expandable manufacturing system through the control unit based on the self-managed robot. During AM, some service resources will be invoked. The introduction of a rule engine serves to achieve the robot's self-managed service processing; its processing flow is shown in Figure 5.
AM services processing
4. Rule Design
Self-management of the AM service process is mainly achieved through the reasoning of the rule engine. Rule reasoning is an important branch of the artificial intelligence field, where knowledge representation and knowledge reasoning are used to simulate the thought processes of human experts and solve complex problems that are solved by domain experts. The method used in AM virtualized resource management mainly deals with the following two issues: (1) reasoning based on rules to achieve resource allocation for single self-managed robots; (2) extension of management rules to form AM domain knowledge, which is combined with collaboration among robots for the configuration of multiple self-managed robots, so that optimal use of the complete set of AM resources is achieved.
Resource allocation of single self-managed robots is based on the inference of rules; this mainly depends on the knowledge representation of AM resources and a reasonably defined rule format. An AM resource is defined as a simple first-order logic fact by way of an artificial intelligence expression. However, due to the fact that the rule engine does not directly support the necessary reasoning for an AM description format of resources, the rule's definition uses two ways to map expressions, one internal and one external. The external expression is applied to describe the business logic of the AM process, while the internal expression is applied to the rule engine's inference and conflict management among the rules of multiple robots.
The optimal resource allocation of multiple self-managed robots is mainly based on the collaboration among robots and the expansion of self-management rules. Firstly, in the proposed management system based on multiple peer-robots, the robots’ knowledge and collaboration capabilities determine their overall self-management capabilities. A single self-managed robot assesses its own manufacturing capacity and reasons out the virtual resources that may be invoked through the expansion and optimization of the rules. Secondly, considering the overall manufacturing capacity and the number of service requests, the resources will be redistributed among robots through collaboration and rule management. Finally, each self-managed robot will output the virtual resources that may eventually be invoked. Through these three steps, i.e., initial screening, collaboration reasoning and resource reallocation, the optimal allocation of MRs is achieved, and the utilization levels of MRs for each robot is improved. For example, 3DP and SLS machines are able to print multiple parts at the same time; it is more economical to deal with the corresponding service requests intensively by optimizing their configuration based on rules.
Considering the two above aspects of rule design demands, AM rules should be described in such a way so as not only to achieve scalability, but to also render them enforceable by the rule engine. In Figure 6, the design of AM self-management rule is shown, which uses first-order logic semantics and XML-based representation for users to define rules, and employs template mapping to convert these rules to the rule engine. To avoid conflicts, priority of the rules is introduced to support defeasible reasoning [28]. This will not only ensure the accuracy and effectiveness of the system, but also to some extent reduce the requirements for platform operators to grasp AM domain knowledge.
Rule design
4.1. Rule definition
The simple logical facts of AM are shown in Figure 7. Some of the properties associated with the equipment, such as the craft, material, status and so on, are described as simple first-order logic facts. For example, the “makerbot_print_seize_100_100_125“ is used to express the size of a printer named makerbot, the length, width and height of which are 100, 100 and 125, respectively. Other properties of resources such as software, manual and monitor, are also expressed in a manner suitable for knowledge representation, using the same approach.
Knowledge representation of equipment
The enforcement rules of the makerbot printer are shown in Figure 8. The rules consist of simple logic facts from the representation of equipment, the request and the action. The R1 shown in Figure 8 means that if the conditions are satisfied, the request's craft is FDM, the makerbot printer's craft is FDM and its status is leisure; then, the action of invoking this printer makerbot is executed. The capabilities and state property of resources are expressed in the form of knowledge and are applied to resource management and optimization.
Rule form
However, when a large number of facts and rules are added, there may be conflicts between the rules. Defeasible logic is used to resolve conflicts through a set of priority sequence level-n rule grade definitions. A larger priority number n indicates that the rule is of a higher grade; higher grade rules take precedence over lower priority rules. As shown in Figure 8, a conflict may occur due to the “condition” added between rule 1 and rule 2, and the “parameter value” of the match pattern being changed.
4.2. Rule reasoning
In this paper, the Rete algorithm [29], which is an efficient mode-matching algorithm used in production systems, is employed to achieve rule inference. The algorithm operates on productions and working memory elements (WME). A production is defined by a set of conditions (also called rules) that are valuated against the WME dataset and actions, which are executed when these conditions have been met. The process of reasoning is divided into two portions: the establishment of the Rete-dataflow network and the matching of facts. Prior to the establishment of the Rete-dataflow network, conflicting rules are repealed and only the highest level rules are compiled to form the network.
As depicted in Figure 9, the Rete-dataflow network, inspired by [30], comprises alpha memory, beta memory and join nodes. The alpha memory node is part of the “alphanetwork”, which acts as a predicate on the WMEs. For example, the node in Figure 9 that is defined by Condition 1 (request craft <?x>) contains WMEs that match the corresponding template (i.e., WME with attribute craft). The alpha memory treat ?x as wildcards.
The beta memory(BM) nodes contain the result of join nodes. The input to the “join” operator is the previous beta node and the corresponding alpha node. In other words, the join node filters through all the WMEs joined on variable values to the related beta nodes. This process is called left activation.
On the other hand, right activation is triggered by feeding a new WME into an appropriate alpha memory node.
The matching process is a chain reaction of either right or left activations, by the end of which all the matched WMEs are found in the production node, which is essentially the last BM node in the chain flow.
Rete dataflow network acting as a filter
Considering the complexity of developing a knowledge inference engine, we integrate a third-party engine into the framework. The self-managed robots use a translator as a bridge between the inference engine and the system to achieve integration with external systems. In this paper, we use the CLIPS rule engine as an example to illustrate the implementation of the reasoning process. The reasoning involved in self-management rules is divided into two steps: (1) the translation component extracts the self-management rules submitted by the user, as well as the system's resources and status, which are translated into rules and facts in CLIPS format, and then passed to the inference engine;(2) the rule engine makes a decision based on the current information and returns the result to the executor component. To complete the process of reasoning, as described above, the system contains user semantics and execution semantics for describing the two steps. The former provides a method for the user's regular expressions; the later provides a method for the rule engine's regular expression.
The user's semantic rule is defined using the RuleML rule template, which is shown in Figure 10. It is a scalable rule template, in which “rlab” represents the type and the priority level of rules, the “head” tag represents the conclusion or action part of the facts and the “body” represents the condition part. The condition and the conclusion are divided into a number of atoms, with each atom describing various types of attribute information, including service requests, MRs, system status, etc. By specifying a value for each attribute parameter within each atom, a Web-based store, query and use rule can be generated.
User-oriented rule template
The executable semantic rule is defined using the CLIPS rule template and is shown in Figure 11. It is a custom template, established using CLIPS syntax and it consists of a group of tables named “slot”. The various capabilities and status information of AM resources are represented by the keyword “slot”. Mapping the description information of each atom of the RuleML rule template to the “slot” attribute information of the CLIPS rule template can retain correspondence between the user and the rule engine.
Inference-oriented rule template
In order to test the feasibility of the AM resource integration method proposed in this paper, the self-management effectiveness of the designed rules and the efficiency of the rule engine executor were examined. The paper adapts the interoperable XML, which supports data conversion, to achieve the description of AM resources. On this basis, we refer to the AM producing process and construct a series of conventional manufacturing services scenes to simulate different resource allocation scenarios. Many tests were performed to test the robot's accuracy, using actions and feedback obtained from single self-managed robots.
The proposed self-management framework was built using C++, while the integrated rule engine was designed using CLIPS version 6.3. All the experimental data were obtained from a PC with an Intel Pentium 1.87GHz CPU and 2GB of memory.
4.3. An example
As shown in Figure 12, we define an XML template containing the status and capability information of the equipment. The AM resource template can also be effectively extended according to the resource type and functional characteristics. In Figure 13, we see an example XML description file of Makerbot equipment, expressing the corresponding manufacturing information.
XML template of equipment
There are two forms for expressing the equipment management rules. One form of expression, as shown in Figure 14, is based on RuleML, which is additionally based on XML. The other form, expressed in the CLIPS language, is shown in Figure 15.
XML document of the equipment
XML document of rule
CLIPS document of rule
4.4. AM service scene
The AM service scene designed for the experiments is a simulation of the environment in actual application and mainly includes three elements, which are the service resources, the system rules and the service requests. The AM service resources form the primary element of the scene and includes the equipment, software, manual and monitoring of these four MRs categories. According to the frequency of usage of these four MRs and the actual business applications of the AM process, we define a certain percentage of virtual MRs. As shown in Table 1, it is divided into three groups of comparative tests designated A, B and C; the total number of virtual resources in each group are 100, 200 and 300. The specific number of all types of resources is determined according to the type and frequency of usable resources. In practical applications, the number of MRs for each self-managed robot to connect is far less than 100; thus, it is possible to reflect the needs of actual applications in this manner.
Service resource constituents
Ruee constituents
System rules are the second element of the AM scene. In order to test the impact of managers and operators adding different duplicate and conflicting rules pertaining to resource management efficiency, the rules are divided into three groups. As shown in Table 2, the first group covers general governing and some special rules, for which the total number is 15; the second and third group, respectively, adds some special and conflicting rules based on the first group to simulate rule change and redundancy in more complicated applications. Service requests are the third element of the AM scene. In order to test the processing ability of the self-managed robots in large-scale service requests, the number of service requests starts at 500 as the base and is increased. This is used to simulate the response of the cloud platform to service requests during the real scenario.
4.5. Tests and evaluation
The AM scene test is divided into two parts, i.e., a single service request test and multiple service requests test. Both aim to test the accuracy of single self-managed robots at fulfilling the requests. The service resources and the system rules were provided to the self-managed robot; we then initiated individual service requests to the robot and observed the results of the robot's reasoning, based on the current resources’ status and rules. The test results are shown in Table 3. The test response “0” represents acceptance of the service request and the invoking of the appropriate MR; “1” represents a rejection of the service request and the initiation of collaboration. From the experimental results, we can see that the self-managed robot's rule-based inference can fully guarantee the accuracy of reasoning results.
The multiple service requests test is divided into three groups, for each of which the number of system rules was 15, while the number of service resources was 100, 200 and 300, respectively. The experimental data of each group was obtained from an average of 10 times repeated tests. The variation relationship between the self-managed robot's response time and the service requests’ number is shown in Figure 16(a). In the case of the same number of resources, the response time of the resource management robot showed a linear increase alongside the increase of service requests. Different numbers of service requests caused different response times, which ranged from 0.003 0.025s, with the number of resources increasing by 100. When the MRs in the system increase, the number of rules in the system will increase in the same time, which will decrease the speed of reasoning. The trend of these change are shown in Figure 16(b). When the number of rules are increased by 50, the resource management robot service request processing time increased, while the response time difference remained within 0.001 0.010s. Overall, the number of service requests that the self-managed robot was able to process per second ranged between 50000 to 62500.
Single service sample test
For the case where the number of virtual resources within the self-managed robot was 200 and the number of system rules was 15, the dynamic curves of resources and collaborations of the robot is shown in Figure 17, which also indicates the service requests processed by the robot. When the self-managed robot accepts service requests, resources are gradually reduced; when service request processing is completed, resources are released one by one so that they gradually increase. During homoeostasis between resources that invoke and release, the trend for the number of resources in general is a steady decline. When the number of resources for meeting service requests decreases, the robot gradually initiates collaboration. However, from the number of collaborations, it can be seen that the use of the single resource management robots was equal to the total number of used resources, divided by the total number of service requests, which was roughly 85%. Here, we note that the single resource management robot not only had good stability, but was also able to ensure the high usage efficiency of resources when the system faced large numbers of service requests.
Single self-management response time: (a) same number of rules, different number of services, and (b) same number of services, different number of rules
Dynamic curve of resource and collaboration
5. Conclusion
AM and its production patterns have highly integrated and digitally-driven features, which make it easier to build large-scale, highly scalable and on-demand integrated manufacturing systems. Based on conventional multi-agent research, this paper proposed self-management mechanisms and collaborative approaches for redefining resource nodes, and for establishing a robot-based resource integration method and its system prototyping for AM. Its main tasks include: (1) representation of AM MRs as an extensible plug-in accessed by resource self-managed robots, which helps achieve integration of heterogeneous AM resources; (2) through a self-management mechanism and collaboration, forms a scalable manufacturing system that enables a robot to dynamically perceive MRs accessing and updating.
On this premise, we defined two expressions to describe the system rules for the user and the rule engine, and also introduced defeasible logic to resolve conflicting behaviour in actual applications that have rule redundancy and accumulation. Accordingly, tests of AM service scenarios have been performed by simulating AM service processes, which show that single resource self-managed robots have good stability in large scale service requests, and can ensure highly efficient resource usage.
In follow-up studies, we will further expand the described rules and improve the mechanisms of rule input and enforcement, focusing on rule synchronization and task collaboration of large-scale self-managed robots, as well as complete additional work in practical applications.
Footnotes
6. Acknowledgements
This research was supported by a grant from the Huzhou city public key technology research projects, China(No.2013GZ02) and Public welfare technology research project of Zhejiang Province, China (No.2014C31084).