Cloud Manufacturing Service Paradigm for Group Manufacturing Companies

Abstract

The continuous refinement of specialization requires that the group manufacturing company must be constantly focused on how to concentrate its core resources in special sphere to form its core competitive advantage. However, the resources in enterprise group are usually distributed in different subsidiary companies, which means they cannot be fully used, constraining the competition and development of the enterprise. Conducted as a response to a need for cloud manufacturing studies, systematic and detailed studies on cloud manufacturing schema for group companies are carried out in this paper. A new hybrid private clouds paradigm is proposed to meet the requirements of aggregation and centralized use of heterogeneous resources and business units distributed in different subsidiary companies. After the introduction of the cloud manufacturing paradigm for enterprise group and its architecture, this paper presents a derivation from the abstraction of paradigm and framework to the application of a practical evaluative working mechanism. In short, the paradigm establishes an effective working mechanism to translate collaborative business process composed by the activities into cloud manufacturing process composed by services so as to create a foundation resulting in mature traditional project monitoring and scheduling technologies being able to be used in cloud manufacturing project management.

1. Introduction

With the form of global manufacturing network, the focus of information-based application in large group manufacturing company is switching from manufacturing innovation to services innovation. The rapid development of network, IOT (internet of things), cloud computing, and knowledge service provides a powerful tool for agility manufacturing and service innovation. “Manufacturing as a service” is no longer only a concept. It means that the manufacturing resources should be checked, and the resource-sharing service should be provided. Under the circumstances, the scheme of service platform construction for large group manufacturing company has become a key issue for speeding up group manufacturing companies’ development and bringing group manufacturing companies into global manufacturing network.

Recently, a new policy, “advice on annexation and reorganization of enterprises by the state council of China,” has been announced, which requests to speed up the annexation and reorganization of enterprises, aiming to achieve sharing of core resources. The core resources gradually become a main influential factor in enterprise competitiveness and product innovation. Furthermore, the product development features of enterprise group, which refer to large amount of and widely distributed research units, large volume and frequent interacted data, and numerous and short period development tasks, determine that the resource sharing and business cooperation mechanism is needed.

However, the resources in enterprise group are usually distributed in different subsidiary companies, which means they are hard to be intensively used, constraining the competition and development of enterprise. To solve the sharing problem, particular mechanisms and tools are needed to establish high degree of centralized and unified management of all the valuable resources within the group. How to gather, share, and integrate the stock resources within enterprise group is the starting point of cloud manufacturing [1] concept. The cloud manufacturing services platform regards all resources within the cloud for enterprise group as one virtual resource pool to realize manufacturing capacity expansion and meets the requirement of large-scale manufacturing by providing services.

2. State of the Art

The governments and scientists pay lots of attention to the better sharing of the resources and better coordination among companies. However, in spite of any proposed manufacturing modes built on top of different structures and technical characters, the key point of all these modes at resources-sharing aspect is to make resources visible, available, reorganizable, and applicable. Therefore, this paper will describe the state of the relevant technologies from the following aspects: resource sharing, resource access, and resource organization.

2.1. Resource Sharing

The resource-sharing methods can be classified into three categories.

2.1.1. Task-Driven Resources Sharing

The core of this resources sharing paradigm is to achieve collaborative product design and manufacturing by integrating information and resources according to the business process for each task [2–4].

2.1.2. Establishing Specific Resources Sharing Center

Typical examples are early ASP (application service provide) mode [5] and recent SaaS (software as a service) mode [6]. The core of these modes is services, which means supplying application services by packaging the resources online.

2.1.3. The Aggregation of Discrete Resources

This paradigm [7, 8] tries to aggregate and network discrete manufacturing resources in the entire enterprise even across several enterprises and organizations through resources encapsulation and networked integration, shielding resource heterogeneity and geographical distribution and providing resource services to the users with a transparent manner.

2.2. Resource Access

Resource-access technology connects resources to resource sharing platform, making resources visible and available. It can be divided into two types: the tightly coupled and loosely coupled.

2.2.1. Tightly Coupled Resource Access Technology

The tightly coupled resource access technology means that the shared resources are integrated and interdependent [9, 10]. The demanding control mechanism is used in this technology, the system of which needs to know the specific details of other systems or middleware to ensure that the whole system is able to communicate effectively. This often requires hard-coded connection among resources, systems, adapters, message bus, and message broker. Through the integrated use of the message bus, message broker, Hub and other integrated topology, it can create a more flexible integrated type. However, fixed data conversion and resource management process and the lack of support of public open standards make the tightly coupled integration process not only complex and expensive, but also difficult to manage and maintain. The early networked manufacturing ASP and grid manufacturing researches use such technology to access resources.

2.2.2. Loosely Coupled Resource Access Technology

With the continuous development of web services technology, loosely coupled integration technology, taking service-oriented architecture (SOA) as the core, is introduced into resource access process by manufacturing grid manufacturing model [11, 12].

