Modeling of service agents for simulation in cloud manufacturing

Robotics and Computer Integrated Manufacturing 64 (2020) 101910

Contents lists available at ScienceDirect

Robotics and Computer Integrated Manufacturing journal homepage: www.elsevier.com/locate/rcim

Modeling of service agents for simulation in cloud manufacturing Chun Zhao a b

1,a

b

, Xiao Luo , Lin Zhang

⁎,b

T

Beijing Information Science and Technology University (BISTU), Beijing 100101, China School of Automation Science and Electrical Engineering, Beihang University, Beijing 100083, China

A R T I C LE I N FO

A B S T R A C T

Keywords: Service agent Cloud manufacturing Simulation platform

Cloud Manufacturing is a paradigm of intelligent manufacturing system with information opening, resource sharing, and diversified services. In order to research the issues in cloud manufacturing, such as behaviors of a service provider and service consumer, matching of service, dynamic change of resource, verification of business model, scheduling of service and evolution of service network, cloud manufacturing simulation platform is widely applied. However, the method of simulation-based on agent or rule lacks to represent the characteristics of service in cloud manufacturing. This paper presents a method of integrating the service and agent to form a service agent. The service agent integrates intelligence to the service in cloud manufacturing so that it can trade autonomously and adapt itself to the environment. A simulation case of production takt is presented in the rear of the paper. It shows that the conceptual model of the service agent and the communication architecture of the service agent can build the service agent model, which can support the cloud manufacturing simulation platform.

1. Introduction

Developing of agent has accelerated the relevant research in the manufacturing field. The agent becomes an important part of cloud manufacturing[7]. Most of functions in a cloud manufacturing simulation platform are used to simulate the behavior of services. Therefore, an intelligent simulation platform should combine the concept of agent with the concept of service. Using functions and characteristics of the agent, manufacturing services are upgraded and encapsulated to form a service agent. The service agent enables service in a distributed environment to better understand the requirement of consumers and choice more appropriate behaviors. In cloud manufacturing simulation platform, the service agent can simulate the running of service and conduct the cooperation and interaction among the services autonomously. In this paper, a concept of service-agent-based modeling for cloud manufacturing simulation is presented, which includes communication of service agent, modeling of virtualized resource, modeling of manufacturing service, modeling of the service agent, modeling of service center and modeling of transaction. Using the modeling methods of service agents, many kinds of business modes can be simulated in the cloud manufacturing simulation environment. Thus, researchers can study running characteristics of elements in the cloud manufacturing environment, methods of manufacturing service composition, methods of manufacturing resource optimization and prediction of business

With the deepening of cloud-related manufacturing research, many new manufacturing models and solutions are sprung up around the world [1]. Cloud manufacturing is a typical service-oriented manufacturing paradigm. In a cloud manufacturing environment, manufacturing resource supports consumers by the form of service. Service platform is used as a core in cloud manufacturing system, provides the capability of services, such as integration, sharing and distribution, and enables the service’s interaction, collaboration, composition, trading freely. The concept of service-oriented architecture has a great effect on the development of the technologies of distributed system and integration of software system. A service is defined as a network unit, which is independent, opening and non-related with systems. The service is established in a distributed environment, which has advantages in flexibility, reusability and sustainability [2–4]. As a paradigm of intelligent manufacturing system, cloud manufacturing has the characteristics includes information opening, resource sharing and diversity of service. A cloud manufacturing platform can provide consumers with manufacturing services by manufacturing resource access from providers. In order to research issues such as verification of business model, schedule of service, evolution of service network, architectures of cloud manufacturing simulation are sprung up [5,6].

⁎

Corresponding author. E-mail address: [email protected] (L. Zhang). 1 Cloud manufacturing, modeling and simulation, embedded system. https://doi.org/10.1016/j.rcim.2019.101910 Received 9 January 2018; Received in revised form 19 November 2019; Accepted 19 November 2019 0736-5845/ © 2020 Elsevier Ltd. All rights reserved.

Robotics and Computer Integrated Manufacturing 64 (2020) 101910

C. Zhao, et al.

conceptualization of architectural description [16] are presented. Subsystems of each department in cloud manufacturing need to interact flexibly. Therefore, the concept of agent has been widely used in the manufacturing field. A manufacturing process tracking architecture based on multi-agent system and model-driven engineering is proposed and integrated into the manufacturing execution system (MES) to initiate and execute the manufacturing execution plan issued by the management tool [17]. A framework based on smart machine agent for the intelligent shopfloor is proposed[18], which used to quickly organize production, detect and handle faults without operator intervention. An architecture of theoretically-based and empirically-driven agent-based model is presented, using to study the ad hoc definitions of agent behavioral rules[19]. In order to complete the task of the agent’s cooperation, a cloud-assisted self-organized architecture (CASOA) for agent-based manufacturing system is presented, which established an ontological knowledge base[20]. On the other hand, the theories and technologies of the agent are used to solve the issues in cloud manufacturing, such as the optimization and scheduling, the service composition[21], the statistical analysis, the matching, discovery and selection of service and so on[22,23]. The literature [24] presents a multiagent-based real-time task allocation strategy based on the real-time information of the manufacturing resources, which can void the influences of exceptional events in the shop floor timely. Combine an improved contract net protocol, a multi-agent architecture is presented to solve the issue of scheduling in cloud manufacturing[25]. The protocol can support many-to-many negotiation and deal with dynamic task arrivals. The initial concept of service agent was proposed by ZHANG Lin[26]. The mean of the concept is that a service agent can meet the user’s requirement in a distributed environment and produce an appropriate behavior. Base on the expansion of the agent’s intelligent functions and characteristic, the agent makes the service upgrade to a service agent with intelligent characteristics[26]. Base on combining ontology and multi-agent system theory, the intelligent level of service dynamic combination is improved[27]. In the cloud manufacturing platform, the service agent can provide reference and support for the customer’s transaction. This paper applies the concept of service agents to the simulation environment of cloud manufacturing. In this platform, service agents can come from primary collaboration and interaction by simulating the behavior of elements in the manufacturing process. By solving the interaction problem of service agents, we can further study the characteristics of services, business modes, scheduling of cloud services, and evolution of service networks. A simulation architecture integrating industrial simulator and multi-agent system is presented[28], which can verify the effectiveness of new paradigms of manufacturing. The literature [29] presents a set of model based on agent, which can solve the issue of finding optimal agent behavior in the course of exchanges in a local economic system. In summary above, the concept of agent has been applied in cloud manufacturing platforms and cloud manufacturing simulations. However, cloud manufacturing services are different from traditional manufacturing and cloud computing services, which involve manufacturing resources for software and hardware. The current simulation environment does not fully represent the characteristics of cloud manufacturing services. In addition, current research lacks detailed methods for modeling agents, resources, services, and platforms in cloud manufacturing. In order to reflect the characteristics of services in cloud manufacturing, this paper integrates the concept of service agent into the simulation platform. Detailed modeling methods can provide references for related research in cloud manufacturing.

behavior. The contributions of this paper are as follows:

• Through modeling of resources, services and service agents, this • •

work has a very specific reference and helps for related researches on simulation of cloud manufacturing. Through building of service agent communication architecture, problems of service agent communication in a simulation environment are solved. Through application of clock, random number and other parameters, difference and randomness of service agent can be simulated.

