Computing Unit and Data Migration Strategy under Limited Resources: Taking Train Operation Control System as an Example

Abstract

There are conflicts between the increasingly complex operational requirements and the slow rate of system platform upgrading, especially in the industry of railway transit-signaling systems. We attempted to address this problem by establishing a model for migrating computing units and data under resource-constrained conditions in this paper. By decomposing and reallocating application functions, optimizing the use of CPU, memory, and network bandwidth, a hierarchical structure of computing units is proposed. The architecture divides the system into layers and components to facilitate resource management. Then, a migration strategy is proposed, which mainly focuses on moving components and data from less critical paths to critical paths and ultimately optimizing the utilization of computing resources. Specifically, the test results suggest that the method can reduce the overall CPU utilization by 27%, memory usage by 6.8%, and network bandwidth occupation by 35%. The practical value of this study lies in providing a theoretical model and implementation method for optimizing resource allocation in scenarios where there is a gap between resource and computing requirements in fixed-resource service architectures. The strategy is compatible for distributed computing architectures and cloud/cloud–edge-computing architectures.

1. Introduction

In some real-time control domains, there is a significant gap between the computational capabilities of processing units and the requirements of high computational power, clustering, load balancing, distributed parallel computing, etc. [1,2]. For example, in the rail transportation system sector, by the end of 2022, only one system manufacturer had launched a cloud-computing platform with high computational capabilities [3], which is still in the initial stages of operation in 2024. It has become increasingly important to replace computing platforms with new ones or to upgrade existing platforms with new technologies [4]. This issue becomes even more prominent when enhancing and optimizing computational capabilities under conditions such as embedded operating systems where the underlying platform is tightly bound to hardware, with low frequency and small room of updates, and limited computational resources [5]. Therefore, a good component- and data-migration strategy is particularly critical.

System architects and specialists have conducted research from multiple perspectives, including process/thread scheduling, memory management, interface optimization, and load balancing. In terms of computing loading balance, Hu et al. [5] and Tang et al. [6] analyzed the CPU/GPU resource allocation from data flow impact and proposed a framework model for resource scheduling by modifying layers of the operating system. With regard to process/thread scheduling, Sun et al. [7] described the mathematical relationship between energy consumption, response time, and resource utilization, in order to meet the requirements of high energy efficiency and low response time. By using the distributed-flow computing theory, they modeled the data flow graph and gave a real-time and energy-saving resource scheduler based on a RE-STREAM model. In terms of memory management and interface optimization, Yang et al. [8] adopted the Kuhn–Tucker (KKT) theory and Binary Search Iterative methodology, taking time delay and energy consumption into consideration. By doing so, a Branch-and-Bound-based Overhead Minimization Offload Algorithm (BB-OMOA) was proposed to obtain the optimal offload decisions. Li et al. [9] proposed a computing-task-unloading strategy based on the gradient algorithm. They copied the subtasks to the so-called secondary unloading units (which means the edge-computing unit in this context) in case the main computing unit failed. Liu et al. [10] applied the improved genetic algorithm with penalty features to the unmanned aerial vehicle (UAV) mobile edge-computing server. Pu et al. [11] studied the inter-thread scheduling of components on the Storm platform and designed an optimal thread reallocation model and a data migration model based on the CPU usage, memory loading, and network bandwidth.

From the partial studies presented above, which specifically refer to the resource allocation [5,12], computing-resource–data matching [13,14], resource scaling [15,16], and quantitative evaluation algorithm of resource mining/utilization [17,18], it can be seen that those methodologies are kinds of “Aftermath Remediation”, i.e., they attempt to decompose and reallocate computing resources to different levels of the target program when a mismatch between computing resources and demand occurs. This could be very difficult when most of the computing resources are fixed and have clear calculation tasks pre-defined. Little room would be left for computing-resource reallocation. Another point is that in some studies [15,16,17,18,19,20], attention is paid to the cloud-computing or cloud–edge-computing architectures. Embedded safety systems, especially real-time vital control systems which are widely used in the railway transit industry, are rarely mentioned. Furthermore, certain studies [6,7,8,9,10] further revealed an optimization path on a CPU/GPU load-balancing algorithm. In those articles, a research direction of resource-consuming optimization on a cluster is pointed out. However, the scope of work is limited to the main processor (software or hardware). No analysis is put in place on how to conduct a collaborative optimization from the overall system scope. So, it needs further verifications targeting the effectiveness through real engineering projects. Lastly, the critical computing path [11] and critical links [21,22] are determined via the time required from the longest range of dependent activities; thus, accordingly, the critical path method (CPM) algorithm is used to schedule those activities.

This paper attempts to fill up the gap described above: It encapsulates the entire real-time control subsystem as a “node”. A node is responsible for assembling all calculating units to form a complete functional chain; it encapsulates a set of software components as a “computing unit”. A computing unit is responsible for implementing one or more specific functions. By connecting data streams involving inter-unit and intra-unit communication resources through nodes and computing units, a critical computing path strategy is formed, and the computing consumption along the path is calculated. On this basis, a principle regarding component and data migration can be defined, and thus the migration strategy model is established and followed by an experimental analysis with conclusions. To summarize, the contributions of this paper are as follows:

(1)

A hierarchical architecture of computing units and data abstraction is formed under limited computing resources. It abstracts real systems into a data-processing-and- transmission model, which is composed of nodes, components, data, and data flow;

(2)