Service-oriented architecture uses neutral abstract interface (rather than proprietary protocols and programming interface) to link different unit functions of the distributed application components (service) with dynamic binding mechanism. Nondirect interconnection between the systems makes that the integrated system does not need to predefine or clearly understand the knowledge of other resources or middleware. For little interdependence between resources and between resources and platforms, each resource can be independent evolution, in which internal structure change will not affect the normal operation of the integrated system of resources. Loosely coupled service-oriented integration system can better adapt to changing system integration environment, respond to demand, and make adjustments in a timely and flexible manner.

2.3. Resource Organization

Resource organization and application refers to how to organize shared resources to provide services, on the basis of resource access. According to different application goals, resources organization and application technology includes workflow management based organization, organizing resource as a service, and service composition based organization.

2.3.1. Workflow Management Based Organization [13]

These technologies typically use workflow modeling approaches to build business process and bind the corresponding resources to business activities through matching between the requirements of business activities and the description of resources.

For example, some networked manufacturing studies that use CORBA (common object request broker architecture) as the infrastructure bind sharing resources to activities of the business flow by packaging them into ORB (object request broker) objects to promote the integration of resources and the execution of the application based on business processes [14]. One of the core ideas of workflow management based organization technology is to adapt to change of business management and execution process via the separation of application logic and process logic.

2.3.2. Organizing Each Resource as a Service

This method is mainly used in ASP (application service provider) manufacturing model [15]. It packages and publishes each resource as a service which can support multiple users simultaneously. By now, this mechanism is only applied to software resources, namely, software as a service (SaaS), not any other types of manufacturing resources.

2.3.3. Service Composition Based Organization Method [16]

Manufacturing grid researches [17] encourage that enterprises should share their manufacturing resources as services through encapsulation of the function, property, structure, behavior, processes, and other content of each resource into a unified web service object and meet specific business requirement by assembling the various existing services following service-oriented grid computing principle. This method organizes resources through service composition. The discovery and binding of resources is achieved by the discovery and binding of services.

2.4. Summary

2.4.1. Resource Sharing Models

As for the task-driven mode which provides an application service for each source, it has a 1: 1 relationship between the resources and the applications. In this mode, the resource sharing and application is tight coupling and privatization because of the big grain degree, low utilization rate, and the specific realization of information integration and process integration. Moreover, the call logic of resources is often fixed in the specific application environment, which is difficult to be reused in a different application environment. Therefore, the poor scalability determines that this mode is not suitable for dynamic large-scale integration of the resources and application.

As for the services application center mode which has a 1: n relationship between the resources and applications, it focuses on developing a specific and independent manufacturing service, rather than providing integrated and complicated manufacturing services with the integrated distributed resources. Though in this mode a certain resource can provide multiple applications by servitization, the application scenarios and range are limited because of the customization service mechanism for specific application scenarios.

As for the resources concentrate pattern, it has a: 1 relationship between the resources and applications, which means a user or a service is supported by multiple distributed resources. The present study mainly focuses on enterprise cooperation supported by network technology, establishing virtual enterprise to give rapid responses to market demands. This mode considers more on how to gather and acquire resources, instead of better resource sharing and large-scale manufacturing capabilities exchange, resulting in the poor participation of users. Without consideration of resource services for multiple users or tasks, the coarse grained resource encapsulation cannot meet the need of multidimensional dynamic resource combination.

2.4.2. Resource Access Technology

As for resource access technology, the tight coupling cannot dynamically adapt to the independent adjustment of resources and cannot satisfy the demand of large-scale integration of resources. Loosely coupled access technology can guarantee the autonomy of the resource, providing open and extensible resource integration capability. However, all of the current manufacturing modes are mainly aimed at software resource access and lack of effective technical means to make the manufacturing resources, especially machine tools and other manufacturing hardware, be visible and available.

2.4.3. Resource Organization and Application

The realization of resource organizing and applying based on the traditional workflow management technology cannot fully meet the dynamic business cooperation demand since it does not distinguish the relationship between business process logic and resource management logic in the control. Dynamic interorganizational and interdisciplinary process adjustment is difficult.

Application method based on service composition is a simplified and effective solution to network manufacturing resource sharing and service interoperability issues by separating business logic and resource management logic. There are two approaches for service composition implementation: workflow based service composition and artificial intelligence based service composition. The first approach is confined to the workflow development train of thought. The second approach, by now, still needs a breakthrough in the field of artificial intelligence technology.

However, in spite of extensive R&D and successful pilots, current networked manufacturing pattern and relative resources sharing and access and organization technologies are poorly suited for dealing with the strategic, long-term barriers to efficient manufacturing process across the entire enterprise group over highly complex and dynamic networked environment.

The emergence of the cloud computing paradigm takes one step further to satisfy dynamic resource sharing and on-demand resource provisioning by leveraging virtualization technologies at multiple levels (namely, hardware, platform, and application) [1].