The remainder of this paper is organized as follows. First, the related works of modeling and service agent in cloud manufacturing are summarized in Section 2. Second, concept and conceptual model of service agent are presented in Section 3. In Section 4a communication architecture of the service agent is described. Fourth, service-agentbased methods of modeling for cloud manufacturing simulation are presented in Section 5. Section 6, a simulation case is provided to show the methods of modeling above. And the simulation process is analyzed through the monitoring of the service center. Finally, Section 7 concludes the paper. 2. Literature review In artificial intelligence field, agent is an autonomous entity which can observe and respond to the environment by sensors and actuators. An agent is a rational entity that can interact with the environment and perform a task to achieve some specific purpose. In addition, it can achieve its goals by rules, learning or using knowledge. So, an agent can be used as simple or as complex according to situation. Following the emergence of object-oriented concept, many researchers believe that agent is bringing many new models for software development [8]. Today the concept of agent has been applied in many fields, such as manufacturing, real-time control system, e-commerce, network management, science calculates, health care, entertainment and so on. Agent technology can improve the capability of analysis and management in some fields. These fields generally meet the following three conditions[9]: 1. Resource has distributed characteristic. 2. Subsystems exist in a dynamic environment. 3. Subsystems need to interact flexibly. In the environment of cloud manufacturing, most of manufacturing resources, products, manufacutring capability and shopfloors have distributed characteristic. The manufacturing environment is dynamic and is influenced by customer requirements, supply chain and government policies. Especially, for service-oriented manufacturing, the service includes a series of activities. The location, communication, service providers and service demanders have to establish a series of unified models to define[10]. For the manufacturing service supply-demand, a hypernetwork model is presented, which can improve the supply-demand matching and evaluate enterprise collaboration[11]. For the issue of manufacturing enterprises modeling, a language of ”For Enterprise Modeling” (4EM) consisting of six sub-models is proposed [12], including goals model, business rules model, concepts model, business process model, actors and resources model, technical components and requirements model. an approach of engineering enterprise modeling languages is presented to analyze various enterprise [13]. A model for EMS modeling is proposed, which can define relative security levels by using subordination flow [14]. For the issues of practical challenges of processing visualization in enterprise architecture analysis and design, an architecture [15] and an extended

3. Conceptual modeling of service agent Based on the simple agent model, this section proposes a modeling method for service agents. This method extends the BDI model of a single agent at the semantic level, focusing on the behaviors of agent 2

Robotics and Computer Integrated Manufacturing 64 (2020) 101910

C. Zhao, et al.

service demander. Each function is subdivided into two behaviors that handle these two behaviors to determine how to respond. Knowledge library stores status, data and rules. The state and data are stored as a database and the rules are stored in the form of a decision tree. The service agent responds to the required events based on the rules. In Fig. 2, the service is basic business, function, or component. In order for the services to be searchable, a detailed description of the services is required. In general, the method of marking a service is an ideal way to describe the service. It not only describes the functions and attributes of the service from multiple sides, but also establishes a fast and flexible classification mechanism. The service interface is used to determine the input and output of the service. The number of interfaces per service is usually greater than or equal to 1. At the same time, the service composition can be formed after the interface is matched. Each service interface corresponds to a different environment and scenario. In addition, service status can change over time. The service state is similar to a small database that stores static and dynamic data until the service is logged out. In summary, the basic information of these services is described and recorded in WSDL. The clock controller is the stimulus trigger of the service agent, and the vibration can trigger the function of the service agent to handle each response. The knowledge library is used to store related data during the initialization and operation of the service agent. Related data includes: status data, basic data, rule data and function data. The status data is real-time status information of the service agent, such as busy/idle, enabled status, etc.; basic data is used to record the static data and basic attributes of the service agent; the rule data is in the formal description of a behavior rule for the multi-service agent in the negotiation process; function data is real-time and historical data in the process of service agent execution functions. The above four types of data constitute the basic data of the service agent. These basic data can be defined differently based on the application of service agents in different fields. The environment interpretation is used to handle the interaction between the service agent and its surrounding environment. The environment includes service centers and other service agents. The environment interprets communication with the surrounding environment through a message queue. Messages are encapsulated into message packets and stored in the message queue. Based on the service agent’s publishing and search capabilities, negotiation and transaction behavior of other service agents can be implemented. The processor is the core of the intelligence module. For different service roles, such as providers and demanders, different functions can be provided for the processor: for the service provider, there are functions of service delivery and service transaction; for the service demander, there are functions of demand publishing and demand bidding. In addition, core services have the ability to monitor and perform process tracking. For different application areas, the specific functions of the service agent need to be constructed according to the actual situation.

Fig. 1. A simple agent model.

perception, planning, action, coordination and collaboration. Through this method, a model of the instance service is established. This forms a service agent with intelligent features. This paper establishes corresponding functional modules and interfaces for the model, and implements the encapsulation of service agents. Russell S propose a basic model of simple agent[30]. The model describes the interaction between agent and environment, and the internal mechanism of agent, in Fig. 1. The model of simple agent is shown in Fig. 1. The shortage of the model is that it is based on data of current perceived behavior regardless of historical data. The rule of the function is as follows:

if → condition → then → action

(1)

As shown in the Eq. (1), this rule is valid in an open environment. Some agents contain information about their current state. The model of the agent allows them to ignore the conditions whose responders have been triggered. A service agent is an intelligent encapsulation or service driver for service. It can be used as a service demander and service provider. In addition, service agents typically play two roles in a cloud manufacturing platform to ensure they have a profitable opportunity, which makes the cloud manufacturing platform work well. The conceptual model [35] of service agent is show in Fig. 2. Service agents are centered on services. It is encapsulated on a service basis, adding to its autonomy, independence and adaptability. In Fig. 2, the service agent consists of two parts: service and intelligent module. The service part includes basic service descriptions, service interfaces, service status, and data service information. The intelligent module includes a knowledge library, an environment interpretation, a clock controller and a processor, wherein the knowledge library is used for storing state data, basic data, rule data and function data of the service agent; the environment sensor manages the collected environmental data through the message queue; The clock controller is used to generate an excitation signal that triggers related functions of the service agent; and a processor that includes service provider functions and service consumer functions. The intelligent module divides a service agent into service provider agent and service demander agent. Service agents can be used as service providers or as service consumers. Therefore, the processor of the intelligent module contains the functions of the service provider and the

4. Communication architecture of service agent The service agent which is encapsulated by the agent has characteristic of the ability to communicate independently. Therefore, communication architecture is an important technology of service agent. In order to realize the independent communication of service agent, this research builds a communication architecture of service agent, in Fig. 3. As shown in Fig. 3. The communication architecture of the service agent is divided into four layers, Includes the resource layer, service layer, service agent application layer and the network layer. The protocol of the network layer is not restricted, which it can use HTTP, TCP/ IP, UDP and other protocols.

Fig. 2. Conceptual model of service agent. 3

Robotics and Computer Integrated Manufacturing 64 (2020) 101910

C. Zhao, et al.

Fig. 3. Service agent communication architecture.

between services are completed. On the other hand, the main function of the service layer protocol is extending the content of the lower-layer protocol, is as follows:

4.1. Analysis of communication architecture for service agent 4.1.1. Resource layer The resource layer is built over the network layer, which using TCP/ IP protocol to transmit the basic data. Therefore, the communication protocol of the resource layer is the foundation of the entire communication architecture. It is defined as Service Agent Message (SAMSG). Resource layer protocol is the main way of communication among the resources, which can realize the communication for simple information. The types of communication include Request, Respond and Notification, are as follows:

SAMSG = < MSGID, Type, Sender, IDsender , Receiver , IDreceiver , Content >

Content = < Action, Msg >

(3)

Where, Action represents the behavior of the message. This work divides the service agent of the simulation platform into two roles and four behaviors. Thereinto, the two roles refer to service demander agent and service provider agent, and the four behaviors include the behavior of requirement publication, the behavior of the application for trading, the behavior of active query and the behavior of passive acceptance of trading. The details can be covered in the next section. Therefore, the four behaviors are as follows:

(2)

Action = {Msgreq , Msgtrans , Msgquery , Msgrespond}

Where, MSGID is the unique identification of message. Type is the type of message, the expression of TYPE is as follows: Type = {Request , Respond , Notification} There are three main types of messages used to complete three basic operations. Request is a request behavior that a service agent sends to another service agent for some application or for obtaining some data. Respond is the response message when the service agent receives the request. Notification is a notification message that the service agent receives without replying. It can be considered a broadcast message. Sender is the address of the sender and IDsender is the only identifier of the sender. In the same way, Receiver is the address of the receiver and IDreceiver is the only identifier of the receiver. Content represents the Content of the message. In different simulation environments, the Content of the message can be differently defined, and under the basic rules, it can be defined according to the user’s requirements.

(4)

