Robustness Evaluation and Enhancement Strategy of Cloud Manufacturing Service System Based on Hybrid Modeling

Abstract

In dynamic and open cloud service processes, particularly in distributed networked manufacturing environments, the complex and volatile manufacturing landscape introduces numerous uncertainties and disturbances. This paper addresses the common issue of cloud resource connection interruptions by proposing a path substitution strategy based on alternative service routes. By integrating agent-based simulation and complex network methodologies, a simulation model for evaluating the robustness of cloud manufacturing service systems is developed, enabling dynamic simulation and quantitative decision-making for the proposed robustness enhancement strategies. First, a hybrid modeling approach for cloud manufacturing service systems is proposed to meet the needs of robustness analysis. The specific construction of the hybrid simulation model is achieved using the AnyLogic 8.7.4 simulation software and Java-based secondary development techniques. Second, a complex network model focusing on cloud manufacturing resource entities is further constructed based on the simulation model. By combining the two models, two-dimensional robustness evaluation indicators—comprising performance robustness and structural robustness—are established. Then, four types of edge attack strategies are designed based on the initial topology and recomputed topology. To ensure system operability after edge failures, a path substitution strategy is proposed by introducing redundant routes. Finally, a case study of a cloud manufacturing project is conducted. The results show the following: (1) The proposed robustness evaluation model fully captures complex disturbance scenarios in cloud manufacturing, and the designed simulation experiments support the evaluation and comparative analysis of robustness improvement strategies from both performance and structural robustness dimensions. (2) The path substitution strategy significantly enhances the robustness of cloud manufacturing services, though its effects on performance and structural robustness vary across different disturbance scenarios.

1. Introduction

Since the Industry 4.0 era, it has been recognized that the deep integration of advanced information technologies, such as cloud computing and the Internet of Things (IoT), with manufacturing will bring about tremendous changes in the manufacturing industry. With the development of intelligent technologies such as artificial intelligence and the industrial internet, manufacturing has gradually transformed toward digitalization, networking, and service orientation. Academician Bohu Li [1] first proposed the concept of “cloud manufacturing” in 2010, which represents a new service-oriented, networked manufacturing model. In this model, dispersed manufacturing resources and capabilities are aggregated onto a cloud manufacturing platform and further transformed into cloud services. Through service orchestration, different enterprises can conduct transactions on the cloud platform, thereby truly realizing the sharing of manufacturing resources and capabilities.

Over the decade since the proposal of cloud manufacturing technology, it has been gradually promoted and implemented in multiple fields. In the aerospace sector, Aerospace Electric, Aerospace Cloud Network, and Siemens jointly established a smart factory for high-end electrical connectors based on a cloud platform. Foshan Huashu Robot Company built a big data intelligent cloud service platform based on the Aerospace Cloud Network’s INDICS cloud platform, helping enterprises achieve precise and intelligent operation and maintenance services. In the home appliance industry, Haier constructed COSMO, the world’s first smart manufacturing cloud platform based on the interconnected factory model. Centered on users, COSMO integrates users, R&D resources, suppliers, and creators into a co-creation and win–win ecosystem, further integrating global resources through an open platform to quickly respond to users’ personalized needs. Additionally, product customization service websites based on the cloud manufacturing model have been developed globally, such as MFG.COM (the world’s largest manufacturing capability trading platform), Ponoko, Quirky (an innovative product community and e-service platform), and China’s Genyun platform (an industrial internet empowerment platform).

Theoretically, academia has extensively explored cloud manufacturing from perspectives such as hierarchical structures [2], typical characteristics [3], key technologies [4,5,6,7,8,9,10], operation modes [11,12,13,14], and service composition scheduling [15,16,17,18], with substantial research achievements. However, studies on the impact of uncertain environments on cloud manufacturing systems and robustness under disturbance scenarios remain scarce. Due to the complex and volatile manufacturing environment, dynamic and open cloud service processes inevitably face numerous unpredictable disturbances, which can impact and disrupt cloud manufacturing systems to varying degrees. Especially in distributed networked manufacturing environments, cloud manufacturing systems face more uncertain disturbances than traditional manufacturing, including changes in user demand, task cancellations, cloud resource failures, cloud resource connection interruptions, and cloud service providers exiting the platform. For example, during the 29-month operation of the HD smart equipment cloud service platform [19] from April 2016 to August 2018, the annual average frequency of resource overloads and provider withdrawals was recorded as 49 and 32 times, respectively, with a total annual average of 751 task suspensions, cancellations, resets, and changes. The overall failure data of a shipyard’s cloud manufacturing service platform [20] showed annual average failures of 149 resource overloads, 343 dynamic resource additions, 97 provider withdrawals, and 377 service connection interruptions. Therefore, it is crucial to conduct research on the robustness of cloud manufacturing service systems under uncertain disturbances and develop counterstrategies for cloud manufacturing systems against such uncertainties.

The remaining structure of this paper is as follows: Section 2 analyzes the relevant studies. Section 3 constructs hybrid simulation models and complex network models for cloud manufacturing service systems, establishes two-dimensional robustness evaluation indicators, and designs four types of resource edge failure modes, and formulates a path substitution strategy for edge failures; Section 4 conducts a case study; Section 5 summarizes the research conclusions and outlines future prospects.

2. Related Works

2.1. Robustness Research on Manufacturing Systems

Most existing robustness studies employ mathematical programming methods, which involve constructing mathematical programming models and designing corresponding meta-heuristic algorithms for solutions. The advantage of this approach lies in its ability to reasonably select optimization indicators and constraint conditions based on practical scenarios and to efficiently obtain feasible solutions using relevant algorithms. The indicators primarily focus on economic metrics (e.g., cost minimization, profit maximization), time metrics (e.g., demand response time minimization), efficiency metrics (e.g., equipment utilization maximization, order completion rate maximization), and environmental metrics (e.g., environmental impact minimization). For example, Hasani [21] proposed a service-oriented fuzzy multi-objective mathematical programming model to achieve high robustness in global supply chain network structures, with objective functions including total cost minimization, total demand response time minimization, and resilience maximization. A new hybrid solution algorithm was developed to solve this optimization model. Zandieh et al. [22] proposed a bi-objective optimization model for maintenance planning and scheduling in multi-factory production networks, aiming to minimize maintenance costs and maximize reliability, and adopted an effective robust programming method to control the uncertainty of input parameters and the stability of output decisions. Magnanini et al. [23] integrated the stochastic analysis model of manufacturing system production performance evaluation into a mixed-integer programming problem through performance linearization, minimizing the total cost of purchasing machines and buffer slots while meeting target throughput. Foroozesh et al. [24] attempted to create a new green and resilient supply chain for perishable and long-life products, proposing a multi-objective mixed-integer linear programming model with three objectives: total cost minimization, carbon dioxide emission minimization, and facility utilization maximization. The results verified that strategies such as establishing horizontal collaboration, managing capital flows, and hiring backup suppliers, significantly improve system robustness. Hasani et al. [25] developed a mixed-integer nonlinear model for the robustness of global supply chain networks under uncertain conditions, with the objective function of maximizing net after-tax profits in both normal and disrupted states. Sensitivity analysis was used to explore the impact of six resilience strategies on network performance.