A resource consumption calculation method is created. The method establishes a data migration model and lists migration criteria under resource constraints. The attributes of resource consumption, i.e., a combination of CPU usage, RAM occupancy, and network bandwidth demand, are added to the critical computing path;

(3)

A computing unit and data migration method is proposed. This method optimizes the resource cost by placing associate components/data from non-critical paths to the critical paths and transforms the path between nodes into the path within nodes.

Real-time vital control systems are emphasized in this paper, while the next step can be set to create a general migration algorithm with more compatible and configurable features, e.g., weighing the software’s cycloramic complexity, cybersecurity measurement cost, etc., into the algorithm. From a methodological perspective, it can be summarized as how to define low coupling interfaces between components in software detail design, and how to adjust function allocation from a node perspective to make it highly cohesive.

With regard to this paper’s structure, Section 1 is the introduction of this article, including the background, literature review, and innovations; Section 2 presents an abstract hierarchical architecture of computing units and establishes a path-based resource consumption model through suggested critical paths; Section 3 demonstrates the path cost after migration activities and puts forward the basic migration criteria and migration strategies; Section 4 provides the specific algorithm and steps of components and data migration; The effectiveness and correctness of the algorithm is tested in Section 5; and Section 6 provides conclusions and information related to this paper.

2. System Abstraction

In order to analyze the computing units and their data redistribution based on limited computing resources, this Section introduces a hierarchical architecture, which decomposes computing units into nodes (subsystem layer), components (functional modules in computing units), data, and data flows and then generalizes the architecture into a data-processing and -transmission collaboration diagram. Finally, it establishes a path-based resource consumption model through critical transmission paths and provides a theoretical basis for the following component and data migration strategies.

Security control systems and security-critical systems share common features, including real-time monitoring, emergency response, access control, logging, and record-keeping. What makes safety-critical systems different from safety control systems is that safety-critical systems must meet the requirements of safety integration level 4’s requirements (SIl4), which is the highest safety level of a controller.

2.1. Hierarchical Architecture of Computing Units

Based on actual business requirements, we transform a typical safety-critical system into an abstracted, hierarchical architecture of computing units. According to the functional deployment, a typical safety-critical system is composed of business logic units, safety protection logic units, data storage units, and external interface adaptors, as shown in Figure 1.

Figure 1 shows a typical safety-critical train control system in the railway transit industry. From the top down, it contains all necessary functions, including the 2-out-of-3 main processors with a scheduler engine on the top, data management modules, system parameters for applications and operating systems, and hardware drivers for all peripheral equipment. The safety-critical system in Figure 1 can be abstracted into four layers, which are defined as nodes. Each layer (node) has several processing units (e.g., “services” in Figure 1 “business logic layer”), which are defined as computing units. There are several modules in a unit (e.g., “Mode Control” in Figure 1 “services” unit), which are defined as components. Based on the above, the computing unit architecture can be generalized as a hierarchical architecture with topological connections between nodes and components, as shown in Figure 2.

2.2. Object Definition and Analysis

For Figure 2, a symbol list is established, and the concept definitions with descriptions are given, as shown in

Table 1. Symbol table of the component topology.

Set	Instance	Description	Expression in the Model	Definition
$\mathit{C}$	$C$	Computing Unit	$\mathit{C}=\left\{{\mathit{C}}_a,{\mathit{C}}_b,{\mathit{C}}_c\dots {\mathit{C}}_n\right\}$	Definition 1
$\mathit{N}$	$n$	Node	$\mathit{N}\left(\mathit{C}\right)=\left\{n_1,n_2,n_3\dots n_m\right\}$	Definition 1
$\mathit{E}$	$e$	Element of Computing Unit (component)	$\mathit{E}\left(\mathit{C}\right)=\left\{e_{j1},e_{j2},e_{j3}\dots e_{jn}\right\}$	Definition 2
$\mathit{D}$	$d$	Data	$\mathit{D}\left(\mathit{N}\right)=\left\{d_{j1},d_{j2},d_{j3}\dots d_{jn}\right\}$	Definition 3
$\mathit{R}$	$r$	Resource, i.e., CPU, RAM, communication consumption	$\mathit{R}\left(\mathit{N}\right)=\left\{r_{n1},r_{n2},r_{n3}\dots r_{nm}\right\}$	Definition 5
$\mathit{P}$	$p$	Data flow computing path	$p\left(e_{ji},e_{mn}\right)=e_{ji}\stackrel{path}{\to }{e}_{mn}$	Definition 4
$\mathit{F}$	$f$	Edge (data flow)	$f\left(p\left(e_{ji},e_{mn}\right)\right)$	Definition 2

.

Definition 1 (Node and Computing Unit). 

Set computing unit $\mathit{C}=\left\{{\mathit{C}}_a,{\mathit{C}}_b,{\mathit{C}}_c\dots {\mathit{C}}_n\right\}$, then

$$\mathit{N}\left(\mathit{C}\right)=\left\{n_1,n_2,n_3\dots n_m\right\},$$

(1)

is a dataset of the unit $\mathit{C}$, and we call $\mathit{N}\left(\mathit{C}\right)$ a node. The node is composed of software-computing units corresponding to a layer in Figure 2’s hierarchy. For instance, in Figure 2, there are four nodes: $n_1$, $n_2$, $n_3$, and $n_4$, and node $n_2$ has three computing units: $C_c$, $C_d$, and $C_e$.

Definition 2 (Computing Unit, Relationship between Computing Units). 