Where, Msg is the message body. According to different behaviors, the body of message provides the different information. The JSON object is used to describe the content of Msg, and each object can be represented by a pair of key and value, are as follows: object= string1: value1,string2: value2,... array=[value1,value2,... ] Where, the curly braces are used to store objects, and the square brackets are used to store arrays, and the data is separated by commas. 4.1.3. Service agent application layer The application layer service can be considered as a high-level function of the service agent. When a service agent has the ability to handle complex transactions such as complex negotiation or game, the layer extends more functions base on the service layer. For example, when a service agent represents an enterprise, the trading in a business environment can generate communication requirements such as tenders, bargaining and so on. However, the requirements are usually not easily described by the service layer protocol, Therefore, the protocol of the service agent application layer can be extended on the basis of the protocol of the service layer. ....

4.1.2. Service layer The service layer is an upper-level protocol which can be defined by a developer. Therefore, the protocol of the service layer gives the developer a flexible space for communication among the services. However, the protocol of the service layer must strictly follow the resource layer protocol to implement the function includes search, publish, get and so on. Thus, the basic communication requirements 4

Robotics and Computer Integrated Manufacturing 64 (2020) 101910

C. Zhao, et al.

environment. It has certain intelligence, acts on the environment and executes to achieve a goal. Agents can also learn or use knowledge to achieve their goals. According to the differences of structure, function and intelligence, agents can be classified into many categories, Bauer et al. proposed five categories of service agent [31]. The service agent can be used to simulation platform and enables a service to have intelligence. The basis of trading between service agents is that their services can be matched. In the process of service execution, it also depends on real-time interaction with virtual resources. Therefore, the modeling of service agent in this paper is divided into three steps:

32 .... 47 ... .... As shown in the example above. The communication protocol of the service agent is encoded by XML. The protocol consists of two section include the head and the body. The section of head contains the basic attributes of information, such as information types, message identification, sender information and receiver information. The section of body contains the attributes of the content, such as the content, the length of the content, the encoding of the content and so on.

• Modeling of virtual resource from a manufacturing resource. This •

4.2. Parsing of the communication protocol

•

The parsing of communication protocol is an important part of the service agent communication. A service agent is services encapsulated by agent, and the service is a resource by servitization. The communication of the service agent contains three contents, includes resources, services, and service agent. Therefore, the communication protocol parsing of the above three sections is required, in Fig. 4. As shown in Fig. 4. when a service agent received a message, the parsing module first parses the section of head, includes the checking of the identification of message, verification of address of sender and receiver, verification of identification of sender and receiver. the above works validate the accuracy and target of the message. Next, the order is parsed, which the types of the order include request, response and notification. If the order is a response, the parsing module handles the order based on the preorder of it. For the parsing of the section of body, The module can parse the information of resources, services, service agents, and send them to the related unit. In summary, the SAMSG can give the developer more possible to expand, and it can transmission on the network layer or transport layer. Therefore, SAMSG is more suitable for communicating among the service agents.

process extracts the main functions of manufacturing resources and virtualizes them. Modeling of manufacturing service from a virtual resource. This process describes the function’s interfaces of virtual resources in order to it can be matched and invoked. Modeling of service agent from a manufacturing service. This process enables the service to have intelligence and autonomous trading in simulation platform.

The method of service agent encapsulation and detailed steps are as follows. 5.1. Modeling of virtualized manufacturing resource In the cloud manufacturing environment, the manufacturing resources are varied, and their description and access methods are much more complex than the computational resources in the cloud computing. In order to enable manufacturing as a service, the production status of the manufacturing resource should be monitored [11]. In the cloud manufacturing service platform, manufacturing resources are managed through the establishment of a manufacturing resource pool. Manufacturing resources will be monitored and digitized and placed in a pool of manufacturing resources to form virtualized manufacturing resources. At the same time, more and more modern manufacturing resources provide digital operating interfaces, which can be encapsulated as resource functions, and then can be invoked by application systems through service. The modeling of manufacturing resource virtualization described in this section is the first step towards the formation of service agents. Cloud manufacturing simulation platform realizes the simulation of behaviors in cloud manufacturing environment. The actual manufacturing resources can be accessed by the simulation platform, also can be simulated its behavior by a virtual resource. Without access to actual manufacturing resources, the simulation platform encapsulates a virtual manufacturing resource to simulate, which is called a virtualized resource. According to the characteristics of resources and services in the cloud manufacturing environment, we encapsulate a virtualization resource using the model of a simple agent. As shown in Fig. 5, the virtualized resource receives requests from the other virtualized resources and returns the response according to the rules. The response of the virtualized resource is generated according to its own state, which reflects the current state, and without analyzing historical data and cannot predict future trends. The model of virtualized resource is as follows:

5. Service-agent-based modeling for cloud manufacturing simulation Service agent gives the service intelligent and autonomy, which can cooperate actively. In the cloud manufacturing environment, due to the complexity and variety of manufacturing resources, and services are more diverse, and descriptions of services are more complex. In the cloud manufacturing application platform, service agents can help enterprises find partners faster with more accurately. But In the cloud manufacturing simulation platform, the service agent can simulate the behavior of service,the business model, the service composition and the evolution of the service network. The agent is an autonomous entity that responds by sensing the

RScmfg = < RSID , InfoState , Templ , Data, Func01, Func02, …, Funcn>

(5)

Where, RSID is the unique identifier of a virtualized resource used to identify a specific virtualized resource in the environment. InfoState is a resource state. Virtualized resources can define different

Fig. 4. Module of communication protocol parsing. 5

Robotics and Computer Integrated Manufacturing 64 (2020) 101910

C. Zhao, et al.

manufacturing resource and real-time information. The status is used to reflect the availability of manufacturing resources. The function is used to simulate functional feedback of manufacturing resources. 5.2. Servicelized modeling for virtualized resources The cloud manufacturing system takes service as the core, and the manufacturing service is realized by the encapsulation of virtualized resources. In cloud manufacturing environment, in order to achieve the goal of manufacturing, a service should: 1. Publish and be invoked; 2. Can be matched or applied by service descriptions; 3. Can be composited by service interfaces. According to the objectives above, a servicelized model is as follow:

SEcmfg = < SID , RSID , InfoState , Interface , InfoBasic , FuncTempl, FuncData, FuncCall, FuncOrder >

Fig. 5. A model of virtualized manufacturing resource.

states to represent the real-time status of resources. For example, Idle, Busy, Suspend. Templ is a resource template. In a cloud manufacturing environment, a resource template is an important method of manufacturing resource virtualization. A resource template is divided into static sections and dynamic sections, which are described by metadata. Each type of manufacturing resource has a unique resource template. The static section are used to record the basic description of manufacturing resources, which do not change or accumulate over time. The dynamic section are used to record data or status data generated by manufacturing resources during mission execution, such as real-time status data, maintenance data, beat data and so on. Data is the data of manufacturing resource, which is divided into static data and dynamic data like resource template, and is stored in static section and dynamic section of resource template respectively. In a cloud manufacturing environment, manufacturing resources are formed into manufacturing services through service formation, and manufacturing services collect, extract, and process manufacturing resource data in order to provide corresponding services. Funcn is the function of virtualized resources. Each virtualized resource can be made up of many functions that can be encapsulated into services. For example, print function encapsulation for 3D printer resources, is as follows:

Func = fprint (FILEstl ) → Result

(7)

SID is the unique identifier of a service in the environment. RSID is a unique identifier of a resource. The services and the resources are many-to-many relationships. That is, one resource is encapsulated into one service, one resource can form multiple services, and multiple resources can cooperate to form a service. Therefore, the RSID represents the ID of a resource or the ID of a group of resources. Infostate is the state information, which is used to describe the current state information of the service. There are five kinds of service state are as follows:

Infostate = {Check , Publish, Idle , Busy, Unavailable}

(8)