Robustness analysis based on complex network theory is another common method for studying manufacturing system robustness. By modeling entities within the manufacturing system (workpieces, machines, employees) as nodes and their connections as edges, a manufacturing network can be constructed to analyze system robustness from a network structure perspective. The indicators mainly consider two categories: network connectivity under different failure modes (e.g., maximum connected subgraph) and network average distance (e.g., network efficiency). Shi Xiaoqiu et al. [26,27] used sensitivity analysis to explore the impact of factors such as the number of nodes, the number of interconnection links, interconnection patterns, scaling exponents, and load capacity on the robustness of interdependent supply networks under random and intentional interruptions. Considering the heterogeneity of different nodes in robustness indicator selection, they proposed the “maximum full-role connected subnetwork” to replace the traditional “maximum connected subgraph” indicator. Fan Dongming et al. [28] redefined robustness measurement indicators for two-layer networks from a complex network perspective and compared robustness changes under three different partnership construction strategies.

Evidently, advanced networked manufacturing models such as cloud manufacturing face significant uncertainties and risks due to their networked, distributed, and loosely coupled characteristics, making robustness analysis a research hotspot in academia, with scholars exploring it from multiple perspectives. An analysis of the two methods above shows the following: (1) While mathematical programming models can focus on performance indicators such as service time and cost in cloud manufacturing systems, their research emphasis lies in parameter optimization and algorithm design, failing to describe the dynamics, autonomy, and collaboration of complex systems such as cloud manufacturing. (2) Complex network analysis methods overly abstract system entities and connections, making it difficult to reflect the dynamic operation processes of cloud manufacturing systems or the logical judgment and dynamic temporal relationships between entities. Additionally, they can only analyze structural indicators such as system topology, struggling to evaluate performance indicators such as service time, cost, and quality of service (QoS).

2.2. Multi-Agent Simulation Research on Cloud Manufacturing Systems

Cloud manufacturing systems consist of multiple types of entities, each with distinct behavioral characteristics, and involve various interaction mechanisms between different entities. Therefore, the agent-based simulation method has become an effective approach for analyzing cloud manufacturing. By mapping individuals to agents, this method simulates the independent yet interdependent interactions between individuals through agent autonomy, reasoning, communication, and collaboration mechanisms, thereby studying the overall structure and functions of the system.

Zhao et al. [29] proposed a conceptual model of cloud manufacturing platforms in their simulation research, stating that a cloud platform primarily consists of three roles, three actions, and one core. The three roles include the cloud manufacturing platform (service center), cloud service demanders, and cloud service providers; the three actions include service protocol publication, search requests, and collaborative communication; and the ontology knowledge base serves as the operational core of the entire model. Zhao et al. [29] also proposed a conceptual model of cloud manufacturing service agents, which mainly includes two components: an intelligent module and a core service module. Zhao et al. [30] used service agents in the simulation platform to drive manufacturing services to form service networks and collaboration networks and proposed models for these two types of networks using set pair analysis (SPA) theory, along with evaluation methods for each network model.

It can be seen that simulation models for cloud manufacturing systems have been applied to study various issues, such as cloud service selection and scheduling and cloud manufacturing trust and security. However, research on the robustness of cloud manufacturing based on simulation methods remains relatively scarce.

2.3. Research on Robustness Improvement Strategies for Cloud Manufacturing Systems

A complex and volatile manufacturing environment can impact and disrupt cloud manufacturing systems to varying degrees. Therefore, it is essential to design counterstrategies against uncertain environmental disturbances to enhance the resilience of cloud manufacturing systems and ensure their stable operation. One approach is to develop multiple robustness improvement strategies, such as setting up alternative services for failed tasks, to enhance the system’s disturbance resistance during the design phase.

Robustness improvement strategies, such as configuring redundant nodes, alternative nodes, and adding links (edges), are widely applied in network structure models. Studies [31,32] have shown that backup edges, which remain inactive under normal conditions, can temporarily replace failed edges during network disruptions to maintain network functionality and connectivity. Other scholars have further investigated the effects of node and link addition strategies on the robustness of different networks [33,34,35,36].

On the other hand, robustness improvement strategies are increasingly being integrated into mathematical optimization models for cloud manufacturing. Yang et al. [37] proposed a robustness configuration framework by assigning preferred services and alternative services to subtasks, constructing a robust service composition and optimal selection model (rSCOS) for cloud manufacturing, and developing a gABC-GWO algorithm to solve the model efficiently. Zhang et al. [15] introduced an adaptive robust service composition and optimization model (ARSCOS) to dynamically determine whether to wait for anomaly repair or invoke alternative services in real time; the model is accompanied by an enhanced multi-objective artificial hummingbird algorithm (EMOAHA) for model solution.

Although existing studies have proposed robustness improvement strategies, such as adding alternative nodes and links, integrating these methods with simulation models of cloud manufacturing systems remains an urgent challenge. This paper aims to enhance the robustness of cloud manufacturing service systems during the design phase by providing alternative paths for cloud service routes to address common service route interruptions. The proposed strategy is implemented via simulation, and its feasibility and effectiveness are validated through comparative experiments.

3. Methodology

3.1. Hybrid Simulation Model Construction

The overall structure of the hybrid simulation model proposed in this paper is shown in Figure 1, which clarifies the relationships between cloud service entities and the connection between the cloud manufacturing entity model and the cloud service process model. The basic operational logic of the hybrid simulation model can be summarized as follows:

(1)

After initializing the hybrid model, the discrete manufacturing service process model is activated. Through technologies such as informatization transformation, resource sensing, resource access, and unified cloud service modeling, cloud service providers integrate various manufacturing equipment resources and capability resources into the cloud platform and store them in the cloud service pool. This enables centralized management and sharing of geographically dispersed resources, breaking spatial and distance limitations.