Therefore, cloud manufacturing [1, 18, 19], a new resource sharing and leveraging paradigm in networked manufacturing environment, has been proposed to provide a processing infrastructure for massively collaborative manufacturing with agility, adaptability, and cost-effectiveness.

In the context of cloud manufacturing, we will propose a new cloud manufacturing paradigm for group manufacturing company based on our previous research on the vision of cloud manufacturing [1, 20].

3. Cloud Manufacturing Paradigm for Group Manufacturing Company

According to the could manufacturing concept definition in our previous work [1, 20], a cloud manufacturing paradigm (called GetCM) includes five parts: resources cloud, business cloud, manufacturing cloud, infrastructure and public platform, and cloud user.

1. Resources cloud is composed of the resources represented by cloud service. Manufacturing resources achieve the cloud sharing through the cloud virtualization (RaaS, resource as a service).

2. Business cloud is composed of business-oriented cloud services, which implements the business sharing through the business cloud service virtualization (BaaS, business as a service).

3. Manufacturing cloud is composed of the manufacturing process encapsulated by manufacturing cloud services (MaaS, manufacturing as a service). It performs a cloud manufacturing process by invoking the relative cloud resources and businesses.

4. Cloud manufacturing infrastructure and public platform builds the underlying technology and services for cloud manufacturing on top of the cloud computing platform of IBM, VMware, and so forth.

5. Cloud users can not only access manufacturing cloud, but also access resources and business clouds, in other words, cloud users with the flexibility to use resources with different particle size.

However, GetCM paradigm cannot be directly used to enterprise group because the resources in enterprise group are usually distributed in different subsidiary companies. It is not adaptable to resources sharing and centralized management across organization hierarchy.

In this context, we propose a new cloud manufacturing paradigm for group manufacturing company through the extension of the previous paradigm, as shown in Figure 1. The new paradigm is a hybrid clouds structure. Each subsidiary company establishes its own cloud manufacturing platform based on GetCM paradigm, called private CM (cloud manufacturing) for subsidiary company. Each private CM for subsidiary company can share its cloud services in resource cloud and business cloud by publishing these services on the cloud manufacturing platform for enterprise group (called private CM for group). Private CM for group is also created based on the GetCM paradigm, but its services in resource cloud and business cloud are from private CM for subsidiary company. So, the cloud manufacturing paradigm for entire enterprise group is a hybrid private clouds hierarchy.

Figure 1:

Hybrid private cloud paradigm for enterprise group.

By contrast, the new cloud manufacturing paradigm for enterprise group has more advantages than previous typical manufacturing modes, as shown in Table 1.

Table 1:

The technology contrasts of typical manufacturing modes.

Classification	Networked manufacturing	ASP	Grid manufacturing	Cloud manufacturing for enterprise group
Mode
Manufacturing mode	Resource sharing based on task-drivenCollaboration by information and process integratingThe relationship between resource and application is 1: 1	Establish resources center independentlyDeveloping specific and independent manufacturing servicesThe relationship between resources and application is 1: n	Centralized application by gathering discrete resourcesThe relationship between resources andapplication is n: 1	Discrete services by capability virtualization via gathering discrete resources The relationship between the resources and applications is n: 1: m
Resource sharing mode for entire organization hierarchy	Without consideration	Without consideration	Without consideration	Support by creating hybrid cloud sharing structure
Business mode	Task-oriented settlement	Hiring mode	Task-oriented settlement	Service-oriented utility computing model
Performance
Expansibility along the industry chain	Expanded by integration, weak expansibility	Not expandable	Expanded by services composition, strong expansibility	Expanded by capability virtualization and services composition, strong expansibility
Scalability of scale	Large-scale	General scale	Large-scale	Large-scale
Reliability	Compact style	General reliability	Grid computing-based data reliability	Fault-tolerant technology and process control, cloud-based reliable storage, and computation of credit
Quality of service	Organization assessment	User assessment	Single-level definition of quality	Quality definition and limitation across multilevel and boundary
Agility	Depend on integration	inconsiderable	Task-oriented dynamic service binding	Dynamical construction and reconstruction of business based on services composition
Adaptivity	None	None	Adaptivity by resources binding	Multilevel adaptivity of resources, capacity, and business
Technology
Resource access	All resource typesTask-driven accessInformation integration and process integration	Software resources	All resource types	All resource typesAccess methods of virtualization, routing, and internet of thingsPerception and monitoringPlanning
Resource management	No consideration	No consideration	Lack of unified resources management mode	Unified, virtual resource-distributed management
Resource applications	Task-driven	Demand-driven	Task-driven	Open drive, public cloud, private cloud
Resource Organization	Workflow-based organization	SaaS	Workflow-based organization	Virtual organizationBPM-based organization
Resources to join and exit	Static	Static	Dynamic, autonomous	Dynamic, autonomous
Isomerism solution	Private middleware	Private middleware	Private middleware	Standardized
Service abstraction	No consideration	Software as a service	Resource as a service	Abstraction layer, ability as a service
Virtualization Technology	None	None	Partial virtualization	All layers of virtualization
Multitenant	None	Coordinating through the establishment of an intermediate layer	None	Separated by virtualizationDiverse processing protection
Security	Basic security	Basic security	Basic security	Basic security and federal safety management
Development technology	None	Web-based development, service development	Distributed development	Distributed developmentService-oriented development