Where, Check is the state of check after a service published. At the state of check, the platform can check the feasibility and rationality of the service, and the service is in a pending state with not available. Publish is a state, which means that the service can be invoked after the platform checked, but the service is unavailable at this time. Idle is an idle state of service after the service is checked and published. When the service provider determines that the service is ready and can be invoked, the service is in this state. In addition, when the service completes an invoking and is ready for the next work, the service is in this state and the service is available. Busy is a busy state of service, which means that when the service is working and cannot accept other jobs at the same time, the service is in this state, and the service is unavailable. Unavailable service is an unavailable state, which means that the service after checked and published, the service cannot be invoked because of some reason or service maintenance caused by the temporary service, then the service is not available. Interface is the interface of service, it is an important component of a service, and is an important foundation of the composition of service. Whether the two services can be assembled is determined by the definition of the interface. In the process of service invoked, the interface of service can measure whether the output of service can meet the requirement, the structure of which is as follow:

(6)

In Eq. (6), the printing function of the 3D printer is a function provided by the 3D printer resource itself, its input is an STL file, and the output is an actual product. This function can be digitized, so the sevice can be invoked by traditional methods, and the service can be described by XML. In the cloud manufacturing environment, there are many similar methods of processing, but the input and output interfaces are very diverse and complex. Many interfaces cannot be quantized, but can only be described by semantic. The service network is formed by the complex interfaces, and there are many complex and uncertainties. In the cloud manufacturing environment, with the increasing of the digitalize capability of manufacturing resources, the more interfaces for invoking by the cloud system are provided. In the cloud manufacturing simulation platform, the simulation is performed by invoking many functions, so that the simulation environment is similar to the real environment. The virtualization of manufacturing resource is the foundation of manufacturing resource pools, the model of virtualized resource is shown in Fig. 5. As shown in Fig. 5, the virtualized manufacturing resource model consists of three basic units, include data, status and capabilities. The data including the sections of static and dynamic, the description of

Interface = Input = < ,< Interface2 , Vaule2> … < Interfacen , Vaulen > ,Rule> Output = << Interface1, Vaule1 > ,< Interface2 , Vaule2> … < Interfacen , Vaulen > ,Rule>

(9)

In Eq. (9), the interface is divided into two types of input and output interfaces. Both the input and output interfaces are composed of multiple < Interfacei, Vaulei > , Interfacei is the interface type. In the cloud manufacturing environment, the interface of manufacturing services is much more complex than that of cloud computing. Besides the traditional data type, there are many unstructured or unquantifiable types. For example, the input of a CNC machine service includes digital design 6

Robotics and Computer Integrated Manufacturing 64 (2020) 101910

C. Zhao, et al.

both application and simulation platforms. The service agent uses the intelligent functions and features of the agent to upgrade and encapsulate the service to form a service agent. In the cloud manufacturing simulation platform, service agents can collaboratively and interactively simulate the behavior of services or transactions. In order to solve the interaction problem between service agents, a lot of research on service characteristics, business mode verification, cloud service scheduling and service network evolution has sprung up. In a cloud manufacturing environment, a service agent can be either a service provider or a service demander, so the service agent has the characteristics of a provider and a demander. Therefore, there are two roles and four behaviors in the cloud manufacturing environment. Wherein, the service provider and the service demander have two roles, and the four behaviors are as follows:

documents (interface of documental), specification parameters (interface of quantifiable), processing material (interface of unquantifiable), processing location (interface of unquantifiable) and requirements of CAPP(interface of semantic description). This makes the matching of an interface very complicated, and the interface of the semantic description usually applied in a cloud manufacturing environment. Therefore, in the design of a cloud manufacturing platform, the interfaces of service are first sorted and classified. valuei is the value of the interface. According to the type of interface, the value is also expressed in many ways, such as parameters, data, data flow and semantic description. Rule is a constraint for interfaces, which can be used to check whether the input or output interface values reach a fixed range of constraints and the service can be invoked within the range. InfoBasic is the information of service description. The description of the service is used to match between the search and the requirement of the service, and is expressed in the form of data and semantic description. In the cloud manufacturing environment, the service is usually linked by labels. The relationship among the labels can be determined by classification, and the label can also form a relational network. As a result, services can be described in multiple dimensions. The internal functions of manufacturing services are mainly composed of four functions include FuncTempl, FuncData, FuncCall, FuncOrder, Compared with the computing service, in order to conduct the manufacture tasks which include the software, the hardware and the operators involved, the manufacturing service is more complicated. Through the four internal functions, the digital manufacturing task can be completed. FuncTempl is a template function that provides a description template of service for making resources, that is, provides a format of template for producing static and dynamic data for resources. Through these two types of the section in a template, a virtualized manufacturing resources can be built. This type of service is required when building digital twins or building real-time simulations. FuncData is a data function. In the cloud manufacturing environment, after virtualization of manufacturing resources, static data and dynamic data are uploaded to the cloud to form a manufacturing resource pool. The static data of manufacturing resources (means no accumulating, no changing) is a description of the basic information of resources. The dynamic data of manufacturing resources means can be accumulated and changed with time, such as power consumption, temperature, speed, maintenance, production takt and so on. Using these two kinds of data can build a real-time dynamic manufacturing resource. The data function is to summarize the required data according to the requirements of the service. In particular, the change of real-time parameters or the stability of the production takt can directly affect the service time and service quality of the service. FuncCall is an invoking function that is similar to the invoking of traditional cloud-based function. This function can be described directly from the WSDL and be invoked through the WEB. In the cloud manufacturing environment, more and more processing equipment has the digital controllable function, and has a remote access interface. This function provides the capability to invoke directly to the equipment. FuncOrder is an instruction function, in the cloud manufacturing environment, manufacturing resources are very complicated, there is a lot of equipment which cannot access to the cloud and be called ”dumb” equipment, needs software, hardware, technical personnel to complete the manufacturing tasks. Therefore the service encapsulated by such resources needs to be invoking by sending instruction, message and worksheet.

1. The behavior of demand publishing from service demanders. In this behavior, the service demander posts requirements and waits for the service provider application. Then, the service demander selects and cooperates with the appropriate service provider based on the rules. This behavior is similar to the bidding behavior in the bidding mode. 2. The behavior of a transactional application form service providers. In this behavior, the service provider can find the requirement of the service demander from the requirements bulletin. The service provider sends the transaction application and cooperates with the selected service demander. This behavior is similar to competitive bidding in a bidding mode. 3. The behavior of active inquiry from service demanders. In this behavior, the service demander can actively find the service provider and negotiate the price when the service provider responds. Finally, the two agents began to cooperate according to the agreement. 4. The behavior of passive acceptance from service providers. In this behavior, when the service demander actively finds the service provider, the service provider will respond to the current state. Finally, when the agreement was reached, the two agents began to cooperate. The above four basic behaviors can be combined to meet the simulation of the business model in the cloud manufacturing environment. These behaviors are triggered by the service agent’s clock to precisely control the frequency of each behavior in the run. The service agent model of cloud manufacturing simulation platform is as follows:

SAcmfg = < SAID, SID, Infostate , Infobasic , Msgsa, ClkSA, Funcreq, Functrans , Funcquery , Funcrespond>

(10)

Where, SAID is the unique identifier of a service agent in the environment. SID is the unique identifier of a service encapsulated by the current service agent. Infostate is the state information, which is used to describe the state information of the service agent. There are four kinds of state information. Four types of states correspond to feedback of four functions are as follows:

Infostate =

(11)

These states record the state of the service agent in different role, the details are as follows:

Statereq = {Sleep, Idle, Publish, Wait, Process, Finish}

(12)

Statereq is the state of requirement publish. When the service agent as a service consumer get feedback and update through Funcreq. This state has six kinds of change as follow: When service agent is not a service consumer and does not generate requirements, the state is Sleep. When the service agent as a service consumer and ready to publish requirements, the state is Idle. When service agent begins publish

5.3. Modeling of service agent In cloud manufacturing, resources are encapsulated into manufacturing services. In the cloud manufacturing simulation platform, the encapsulation method of service is the same as the cloud manufacturing application platform. Therefore, the servitization method is the same on 7

Robotics and Computer Integrated Manufacturing 64 (2020) 101910

C. Zhao, et al.

requirements, the state is Publish. When the service agent publishes the requirements and waits for the service provider to apply for the service, the state is Wait. When the service agent works with the service provider and starts the service, the state is Process. When the service is complete, the two side end the service and begin to evaluate, the state is Finish.