(2)

Cloud demanders submit service requests (orders) to the cloud platform via terminal devices. Orders from multiple demanders are centrally stored in the cloud demand pool for processing.

(3)

When there are pending orders in the cloud demand pool, cloud service processes are executed for each order sequentially.

(4)

The cloud platform decomposes each order into multiple subtasks, with different orders corresponding to service routes of varying structures (serial, parallel, etc.). In this paper, the previous process of the current task is termed the immediate predecessor process, and the subsequent process is termed the immediate successor process. Specifically, when there are multiple immediate successor processes, subtask decomposition and task information redistribution are required; conversely, when there are multiple immediate predecessor processes, multiple subtasks must be merged and task information aggregated.

(5)

During the service process, each subtask requests corresponding cloud resources from the cloud service pool based on its type to complete the service.

(6)

Idle cloud resources transition to a “busy” state upon request and revert to “idle” after task completion.

(7)

When all subtasks for an order are completed, the order is considered processed.

(8)

Performance indicators, such as service cycle and cost for completed orders, are recorded and stored in a historical dataset. The above steps are repeated until the current service plan is completed and all simulation outputs are generated.

In summary, the hybrid simulation model employs a multi-agent modeling approach combined with discrete event dynamic modeling to describe the discrete service process of orders. This study selects AnyLogic as the primary modeling software for the cloud manufacturing agent model. Upon creating a model, the software automatically generates a main class, serving as both the user interface and the main logic for simulation execution. Additionally, the software supports creating new Java classes and Agent classes, both based on object-oriented creation methods. The former is mostly used for simple entities and lacks sufficient autonomy, while the latter can encapsulate complex entity attributes, methods, and functions.

In AnyLogic version 8.7.4—used in this paper—Java class objects are hidden from the main interface due to their single functionality. Therefore, agent class objects assume the dual role of encapsulating and modeling both simple and complex entities. The correspondence between each entity and the class objects in AnyLogic is shown in

Table 1. Correspondence between entity classes and AnyLogic object classes.

AnyLogic Object Class	Cloud Manufacturing Entity Class
Main class	Platform agent (PA)
Simple agent class (containing only attribute settings)	Resource agent (RA)
	Message agent (MA)
	Orders agent (OA)
Complex agent classes (with multiple attribute and method settings)	Demander agent (DA)
	Server agent (SA)
	Task agent (TA)

.

3.1.1. Cloud Platform Agent Modeling

The cloud platform serves as the core of the entire cloud manufacturing service system, undertaking the following primary functions in the simulation model: (1) unified storage and management of cloud orders submitted by cloud demanders via terminal devices; (2) subtask division for pending orders and specification of their default processing service routes; (3) real-time recording of information for completed orders and failed orders during processing; (4) statistics and calculation of relevant performance indicators (e.g., service time, service cost, service quality) at the end of a service cycle; (5) Additional functions such as model parameter initialization and experimental parameter adjustment. Synthesizing the above, the cloud platform agent can be expressed as follows:

$$PA=<tobeProcessedOrderList,finishedOrderList,failedOrderList,{Func}_{ini},{Func}_{calcuRos},{Func}_{outputNetwork}>$$

(1)

Considering the path substitution strategy proposed for resource connection interruptions (detailed in Section 5), the attributes of the cloud platform agent are expanded as follows:

$${PA}^{\prime }=PA+<interrupt\_ResourcePairingList,interruptNum>$$

(2)

where (1) $interrupt\_ResourcePairingList$ initializes the sequence of all interrupted resource pairs during robustness experiments; (2) $interruptNum$ sets the number of interrupted resource pairs in the model for sensitivity analysis of specific parameters.

3.1.2. Cloud Order Agent Modeling

The cloud order agent is represented as follows:

$$OA=<ID,owner,taskList,routeStamp,cost1Accum,cost2Accum,$$

$$cost3Accum,reliabilityAccum,startTime,finishTime>$$

(3)

Considering the path substitution strategy proposed for resource connection interruptions, the attributes of the cloud order agent are expanded as follows:

$${OA}^{\prime }=OA+{<taskList}_1,{taskList}_2,is\_ChangeProcess, before\_ResourceList>$$

(4)

where (1) ${taskList}_1$ (the $taskList$ attribute in the basic order model) specifies the default processing path for the order type; (2) ${taskList}_2$ specifies the alternative processing path for the order; (3) $is\_ChangeProcess$ indicates whether the alternative processing path strategy has been invoked for the current order; (4) $before\_ResourceList$ records the resource information used in the immediate preceding process of the order’s current process.

3.1.3. Cloud Task Agent Modeling

The cloud task agent can be expressed as follows:

$$TA=<ID,owner\_Orders,pre\_taskList, after\_taskList,$$

$$reque\_resourceList,basicWorkingTime,currentOrder,{Func}_{selectBestServer},$$

$${Func}_{selectBestResource}, {Func}_{recordRouteStamp}, {Func}_{recordTaskTime}, {Func}_{recordTaskCost},$$

$${Func}_{recordTaskReliability}>$$

(5)

Considering the path substitution strategy for resource connection interruptions, the attributes of the cloud task agent are expanded as follows:

$${TA}^{\prime }=TA+{<pre\_taskList}_1,{pre\_taskList}_2,{after\_taskList}_1,$$

$$after\_{taskList}_2, {Func}_{recordBeforeList}, {Func}_{generatePairingList},$$

$${Func}_{changeProcess},{Func}_{failRoute}, {Func}_{turnBusyCondition}>$$

(6)

where (1) ${pre\_taskList}_1$ (the $pre\_taskList$ attribute in the basic task model) specifies the set of immediate predecessor tasks in the default processing path (Path 1); (2) ${pre\_taskList}_2$ specifies the set of immediate predecessor tasks in the alternative processing path (Path 2); (3) ${after\_taskList}_1$ (the $after\_taskList$ attribute in the basic task model) specifies the set of immediate successor tasks in the default processing path (Path 1); (4) $after\_{taskList}_2$ specifies the set of immediate successor tasks in the alternative processing path (Path 2); (5) ${Func}_{recordBeforeList}$ automatically records the resource information of the current process as the predecessor resource for the subsequent process; (6) ${Func}_{generatePairingList}$ generates a sequence of resource pair information based on the current and preceding process resources and determines whether the connection between the two resources is interrupted; (7) ${Func}_{changeProcess}$ redirects orders from Path 1 to Path 2 for continued processing if a resource connection interruption is detected; (8) ${Func}_{failRoute}$ adds orders in Path 2 to the failed order list and records relevant information if a resource connection interruption occurs; (9) ${Func}_{turnBusyCondition}$ releases the optimal resource requested by the current process (changing its status from “busy” to “idle”) if its connection to the preceding resource is interrupted and the resource can no longer be used.