4. Framework

Because each subsidiary company establishes its own cloud manufacturing platform based on GetCM paradigm, each private CM for subsidiary company has the same framework with the GetCM framework [20]. However, for private CM for group, it must transform the architecture derived from GetCM framework to adapt to the changes brought by the hybrid private clouds hierarchy paradigm.

As shown in Figure 2, framework for private CM for group is a semantic-based and service oriented business process management framework, which is composed of seven layers including infrastructure layer, sharing manufacturing resource service layer, sharing business unit service layer, business cloud and resource cloud layer, model layer for cloud manufacturing process, manufacturing cloud layer, and ontology layer.

Figure 2:

Architecture for private CM for group.

(1) Infrastructure Layer. This layer is the infrastructure and public platform for cloud manufacturing, which provides the following functions such as credit evaluation, cloud service life cycle management, and resource virtualization.

(2) Sharing Manufacturing Resource Service Layer. Different from GetCM framework, this layer represents a collection of the shared services from resource cloud in private CM for subsidiary company according to the paradigm for enterprise group. The private CM for group aggregates resources distributed in different subsidiary companies in this layer by manufacturing resource services sharing.

(3) Sharing Business Unit Service Layer. Different from GetCM framework, this layer is constituted by sharing business unit service sets from business cloud in private CM for subsidiary company according to the paradigm for enterprise group. Each business unit service is an independent atomic operation to complete a business function, which does not depend on any other business process. A business unit service can invoke multiple manufacturing resource services to complete the task. The private CM for group aggregates business units distributed in different subsidiary companies in this layer by business services sharing.

(4) Business Cloud and Resource Cloud Layer. Different from GetCM framework, this layer is responsible for the reencapsulation of business units and resource services so as to resolve semantic heterogeneity among different services shared from different subsidiary companies by semantic description of the service capability based on the ontologies defined in ontology layer. It also provides an environment for cloud service to model, publish, and operate rather than encapsulate business unit and resource like in GetCM. So, all business services and resource services from sharing manufacturing resource service layer and sharing business unit service layer will be translated into cloud services for private CM for group in this layer.

Definition 1. A cloud service in private CM for group can be defined as cs = (SO,M_so,A). It is exactly the same as semantic web service where SO is a service object entity that is made of interfaces and realization codes defined via OWL (web ontology language) to achieve the functionality provided by the corresponding manufacturing resources or business unit service wrapped by this service; M_so is a mapping between SO and SO s in manufacturing resource and business unit services shared from private CM for subsidiary companies in order to achieve encapsulation, virtualization, distribution, and invocation of the operation on manufacturing resource or business unit service; A is the semantic description of cloud service capability, which contains machining-readable contexts about services features, such as quality properties, whose information is restricted by semantic annotation using domain ontology defined in ontology layer.

The collection of the entire SO in cloud services constitutes the service implementation sublayer, and all A constitutes the service capability sublayer at semantic level. In particular the “semantic level” means that two cloud services are the same depending on whether the ability description A of each service is semantically identical.

One of the most important issues in cloud service generating is heterogeneity of underlying manufacturing resources. In a group enterprise, each subsidiary company has its own working tools and its own material and software infrastructures as well as its own organization even if resources are encapsulated into web services. The semantic heterogeneity constitutes an important obstacle in modeling.

On the other hand, the state of manufacturing resources is heterogeneous, but from the point of view of resources sharing and cooperation, these resources have one important common feature: the sharing requirements can be translated into certain capacity requirements. For example, there is a request for sharing one numerical control machine. This does not mean that the requester wants to get ownership of the machine, but to make use of processing capacity information such as type of process, accuracy, and associated geometry, what the machine can perform.

Therefore, we present a general formal framework for manufacturing capability profile (A) which allows the service provider partners to advertise their sharing resources. Manufacturing capability profiles are stored in open registries like UDDI which provide human and computer interfaces to register services and to search for them.

Definition 2. Amanufacturing service profile A = (Property, ECapacity, Interface, Quality) is four tuples, where Property is the set of basic service information such as name, provider, and location (e.g., URL); ECapacity is the set of what kind of problem can be solved in collaborative manufacturing; Interface is the set of input and output parameters; and Quality is the set of nonfunctional properties such as cost and time.