Statetrans = {Sleep, Idle, Apply, Wait, Process, Finish}

Fig. 6. Mode of message transfer.

(13)

Statetrans is the state of transaction application, as shown in Eq. (13). When the service agent as a service applicant get feedback and update through Functrans This state has six kinds of change as follow: When service agent is not a service provider and does not generate requirements, the state is Sleep. When the service agent as a service provider and ready to publish requirements, the state is Idle. When service agent begins to look for appropriate requirements, the state is Apply. When the service agent publishes the requirements and waits for the service consumer to apply for the service, the state is Wait. When the service agent works with the service consumer and starts the service, the state is Process. When the service is complete, the two side end the service and begin to evaluate, the state is Finish.

application behavior, argaining weight of the rules of both parties. Msgsa is a communication message controller between service agents, and the communication architecture is based on the architecture described in Fig. 3.

Msgsa = < ps, pe, Queuemsg >

The messages are stored in a message queue. The system message queue stores all the messages in the system based on the time sequence. When the clock of service agent ClkSA generates a trigger, the message controller in service agent can transfer the new message from the system message queue to the service agent message queue. In Eq. (17), the ps and pe are pointers to the system message queue, which are used to record the start and end positions of the last message in the system message. Queuemsg is the message queue of service agents, which records the own messages of a service agent. As shown in Fig. 6, SAiMQ is the message queue of the service agent and SCMQ is the message queue of the service center. During the communication between service agents, the message queue of the service center can collect the new messages. When the clock of service agent generates a trigger, the service agent transfers the message sent from the message queue of service center SCMQ to the message queue of service agent SAiMQ. In Fig. 6, service agent SAi finds its own message at the time tm, the length of the new messages is j. The new message is copied to the tl of the message queue of service agent SAiMQ, and the last values of start and end location of the message queue are stored in the values psi and pei. Next, SAi received another new message at the time tn, the length of new message is k. So the SAi copies the message to the location of tl + j in the message queue of service agent SAiMQ, and updates the last start and end location of the message into the values of psi and pei. When the service agent SAi triggers the function of Func, the latest messages and historical messages are processed from the current SAiMQ. ClkSA is a clock of service agent, and different service agent has different clock frequencies. when the clock is triggered, a function of Func can be invoked. On the other hand, the clock can represent the response speed of a service agent. In the process of simulation, it can reflect the execution speed of an enterprise, the update speed of a service or the running capability of a virtual machine. As shown in Fig. 7, There 4 service agents with a different clock. In the figure, the service agent SA1 sends a demand of Task1 at time of t0, and the others service agent respectively activate the Apply1 at the different time. Because of the different frequency, the order in which

Statequery={Sleep, Idle, Search, Negotiate, Process, Finish}

(14)

Statequery is the state of active inquiry, as shown in Eq. (14). When the service agent as a service consumer get feedback and update through Funcquery This state has six kinds of change as follow: When service agent is not a service consumer, does not generate requirements and not ready to actively seek services, the state is Sleep. When the service agent as a service consumer and ready to publish requirements, the state is Idle. When service smart creates new requirements and starts looking for service providers, the state is Search. When the service agent finds and starts negotiating with the relevant service provider, the state is Negotiate. When the service agent works with the service provider and starts the service, the state is Process. When the service is complete, the two side end the service and begin to evaluate, the state is Finish.

Staterespond={Sleep, Listen, Accept, Negotiate, Process, Finish}

(15)

Staterespond is the state of passive acceptance, as shown in Eq. (15). When the service agent as a service applicant get feedback and update through Funcrespond. This state has six kinds of change as follow: When service agent is not a service provider and is not ready to provide services, the state is Sleep. When the service agent as a service provider and is ready to accept the request, the state is Listen. When the service agent receives a request from the service consumer and ready to negotiate the price, the state is Accept. When the service agent starts negotiating with the relevant service consumer, the state is Negotiate. When the service agent works with the service provider and starts the service, the state is Process. When the service is complete, the two side end the service and begin to evaluate, the state is Finish. Infobasic is the basic information of service agents. Unlike the state information Infobasic, Infobasic is constantly updated and switches between several states. Infobasic is more like a database, storing some basic descriptions, rules and data, is as follow:

Infobasic = < DATAbasic , DATArule , < DATAreq , DATAtrans , DATAquery , DATArespond > >

(17)

(16)

DATAbasic is the basic information used to store the basic information of the a service agents, such as name, description, location and so on. DATArule is the rule information, which is used to store the behavior rules of the current service agent, such as response speed, random number MOD. In addition, some data and rules for four behaviors are stored: . For example, The selection weight of the service provider when the requirements are published, The weight of choice of service users for transaction

Fig. 7. Task sequence diagram of service agent. 8

Robotics and Computer Integrated Manufacturing 64 (2020) 101910

C. Zhao, et al.

Functrans = ftrans [ftriger (MODtrans ), SAID, SID ,

the SA1 receives Apply1 is SA2, SA4 and SA3. Next, the SA1 sends a demand of Task2 at the time of t1. The order in which the SA1 receives Apply2 is SA4, SA2 and SA3. Such different clock settings can increase individual differences in service agents while increasing the randomness of events. Func is the basic behavior of service agent, which represent by 4 types of function. When the CLKSA is triggered, the Func is invoked to perform a task. The behavior of the Func only indicates that the process of negotiation between the service agent. it is not related to the service. In order to enhance the randomness and individual difference of the service agent, the trigger function is added to Func except for added different clocks. When the clock excitation function executes, the Func first performs the trigger function. if the trigger function is true, the Func can execute. And if the trigger function is false, it can not be executed. As shown in Eq. (18).

TRUE random%x = 0 ftriger = ⎧ FALSE (random%x ) ≠ 0 ∪ x = 0 ⎨ ⎩

Statetrans , Infobasic ]

As shown in Eq. (22), the input of function shown below. The result of ftriger(MODtrans) is used to determine whether the function can be invoked. SAID is the identity of the service agent and SID is the identity of the service. The state of transaction Statetrans is used to determine which phase of the transaction process the service agent is going through. The Statetrans can be updated when the function being executed. The basic information Infobasic can read the relevant data during the process of the transaction. In the same way, The Infobasic can be updated when the function being executed. Funcquery is a function of the active query. The function is triggered when the service agent as a service consumer.

Funcquery = fquery [ftriger (MODquery ), SAID, SID , Statequery , Infobasic ]

(18)

Funcrespond = frespond [ftriger (MODrespond ), SAID, SID , Staterespond, Infobasic ]

(19)

Funcreq = freq [ftriger (MODreq), SAID, SID , (20)

As shown in Eq. (20), the inputs of the function shown below. The result of ftriger(MODreq) is used to determine whether the function can be invoked. SAID is the identity of the service agent and SID is the identity of the service. The published state of a requirement Statereq is used to determine which phase of the requirement publish process the service agent is going through. The Statereq can be updated when the function is executed. The basic information Infobasic can read the relevant data during the process of requirement publish. In the same way, The Infobasic can be updated when the function being executed. In the execution process of the function of Funcreq, the function needs to choose the top evaluation of the service provider as a partner. The utility evaluation model is shown in Eq. (21). m

U(i, j) =

∑ (1 − k

Pki ) × ω P kj Max (Pkn )

(24)

As shown in Eq. (24), the inputs of the function shown below. The result of ftriger(MODrespond) is used to determine whether the function can be invoked. SAID is the identity of the service agent and SID is the identity of the service. The state of passive trading Staterespond is used to determine which phase of passive trading the service agent is going through. The Staterespond can be updated when the function is executed. The basic information Infobasic can read the relevant data during the process of the passive trading. In the same way, The Infobasic can be updated when the function being executed.

Eq. (19) represent the trigger random number in the function of ftrigger, the MODreq, MODtrans, MODquery and MODrespond represents the input parameter x of ftriger in the 4 types of function respectively. Funcreq is the function of requirement publish. The function is triggered when the service agent as a service consumer.

Statereq, Infobasic ]

(23)