3.1.4. Modeling of Other Agents

In addition to the above agent types, the cloud manufacturing system also includes multiple types of agents, such as resource agents, message agents, demander agents, and server agents, which can be expressed sequentially as follows:

$$RA=<ID,produceLevel,busy,broken,owner,price>$$

(7)

$$MA=<msg,resourceList,owner>$$

(8)

$$DA=<ID,location,orderList,{Func}_{sendOrders}>$$

(9)

$$SA=<ID,locatioin,resourcePool,dScore,pScore,totalScore,{Func}_{configureResource}>$$

(10)

The attributes and method information of these four types of agents have been detailed in Reference [38], so they are not repeated here.

3.2. Construction of Complex Network Model Based on Cloud Entity Relationships

The hybrid simulation model supports the extraction of information about cloud manufacturing entities and the association relationships between them. By further organizing this information into formats directly recognizable by network analysis tools, such as Pajek and the Python extension networkx, a complex network model based on cloud entity relationships can be established. For example, a cloud resource network model can be built based on connections between resource nodes, and a cloud task network model can be constructed from relationships between task nodes.

This study primarily focuses on the cloud resource network model, which consists of cloud resources and the association relationships between them. Different order types correspond to distinct task processing paths, where immediate predecessor and successor tasks in the same path have direct connections. Additionally, each task requests specific cloud resources during processing. In this paper, if two tasks are directly connected in a path, their corresponding resources are considered associated. Thus, by treating all cloud resources as network nodes and resource associations as edges, a cloud manufacturing resource network is formed. A schematic diagram is shown in Figure 2:

(1)

The service process simulation model in Figure 3 includes three types of cloud manufacturing orders: Order-AA, Order-BB, and Order-CC. For example, Order-AA follows a serial processing path with four tasks: Task a, Task b, Task c, and Task d. The corresponding resources are R1-Si (affiliated with service provider Si), R2-Si, R4-Si, R3-Sj (affiliated with service provider Sj), and R5-Sj. This establishes connection relationships among the five resources.

(2)

Similarly, the paths of Order-BB and Order-CC, along with the resource relationships of their tasks, reveal the local correlation relationships among all 13 resources.

(3)

Furthermore, since the three independent local networks share common resource nodes, deduplication and aggregation of these nodes yield the overall cloud manufacturing resource network model.

Notably, the schematic diagram only lists three order types and 13 resources. In real-world scenarios, cloud manufacturing involves a massive number of resources and complex connection relationships, making complex network models suitable for analyzing the relational model of cloud resource entities.

3.3. Robustness Evaluation Indicators

3.3.1. Performance Robustness

Existing evaluations of cloud manufacturing systems mostly focus on the quality of service (QoS) indicator, which is comprehensively calculated from multiple dimensions, such as service time, service cost, and reliability. In this paper, the measurement of performance robustness draws reference from the QoS definition. As the hybrid simulation model supports the recording and output of data, such as service cycles and costs, these performance metrics are also used to evaluate robustness. Additionally, combining the concept of system robustness, the focus of performance robustness evaluation is not on performance itself but on the degree of performance loss and fluctuation under different disturbances. Therefore, this paper proposes the concept of robustness of service (RoS) as the robustness evaluation indicator for system performance:

$$RoS=ofr\ast [1-({\omega }_1\ast {\displaystyle \frac{\left|T-T_0\right|}{T_0}}+{\omega }_2\ast {\displaystyle \frac{\left|C-C_0\right|}{C_0}}+{\omega }_3\ast {\displaystyle \frac{\left|rel-{rel}_0\right|}{{rel}_0}})]$$

(11)

where $T_0, C_0$, and ${rel}_0$ are baseline values for service time, cost, and reliability under disturbance-free conditions, respectively; $T$, $C$, and $rel$ are the actual values of the current experimental group; $ofr$ is defined as the ratio of completed orders to the total number of planned orders, and ${\omega }_1$, ${\omega }_2$ and ${\omega }_3$ are weight coefficients satisfying $\sum _{i=1}^3{\omega }_i=1$.

3.3.2. Structural Robustness

Cloud manufacturing systems encompass massive cloud service entities and large-scale manufacturing service scenarios whose structural properties can be explored by constructing relational models between entities. The structural robustness evaluation indicators in this paper are primarily developed based on the constructed complex network model of cloud resource relationships. Generally, network robustness refers to the degree of retention of a network model after node or edge failures. Existing studies often focus on network connectivity or efficiency, with two common categories of evaluation indicators: the relative size of the maximum connected subgraph (S) and network efficiency (φ). This paper primarily selects the relative size of the maximum connected subgraph, S, as the robustness evaluation indicator for the network model.

When a network is disturbed or damaged, it causes changes in the overall topological structure. For example, as shown in Figure 3, when all edges of nodes A and B in the network are damaged, the original connected network is decomposed into two connected components and three isolated small clusters. Among them, one major connected component in the two components has significantly more nodes and edges than the others, representing the maximum connected subgraph after decomposition. Based on this, the specific description of the relative size S of the maximum connected subgraph is as follows:

When network G is attacked, nodes v1, v2,……, and vm(1 ≤ m ≤ N) lose connectivity with other or all nodes in the network, dividing G into several independent clusters and connected subgraphs G1, G2,…, and Gt (1 ≤ t ≤ n). Let Ki be the number of nodes in connected subgraph Gi(1 ≤ i ≤ t). Then,$N^{\prime }$ denotes the absolute size of the maximum connected subgraph after the attack, and S denotes the relative size of the maximum connected subgraph, expressed as follows:

$$N^{\prime }=\mathrm{m}\mathrm{a}\mathrm{x}\{K_i,i=\mathrm{1,2},\dots ,t\}$$

(12)

$$S={\displaystyle \frac{N^{\prime }}{N}}$$

(13)

where N is the initial size of the network, with $N^{\prime }$≤N. In the undisturbed initial state, $N^{\prime }=N$ and $S=1$. A value of S closer to 1 indicates that more nodes remain connected in the cloud manufacturing network after an attack, signifying a more stable network structure. Conversely, a smaller S value indicates fewer connected nodes after an attack, reflecting weaker network robustness.