Obviously, ECapacity is the core of the definition of A. Its content delivers engineering and business information that normal web service or semantic web service has yet to be addressed. As mentioned above, enterprises do not care about the comprehensive description of the internal structure of manufacturing resources. From the external point of view, that is, that of a service requester, a manufacturing cloud serviceis seen as a black box that exhibits a certain exported behavior on some Products. When executed, the manufacturing service can perform its task by directly invoking encapsulated manufacturing resources and using certain methods under certain conditions. These five factors are more concerned information in distributed manufacturing. So, ECapacity is defined as Ecapacity = (product, method, resource, condition, task). For the cloud services in private CM for group, resource in ECapacity refers to the sharing business and resource service from private CM for subsidiary company.

The manufacturing capability profile provides a clear and precise characterization definition of cloud manufacturing services. Semantic understanding is achieved to facilitate knowledge sharing and reuse among service providers and requesters. A richer service profile is very conducive to subsequent service discovery and composition efforts, to avoid low precision caused by purely depending on the key words search or semantic matching of input and output parameters of services.

(5) Model Layer for Cloud Manufacturing Process. This layer is responsible for describing the collaborative relationships of manufacturing activities in manufacturing transactions. It is the basis for the operation and control of collaborative manufacturing processes.

Definition 3. A manufacturing process model MPM = (MA,F_MA-MA) is a resource-independent process plan, where MA is a finite, nonempty set whose members (i.e., manufacturing activity) specifies requirements for the manufacturing goal, such as quality requirements and input/output parameters; F_MA-MA⊆MA × MA − I_MA is a noncycle relation used to represent the business synergies between ma, where I_MA is the identical relation.

(6) Manufacturing Cloud Layer. This layer is responsible for the establishment of mappings between manufacturing activities and business cloud service or resource cloud services. Then a partial order sequence of services will be set up and executed. In fact, one manufacturing cloud service is an instance of MPM in which each manufacturing activity is attached to a single cloud service for manufacturing resource or business unit. By locating, orchestrating, and invocating of manufacturing activity, manufacturers and suppliers are transparent in the underlying processes and computing environments of the participants. This mapping is realized through the semantic matching between the abilities of manufacturing activities and cloud services.

(7) Ontology Layer. The layer is made of a number of domain ontologies. The domain ontology is the common understanding of some certain partners. This layer provides semantic reference basis for semantic description for manufacturing activities and capabilities of cloud services and makes their contents be clearly understood in different business and computer programs.

Each set in A is finite and nonempty in which each element is attached to concepts in domain ontologies. OWL-S is an OWL-based web service ontology which makes these functionalities such as automatic web service discovery possible. It groups web service details into three components and defines respective ontologies called ServiceProfile, ServiceModel, and ServiceGrounding. Furthermore OWL-S enables the creation of ontologies for any domain and the instantiation of these ontologies in the description of specific web sites. So, we extend OWL-S to instantiate the meaning of a manufacturing capability profile.

As shown in Figure 3, the sets of Property and Interface are still represented by ServiceModel and ServiceGrounding. The extension of ManufacturingProfile and QosProfile isthe subclass of the ServiceProfile. We focus on providing a kind of abstract layers that can be the basis for manufacturing domains.

Figure 3:

The extension of OWL-S.

ManufacturingProfile is used to represent ECapacity set of A which has five properties, namely, hasProduct, hasTask, hasMethod, hasResource, and hasCondition. It should be noted that in a high-level ontology these properties and their relationships to classes (domain and range) are identified without cardinality restrictions.

QosProfile provides a universal conceptual model for nonfunctional properties of services. Nonfunctional properties like response time, availability, and performance are difficult to formalize and very often conflict. The class of Metric defines QoS (quality of service) parameters. The class of Unit is a precisely specified quantity of Metric. The Weight class is used to express which parameter the requester favors.

With the support of this framework, heterogeneous resources and business units distributed in different subsidiary companies are aggregated and used in private CM for group from the entire enterprise group perspective.

5. Working Principle

According to the paradigm and framework, in principle, the working essence of cloud manufacturing mode for group is a working and management process of cloud business projects on the private CM for group driven by virtualization capability. Unlike traditional business management, project management based on cloud manufacturing has the following characteristics.

(1) Manufacturing Capability as Basic Scheduling Unit. In cloud manufacturing, manufacturing resources are virtualized as a cloud manufacturing service with specific manufacturing capability. Cloud manufacturing projects are to complete the task through service planning, composition, and execution.

(2) Project to Be Generated On-Demand Dynamically. Project planning is carried out simultaneously with execution. The number of projects and the implementation situation has a great dynamic characteristic. In cloud manufacturing, all of the projects are generated on-demands. There is no annual plan and long-term plan which is in traditional project management. And it is impossible to schedule the accurate plan of project execution in advance. The implementation of plan may be changed as the statements of selected services change.

(3) No Global Regulation. There is no organization structure relationship between the cloud manufacturing projects. All projects are aimed at satisfying the customer requirements as the only goal, which are not affected by other projects and organizations. They are with full autonomy and there is no global regulation.