As shown in Eq. (23), the inputs of the function shown below. The result of ftriger(MODquery) is used to determine whether the function can be invoked. SAID is the identity of the service agent and SID is the identity of the service. The state of active query Statequery is used to determine which phase of active query the service agent is going through. The Statequery can be updated when the function is executed. The basic information Infobasic can read the relevant data during the process of the active query. In the same way, The Infobasic can be updated when the function being executed. Funcrespond is a function of passive trading. The function is triggered when the service agent as a service provider.

In Eq. (18). ftriger is a segmented function. The function input is x, which is a random number based on the current time. The function takes the modular operation with x. If the modular is 0, represent the x can be divisible. In this point, the returned value of ftriger is true. If the modular is not 0, the returned value of ftriger is false. In addition, if x is 0, the returned value of ftriger is false, which represents that current behavior cannot be enabled. In simulation environments, if some service agent only has one behavior. The 4 types of function are shown below: Funcreq, Functrans, Funcquery and Funcrespond. There is a set of state parameter of DATArule in the Infostate. Among them,

MOD = < MODreq , MODtrans , MODquery , MODrespond>

(22)

5.4. Modeling of service center In the cloud manufacturing simulation, a service center is the management center of service agents. The service center provides bulletin, environmental information, messages and other information for service agent. As shown in Eq. (25).

SCcmfg = < ClkSC , Msgsc , Infoenv , Bulletinreq, Bulletinservice , Funcsample, Funcreqpub, Funcspub, Funcgetinfo>

(25)

ClkSC is a clock of the service center, and also the environment clock of environment for cloud manufacturing simulation. The clock can trigger the Func in service center work and perform the related tasks. As shown in Fig. 8. A service agent SA1 publishes a requirement of Task1 at the time of t0. The service center SC returns bulletin information at the time of t1. SA2 triggers the transaction function and find a requirement. So the SA2 sends a application Apply1 at the time of t1. SA3 triggers the transaction function and sends a application Apply1 at the time of t1. When the SA1 makes a decision at the time of t2, the SA2 and SA3 received the selection results at times of t4 and t2 respectively. The function of SC can collect the action of the service agent in the simulation environment. The SC triggers the Func at the time of t0, t2, t4, t8, t24, t26, t28 and t32. And the dynamic information in the environment are collected.

(21)

Where, U(i,j) is the score of utility evaluation. Service consumer SAj evaluates service provider SAi based on the rule weight of SAj. P is the evaluation element, such as quality, price, service time and so on. There are m types of evaluation element, Pki is the evaluation element k of P ki is the normalized value of several service service provider SAi. Max (P kn)

providers. n is the total of the service providers. ω P kj is the weight of the service consumer SAj for the index k of evaluation element. Functrans is the function of the trading a transaction. The function is triggered when the service agent as a service provider. 9

Robotics and Computer Integrated Manufacturing 64 (2020) 101910

C. Zhao, et al.

where, the Msgreq includes SAID and Siparam. SAID is the unique identity of the service agent who publishes the requirement. Siparam is the parameters of the output interface of requirement. freqpub insert the above information to the Bulletinreq, which is used to be inquiried by the service provider. Bulletinreq is a information bulletin of requirements, which is used to store the information of requirements published by the service consumer.

Bulletinreq =

(32)

In Eq. (32), SAID is the unique identity of the service agent who publishes the requirement. Siparam is the parameters of the output interface of requirement. When a service provider finds some requirements, Siparam is used to match the output interface with the interface of service provider. If the requirement is met, that means the service agent can provide the service.

Fig. 8. Task sequence diagram of service center.

The clock of service center is the equivalent of the environment clock, at least twice as often as the fastest service agent clock to meet the Nyquist Shannon Sampling Theorem. Therefore, when building the clock of service agent, it should be satisfied with the conditions of Eq. (26).

State = {Running, Finish, Expire}

(33)

Msgsc is a controller of message for the service center to collect messages between service agents.

The State is a state of requirement with 3 states includes Running, Finish and Expire. Among them, The Running is a state that the requirement is waiting for application without forming a trading. The Finish is a state that the requirement has created a transaction. The Expire is a state that the requirement has expired and failed to find the service provider.

Msgsc = < Queuemsg >

Funcspub = fspub (Msgservice )

Clksc⩾2 × Max (Clksa)

(26)

(27)

The message queue of service center is similar to the queue of service agent, message queue of service center records all messages among the service agents include publish, accept, query, respond and so on.

Funcspub is the function of the service publishment. When request from a service provider is received, the service center calls the function. As shown in Fig. 34, the input of the function is the message of service publishment.

Infoenv = < Quantityreq , Quantityapply , Quantityquery , Quantityrespond >

Msgservice = < SAID , Siparam>

(28)

Bulletinservice =

State = {Available, Suspend}

(37)

The State is a state of service with 2 states includes Available and Suspend. Among them, The Available is a state that the service is available and can work for a service consumer. The Suspend is a state that the service is suspend and can not work. The state of the service bulletin only reflect the availability of a service and cannot reflect the leisure of the service. The leisure state of the service can only be obtained through communication between the service consumer and the service provider.

(29)

Funcgetinfo = fgetinfo (void )

(38)

Funcgetinfo is a function to get information about the service center. As shown in Eq. (38). The result of the function is a pointer which includes Infoenv, Bulletinreq and Bulletinservice. The service agent can query the relevant information through the pointer. The service provider can obtain the information of the Bulletinreq and query the requirements. The service consumer can obtain the information of the Bulletinservice to find the available services. Each service agent can get the real-time status and historical data of the simulation platform through Infoenv and make decisions based on it.

(30)

Funcreqpub is a function of the requirement publishment function. When request from a service consumer is received, the service center calls the function. The function input is the message of requirement publication.

Msgreq = < SAID , Siparam>

(36)

In Eq. (36), SAID is the unique identity of the service agent who publishes the serivce. Siparam is the parameters of the input interface of service. When a service consumer finds some services, Siparam is used to match the input interface with the interface of service consumer. If the service is met, that means the service provider can provide the service.

Funcsample is a sampling function that collects and stores real-time information of the environment. As shown in Eq. (29). When the clock Clksc is triggered, the function can be stimulated, the input is the pointer of the environmental information Infoenv, and the sampling function can store the collected real-time information.

Funcreqpub = freqpub (Msgreq)

(35)

The Msgservice includes SAID and Siparam. SAID is the unique identity of the service agent who publishes the service. Siparam is the parameters of the input interface of service. freqpub insert the above information to the Bulletinservice, which is used to be inquiried by the service consumer. Bulletinservice is a information bulletin of services, which is used to store the information of services published by the service proficer.

Infoenv is the environmental information register for the service center, which is used to store the real-time data and historical data of the environment. Environmental information is a data queue consisting of 4 elements include Quantityreq, Quantityapply, Quantityquery and Quantityrespond. The environmental function is Funcsample, the clock can trigger the data collection. Because the environment variable clock frequency meets the Nyquist Shannon Sampling Theorem, every action of the service agent can be collected. Quantityreq is a total of the real-time requirements. It used to record the total of requirements published by the service consumer without creating a transaction. Quantityapply is a total of the real-time applications. It used to record the total number of applications sent by the service provider without creating a transaction. Quantityquery is a total of the real-time active queries. It used to record the total number of service consumers who are looking for a service provider. Quantityrespond is a total real-time passive transaction. It used to record the total number of service providers who are being asked or negotiating for a transaction.

Funcsample = fsample (Infoenv )

(34)

(31) 10

Robotics and Computer Integrated Manufacturing 64 (2020) 101910

C. Zhao, et al.

toolbox. In this section, a case about the issue of production balance is proposed, which uses the cloud manufacturing simulation platform based on modeling of service agent. In the trading of service agent, a provider agent can provide the services to a consumer agent. In the running of the service, the overall execution time of service is affected by the execution time of each step in the service. In the manufacturing environment, heavily using product line to complete the tasks of manufacturing. The imbalance and instability of the product line can cause the production to be blocked, which can lead to suspending or mistake, and it may even affect other production lines[32–34]. In the cloud manufacturing environment, a production line is composited by several manufacturing resources, and the production line is encapsulated as a manufacturing service. In the running of a set of service, the production takt can be used as the basis of service monitoring. When individual manufacturing resource (such as CNC machine) is encapsulated into a service, manufacturing resources run tasks in the fixed processing sequence(such as g-code). The time of each execution segment or instruction can be used as a separate production takt, which is a basis of the service monitoring. In the process of production, the total execution time is composited of the time of each procedure. A service agent needs to check the time of each procedure, in order to react in time when there is an exception in the execution of the service.