Figure 3. Schematic diagram of the maximum connected subgraph.

Figure 3. Schematic diagram of the maximum connected subgraph.

3.4. Design of Robustness Failure Modes

This paper primarily explores the robustness of cloud manufacturing service systems under different disturbance scenarios. Therefore, based on the constructed simulation model and evaluation indicators, the design of failure modes for robustness analysis is a critical focus, as it serves as the key to robustness analysis.

Since the path substitution strategy in this paper mainly addresses the issue of cloud resource connection interruptions (i.e., the cloud resources themselves are not faulty, but the collaborative relationship between upstream and downstream resources is interrupted, preventing normal connection between their corresponding predecessor and successor subtasks), this is modeled by marking interrupted resource agent association pairs. Orders requiring direct collaboration between these pairs are redirected to a failed order set. The specific description of resource edge failure modes (edge interruption scenarios) is as follows:

The detailed process of resource edge failure is shown in

Table 2. Design of edge failure mode based on resource connection interruption.

Failure Mode Category	Failure Mode Name	Description of Failure Process
Failure based on initial topology	Initial edge weight loss (IEW)	Sort the associated resource edges in the initial network (Network-0) in descending order of edge weights. In the simulation model, mark the resource pairs corresponding to one edge at a time as “interrupted resource pairs” to simulate cloud resource association interruptions. Repeat this process n times until all associated resources in the simulation model are interrupted.
	Initial edge betweenness loss (IEB)	Sort the associated resource edges in the initial network (Network-0) in descending order of edge betweenness. In the simulation model, mark the resource pairs corresponding to one edge at a time as “interrupted resource pairs” to simulate cloud resource association interruptions. Repeat this process n times until all associated resources in the simulation model are interrupted.
Failure based on recomputed topology	Recomputed edge weight loss (REW)	Sort the associated resource edges in the initial network (Network-0) in descending order of edge weights, remove the first edge, and denote the resulting network as Network-1. In Network-1, re-sort the remaining associated resource edges in descending order of edge weights, remove the first edge, and denote the resulting network as Network-2; repeat this process to record the dynamically calculated edge weight sorting sequence of associated resource pairs. In the simulation model, mark one associated resource pair as “interrupted” at a time in this sequence, repeating n times until all associated resources in the simulation model are interrupted.
	Recomputed edge betweenness loss (REB)	Sort the associated resource edges in the initial network (Network-0) in descending order of edge betweenness, remove the first edge, and denote the resulting network as Network-1. In Network-1, re-sort the remaining associated resource edges in descending order of edge betweenness, remove the first edge, and denote the resulting network as Network-2; repeat this process to record the dynamically calculated edge betweenness sorting sequence of associated resource pairs. In the simulation model, mark one associated resource pair as “interrupted” at a time in this sequence, repeating n times until all associated resources in the simulation model are interrupted.

Notes: (1) during processing, a cloud order is decomposed into multiple subtasks. If the associated resources corresponding to a predecessor subtask and a successor subtask are in an interrupted state, the corresponding cloud order cannot be completed, and it will be directed to the failed order set with relevant information recorded. (2) In the network model, resource connection interruption is represented by the removal of edges (i.e., deleting edges between specified node pairs in the network). In the simulation model, it is represented by real-time recording of resource information used in predecessor and successor subtasks. If the resource pair information belongs to predefined interrupted resource pairs, cloud services cannot continue, and order processing fails.

, and the failure flowchart is presented in Figure 4. For resource edge failures, two structural importance indicators are selected: edge weight and edge betweenness [39]. Edge weight represents the frequency of collaboration between cloud resources—the higher the edge weight, the closer the collaborative relationship. Edge betweenness reflects the structural and functional control of associated resources over the entire cloud manufacturing system—the higher the edge betweenness, the stronger their control. Additionally, two calculation modes are considered: static failure based on the initial topology and dynamic failure based on the recomputed topology. The former determines the sorting, once, of all resource edges by weight and betweenness based on the initial network topology (Network0), while the latter dynamically recalculates the latest edge weights and betweenness rankings after each edge failure.

3.5. Formulation of Path Substitution Strategy

In real-world cloud manufacturing scenarios, uncertainties extend beyond cloud resource failures or withdrawals to include logistics transportation interruptions, equipment communication link disruptions, and other situations (e.g., city lockdowns during pandemics or localized power outages). While these events minimally affect individual resource statuses, they severely disrupt connectivity between specific resources, preventing established collaborative relationships and causing order failures that require joint efforts from multiple cloud resources.

In the context of this paper’s robustness analysis failure mode design, when a cloud order is submitted to the cloud platform, it is decomposed into subtasks undertaken by geographically dispersed enterprises (resource providers). If the connection between upstream and downstream cloud resources is interrupted, the normal handover between predecessor and successor subtasks fails, leading to the failure of the overall service route. To address this, temporary activation of alternative routes is proposed—when one service route is interrupted, another route [40,41,42,43] can replace it for continued processing. This necessitates robustness improvements for cloud manufacturing service systems, specifically by configuring alternative service routes for each order to emphasize path diversity and interchangeability. Based on this, a path substitution strategy for cloud manufacturing services is proposed against an initial model (control group):

(1)

Path substitution strategy: each order type is provided with two processing paths: a default processing path (Path 1) and an alternative processing path (Path 2). Cloud orders are first directed to Path 1 for processing according to their technological routes. During processing, the cloud task agent automatically records the currently used cloud resource (denoted as Ri-Si) and determines whether normal communication exists between this resource and the cloud resource used in the immediately preceding task (denoted as Rj-Sj). If the connection is normal, processing continues in Path 1 until all remaining operations are completed. If the connection is interrupted, Path 1 is deemed unavailable, and the order is redirected to Path 2 for processing. Notably, while alternative paths can complete order processing, they typically incur longer service times, higher costs, and other performance trade-offs compared to Path 1.

(2)

No substitution strategy (control group): each order corresponds to only one default processing path (Path 1). During Path 1 processing, the system continuously checks whether the cloud resource requested for the current operation (Ri-Si) can communicate normally with the resource used in the preceding operation (Rj-Sj). If the connection is normal, processing proceeds to the next operation until completion. If the connection is interrupted, Path 1 is deemed unavailable, the order cannot be processed further, and it is added to the failed order set with relevant information recorded. The logical flow of the two strategies is illustrated in Figure 5.