For $C_j\in C$,

$$\mathit{E}\left(\mathit{C}\right)=\{e_{j1},e_{j2},e_{j3},\dots e_{ji}\},$$

(2)

where $e_{ji}$ represents a component, which is responsible for the calculation of specified function items, and represents the $i$th component running in computing unit ${\mathit{C}}_j$.

Therefore, the architecture in Figure 2 consists of 4 nodes, including 9 computing units, 11 components, and 19 data flow paths. Meanwhile, we can define the starting point of the data flow as the parent component and the ending point as the child component. For example, component $e_b$ in Figure 2 is the parent component of the component set $\{e_c,e_{d1},e_{d2},e_e\}$, and component $e_g$ is a child component of the component set $\{e_{d2},e_e\}$.

Definition 3 (Data, Data-Component Relationship). 

Set

$${\mathit{D}}_n=\{d_{j1},d_{j2},d_{j3},\dots d_{ji}\},$$

(3)

represents data $d_{ji}$ allocated to node $n$, where $d_{ji}$ represents the corresponding data deployed to component $e_{ji}.$ For example, $\{d_{f1},d_{f2}\}$ in Figure 2 are allocated to components $\{e_{f1},e_{f2}\}$. And data here represent local variables, static variables, constants, logical macro definitions, and data structures defined in real software components. The relationship between components and data should not be affected by migration strategies because the components–data relationship should be considered as an inherent characteristic brought from business logic requirements.

Definition 4 (path, path attributes). 

Set the data flow in the component as a path. A path refers to a sequence of elements that leads from one point to another within a system or structure. In this context, it represents the data flow or call relationship between functions, which can be recorded as $p(e_{ji},e_{mn})$. It stands for a path starting from $e_{ji}$ and ending up with $e_{mn}$.

According to the directional graph connectivity property [23], a path can obtain any sub-path, i.e., $\forall p\in p\left(e_{ji},e_{mn}\right)$, $\exists r\in ps.t.p_{jr}\in p\left(e_{ji},e_{mn}\right)$. Similarly, this expression can be deduced, as for $\forall p_{k,l}\in p\left(e_{ji},e_{mn}\right)$, if $k\ne j$, then $\exists m\in \mathit{P}$, $s.t.p_{m,k}\in p\left(e_{ji},e_{mn}\right)$. Furthermore, if $i=j$, then $\exists m\in \mathit{P}$, $s.t.p_{l,m}\in p\left(e_{ji},e_{mn}\right)$.

2.3. Computing-Resources Consumption on Computing Path

If the resource consumption on path $p\left(e_{ji},e_{mn}\right)$ is denoted as ${\mathit{S}}_p(e_{ji},e_{mn})$, then the total cost of all components $e$ and all directed edges $f$ (see symbol in Table 1) from the beginning of the path to the end can be used to obtain the Equation below:

$${\mathit{S}}_p\left(e_{ji},e_{mn}\right)={\sum }_{e_{ji}\in E\left(\mathrm{p}\left(e_{ji},e_{mn}\right)\right)}{e}_{ji}+{\sum }_{f_{ji}\in F\left(p\left(e_{ji},e_{mn}\right)\right)}{f}_{ji}.$$

(4)

It can be understood that the required resource ${\mathit{S}}_p\left(e_{ji},e_{mn}\right)$ for computing $\left(e_{ji},e_{mn}\right)$ is the sum of resources consumed by all logical operations and data processing $\sum _{e_{ji}\in E\left(\mathrm{p}\left(e_{ji},e_{mn}\right)\right)}{e}_{ji}$ and the resources consumed by data transmission within and between all components $\sum _{f_{ji}\in F\left(p\left(e_{ji},e_{mn}\right)\right)}{f}_{ji}$. Furthermore, if there are $n$ paths from $e_{ji}$ to $e_{mn}$ within the entire topology, the path with the largest resource consumption can be defined as follows:

$${\mathit{S}}_p^{max}\left(e_{ji},e_{mn}\right)=\mathit{max}\left({\mathit{S}}_{p1}\left(e_{ji},e_{mn}\right),{\mathit{S}}_{p2}\left(e_{ji},e_{mn}\right)\dots {\mathit{S}}_{pn}\left(e_{ji},e_{mn}\right)\right).$$

(5)

Equation (4) gives the relationship between computing-resource consumption and path. We can see that resources are represented by algebraic symbols, while in the real world, the related studies [7,24,25] have pointed out that three kinds of computing resources are most “key but scarce” in terms of computing, including (1) computing power for high-frequency real-time computing CPU, (2) memory capacity and reading speed for data storage and processing, and (3) data transmission rate in a network environment. They have also pointed out that these three resources have different impacts on system operation, which can be sorted out as follows: network transmission ≥ CPU utilization ≥ memory [20,26]. Therefore, the following definition is proposed regarding the cost under limited resources.

Definition 5. 

Set the resource consumption percentage on node $n$ to ${\mathit{R}}_n=(r_{n1},r_{n2},r_{n3}\dots r_{nm})$, the maximum resource occupancy is ${\mathit{R}}_{\mathit{n}}=\left({\mathit{R}}_{\mathit{N}}^{\mathit{C}},{\mathit{R}}_{\mathit{N}}^{\mathit{M}},{\mathit{R}}_{\mathit{N}}^{\mathit{T}}\right)$; then, we obtain the following Equation: 