Fig. 9. Conceptual model of simulation platform.

6. Case study In the previous work, we built an agent-based cloud manufacturing simulation platform [6]. The platform enables the functions to include simulation, data storage, visual output and so on. In this paper, we improve the system and clarify the encapsulation of resources, services and service agents, especially the architecture of message. After improvement, the conceptual model of cloud manufacturing simulation platform is shown in Fig. 9, which consists of three types of roles, three types of actions and one core. Three types of roles include service center, service demander agent and service provider agent. The three actions include publishing, finding and communicating. One core is ontology knowledge library, which establishes an ontology tree using OWL to describe services and service agents. The basic modules of the simulation platform are shown in the Fig. 10. The platform is developed by Visual Studio, providing visual output and operation interface. Enabling the management through the technology of database include realizing real-time data, historical data and operation data, in order to ensure long-term stable operation of the platform. Among them, the background function is used to support platform operation, including data sampling, resource and service operation and message management. In addition, the technology of multi-threaded is used to drive the service agent to run. The front functions enable functions such as user interface, data generation, chart output, secondary development interface and so on. The real-time data, control data and historical data of the simulation platform are stored in the database to support the simulation platform operation. In addition, the simulation platform also includes a simulation auxiliary toolbox and a management auxiliary

6.1. Modeling of trading In the cloud manufacturing simulation, the two service agents finally realize the transaction through negotiation. After the completion of the transaction, some typical transaction can be used as a case transaction have been saved to provide references for other users.

T(i, j) = < TID , SAIDi , SAIDj , SID, Bulletinreq, Timebegin, Timeend , State>

(39)

Eq. (39) presents a modeling of the transaction, where: TID is the unique identity of a transaction, is used to determine specific transactions in the environment. SAIDi is the unique identity of the service provider, SAIDj is the unique identity of the service consumer. SID is the unique identity of the service which is provided in the transaction. Bulletinreq is the unique identity of the requirement in the publishment bulletin. If the execution of the transaction is based on the requirement, Bulletinreq can record the identity of the requirement. However, some transaction comes from the active query by the service consumer. At this point, the value of Bulletinreq is Null. Timebegin is the start time of the transaction, the time refers to service center clock ClkSC. Timeend is the end time of the transaction, the time refers to service center clock ClkSC. State is the state of the transaction, includes 5 types of state, are as follows:

State = {Process, Finish, Evaluate , < Archive , Close > }

(40)

Process is a state of the transaction means the transaction has started. Finish is a state of the transaction means the service is completed, the transaction is completed too. Evaluate is a state of the transaction means the transaction is being evaluated. The model of transaction evaluation is shown in Eq. (41).

Ev (Tc ) =

∑in= 1 [ Timei − ( SAtimei + SEtime ) ] 2 n × [ Timec − ( SAtimec + SEtime ) ] 2

+ ereq × ωreq + epro × ωpro

× ωtime (41)

Where, firstly, the error between the service time Timei of the transaction i in the transaction set T and the scheduled completion time is calculated. Secondly, The ratio of average error of all transaction time

Fig. 10. Basic modules of simulation platform. 11

Robotics and Computer Integrated Manufacturing 64 (2020) 101910

C. Zhao, et al.

Fig. 11. Changing of the state.

errors in set T and the error of the service time of the transaction c is calculated. If the ratio more than 1, the error of the transaction c less than the average error, and vice versa. Thirdly, both of the evaluation score of the service consumer of the transaction c and the evaluation score of the service provider of the transaction c are added. Fourty, the weights include ωtime, ωreq and ωpro are multiplied respectively. Finally, the evaluation score Ev(Tc) of the transaction c is obtained.

Fig. 12. Simulation processing of service.

n

Ev (Tc ) > Min (Ev (T )] +

∑ Ev (Ti ) 1 ×{ i − Min [Ev (T )]} 2 n

the SPrate of past-procedures, in Table 1. As shown in Table 1, there are differences between the actual time and the planned time, and the balance rate of service execution fluctuates accordingly. The processing of the service is shown in Fig. 12. In the figure, the planned time of the service is represented by the ball, the actual time is represented by the prism. As shown in Fig. 12, sometimes the actual time is more of the planned time, and sometimes the actual time is less of the planned time. In the actual production, due to the replacement of fixtures, manual participation or other factors, the conditions above often occur. Therefore, the balance rate of service execution can be changed. As shown in Fig. 13, SPrate keeps changing in the processing of service. It can be seen from the figure that the actual time is more than planned time in the initial procedures. Therefore, the SPrate is also relatively high at the beginning and gradually becomes stable as the processing of service continues. The service agent provides the monitoring of the processing of service. When the service agent finds the exception, it can immediately adjust by notifying the operator or reducing the wait time during service processing. In the cloud manufacturing simulation platform, the balance rate of service execution SPrate is an important parameter affecting the processing of the service. By adjusting the SPrate, the processing of service in the actual manufacturing environment can be simulated.

(42)

In Eq. (42), Min[Ev(T)] is the minimum value of the evaluation score in the case library. If the evaluation score of the transaction c is greater than half of the difference between the average value of the evaluation score and the minimum value, it can be a case transaction. Through the evaluation of the transaction, some typical transaction can be stored as case transaction. Where, the State can be set to Archive. Other transactions can be closed as a normal transaction, the State can be set to Close, shown in Fig. 11. 6.2. Simulation for service agent With the development of IoT, the dynamic data provided by manufacturing resources can be used to describe the process of production. This information can be traced to the production takt (such as the time of each process) of the manufacturing resources. The service agent can get the data of production takt by invoking the data function in the service. Comparing the current production takt with the average production takt in historical data or the production takt of the service plan, the balance rate of service execution defined as SPrate can be obtained. The rate can be used to monitor the stability of a service process, is as follows: k

SPrate =

∑i = 1 Pi − Ri k

× 100%

k

k × ∑i = 1 Pi − ∑i = 1 Ri

(43)

7. Conclusions

Where, Pi is the planned time of procedure of i, Ri is the actual time of procedure of i, k is total of procedures. the balance rate of service execution should focus on the difference between the actual time and the planned time of each procedure. First, the sum of the difference is k obtained by ∑i = 1 Pi − Ri . Second, the average of the difference is ob∑k

Services evolved into service agents through encapsulation of agent and have many characteristics of intelligence such as autonomy, independence, and adaptability. Service agents can proactively self-assemble and self-schedule according to their needs, thus reducing the burden on the service registry. In a system without a central or weak center, the advantages of the service agent can be more reflected, and components can be formed quickly and efficiently to meet the needs of demanders. There are many differences in the service agent modeling between the cloud manufacturing application platform and the cloud manufacturing simulation platform. Based on the concept of service agent, a conceptual model of service agent in cloud manufacturing simulation environment is proposed in this paper. In order to enable the service agent to communicate in the simulation environment, the

P − Ri

. The average of the difference can represent the tained by i = 1 i k distance between the planned takt and actual takt. Finally, the balance rate of service execution SPrate can be obtained by the ratio between the average difference and the difference of the sum of planned time and the sum of actual time. The case in this section includes 12 procedures. The planned time of each procedure is defined P. The actual time of each procedure is defined R. In the processing of production, the service agent can calculate Table 1 The production takt of the case. Procedure

1

2

3

4

5

6

7

8

9

10

11

12

P R SPrate

4 5.93 1

3 6.49 0.5

5 7.04 0.33

8 8.92 0.25

3 5.91 0.2

4 5.57 0.16

5 3.45 0.18

8 5.11 0.25

4 7.21 0.19

2 2.85 0.17

7 8.85 0.14

4 5.18 0.13

12