4. Case Study

4.1. Model Parameter Description

This section conducts a specific case study based on a cloud manufacturing project. The project includes 24 order types and 72 cloud resource types (r1–r72). Notably, an alternative processing path is added for each of the 24 orders’ default processing paths, increasing the number of cloud tasks to 117 (t1–t117). The correspondence between each cloud task and the required resource type is shown in

Table 3. Default processing paths and alternative processing paths for each order.

Order Type	Default Processing Path	Alternative Processing Path
Order11
Order12
Order13
Order14
Order15
Order16
Order21
Order22
Order23
Order24
Order25
Order26
Order31
Order32
Order33
Order34
Order41
Order42
Order43
Order44
Order51
Order52
Order53
Order54

; the cloud processing routes and alternative processing routes for each order type are listed in

Table 4. Correspondence between tasks and resources.

Task	Required Resource	Task	Required Resource	Task	Required Resource	Task	Required Resource
t1	(r1)	t2	(r3)	t3	(r2)	t4	(r4)
t5	(r11, r30)	t6	(r5)	t7	(r12, r29)	t8	(r6)
t9	(r12, r29)	t10	(r31)	t11	(r11, r30)	t12	(r67)
t13	(r32)	t14	(r1)	t15	(r7)	t16	(r1)
t17	(r2)	t18	(r8)	t19	(r2)	t20	(r5)
t21	(r5)	t22	(r41)	t23	(r6)	t24	(r6)
t25	(r71)	t26	(r42)	t27	(r33)	t28	(r9)
t29	(r9)	t30	(r34)	t31	(r10)	t32	(r10)
t33	(r9)	t34	(r7)	t35	(r9)	t36	(r7)
t37	(r10)	t38	(r8)	t39	(r10)	t40	(r8)
t41	(r13, r14)	t42	(r61)	t43	(r21, r23)	t44	(r51, r52)
t45	(r15, r16)	t46	(r62)	t47	(r22, r24)	t48	(r53, r54)
t49	(r21, r23)	t50	(r47, r48)	t51	(r47, r48)	t52	(r33)
t53	(r35, r37)	t54	(r63)	t55	(r43, r45)	t56	(r22, r24)
t57	(r49, r50)	t58	(r49, r50)	t59	(r34)	t60	(r36, r38)
t61	(r64)	t62	(r44, r46)	t63	(r35, r37)	t64	(r41)
t65	(r41)	t66	(r39)	t67	(r25, r27)	t68	(r65)
t69	(r13, r14)	t70	(r36, r38)	t71	(r42)	t72	(r42)
t73	(r40)	t74	(r26, r28)	t75	(r66)	t76	(r15, r16)
t77	(r47, r48)	t78	(r51, r52)	t79	(r57, r58)	t80	(r47, r48)
t81	(r49, r50)	t82	(r53, r54)	t83	(r68)	t84	(r59, r60)
t85	(r49, r50)	t86	(r57, r58)	t87	(r17, r19)	t88	(r63)
t89	(r55)	t90	(r59, r60)	t91	(r18, r20)	t92	(r69)
t93	(r64)	t94	(r70)	t95	(r56)	t96	(r2)
t97	(r4)	t98	(r1)	t99	(r3)	t100	(r67)
t101	(r31)	t102	(r12, r29)	t103	(r8)	t104	(r10)
t105	(r7)	t106	(r9)	t107	(r2)	t108	(r4)
t109	(r1)	t110	(r3)	t111	(r18, r20)	t112	(r53, r54)
t113	(r69)	t114	(r64)	t115	(r59, r60)	t116	(r70)
t117	(r68)

.

Five cloud service providers (S1–S5) participate in the project, each offering all 72 cloud resources. Additionally, there are 14 cloud demanders (d1–d14), each submitting all 24 types of orders with a quantity of one per order. The basic information of each cloud service provider and demander is imported from an external Excel file, with partial Excel data shown in

Table 5. Partial attribute information of cloud service providers and demanders.

ID	City	Location (Longitude, Latitude)	ID	City	Location (Longitude, Latitude)
S1	Beijing	(116.41, 39.91)	d5	Jinan	(117, 36.4)
S2	Shanghai	(121.43, 31.21)	d6	Lanzhou	(103.73, 36.03)
S3	Chengdu	(104.06, 30.66)	d7	Wulumuqi	(87.68, 43.76)
S4	Hangzhou	(120.2, 30.26)	d8	Changsha	(113, 28.21)
S5	Shenzhen	(114.06, 22.61)	d9	Nanchang	(115.9, 28.68)
			d10	Fuzhou	(119.3, 26.08)
d1	HaErbin	(126.63, 45.75)	d11	Nanning	(108.19, 22.48)
d2	ShenYang	(123.38, 41.8)	d12	Lasa	(91, 29.6)
d3	Baotou	(109.49, 40.39)	d13	Lianyungang	(119.1, 34.36)
d4	Tianjin	(117.2, 39.13)	d14	Hefei	(117.17, 31.52)

.

4.2. Simulation Result Analysis of Path Substitution Strategy

Based on the edge failure modes designed in Section 3.4, simulation experiments were conducted using Python’s networkx 2.8.4 package and AnyLogic 8.7.4 simulation software to investigate the enhancement effects of the path substitution strategy on the structural robustness and performance robustness of cloud manufacturing systems under different resource connection interruption modes. The simulation experiments were performed on a PC configured with an Intel Core i7 CPU (2.8 GHz), 8.00 GB RAM, and a 64-bit Windows 10 operating system. Each set of simulations was run 30 times, and the average values of all output data were statistically analyzed after the 30 simulations to calculate the robustness evaluation indicators RoS (robustness of service) and S (relative size of the maximum connected subgraph).

4.2.1. Performance Robustness Analysis

The changes in performance robustness indicators (RoSs) of the cloud manufacturing system under the two strategies and different resource connection interruption modes are shown in Figure 6. A comparison between the path substitution curve and the no substitution curve reveals the following improvements in system performance robustness (RoS) provided by the path substitution strategy: (1) Under the four resource connection interruption modes (IEW, IEB, REW, REB), the path substitution curve consistently lies above the no substitution curve, with a significant gap between them, confirming the effectiveness of the proposed path substitution strategy in enhancing system performance robustness. (2) The gap between the two curves in the REW and REB interruption modes is smaller than that in the IEW and IEB modes, indicating that the proposed strategy has a less pronounced effect on improving system performance robustness in the REW and REB modes compared to the IEW and IEB modes.