$${\mathit{R}}_n=\left({\mathit{R}}_{\mathit{N}}^{\mathit{C}},{\mathit{R}}_{\mathit{N}}^{\mathit{M}},{\mathit{R}}_{\mathit{N}}^{\mathit{T}}\right)=\left(\begin{array}{cccc}{r}_{n1}^C& r_{n2}^C& \cdots & r_{nm}^C\\ r_{n1}^M& r_{n2}^M& \ddots & r_{nm}^M\\ r_{n1}^T& r_{n2}^T& \cdots & r_{nm}^T\end{array}\right),$$

(6)

where $r_{ni}^C$, $r_{n1}^M$, and $r_{n1}^T$ represent the CPU peak usage, memory consumption, and network transmission consumption (e.g., network band width) on node $n_i$, respectively. If the system runs normally, it must be at node $n_i$; then, the sum of three types resources of all components on $i$ is less than the peak value. Through this, it can be concluded that for $e_{ji}$, the resource consumption occupied meets the following requirements:

$$\left\{\begin{array}{c}\sum _{r_{ni}\in R_N}{\mathit{S}}_p^C\left(e_{ji}\right)\le r_{ni}^C\\ \sum _{r_{ni}\in R_N}{\mathit{S}}_p^M\left(e_{ji}\right)\le r_{ni}^M\\ \sum _{r_{ni}\in R_N}{\mathit{S}}_p^T\left(e_{ji}\right)\le r_{ni}^t\end{array}\right..$$

(7)

If a component (including data) is added to the node at the moment, the consumption of the adding component will be still below the peak value [27]. Therefore, we can set the newly added component$e_{ji}^{\prime }$, and its resource consumption corresponding to the CPU, memory, and network communication as $r_{ni}^{C^{\prime }}$, $r_{ni}^{M^{\prime }}$, and $r_{ni}^{T^{\prime }}$ respectively, and then, we can obtain Equation (8) from Equation (7):

$$\left\{\begin{array}{c}{r}_{ni}^{C^{\prime }}+\sum _{r_{ni}\in R_N}{\mathit{S}}_p^C\left(e_{ji}\right)\le r_{ni}^C\\ r_{ni}^{M^{\prime }}+\sum _{r_{ni}\in R_N}{\mathit{S}}_p^M\left(e_{ji}\right)\le r_{ni}^M\\ r_{ni}^{T^{\prime }}+\sum _{r_{ni}\in R_N}{\mathit{S}}_p^T\left(e_{ji}\right)\le r_{ni}^t\end{array}\right..$$

(8)

Now, we obtain the component and data migration constraints.

3. Component and Data Migration Model under Limited Resources

From the above analysis, the key to component and data migration is to meet the required constraint defined in Equation (8), which means, the total resource consumption after migration should be less than the available peak resources. More importantly, the resource consumption after migration should be less than the one before migration, which is the purpose of migration. Therefore, the purpose of this section is to calculate the path cost after migration, establish a data migration model, and then push out basic migration guidelines and strategies.

3.1. Component and Data Migration Model

Equation (4) shows that the resource consumption of the data flow path consists of the component logic cost and data-processing cost in the node, the communication consumption between components, and the communication consumption between nodes. For ease of derivation, Equation (4) can be simplified: assume that the original path resource consumption is $\mathit{S}$, and the path resource consumption after the migration is ${\mathit{S}}^{\prime }$, and then the following requirement shall be satisfied:

$$\mathit{S}\le {\mathit{S}}^{\prime }.$$

(9)

The following variables can be defined for better understanding: the communication cost between nodes ${\mathit{S}}_n^T$, the communication cost between components in the node ${\mathit{S}}_n^{T^0}$, the logic and data-processing cost of the computing unit ${\mathit{S}}_{\mathit{C}}$. Based on this, for $\mathrm{n}$ paths between nodes in the topology, it can come up that the resource consumption of each path between nodes is ${\displaystyle \frac{{\mathit{S}}_n^T}{n}}$. And for $\mathrm{m}$ paths between the components, the resource consumption between each component is ${\displaystyle \frac{{\mathit{S}}_n^{T^0}}{m}}$. After data migration, there are a total of $\alpha$ paths between nodes that have been changed. Among these, $\beta$ paths between nodes are converted into internal node paths, and $\gamma$ paths within the nodes are converted into inter-node paths; thus, the resource cost formulas before and after migration can be presented as Equation (10).

$$\left\{\begin{array}{c}\mathit{S}={\mathit{S}}_n^T+{\mathit{S}}_n^{T^0}+{\mathbf{S}}_{\mathit{C}}\\ {\mathit{S}}^{\prime }={{\mathit{S}}^{\prime }}_n^T+{{\mathit{S}}^{\prime }}_n^{T^0}+{{\mathit{S}}^{\prime }}_{\mathit{C}}\end{array}\right..$$

(10)

Substituting the cost variables above, we can obtain the resources consumed between nodes after migration ${{\mathit{S}}^{\prime }}_n^T$:

$$\begin{gathered} {{\mathit{S}}^{\prime }}_n^T={\mathit{S}}_n^T-d⬝{\displaystyle \frac{{\mathit{S}}_n^T}{n}}+c⬝{\displaystyle \frac{{\mathit{S}}_n^T}{n}} \\ =\left(1-{\displaystyle \frac{\beta }{n}}+{\displaystyle \frac{\gamma }{n}}\right)⬝{\mathit{S}}_n^T \\ =\left({\displaystyle \frac{n-\beta +\gamma }{n}}\right)⬝{\mathit{S}}_n^T. \end{gathered}$$

(11)

Similarly, by substituting the cost variables above, we can obtain the resources consumed in the nodes (between components) after migration ${{\mathit{S}}^{\prime }}_n^{T^0}$:

$$\begin{gathered} {{\mathit{S}}^{\prime }}_n^{T^0}={\mathit{S}}_n^{T^0}+\beta ⬝{\displaystyle \frac{{\mathit{S}}_n^{T^0}}{m}} \\ =\left(1+{\displaystyle \frac{\beta }{m}}\right)⬝{\mathit{S}}_n^{T^0} \\ =\left({\displaystyle \frac{m+\beta }{m}}\right)⬝{\mathit{S}}_n^{T^0}. \end{gathered}$$

(12)

Since the difference between pre- and post-migration is only the nodes, and according to Definition 3, data-component binding is fixed before or after migration, we can infer that the total data amount has no change during migration; thus, there are no changes in the logic and data-processing cost, as shown in Equation (13).

$${{\mathit{S}}_{\mathit{C}}}^{\prime }={\mathit{S}}_{\mathit{C}}.$$

(13)

Then, by substituting Equations (11)–(13) into Equation (10), we can obtain the linear relationship between the pre/post-migration and the cost on the overall path:

$$S^{\prime }={{\mathit{S}}^{\prime }}_n^T+{{\mathit{S}}^{\prime }}_n^{T^0}+{{\mathit{S}}^{\prime }}_{\mathit{C}}=\left({\displaystyle \frac{n-\beta +\gamma }{n}}\right)⬝{\mathit{S}}_n^T+\left({\displaystyle \frac{m+\beta }{m}}\right)⬝{\mathit{S}}_n^{T^0}+{\mathit{S}}_{\mathit{C}}.$$

(14)

Now, the component data migration objective function under resource constraints is obtained, as shown in Equation (14).

3.2. Objective Function Analysis

Through the derivation of the objective function, two conclusions can be drawn:

(1)

Within limited resources, data should be preferentially moved to nodes with low resource occupancy, which shortens the path. According to Equation (13), if we need to optimize computing resources while the total amount of resources is fixed, a feasible way is to put components and data from the non-critical paths to the critical paths in case the critical path node has sufficient computing resources, and vice versa. In this way, the redundant computing resources can be fully used, and it also reduces the tension of computing resources of non-critical path nodes. The conclusion is consistent with the “High Cohesion” theory in software engineering system design method [28]. A case in point is that in the cloud–edge-computing architecture, a large amount of data and related components can be uploaded onto the cloud platform [29,30] as a non-critical path, while the business parameters with safety-critical but small data can be put on the edge server, with real-time security-logic-computing components, which is a critical path.

(2)

When the path number of internal nodes converted from inter-nodes is greater than the path number of inter-nodes converted from internal nodes, the overall computing resource consumption will be reduced. For example, according to Equation (12), the communication cost of components in the node ${\mathit{S}}_n^{T^0}$ is an in-line function, its CPU consumption depends on the Interrupt Request (IRQ), and, thus, the assigned time slice from the CPU is extremely low compared to the application-calculated time slice. Similarly, the memory consumption is usually limited within related heaps or stacks, so their ${\mathit{S}}_n^T$ resource consumption is minimal. On the contrary, the communication time between nodes, such as the transmission time between different subsystems, often takes up more computing resources. As an example, it is proven that a simplified interface design in distributed architecture has significantly improved computing efficiency [31,32]. This conclusion is consistent with the “Low Coupling” theory in software-engineering system design methods [28].

4. Basic Migration Rules and Strategies

Based on the derivation and analysis of the objective function, this Section summarizes the basic migration rules and then transforms the steps into a specific algorithm.

4.1. Basic Migration Rules

The basic rules for data migration can be summarized as follows:

(1)

According to Equation (9), the original consumption after migration does not exceed the peak value.

(2)

According to Definition 4, all components related to the critical path should be included in the critical path.

(3)

According to Equation (8), the resource consumption after migration should be less than the one before migration.

4.2. Migration Strategy

When we review and sort out the derivation steps and formula evolution process, a migration strategy can be assembled as follows:

Step 1: According to sub-equation $r_{ni}^{C^{\prime }}+\sum _{r_{ni}\in R_N}{\mathit{S}}_p^C\left(e_{ji}\right)\le r_{ni}^C$ in Equation (8), check the resource utilization rate of the node: If the resource constraints are not reached, migrate the components (with their data) from non-critical path to the parent components which located on the critical path (see Definition 2 for children-parent component);

Step 2: According to Equation (8), preferentially migrate components and data to the nodes with small communication delay and low bandwidth consumption; in particular, ① when a non-critical child component corresponds to a unique key parent component, it shall be migrated to the critical node path where the critical parent component is located and satisfy the condition $\sum _{r_{ni}\in R_N}{\mathit{S}}_p^T\left(e_{ji}\right)\le r_{ni}^t$ in Equation (8); ② when a non-critical child component corresponds to two or more critical node parent components, it should be preferentially allocated to the critical node where the critical parent component with the lowest CPU utilization is located and satisfy the condition $r_{ni}^{C^{\prime }}+\sum _{r_{ni}\in R_N}{\mathit{S}}_p^C\left(e_{ji}\right)\le r_{ni}^C$ in Equation (8); and ③ if the CPU utilization of the parent components has reached or is close to the upper limit, they should be migrated to the critical node where the parent component with the lowest memory utilization is located and satisfy the condition $r_{ni}^{M^{\prime }}+\sum _{r_{ni}\in R_N}{\mathit{S}}_p^M\left(e_{ji}\right)\le r_{ni}^M$ in Equation (8);

Step 3: According to Definition 3, after the new topology is created, the original data $d_{j-1,i-1}$ also need to be changed to the new path. For example, the network delay between nodes after migration in Step 2 ① will be converted into communication between components.

Step 4: According to Equations (6) and (9), check the consumption of topology resources, and it should be lower than the resource limitation after migration.

Step 5: Repeat Steps 1 to 4 until all critical paths are traversed.

Based on the strategy, the algorithm flow of component and data migration is proposed, as shown in Figure 3.

5. Practical Analysis and Model Validation

This section first rolls out a system architecture of data-computing and logical–operation collaboration, then optimizes its computing resources by using the migration strategy described in Section 4, and then builds a test environment in the form of cloud–edge architecture, to verify the effectiveness and correctness of the migration algorithm. The overall computing resources (i.e., cloud-edge servers) are intact before and after the experiment in this case.

5.1. Practicability Analysis

A train operation control system of urban rail transits that integrates a large amount of data operation and high-frequency logic operations was treated as an object. It is characterized by not only including line data, vehicle health status, station information, and other data that occupy a large amount of computing resources but also using logic operations with extremely high frequency, such as train positioning, mobile authorization, emergency braking, and other small amounts of data which require high safety and real-time performance.

Table 2. Data type analysis of the validation objective.

No.	Data Type *	Business Layer	NOT Participate in Real-Time Calculations	Low Impact on Fail-Safe Principle	Data Quantity/Bytes	Belongs to Logic Operation	Belongs to Data Computing
1	OS parameters	x	x	x	0.223 K	√
2	Framework parameters	x	x	x	15.012 K	√
3	Main clock	x	x	x	0.101 K	√
4	IRQ	x	x	x	0.332 K	√
5	Diagnostic parameters	x	√	√	18.556 K		√
6	Com-configuration parameters	x	x	x	5.105 K	√
7	GEBR braking rate	√	x	x	0.214 K	√
8	Data protection macro	√	x	x	0.101 K	√
9	CPU occupancy	x	x	x	0.109 K	√
10	RAM occupancy	x	x	x	0.176 K	√
11	Line data	√	√	√	128.241 M		√
12	External equipment status	√	√	x	26.442 M		√
13	PIS data	√	√	√	770.009 M		√
14	PAS data	√	√	√	14.500 M		√

* OS: operating system; IRQ: interrupt request; Com: communication; GEBR: guaranteed emergency brake rate; CPU: central processing unit; RAM: random access memory; PIS: passenger information system; PAS: passenger alarm system.

provides a detailed list of the data with their features. Meanwhile, because high availability and high reliability requirements must be met in compliance with industry standards, the probability of leading to dangerous outputs is less than ${10}^{-9}$ per hour, and the software- and hardware-upgrading rate is much lower than in other industries. This leads to its computing capacity gradually becoming the bottleneck of the rapidly growing demand from operations. One of the approaches is to use the migration strategy described in this paper, introduce the edge computing mode to take the cloud as the main body of data computing, and take the on-board train control system as the main body of edge computing. In other words, it separates the data computing and logical computing, then allocates relevant components and data to different nodes (sub-systems, business clusters), and utilizes the communication between nodes to coordinate the computing results. In this way, the complementarity of the critical computing paths of the two types of nodes can be used to meet the requirements of real-time and large computing power at the same time, without upgrading the system hardware or software platform.

Figure 4 shows a system architecture before resource optimization and its data flow between components. In the figure, the cloud platform is responsible for data processing associated with upper Human Machine Interfaces (HMI) and management supervision business. The embedded security system, as an edge-computing unit, is responsible for real-time safety protection and all operation-related data. As a controller of edge computing, the edge unit carries a heavy computing load. Literature [33] and [34] put forward a method of computing unloading from the perspective of emergency management and improved genetic algorithm; literature [35,36] raise computing resource allocation methods from the view of computing cache; literature [37,38] provide multi-objective ant colony algorithms in the field of industrial internet in terms of adapting multi-demands of a mobile network; a revised algorithm is raised in literature [39] to reduce the weak correlation rules that generated by the data mining algorithm, so as to relieve the unit’s calculation pressure; literature [21,22], very similarly to the migration strategy’s logic, put forward the critical links definitions with centrality, degree, and neighborhood dimensions and specify a validity measurement that derives from combining the probabilistic and fuzzy set model. In light of the above, studies do provide migration references from different angles. However, according to the safety and real-time characteristics of the rail transit control system, there are strict requirements for logical data cache and functional dynamic allocation, as well as strict constraints on the dynamics of key calculations, especially for the embedded subsystems, where these methods cannot be fully applied.

5.2. Strategy Validation and Data Analysis

According to the above approach, we formulate the steps of the strategy validation to verify its effectiveness and correctness.

(1) Determine the critical path of data computing and logic operation

According to Figure 4, we sort out the system data types and judge whether the data and its operation components belong to the critical path of logical calculation or to the data analysis. The judgment is based on four aspects: application classification, participation in real-time calculation, security protection impact, and data volume, as shown in Table 2.

Table 2 lists 12 types of data that are to be processed by the system, mainly including system intrinsic parameters, application-loading parameters, and specific business data. It can be seen that there is a large amount of line data, passenger information, and alarm information data, which takes up huge computing resources. On the contrary, for the target system, what it might need for those data is probably only a Boolean flag (e.g., normal or abnormal) as the judgment condition for the operation to continue, and such data should be placed on the key path of data calculation. On the other hand, data such as clock, interrupt, frame parameters, and communication configuration parameters belong to the system parameters of the computing unit and cannot be unloaded or migrated; these should be placed on the critical path of logical computing.

(2) Reschedule the critical path according to the system operation topology

While keeping the overall computing resources of the research object unchanged, the data flow of each computing unit is described according to the definition of business requirements, safety interfaces, and data transmission protocols. Based on this, the computing unit is classified into the data-computing class and logic judgment class. An optimized system architecture is proposed based on the migration strategy, as shown in Figure 5.

(3) Software algorithm realization

According to the migration strategy in Figure 3, we further identify the components and data that can be migrated on the critical path. In the phase of detail design and coding, the module collaboration diagram of the migration strategy algorithm is shown in Figure 6.

In Figure 6, the data migration and synchronization module (i.e., redSyncMgr) in the software implementation is the main processor responsible for the entire migration algorithm. It is mainly used to traverse the data ID in the ModuleStaticData container to call the corresponding data processing module and compares it with the predefined VitalStateID to determine whether the current component and data belong to a data class or a logical class. Finally, according to the component interface function (i.e., Module_red), it moves the components according to the data migration strategy in the mode of “Type Copy” (i.e., applicable to nodes on different physical platforms) [25] or “Type Reference” (i.e., applicable to nodes on the same physical platform) [40].

(4) Lab configurations

To verify the effectiveness of the migration strategy, a real embedded vehicle control system was treated as the edge-end object; it plays the role of the logic- and data-computing node before migration and the logic-computing node after migration. As shown in Figure 5, the edge unit has two servers: one for data processing and one for IO interface management. The cloud is adopted in the form of a minicomputer private cloud platform and is the data-computing node after migration. The cloud unit is running on another data server. In addition, one separated IO server which is in charge of IO security is shared with both cloud and edge. The configuration information is given in

Table 3. Data analysis of the validation objective—edge.

Configuration Items	Onboard Control System
OS Environment	RedHat Linux 5.3 TAS O/S  2.1.0.2 GNU C++ Compiler/Linker 4.4.5-plf2.0 Doxygen/UMLDox 1.7.6.1
HW Configuration	1.86 GHz, 4 MB L2 cache, 1066 MHz Front Side Bus 3 GB RAM 160 GB Hard Disk Drive 4 NIC ports2×2 dual ports or 1 × 4 ports Ethernet adapter 2×dual port serial adapters for MPU

and

Table 4. Configuration analysis of the validation objective—cloud.

Applications Location	Node Nr.	Private Cloud
		CPU	CPU Load Setting		RAM Setting	RAM Load Setting		Hard Disk Volume	HD Usage Setting	Shared RAM Setting	Shared RAM Usage Setting
			Avg	Peak		Avg	Peak
Data Server	2	16-core	30%	70%	32 GB	30%	70%	300 GB×2	30%	2 TB	50%
IO Server	2	16-core	30%	70%	32 GB	30%	70%	300 GB×2	30%
Station (Cloud desktop)	6	8-core	30%	70%	4 GB	30%	70%	1 TB	30%

.

Note that the IO server#2 in Figure 5 is assigned separately in consideration of cyber security. Physical isolation could be a good way to avoid any attacks from hackers. Encryption techniques, firewall, authentication methods, as well as regular updates and patching can be easily loaded to the IO server, with no influence on the cloud- and edge-computing units.

(5) Result analysis

As illustrated in Figure 7, according to migration strategy steps 1 to 2, the non-vital datasets listed in Table 2 are reallocated to the cloud unit during the validation, including PIS data, Diagnostic data, Line data, External Equipment Status, and PAS data. The features of those data are on the computing large-size path. The vital logic-related data, i.e., OS, Framework, Main Clock, IRQ, DB protection Macro, and CPU and RAM status, are integrated into the edge unit.

According to the migration strategy step 3, communications between five vital computing units are still inter-component; the inter-node communication between the original business-layer data (e.g., PIS, PAS, line data) and the original process-layer data (e.g., Diagnostic, equipment) is ultimately transformed into an inter-component one. In addition, the data exchange of the inter-node interfaces is simplified from the whole data package to a computing result normally presented as qualitative Boolean flags (e.g., True/False, Pass/Fail, 1/0, Healthy/Unhealthy) after judgment from the data process host.

Table 5. Data comparison before and after the migration—detail.

No. *	Resident Memory	Migrated?	Host	Peak Memory Consuming		Peak CPU Consuming		Data Transfer Consuming
				Before %	After %	Before %	After %	Before kbps	After kbps
1	0.223 K	NO	Edge	0.4013	0.4123	1.164	1.163	0.00	0.00
2	15.012 K	NO	Edge	1.1290	1.1516	2.625	3.643	0.00	0.00
3	0.101 K	NO	Edge	0.8671	0.8064	0.877	0.991	0.00	0.00
4	0.332 K	NO	Edge	0.5527	0.5582	0.538	0.544	0.00	0.00
5	18.556 K	YES	Cloud	2.6345	2.3472	2.456	1.221	0.00	16.00
6	5.105 K	NO	Edge	1.6151	2.5041	0.976	1.911	0.00	0.00
7	0.214 K	YES	Cloud	0.2889	0.0096	0.243	0.211	0.00	16.00
8	0.101 K	NO	Edge	0.2661	0.3006	3.196	4.323	0.00	0.00
9	0.109 K	NO	Edge	0.5212	0.5175	2.223	2.222	0.00	0.00
10	0.176 K	NO	Edge	0.5207	0.5763	3.350	3.011	0.00	0.00
11	128.241 M	YES	Cloud	2.9427	1.9921	16.425	9.989	32.00	17.00
12	26.442 M	YES	Cloud	3.2364	2.8911	6.321	3.667	20.00	12.70
13	770.009 M	YES	Cloud	5.2563	4.9724	20.025	13.321	66.00	12.70
14	14.500 M	YES	Cloud	2.0231	1.7031	11.115	6.006	16.00	12.70

* Consistent with the component sort number in Table 2.

illustrates the differences in resource occupancy before and after migration. For each component, the demanded computing resource has no outstanding changes, as there is no functional or algorithm change, but the percentage of resources used by the vital controller (edge unit) has obviously decreased due to migration, and non-vital data calculation is moved to the non-vital controller (cloud unit).

In light of the above, Table 5 and

Table 6. Data comparison before and after the migration.

Items	Before Migration	After Migration	Change Rate
Node	7	7	0% (−)
Computing unit	13	9	30.77% (↓)
RAM consuming (unit:10 M)	22.255	20.742	6.80% (↓)
Call relationship (unit:100 pairs)	52.7	34.2	35.10% (↓)
CPU usage (/%)	71.53	52.22	27.00% (↓)
Components	73	73	0% (-)
Data structure	78	92	17.95% (↑)
Response time (ms)	96.03	75.48	21.40% (↓)
Path	146	75	48.63% (↓)
Bandwidth (kbps)	134	87.1	35.00% (↓)

Note: “−”, “↓” and “↑” represent the flat, rise, and fall of the corresponding value.

and Figure 8 show the changes in various indicators before and after migration.

From this Table, we can see the following:

(1)

The initial setting of this test is not to change the functional modules, system architecture, and total computing resources; so, the node (i.e., number of subsystems) and components (i.e., number of functional modules) remain unchanged before and after migration;

(2)

Due to the migration and consolidation of components, the number of logical set units of components decreased from 13 to 9. The number of paths (i.e., call relationships including non-critical paths) is reduced from 146 to 75;

(3)

Due to the subdivision of data interface functions after migration, the data structure related to the interface is split from 78 to 92;

(4)

CPU utilization is reduced by 27%, memory usage is reduced by 6.8%, and the network bandwidth is decreased by 35%.

6. Discussion

Through model deduction and validation result analysis, it can be seen that the migration strategy is feasible. In practice, some experience can be drawn from the implementation. Firstly, the components with aggregation or inheriting relationships can be put together in one computing unit. Taking ATS applications as an example, diagnostic data, equipment supervision, and line data which are closely attached to the ATS can be migrated under the condition that the computing capability is sufficient. Figure 9 shows the collaboration of these components.

Secondly, it also can be seen from the validation implementation that there is a prerequisite lying on top of the applicability, which is a good model and structural design of the original software: ① A clear definition of parents–children components makes it possible to move components from/to a critical computing path. For example, the ATS module (Figure 7, in Cloud Unit) is the “parent” of the PIS and PAS module, with an inherited relationship, and aggregation is the relationship between ATS and other modules, such as diagnostic and line data. Thus, these components can be integrated into one computing unit as a form of path. ② The explicitness of the function–call relationship enables the interface simplifying. For example, the vital module DB Macro (Figure 7, in Edge unit) calls the Equip data’s (Figure 7, in Cloud Unit) state by obtaining its result’s flag instead of obtaining the whole data package as a parameter (address or pointer); thus, the cloud unit can take on the calculation and carry out the result before sending, and the inter-node load of the network can be reduced from 26.442 M (Equip data size in Table 2) to 2 bytes. To summarize, the key is that a high-cohesion and low-coupling principle migration solution must be supported by an original design with the same principle.

7. Conclusions

No matter what kind of computing-unit architecture, its computing resources have an upper limit, and there may be resource shortage due to insufficient computing resources or improper unit deployment. This paper studies the migration strategy of computing units and data under limited resources. Through model transformation and derivation, three main parameters that have a significant impact on computing resources before and after migration are identified: communication amount cost between nodes, communication cost of components within nodes, and computing cost of non-critical data. On this basis, the algorithm and implementation of non-computing-critical path components converging to computing-critical path components under resource constraints are proposed. The experiment proves that the migration strategy can well alleviate the computing-resource tension and/or release computing resources. Under the condition of unchanged overall computing resources and unaffected functionality and performance implementation, the migration strategy reduces the CPU utilization by 27%, the memory by 6.8%, and the network bandwidth by 35%.

The proposed strategy has high universality and is applicable to traditional servers and embedded computing unit structures with relatively fixed resources, as well as cloud-platform-computing or cloud–edge-computing architecture. Meanwhile, this strategy does not limit the migration scope of components and data. It can be implemented within or between current service platforms. The migration strategy in this paper is applicable to system software with a clear hierarchical design, low coupling of interface definitions between components and between computing units, and strong cohesion of component functions. In addition, further research is needed on how to generalize this strategy to apply it to all types of programming.