Robotics and Computer Integrated Manufacturing 64 (2020) 101910

C. Zhao, et al.

Supplementary material Supplementary material associated with this article can be found, in the online version, at 10.1016/j.rcim.2019.101910. References [1] X.V. Wang, et al., Ubiquitous manufacturing system based on cloud: arobotics application, Robot. Comput. Integr. Manuf. 45 (2017) 116–125. [2] M. Endrei, et al., Patterns: Service-Oriented Architecture and Web Services, IBM Corporation, International Technical Support Organization, 2004. [3] G. Alonso, et al., Web Services, Web Services, Springer, Berlin, Heidelberg, 2004, pp. 123–149. [4] J. Yu, Y. Han, Service oriented computing-principle and application, Qing Hua University publisher, (2006). BeiJing [5] F. Tao, et al., SDMSIm: a manufacturing service supply demand matching simulator under cloud environment, Robot. Comput. Integr. Manuf. 45 (2017) 34–46. [6] C. Zhao, et al., Agent-based simulation platform for cloud manufacturing, Int. J. Model. Simul.Sci. Comput. 8 (3) (2017) 1742001. [7] L. Wang, Machine availability monitoring and machining process planning towards cloud manufacturing, CIRP J. Manuf. Sci. Technol. 6 (4) (2013) 263–273. [8] M. Luck, Guest editorial: challenges for agent-based computing, Auton. Agent Multi Agent Syst. 9 (3) (2004) 199–201. [9] B. Chen, H.H. Cheng, A Review of the Applications of Agent Technology in Traffic and Transportation Systems, IEEE Transactions on Intelligent Transportation Systems, volume 11, (2010), pp. 485–497. [10] L. Li, et al., A survey of feature modeling methods: historical evolution and new development, Robot. Comput. Integr. Manuf. 61 (2020) 101851. [11] Y. Cheng, et al., Modeling of manufacturing service supply demand matching hypernetwork in service-oriented manufacturing systems, Robot. Comput. Integr. Manuf. 45 (2017) 59–72. [12] J. Stirna, A. Persson, An Example of an Enterprise Modeling Method: 4EM, Enterprise Modeling, Springer, Cham, 2018, pp. 51–63. [13] S. de Kinderen, Q. Ma, Towards Purposeful Enterprise Modeling for Enterprise Analysis, Proceedings of the 2018 International Conference on Information Management & Management Science, ACM, 2018. [14] L. Kauspadiene, et al., Modeling of enterprise management structure for data leakage evaluation, Inf. Security J. 27 (1) (2018) 1–13. [15] D. Jugel, et al., Tool capability in visual EAM analytics, Complex Syst. Inform. Model. Q. 2 (2015) 46–55. [16] D. Jugel, Modeling interactive enterprise architecture visualizations: an extended architecture description, Complex Syst. Inform. Model. Q. 16 (2018) 17–35. [17] M. Löpez, et al., Supporting Product Oriented Manufacturing: A Model Driven and Agent Based Approach, 2018 IEEE 16th International Conference on Industrial Informatics (INDIN), IEEE, 2018. [18] Y. Zhang, et al., Agent and cyber-physical system based self-organizing and self-adaptive intelligent shopfloor, IEEE Trans. Ind. Inf. 13 (2) (2017) 737–747. [19] V. Rai, S.A. Robinson, Agent-based modeling of energy technology adoption: empirical integration of social, behavioral, economic, and environmental factors, Environ. Model. Softw. 70 (2015) 163–177. [20] H. Tang, et al., CASOA: an architecture for agent-based manufacturing system in the context of industry 4.0, IEEE Access 6 (2018) 12746–12754. [21] M. Yuan, et al., Service composition model and method in cloud manufacturing, Robot. Comput. Integr. Manuf. 61 (2020) 101840. [22] Y. Liu, L. Wang, X.V. Wang, Cloud manufacturing: latest advancements and future trends, Procedia Manuf. 25 (2018) 62–73. [23] Y. Liu, et al., Scheduling in cloud manufacturing: state-of-the-art and research challenges, Int. J. Prod. Res. (2018) 1–26. [24] J. Wang, et al., Multi-agent and bargaining-game-based real-time scheduling for internet of things-enabled flexible job shop, IEEE Internet Things J. (2018). [25] Y. Liu, et al., Multi-agent-based scheduling in cloud manufacturing with dynamic task arrivals, Procedia CIRP 72 (1) (2018) 953–960. [26] S. Nan, Z. Lin, G. Hua, Research on the semantic SOA service composition method based on multi-agent system, in: National Conference on a multi-agent system and control, 2009-9. [27] L. Jie, Z. Lin, L. Yongkui, Research on dynamic service composition based on service agent, Sciencepaper Online 12 (2013) 27. [28] A.D. Rocha, et al., Environment to Simulate Distributed Agent Based Manufacturing Systems, International Workshop on Service Orientation in Holonic and Multi-Agent Manufacturing, Springer, Cham, 2016. [29] O.M. Zvereva, et al., Optimization of manufacturers behaviour on the basis of a local economic agent-based model implementation, IFAC-PapersOnLine 51 (32) (2018) 115–120. [30] S.J. Russell, P. Norvig, Artificial Intelligence: a Modern Approach, Malaysia; Pearson Education Limited, 2016. [31] B. Bauer, J.P. Müller, J. Odell, Agent UML: a formalism for specifying multiagent software systems, Int. J. Software Eng. Knowl. Eng. 11 (3) (2001) 207–230. [32] Z. Yifei, Research on the takt time of shipbuilding based on intermediate products, 2014. Jiangsu University of Science and Technology. [33] Z. TANG, et al., Optimization for auto rear axle assembly line balancing, Modular Mach. Tool Automatic Manufacturing Technique 8 (2009) 32. [34] Z. YANG, D. LIU, L.I. Zhi-qiang, Research on balancing problem of engine assembly line, Mach. Des. Manuf. 1 (2008). [35] L. Zhang, B.P. Zeigler, Y. Laili, Model engineering for simulation 3, Elsevier, 2019. [36] Y. Lu, et al., Digital twin-driven smart manufacturing: connotation, reference model, applications and research issues, Robot. Comput. Integr. Manuf. 61 (2020) 101837. [37] M.H. Mourad, et al., Assessment of interoperability in cloud manufacturing, Robot. Comput. Integr. Manuf. 61 (2020) 101832.

Fig. 13. Changing of the SPrate .

communication architecture of the service agent is proposed, and the functions of each layer are introduced in detail. Next, this paper presents a method to model a set of models in the cloud manufacturing simulation environment, including: virtualized modeling of manufacturing resources, service modeling of virtual resources, modeling of service agents, modeling of service centers and modeling of transactions. In addition, combined with the communication architecture of the service agent, the message delivery between the service agents is described in detail. Taking production takt as a case study, the simulation process is introduced. These modeling and simulation methods can provide reference and help for the research of cloud manufacturing related issues. The concept of Digital Twin has a great impact on intelligent manufacturing. As a modeling and simulation method, the digital twin gives new connotations to workshops, products and processes[36]. However, the simulation platform also can be seen as the digital twin of the service platform. In the future, service agent-based simulation platforms will be used to simulate many issues in cloud manufacturing, such as service composition, manufacturing resource optimization scheduling, business model validation, and business behavior prediction. Through the simulation platform, a service agent network will be formed. The assessment of the network and the interactivity between services [37] will also be important research issues. We will explore to integrate digital twin modeling methods into the service agent, with more case applications and feedback on results, the model of the service agent will be continuously improved.

Declaration of Competing Interest We wish to confirm that there are no known conflicts of interest associated with this publication and there has been no significant financial support for this work that could have influenced its outcome.

CRediT authorship contribution statement Chun Zhao: Software, Data curation, Writing - original draft. Xiao Luo: Conceptualization, Supervision. Lin Zhang: Writing - review & editing.

Acknowledgment This work is supported by the National Program on Key Basic Research Project of China (Grant No. 2018YFB1701602), the National Natural Science Foundation of China (Grant No. 61374199), the National High-tech Research and Development Program of China under (Grant No. 2015AA042101). 13