The above graphical analysis initially confirms the performance improvement of the proposed strategy under resource connection interruptions. To further validate these results, a paired t-test was conducted on the RoS values of the two strategies. The results of the paired t-test for the RoS indicators are shown in

Table 6. Paired t-test of RoS values under path substitution strategy and no substitution strategy.

Failure Mode	Strategy	Mean	SD	SE	Difference 95% CI		t	df	Sig.
					Lower	Upper
IEW	Substitution/no substitution	0.449	0.129	0.024	0.399	0.498	18.675	28	<0.001
IEB	Substitution/no substitution	0.585	0.194	0.037	0.509	0.662	15.701	26	<0.001
REW	Substitution/no substitution	0.162	0.117	0.027	0.105	0.218	6.012	18	<0.001
REB	Substitution/no substitution	0.214	0.118	0.025	0.161	0.266	8.471	21	<0.001

. The test results indicate that there are significant differences in the RoS values between the two strategies in the four groups of simulation experiments (IEW, IEB, REW, REB) at a 95% confidence interval, demonstrating that the path substitution strategy significantly enhances the performance robustness of cloud manufacturing systems under resource connection interruptions.

Through the relative positions of the RoS value curves and the statistical paired t-test, the enhancement effect of the proposed path substitution strategy on the performance robustness of cloud manufacturing systems has been analyzed. Next, a horizontal comparison of the two strategies is continued from the following two perspectives: (1) the RoS indicator value when the number of resource connection interruptions is maximized; (2) the number of resource connection interruptions when the RoS indicator value drops to 0. The analysis results based on this case are shown in

Table 7. Minimum value of RoS and corresponding number of resource connection interruptions under two strategies.

Failure Mode	Strategy	Minimum Value of RoS	The Number of Edge Failures Corresponding to RoS Dropping to 0
IEW	No substitution	0	594
	Path substitution	0.485	-
IEB	No substitution	0	594
	Path substitution	0.485	-
REW	No substitution	0	279
	Path substitution	0	461
REB	No substitution	0	284
	Path substitution	0	541

and Figure 7.

As shown in Figure 7a, under the IEW and IEB connection interruption modes, the RoS value of the no substitution strategy eventually drops to 0, while the RoS value of the path substitution strategy remains at a certain level (0.485). This indicates that the path substitution strategy significantly improves the system’s performance robustness under the two initial topology interruption modes. As shown in Figure 7b, the REB and REW connection interruption modes cause greater damage to the system’s performance robustness, and the RoS values corresponding to both strategies eventually drop to 0. By comparing the number of connection interruptions when RoS drops to 0, it can be seen that the no substitution strategy only requires fewer interrupted associated resources (279 and 284) to make its RoS value drop to 0, while the path substitution strategy requires more failed associated resources (461 and 541) to make RoS drop to 0. This indicates that the path substitution strategy also significantly improves the system’s performance robustness under the two recomputed topology interruption modes.

Finally, the physical meaning and mechanism of the above results are analyzed as follows: (1) From the perspective of system performance, the interruption of upstream and downstream cloud resource associations directly causes the interruption of collaborative production between predecessor and successor subtasks, making the service route where the two subtasks are located unable to complete the current order processing, resulting in order processing failure. (2) Order failures reduce the total number of completed orders within a cloud service cycle, causing a sharp decline in performance indicators such as service cycle and cost, which is collectively reflected in the rapid decrease in the system performance robustness indicator RoS. (3) When the path substitution strategy is adopted, the cloud platform can promptly identify resource connection interruptions. When the current service path, where associated resources are located, cannot complete order processing, an alternative service path is temporarily activated. If the alternative service chain is available, the original failed order can be reprocessed, and the number of completed orders within the service cycle remains unchanged, so the RoS indicator value does not fluctuate significantly. However, since it is an alternative path, although it can complete the specified task, it will increase service time, service cost, and other indicators, which is collectively reflected in a small decrease in the RoS indicator from its original level. (4) When the number of interrupted resource associations increases, there may be situations where both the service path and its alternative service path are unavailable, at which point the order will still fail to be processed, causing the RoS indicator value to drop rapidly. Since this case only sets one service path and one alternative service path for each order type, its ability to resist resource connection interruptions is limited. When the number of connection interruptions is small, the service substitution strategy has a significant effect on improving system performance robustness. However, as the number of connection interruptions gradually increases, the overall performance robustness of the system will still decline.

4.2.2. Structural Robustness Analysis

The changes in structural robustness indicators (S) of the cloud manufacturing system under the two strategies and different resource connection interruption modes are shown in Figure 8. A comparison between the path substitution curve and the no substitution curve reveals the following improvements in system structural robustness (S) provided by the path substitution strategy: (1) Under the four resource connection interruption modes (IEW, IEB, REW, REB), the path substitution curve consistently lies above the no substitution curve, with a significant gap between them, preliminarily confirming the effectiveness of the proposed path substitution strategy in enhancing system structural robustness. (2) The gap between the two curves in the REW and REB interruption modes is smaller than that in the IEW and IEB modes, indicating that the proposed strategy has a less pronounced effect on improving system structural robustness in the REW and REB modes compared to the IEW and IEB modes.

The above graphical analysis initially confirms the structural robustness improvement of the proposed strategy under resource connection interruptions. To further validate these results, a paired t-test was conducted on the S values of the two strategies. The results of the paired t-test for the S indicators are shown in

Table 8. Paired t-test of S values under the path substitution strategy and the no substitution strategy.

Failure Mode	Strategy	Mean	SD	SE	Difference 95% CI		t	df	Sig.
					Lower	Upper
IEW	Substitution/no substitution	0.414	0.185	0.034	0.344	0.485	12.032	28	<0.001
IEB	Substitution/no substitution	0.667	0.163	0.031	0.602	0.731	21.240	26	<0.001
REW	Substitution/no substitution	0.335	0.240	0.055	0.220	0.451	6.097	18	<0.001
REB	Substitution/no substitution	0.224	0.226	0.048	0.124	0.324	4.647	21	<0.001

. The test results indicate that there are significant differences in the S values between the two strategies in the four groups of simulation experiments (IEW, IEB, REW, REB) at a 95% confidence interval, demonstrating that the path substitution strategy significantly enhances the structural robustness of cloud manufacturing systems under resource connection interruptions.