Obviously, traditional project management cannot meet the project management requirements which are complex and dynamic on-demand. And a new management mechanism is needed. In essence, though there is no global scheduling and coordination in cloud manufacturing, on the view of the using of capability services, it is possible to establish potential relationship between cloud manufacturing projects because of the relationship between the capability services. For example, the same services may be in different projects to serve different stages at the same time. For cloud manufacturing, though the services may have multiple instances, the capability of service is finite, even exclusive. For instance, some software services cannot provide services unlimitedly because of the constraints of authorization and computing capability, but some machining services may be independent. Such finiteness of capabilities or services make cloud manufacturing project inevitably in the constraints of established service and requirements, rather than completely unrestricted.

Therefore, the cloud manufacturing platform must take the exceptional cases of projects working into consideration to provide a mechanism that can monitor the status of the projects on the platform and the constraints relationship and mutual status influence in different projects. It can provide the decision making for different projects and the suggestion for service capability of new project. But it can monitor and supervise all of the cloud manufacturing projects.

The working principle can be summed up as follows: “taking the capability hierarchical level network plan for multiproject as basis, the status monitor of the full ability services as the mainline, the determination of multifactorial influences area as means, and the global influence area minimum as target, to provide suggestion for cloud manufacturing project plan's adjustment and establishment.”

Technically, it means to transform the cloud manufacturing project plan which is with activities as the core to capability hierarchical network plan which is with capability as the core. Through the real time monitor on capability state, the abnormal influence region is obtained and provides the suggestions and management. It is expressed as follows:

$CP\left(C\right)=\left\{{CP}_{\mathrm{0}}\left(C\right),\Delta CP\left(C\right)\stackrel{Rf\left(Cap\right)}{\to }{CP}^{\prime }\left(C\right)\right\}.$

(1)

The basic principle diagram is shown in Figure 4.

Figure 4:

The basic principle of the monitor for cloud manufacturing project plan.

• CP(C) is the capability hierarchical network plan.

• CP₀(C) is the capability hierarchical network plan that is not affected; CP₀(C) = {CP _finish (C),CP _undo (C)}, including the finished capability hierarchical network plan CP _finish (C) and the unfinished capability hierarchical network that is not affected CP _undo (C).

• ΔCP(C) is affected capability hierarchical network plan.

• Cf(Cap) is reconstruction function.

• CP′(C) is the new capability hierarchical network plan after being reconstructed.

In fact, the basic principle of monitor for cloud manufacturing project plan is a process of monitoring the project, determining the affected capability hierarchical network plan ΔCP(C) (determining the influence region), and readjusting (reconstructing) the plan.

5.1. The Capability Hierarchical Level Network Plan for Multiproject as Basis

Traditional project monitor regards activity as the basic unit and cannot analyze the impact of constraint relations between the capacities on the implementation of the projects. To solve this problem fundamentally, the monitor of cloud manufacturing projects is with capacity as the basic unit rather than activity. (a)Taking capacity as starting point: traditional plan model regards activity as the starting point and judges the project execution state according to the activity as planned whether processed or not. Thus the potential influence between capacities cannot be determined. For example, A1, A2, and A3 are unrelated activities in projects, and they need capacity C in different stages. If A1 is delayed and capacity C cannot be released in time, it cannot capture the influence of capacity C on A2 and A3. So the cloud manufacturing project plan monitor model should take capacity status as monitor element. (b) Considering the influence on the activities from the perspective of the capacity: in order to meet the user's custom of business needs, despite the fact that the project monitor of cloud manufacturing takes capacity as basic monitor unit, the demands are put forward as project activities. That is to say, traditional activity-focused project planning can be generated according to customer's needs in the level of the users’ needs. While in the level of monitoring, taking the capacity service state as the monitoring unit, the impact of the state of capacity service on activities is determined by constraint and management of the capacity. (c) Considering the substitute of the capacities: the logic relationships between capacities may include containment relation and intersection relation. According to the constraint of capacities, when the conflicts are occurred because of capacity calling, cloud manufacturing platform is able to conduct a comprehensive analysis and unified deployment to provide optimized suggestion, which is useful to establish the coupled relationship of loose and activity-based process logic and management logic. For this, this paper proposes to construct capability hierarchical network plan to monitor the cloud manufacturing project based on capacity.

Capability hierarchical network plan can be expressed as

$\text{CPM}=\left\{C,C\left(A\right),Cel\left(C\right)\right\}.$

(2)

C is the capacity (service) set, A represents an activities set, C(A) represents activities set sharing a certain type of capacity, activities in this set can be from different projects, and Cel(C) indicates the relationship between capabilities, as shown in Figure 5

Figure 5:

Diagram of capability hierarchical network plan.

5.2. The Status Monitor of the Full Ability Services as the Mainline