Through the trend of the system structural robustness indicator (S) values and the statistical paired t-test, the enhancement effect of the proposed path substitution strategy on the structural robustness of cloud manufacturing systems has been analyzed. Next, a horizontal comparison of the two strategies is continued from the following two perspectives: (1) the S indicator value when the number of resource connection interruptions is maximized; (2) the number of resource connection interruptions when the S indicator value drops to 0. The analysis results based on this case are shown in

Table 9. Minimum value of S and corresponding number of resource connection interruptions under two strategies.

Failure Mode	Strategy	Minimum Value of S	The Number of Edge Failures Corresponding to S Dropping to 0
IEW	No substitution	0	594
	Path substitution	0.346	744
IEB	No substitution	0	594
	Path substitution	0.346	676
REW	No substitution	0	279
	Path substitution	0	461
REB	No substitution	0	284
	Path substitution	0	541

and Figure 9.

As shown in Figure 9a, under the IEW and IEB connection interruption modes, the S value of the no substitution strategy eventually drops to 0, while the S value of the path substitution strategy remains at a relatively high level (0.346). This indicates that the path substitution strategy significantly improves the system’s structural robustness under the two initial topology interruption modes. As shown in Figure 9b, the REW and REB connection interruption modes cause greater damage to the system’s structural robustness, and the S values corresponding to both strategies eventually drop to 0. By comparing the number of connection interruptions when S drops to 0, it can be seen that the no substitution strategy only requires fewer interrupted associated resources (279 and 284) to make its S value drop to 0, while the path substitution strategy requires more failed associated resources (461 and 541) to make S drop to 0. This indicates that the path substitution strategy also significantly improves the system’s structural robustness under the two recomputed topology interruption modes.

Finally, the physical meaning and mechanism of the above results are analyzed as follows: (1) In cloud manufacturing systems, massive cloud resource entities collaborate to complete order services, forming complex correlation networks due to diverse order types and service route structures. (2) Interruptions in resource associations disrupt predecessor–successor subtask connections, leading to order failures. From a structural perspective, this removes the connected subgraph of resources involved in the order, rapidly reducing the network size and causing a sharp decline in the S value. (3) The path substitution strategy enables the cloud platform to identify interrupted resource pairs, deactivate failed service routes, and activate alternative paths. If available, alternative routes restore order processing by introducing new connected subgraphs (composed of resources in the alternative path) into the network, recovering its size. (4) Although alternative paths may increase service time/cost, these performance factors do not directly affect the structural indicator S. Additionally, alternative paths often have different route structures and resource compositions, leading to new connected subgraphs that are larger than the failed ones, causing a slight increase in the S value. (5) When the number of interrupted resources grows, both primary and alternative paths may fail simultaneously, removing large connected subgraphs and drastically reducing the S value. With only one alternative path per order in this study, the strategy’s robustness is limited: it effectively protects structural integrity under low interruptions but struggles as disruptions increase.

4.3. Management Recommendations

This paper addresses the disturbance of resource connection interruptions (edge failures) by proposing a path substitution strategy, which involves setting an alternative service path for each order alongside its default path. Simulation experiments based on a specific case were conducted to analyze the strategy’s enhancement effects on system performance robustness and structural robustness under four resource interruption modes. The following management recommendations are derived from the simulation results:

(1)

In real-world cloud service scenarios, uncertainties extend beyond individual resources to include connection uncertainties (e.g., logistics disruptions due to pandemic lockdowns or communication failures from localized power outages). Although these events minimally affect resource hardware, they severely disrupt inter-resource connectivity, potentially causing order failures when multiple resources are required for collaboration. Cloud platform managers should therefore implement protective measures not only for resource hardware failures but also for communication interruptions, connection status disruptions, and software faults.

(2)

To mitigate resource connection interruptions, managers can draw inspiration from the concept of “process flexibility” to provide multiple feasible service routes for cloud orders, including alternative paths for existing routes. Simulation results show that alternative paths allow orders to resume production when primary routes fail, thereby maintaining system stability. Cloud platform managers should prioritize diversity and interchangeability of service routes alongside resource diversity to enhance system robustness.

(3)

When configuring alternative service routes, managers must consider factors such as service cycle and cost. While alternative paths offer a fast response to interruptions without requiring adaptive mechanisms, they often involve more complex routes or additional resources, leading to longer cycles and higher costs. Managers should therefore control the complexity of alternative paths and the number of new resources involved. Additionally, the trade-off between system robustness and management costs—given that more resources increase platform management overhead—requires careful consideration.

5. Conclusions

This paper proposes a path substitution strategy based on alternative processing paths to enhance robustness against resource connection interruptions, validated through simulation experiments comparing scenarios with and without path substitution. Results show that the strategy significantly improves both performance and structural robustness, though its effectiveness varies across disturbance scenarios. Management recommendations are provided to address resource interruption challenges and design robustness enhancement strategies.

The proposed robustness analysis model accurately captures complex disturbances in cloud manufacturing, and the designed simulation experiments enable the multi-dimensional evaluation of robustness strategies from performance and structural perspectives, offering a quantitative method for selecting robustness enhancement measures under complex disturbances.

However, this study still has certain limitations and shortcomings, which require further exploration in future research:

(1)

Conduct in-depth research on simulation modeling of robustness improvement strategies for cloud manufacturing systems. Currently, only simulation modeling methods based on two ideas—adding alternative resources and adding alternative paths—are proposed for cloud resource failures and cloud resource connection interruptions. In the future, more interference scenarios should be considered, more targeted robustness improvement strategies should be formulated, and specific simulation modeling methods should be proposed for verification.

(2)

Further construct the cloud manufacturing network relationship model and propose more comprehensive evaluation indicators based on the system structure dimension. Current research mainly focuses on cloud resources themselves and the relationships between cloud resources to construct an association network of cloud resources. In the future, it will be possible to consider constructing multi-type entity networks (e.g., cloud task networks, cloud knowledge networks, cloud order networks) to realize the correlation analysis between dual-layer or multi-layer networks. Additionally, based on the establishment of new network models, more comprehensive robustness evaluation indicators based on the structural dimension should be proposed.

(3)

Further construct the cloud manufacturing simulation model, including the further enrichment of agent behaviors. Currently, the construction of agents for cloud manufacturing systems mainly focuses on the operation of cloud manufacturing service systems under different interference scenarios. In the future, it will be necessary to further improve and expand agent attributes, methods, knowledge bases, and protocol mechanisms, aiming to solve cloud manufacturing decision-making problems in more scenarios.