From the logic of the activity's execution, the execution of the activity is calling and releasing of a certain capacity at a time. From the view of capacity, it can be regarded as the dynamic adjustment of the capacity state at different times. In fact, capacity state (dynamically changes over time and activities) can comprehensively reflect the changes of factors, like time, activity, and capacity. We can achieve a monitored integrating of time, activity, and capacity by monitoring capacity state. The granularity is fine and the monitor targets are more simplified. So this paper proposes the whole capacity state as the mainline to monitor the project, as is shown in Figure 6.

Figure 6:

Taking the capacity state as the mainline to monitor the project.

In order to monitor capacity state, this paper proposes concept of capability (services) pool to monitor the project progress by state information reflected by capability pool.

Definition 4. Capacity pool (CP) is a container to manage the same capacity C _i and can be expressed by CP = {CType, ActiveSet, Time, State (c _i ),∪c _i }, where (a) CType is the capacity type of CP; (b) ActiveSet is the activity set calling this type of capacity; (c) Time is the time when computing the CP; (d) State(c _i ) is the capacity state; (e) ∪c _i is the residual capacity C _i set at this time. The number of capacity types decides the number of CP s.

CP mainly reflects two aspects: one is the value of the capacity, and capacity is being called and released by the time. The number of it changes dynamically. The other is the capacity state, which reflects whether the current state is right or not. Therefore, in the process monitoring, two aspects must be considered: whether the time of calling and releasing capacity is the same as the original plan and whether capacity state is right or not. When the time of the capacity called and released is the same as the original plane, the project state is normal, or it indicates that the potential activities may be affected and the monitor alarm is given. Then the further analysis is processed.

So we can achieve a monitored integrating of time, activity, and capacity by monitoring capacity state.

5.3. The Determination of Multifactorial Influences Area as Means

The accurate determination of influence area is an important prerequisite for adjusting project plans correctly. The determination of influence area is based on capability hierarchical network plan. According to the characteristics of the project, the deviation node appears at the bottom level of the capability hierarchical network firstly. The capacity of this level is an atomic capacity, which cannot be divided. Once the number of calling this capacity is out of the maximum capacity limit, it cannot be called by other activities until the capacity is released. This node is regarded as “conflict source” and the same level influence area is determined by analyzing the same level network plan. According to the scope of influence area, we can determine the whole influence area by analyzing the higher level recursively. Traditional methods are based on activity; only two factors of sequence and transfer are considered. They regard that if the deviation is not in the critical path, the project will not be delayed. This assumption becomes insufficient when the activity in uncritical path will affect the activities in critical path because of capacity sharing. Therefore, this paper proposes multifactorial influences area as means, taking the capacity factor into account which is integrating time, capacity, and transfer to determine the accurate influence area.

If an activity node (capacity instance node) corresponding to a type of capacity cannot start in the scheduled time, the node is part of the influence area. There are two causes: (a) the capacity instance node which is with previous constraint is not complete (sequence factor); (b) the capacity is not satisfied (capacity factor). It means that the capacity is invalid or capacity is not released. In addition, transfer is also a factor to determine the influence area. When a node cannot start in the scheduled time because of above reasons, the time of the node executed should be redetermined in order to detect downstream nodes. The process of time parameters redetermination is the process of influence area transferring to downstream. This is about transfer strategy. The time parameters redetermination will be different with different transfer strategy, and the influence area will be different.

5.4. The Global Influence Area Minimum as Target

There is no necessary relationship between the cloud manufacturing projects. The global suggestions provided by cloud manufacturing platform should be with influence area minimum as principle to use different capacity types to replace it in a project, rather than in different projects. The potential influence in different projects is taken as a way of monitoring alarm or service commendation to support users’ decisions.

Resource is virtualized as capacity in cloud manufacturing. A virtual capacity level is established between manufacturing resource level and activity level to realize their decoupling. In the process, activity does not directly play a role with real resource, and it provides an innate technology to achieve influence area minimum. Through matching of activity needs and capacity which is virtualized to resource, more alternative capacities can be provided and more choices are given for adjustment of project capacity needs.

6. Case Study

Parts of the paradigm explained above were prototypically implemented in a cloud manufacturing platform for China Aerospace Group that is a hybrid structure composed of private MC (manufacturing cloud) for group and private MC for each subsidiary company (Figure 7). Each private MC for subsidiary company (MCS for short) is a private cloud that aggregates manufacturing resources and business units inside the company and publishes them as resource-oriented cloud services and business-oriented cloud services correspondingly. Private user in the company can perform a cloud manufacturing process by invoking the relative cloud resources and businesses. At the same time, each MCS will share its resource cloud services and business cloud services with the private MC for group (MCG for short) by publishing these services authorized by private user of the company on the private MC platform for group. The MCG, therefore, aggregates not only the manufacturing resources and business units owned by the group but also the ones shared from each MCS. In return, users in subsidiary company can perform their cloud manufacturing processes across the entire group organization by invoking the relative cloud resources and businesses services on the MCG if these users are authorized by MCG (called CM users). So, by establishing this hybrid cloud architecture, the MCG aggregates resources and business units within the entire group organization as one virtual resource and business pool to realize manufacturing capacity expansion by deep sharing and centralized control and meets the requirement of large-scale manufacturing by providing services.

Figure 7:

Paradigm implemented by hybrid cloud prototype.

For the experimental setup, seven types of resource are aggregated by manufacturing cloud. Critical items for the aggregation are shown in Table 2. Through aggregating in each MCS and MCG, the prototype private MC platform for group publishes 43 software resource services, 25 computing resource services, 32 machine resource related services, 1 knowledge resource service, 1 data query service, and 34 business services.

Table 2:

Resources aggregation.

	Computing resources	Software	Business unit represented by software process	Manufacturing machine	Knowledge base	Semi-/Unstructured data	Structured data
Virtualization	Hyper-VSemantic description of the computing capability of the virtual computing resource	Virtual desktopIsolation of data accessIsolation of usersSemantic description of the capability of the software	Virtual desktopIsolation of data accessIsolation of usersSemantic description of the capability of business unit	Semantic description of the manufacturing capability of the machine	Do not need	Do not need	Do not need
Servitization	Providing service with capability description at RaaS level	Providing service with capability description at RaaS level	Providing service with capability description at BaaS level	Encapsulating the description of manufacturing capabilities as a resource service	Encapsulating knowledge access as a resource service	Semantic description of data and their relationships Encapsulating data query as a resource service	Semantic description of data and their relationships Encapsulating data query as a resource service
Aggregation mode	Cloud computing mode	Classification according to software application	Classification according to business goal	Classification according to manufacturing capability	Knowledge integration	Semantic integration	Semantic integration

From the point of view of working principle, the cloud manufacturing project plan with activities is transformed to capability hierarchical network plan according to the analyzing results of the capabilities of relative services. An experimental implementation case is shown in Figure 8, which translates an aerospace manufacturing project into a capability project to meet the specific requirements.

Figure 8:

Case for the capability hierarchical level network.

The case studies show that it reduced the idle time of the relative resources by average of 64.5% (corresponds to an improvement of average 10.65% of utilization of relative resources) when experimentally applying the cloud manufacturing service paradigm in Aerospace China Group. However, this benefit is reached only if the resources are not fully shared or few business processes are carried out on this platform. So, the more full sharing of the resources and the more running of the cloud business on the platform, the more effective utilizing of cloud manufacturing service paradigm.

7. Discussion and Conclusion

This research has been conducted as a response to a need for quantitative studies of new resource sharing and leveraging paradigm in networked manufacturing environment called cloud manufacturing, such as [1, 18–20, 20–27]. All these researches, including this research, promise elasticity, flexibility, and adaptability for resources sharing through the on-demand provisioning of manufacturing resources services. Most of these researches have focused on how to characterize the cloud manufacturing by proposing generic framework and mechanisms. The framework of cloud manufacturing may directly adopt and extend the architecture of cloud computing [23, 26, 27] or combine many technologies, such as cloud computing, internet of things, and service computing, with manufacturing schemas and collaborative technologies, such as [18, 21, 22, 24, 25]. In contrast, the framework proposed by this research and its early studies [1, 20] does not want to incorporate more thinking of different technologies, but regards cloud computing thinking as the way to realize the idea of manufacturing service [19]. Until now, most studies are not concerned about the difference in paradigm, framework, working principle, implementation to group companies, and SMEs. Although the research like [22] pointed out the difference existing in cloud manufacturing schemas between group companies and SMEs, the discussion is focused on the outline of the key technologies to be studied and needs further systematic and detailed studies. This is precisely the contribution of this paper. The result of this research presents a derivation from abstraction to the application of a practical evaluative process. This paper has proposed a new hybrid private clouds paradigm which aggregates and uses heterogeneous resources and business units distributed in different subsidiary companies by establishing a services sharing mechanism between private manufacturing cloud for subsidiary and private manufacturing cloud for group based on the proposed new framework. In addition, an effective working mechanism with implementation case to translate the abstract cloud manufacturing framework into practical platform for group enterprises is also presented. This working mechanism is different from some studies [28–30] that tend to build cloud manufacturing services portfolio for manufacturing business from the perspective of service composition and optimization. It argues that the initial plan for cloud manufacturing business project is still based on the traditional program of activities in order to maintain a user-friendly project management manner and translates the traditional plan into capability or service based plan. The working mechanism is embodied in project management from the cloud service perspective, so as to create a foundation resulting in mature traditional project monitoring and scheduling technology which can be used in cloud manufacturing project management. The proposed cloud manufacturing paradigm with its corresponding framework and working principle is the main contribution to the cloud manufacturing research in enterprise group area.

Conflict of Interests

The authors declare that there is no conflict of interests regarding the publication of this paper.