Task-Driven Computing Offloading and Resource Allocation Scheme for Maritime Autonomous Surface Ships Under Cloud–Shore–Ship Collaboration Framework

Abstract

Currently, Maritime Autonomous Surface Ships (MASS) have become one of the most attractive research areas in shipping and academic communities. Based on the ship-to-shore and ship-to-ship communication network, they can exploit diversified and distributed resources such as shore-based facilities and cloud computing centers to execute a variety of ship applications. Due to the increasing number of MASS and asymmetrical distribution of traffic flows, the transportation management must design an efficient cloud–shore–ship collaboration framework and smart resource allocation strategy to improve the performance of the traffic network and provide high-quality applications to the ships. Therefore, we design a cloud–shore–ship collaboration framework, which integrates ship networking and cloud/edge computing and design the respective task collaboration process. It can effectively support the collaborative interaction of distributed resources in the cloud, onshore, and onboard. Based on the global information of the framework, we propose an intelligent resource allocation method based on Q-learning by combining the relevance, QoS characteristics, and priority of ship tasks. Simulation experiments show that our proposed approach can effectively reduce task latency and system energy consumption while supporting the concurrency of scale tasks. Compared with other analogy methods, the proposed algorithm can reduce the task processing delay by at least 15.7% and the task processing energy consumption by 15.4%.

1. Introduction

Over the last few decades, with the rapid expansion of inland navigation and the increase in the number of vessels, inland river shipping has increased significantly, leading to an increase in traffic congestion and greenhouse gas emissions [1]. Traffic conflicts, combined with a lack of efficient navigation and communication systems for ships and infrastructure, lead to an increased risk of accidents and unnecessary navigation delays. Moreover, as Maritime Autonomous Surface Ships (MASS) gradually move into commercial operation, there is an urgent demand for efficient communication systems between MASS and conventional ships, MASS and ports, and MASS and shore-based navigation systems to establish secure and efficient information interaction [2]. The safe and efficient shipping of MASS requires a variety of applications, such as auto target recognition, simultaneous localization and mapping (SLAM), remote control, virtual reality, and other intelligent applications; all navigation safety, navigation efficiency, and navigation information services should be computed and should respond in an efficient and distributed manner. Therefore, the design of a reasonable navigation support system and task service scheme is a very important issue for MASS.

To address the above-mentioned challenges in inland waterway traffic, the Internet of ships (IoS) paradigm has recently emerged [3], being driven by the concepts of e-navigation [4] and Internet of Things (IoT) technologies. The Internet of ships (IoS) is the interconnecting of sensing objects like ships, crews, cargoes, onboard equipment, waterway environment, waterway facilities, shore-based facilities, and other navigation elements, which are embedded with a variety of sensor and heterogeneous network technologies to enable these objects to collect and exchange data [5]. According to the IoS principles, any ship or port or the transportation itself, which includes cranes, containers, the bridge navigation system, the ship engine, and buoys, can sense, communicate, and process the information received from the outside world. When these facilities and devices are connected to each other, information will be shared and further processed among them, which lays the foundation for various intelligent applications in water transportation, including situational awareness, path planning, collaborative decision making, fault diagnosis, environmental monitoring, etc. Once realized, these intelligent applications will largely improve the safety, efficiency, and environmental sustainability of the inland waterway shipping industry.

However, the IoS only provides a paradigm for information interaction among participants in inland waterway transportation systems and lacks a collaborative, real-time process for information data. The interaction among the participants of the IoS leads to a dramatic increase in the frequency and quantity of information interactions, which places higher demands on the comprehensive and accurate sensing, wide-area data transmission, and real-time processing and analysis capabilities of communication networks. The integration of the IoS and cloud/edge computing provides an effective solution to meet the information interaction needs of future inland waterway transportation intelligent applications or tasks. By connecting entities through various communication means and cloud/edge computing, the system has the characteristics of large bandwidth, wide connection, high reliability, and low latency, which can support larger-scale traffic participant connection, higher frequency environmental awareness data collection, and lower latency regulation command issuance, and efficiently empower traffic data transmission and information interaction. Different computing and communication frameworks may be suitable to support different types of MASS applications with highly different quality of service (QoS) requirements for latency, computational resources, and storage capacity. The computational and communication workload of MASS may also vary with time and location under different architectures, which poses challenges for the resource management of computational nodes and the computational task management of MASS. Therefore, a well-designed computing framework and resource scheduling method are very important for the MASS system.

Thus, this paper proposes a cloud–shore–ship collaboration framework that integrates the IoS and cloud/edge computing and clarifies the implementation process of cloud–shore–ship collaboration to achieve high reliability and low latency demand adaptation and meet multidimensional resource collaborative scheduling and data privacy security. On this basis, a task-driven resource scheduling method based on deep Q-learning is proposed to achieve collaborative optimization of ship-side task offloading, cloud-side and shore-side computing resource allocation under high reliability and low latency constraints, and the performance advantages of the proposed method in terms of energy consumption, latency, and throughput are verified through case studies.

The main contributions of this paper are summarized as follows:

(1)

We propose the cloud–shore–ship collaboration framework, which is a basic architecture to support MASS operation for the new generation shipping systems, and we clarify the task processing flow of cloud–shore–ship collaboration.

(2)

On the basis of different tasks in ship intelligent navigation, we propose a task-driven resource allocation method for cloud–shore–ship collaboration, which can adaptively select the computational location of a task based on the priority of the task, the QoS of the task, and the computational resource status of the system nodes, to maximize the average task latency of the system and save energy.

(3)

We constructed a simulation system to evaluate the proposed resource allocation method. By comparing multiple resource management framework methods and multiple resource allocation methods, the simulation results show that our proposed method can reduce the latency of computational tasks, reduce system energy consumption, and support the large-scale computational task service requirements of MASS.

The remainder of the paper is organized as follows. Section 2 presents related works and cloud–shore–ship collaboration framework. Section 3 and Section 4 introduce the system model and task-driven resource allocation scheme in cloud–shore–ship collaboration framework, and Section 5 validates and analyzes the proposed algorithm by simulation examples. The conclusions are placed in Section 6.

2. Related Work

Currently, many new technologies and methods are introduced in inland shipping traffic and are crucial for enhancing traffic safety and efficiency, as explained below in three aspects: the IoS, cloud/edge computing, and resource scheduling method. Finally, we describe the cloud-to-shore ship collaboration framework.

2.1. Internet of Ships

The IoS is a new concept of IoT technology applied in the maritime field; currently, it has been studied by relevant institutions and scholars. The IoS is defined from several perspectives. The paper [6] defined the IoS as a network connecting a ship to a shore-based facility with digital entities. Another work [7] defined the IoS as a novel ecosystem, which incorporates all IoT-based emerging technological trends that are adapted for sea transportation. In summary, the IoS is a network that connects ships and other entities in water traffic and enables information interaction. The IoS enables real-time monitoring of the ship and its onboard equipment, and furthermore, by analyzing and processing the interactive data, it can enhance the safety and efficiency of the ship’s voyage. In addition, in the maritime sector, some countries and international organizations are already using real-time IoS platforms, such as e-navigation of IMO [8], Waterway-Information-Network of the USA [9], Ship-Area-Network of Korea [10], River Information-System of Europe [11], etc. Based on the IoS platform, many emerging applications, such as smart ships, smart traffic, smart ports, smart warehouses, etc., are being developed; they can improve the efficiency of information interaction of transportation and improve transportation safety.

2.2. Cloud/Edge Computing

Cloud Computing (CC) is a computing technology that has evolved over the past decade to perform large-scale and computationally intensive computing. Cloud computing is defined as “a model that allows ubiquitous, convenient, on-demand network access to many configurations of computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and distributed with minimal administrative effort or service provider interaction” [12]. There are many attractive features, such as parallel processing, virtualized resources, high scalability, and security. As a result, CC not only provides the ability to handle computationally intensive tasks but also provides low-cost infrastructure maintenance. However, today, MASS may generate large amounts of data underway, such as assisted driving videos captured by cameras, which will dramatically increase the data to the terabyte/petabyte level in seconds [13]. In addition, a large number of MASS applications tend to be latency sensitive with fast big data processing and quick response requirements. For example, in autonomous navigation scenarios, the sensors and 3D cameras attached to the MASS can generate considerable data. Therefore, the cloud server must compute these data in milliseconds and send highly accurate operation commands to the steering system of the MASS [14]. However, in terms of network topology, the distance between the cloud server and the MASS is long, and network congestion or queuing may lead to long delays and, in the worst case, traffic accidents.

Edge computing (EC) is an effective solution to the above problem, allowing for lower response latency because the computation is performed near the MASS (e.g., shore-based infrastructure in inland waterways) rather than being sent to a remote cloud [15]. The access methods in EC have become more diverse in the MASS navigation scenario. For example, MASS can directly transfer the collected raw data to a computing unit in a robust shore-based infrastructure that can be deployed at a small base station near the navigation channel [16]. In addition, cloudlet is one of the most typical edge computing platforms, with a cluster of resource-rich computing nodes located just a hop away from mobile users (MUs). Essentially, cloudlet is a self-managed data center. Internally, cloudlet resembles a multi-core computer cluster with gigabit internal connectivity and a high-bandwidth wireless local area network [17]. Due to the proximity of the network, the cloudlet can provide low-latency and high-bandwidth wireless connectivity between servers and MASS, making it ideal for providing situational awareness, latency-intensive, and fast-moving managed services and applications. Different cloud/edge/fog computing architectures may be suitable to support different types of MASS applications with highly different quality of service (QoS) requirements for latency, computational resources, and storage capacity [18]. The computational and communication workload of MASS may also vary with time and location under different architectures, which poses challenges for resource management of computational nodes and computational task management of MASS. Therefore, a well-designed computing architecture is very important for the MASS system.

2.3. Resource Allocation Method

Resource allocation is an important application of cloud/edge computing architecture, where resource-constrained ships hand over computing tasks to shore-side nodes or cloud computing centers [19], for example, by means of task offloading to speed up processing and improve task delivery quality. Task offloading mainly includes two major issues: offloading decision and resource allocation.

In recent years, as EC and CC are used in transportation systems, their task offloading and resource allocation problems have attracted a lot of attention from researchers. The authors summarize in detail the EC architecture and computational offloading issues, including offloading decisions, computational resource allocation, and mobility management [20]. The authors introduced the network architecture and deployment scheme of vehicle EC and compared and analyzed different deployment schemes [21]. The authors classify the applications of autonomous vehicles according to their importance and allocate computing resources according to the importance of tasks to improve the efficiency of task execution [22]. The authors divide computing tasks into independent tasks and dependent tasks according to the relationship before tasks [23], and the authors consider the impact of dependencies between tasks on offloading decisions and resource allocation [24]. From the perspective of resource allocation methods, there are mainly heuristic algorithms [25], Markov decision processes [26], game theory [27], etc. Reinforcement learning is a machine learning method. The idea is to use the created software agent to continuously interact with the environment in order to conduct tests in an interactive environment and gradually approach the optimal result through the reward or punishment information fed back by the environment [28]. At present, some studies have proposed the use of deep reinforcement learning methods to solve the task offloading problem in EC. Reference [29] designed a value-based deep reinforcement learning scheme for the offloading problem of mobile edge computing. The value function is optimized through an iterative trial-and-error process to minimize the total cost of the entire system. Reference [30] proposed a deep learning offloading scheme considering inter-task dependencies. The scheme uses an artificial neural network with gates to give the network the ability to learn long-term dependencies on input data so that historical data can be considered to estimate the current state.

To sum up, at present, the allocation methods of computing resources for intelligent ships focus on the solution in the fixed scene but lack the consideration of the correlation between tasks and the mobility of ships. In fact, during the operation of MASS, the related computing tasks are often highly correlated, so we need to pay attention to the logical relationship between tasks. At the same time, due to the mobility of MASS, MASS is always in the dynamic topology of communication networks, and this characteristic also needs to be carefully considered. Aiming at the above challenges, this paper models and analyzes the mission characteristics and ship mobility in the process of MASS operation.

2.4. The Cloud–Shore–Ship Collaboration Framework

Cloud–shore–ship collaboration framework is an all-factor collaborative architecture for the new generation of shipping systems, which can realize water traffic from passive traffic response and optimization to active traffic management and service by continuously enhancing ship–vessel, ship–shore, and shore–cloud collaboration [31]. The cloud–shore–ship collaboration framework is shown in Figure 1. Based on advanced information and communication technology, the architecture enhances the comprehensive sensing capability for both shore and ship domains. The architecture can make full use of the high reliability and low latency of high-speed communication networks such as 5G, as well as the powerful computing capability of the cloud layer, the deployment flexibility of the shore domain, and the comprehensive sensing and timely response advantages of the ship domain [32].

The cloud layer covers the inland river traffic control center, traffic data center, traffic cloud platform, etc. It has rich storage and computing resources and can analyze, manage, and store traffic operation data, ship status data, and environmental sensing data uploaded from the shore–ship domain. The shore layer includes 5G base stations, edge servers, shore-side sensing devices, and intelligent infrastructure such as environment sensing, safety verification, and navigation control, which can meet the task response requirements of real-time and high reliability for intelligent navigation of ships in the region. The ship layer consists of intelligent sensors, a central gateway controller, and ship electronic and electrical equipment that make up the functional domain of the ship.

The basic task processing of cloud–shore–ship collaboration includes data collection, task request, task assignment, task unloading, task processing, and result feedback. As shown in Figure 2, the details are described as follows:

First of all, shipboard and shore-based sensing equipment collects the ship’s tasks, ship navigation data, ship equipment status, channel data, environmental environment, and other data and temporarily stores them in the ship or shore cache queue. Then, they consider the real-time and non-real-time tasks generated by the ship during its voyage, such as real-time control commands from the ship, voice interactions, navigation map requests, warning messages, etc. These tasks can be handled at the ship or transmitted to shore or to the cloud via communication facilities. Tasks offloading contains two cases: ship–shore offloading and ship–shore–cloud offloading. The ship offloads the data in the task offload queue to the shore-side cache queue to wait for processing. Data with low computational complexity and latency sensitivity can be processed directly onshore, while computationally intensive data can be further offloaded from shore to the cloud cache queue to wait for processing. The data processing results from the cloud–shore side will be stored in the result feedback queue and sent back to the ship result feedback queue.

The cloud–shore–ship collaboration framework provides effective support for the water transportation system by collaboratively scheduling resources such as communication, computing, energy consumption, and storage involved in the collaboration process and adapting to the demand for high reliability and low latency of data under intelligent navigation of ships. The cloud computing center analyzes and processes global information and cooperates with distributed shore-based facilities to improve shipbuilding, sailing efficiency, and intelligence. Therefore, considering different task priorities, task correlation, QoS of tasks, and ship mobility in MASS shipping, we propose a task-driven computing offloading and resource allocation scheme for the cloud–shore–ship collaboration framework.

3. Task Processing Model and Problem Formulation

In this section, we describe the task processing model. First, we show the task model. Then, the ship mobility, communication, and computation models are discussed.

We consider the scenario of MASS navigating in inland waterways, a system consisting of a cloud control center, shore-based infrastructure, and MASS in a navigation network cloud-side computing network, as shown in Figure 3. The cloud computing center, with its powerful computing capacity and remote deployment, can be used to process large-scale, long-term data, and it can collect data from the widely distributed shore-based infrastructure, sense the traffic system’s operating conditions, and issue rational dispatch instructions. The shore-based infrastructure layer, which has moderate computing power and is deployed close to the MASS, can be used to complement the MASS, while the shore-based infrastructure is envisioned to have a variety of sensors that can complement the shipboard sensors. The different shore-based infrastructures are interconnected by fiber optic networks to extend the service range. In the ship computing layer consisting of MASS, small-scale, latency-critical data can be processed with the shore-based infrastructure and large-scale, long-term data can be processed with the cloud computing center.

We assume that each mass has computational tasks, and the computational tasks can be executed at any layer. In addition, co-computation is considered at both the shore side and ship side to improve the task offloading performance. Here, we define all shore-based infrastructure units (SUs) and ships as SU = {1,2, …, M} and BE = {1,2, …, N}, respectively. Each shore-based infrastructure unit deploys edge servers to provide computing power. For simplicity, we assume that the ship is covered by the nearest shore-based infrastructure, which is used to perform collaborative computing through a ship-to-shore facility link, and the shore-based infrastructure is connected to each other through a cloud–shore backbone network. Efficient application services are provided for mass navigation through cloud–shore–ship collaboration.

3.1. Task Model

In this paper, we classify tasks/applications in MASS navigation into two types, independent tasks and cooperative tasks, based on whether the tasks are related to each other or not. It should be noted that our framework is not only for single MASS operations, but more for large-scale MASS operations, where tasks are also likely to be interrelated among multiple MASS.

Independent tasks. Independent tasks mean that the tasks are independent of each other, and this independence is mainly reflected between different MASS, which generate a large number of tasks during navigation, such as safety-related tasks, such as collision warning; efficiency-related tasks, such as route planning, and information service tasks, such as situational awareness. When tasks are computed at each layer, the level of urgency with which they need to be executed varies depending on the type of task. For MASS navigation safety-related tasks, they need to be provided with computational resources for computation first, while for efficiency-type tasks, they can be provided with computational resources for computation last.

For processing independent tasks, we need to group and prioritize the tasks. The tasks are characterized by higher information completeness and accuracy. The processing flow of the independent task is shown in Figure 4.

We define the tasks generated by different MASS in the system as A = {a₁,a₂,⋯,a_n}. The tasks are first prioritized and then divided into four task queues above real-time and non-real-time, high-frequency, and low-frequency.

The task priority reflects the importance of the MASS task, the task urgency expresses the degree of urgency, and the task value density indicates the degree of actual value of the task. Therefore, the task priority is calculated by considering the task urgency and the task value density together. Since the simple task value does not reflect the actual value of the task, in order to compare the value of tasks of different lengths, this paper expresses the task value density in terms of the expected value obtained by the MASS per unit length of the task. The task value density is expressed as

$$T_{vd}={\displaystyle \frac{T_{value}}{T_{length}}}$$

(1)

The value of $T_{vd}$ determines the priority of the task; the higher the value, the higher the task priority.

We assume that the current time is t, and the remaining execution time S of the task $a_i$ is obtained. The smaller the value of S, the more urgent it is for that task.

$$S=T_{dt}-t$$

(2)

Considering the two factors of remaining execution time and task value, we can calculate the task priority P,

$$P={\displaystyle \frac{T_{vd}}{S}}$$

(3)

The larger the value of P, the higher the priority. In the scheduling process, tasks with higher priority are scheduled earlier so that tasks with high value and urgent time are scheduled in priority, thus increasing the success rate of tasks within the deadline and improving the completion rate of tasks.

Cooperative tasks imply that the tasks from MASS are interconnected with each other. We assume that each task $a_i$ can be divided into several discrete tasks. ${\beta }^i=b_1^i,b_2^i,\cdots ,b_n^i$, n represents the total number of subtasks belonging to the task $a_i$. Task $a_i$ can be processed at any layer in the cloud–shore–ship collaboration framework. In this paper, we investigate task interdependencies, which affect task execution decisions. Furthermore, according to reference [33], we classify task dependencies in MASS navigation into two basic logical topologies, i.e., linear and lattice. As shown in Figure 2, each task is divided into six subtasks. As shown in Figure 5a, it is a linear serial task, and the later task must start execution after the completion time of the previous task. The total completion time of the entire task is the sum of the individual component completion times. In the mesh logic of task shown in Figure 5b, task 6 starts after the completion time of task 3 and task 5. Therefore, when making decisions about tasks, the interdependence of individual tasks should be considered.

We can represent the association relationship between tasks as a directed acyclic graph, and furthermore, we can abstract it as an association matrix. Specifically, in this paper, we represent it by a lower triangular matrix to I, where the elements in I are 0 or 1, $I_{i,j}^k=\left\{\mathrm{0,1}\right\},1\le j\le i\le n$. If Task i requires the output data of Task j, $I_{i,j}^k=1$; otherwise $I_{i,j}^k=0$. For example, the logical matrix for task 2 in Figure 5 can be given by

$$I^2=\left[\begin{array}{cc}\begin{array}{ccc}0& 0& 0\\ 1& 0& 0\\ 1& 0& 0\end{array}& \begin{array}{ccc}0& 0& 0\\ 0& 0& 0\\ 0& 0& 0\end{array}\\ \begin{array}{ccc}0& 1& 0\\ 0& 0& 0\\ 0& 0& 1\end{array}& \begin{array}{ccc}0& 0& 0\\ 1& 0& 0\\ 0& 1& 0\end{array}\end{array}\right]$$

(4)

3.2. Ship Mobility Model

One of the challenges of MASS is the maneuverability of ships on inland waterways, which leads to instability of shipboard resources, and MASS can only perform computational offloading when the ship is in the coverage area of the SU. We assume that MASS enters the cloud–shore–ship collaboration system subject to a Poisson distribution with arrival rate ${\mathsf{\lambda }}_t$. Each MASS may generate task requests from time to time. Therefore, for a given route segment s, the number of tasks generated in a time unit follows a compound random process.

$$Y\left(s\right)=\sum _{n=1}^{N\left(s\right)}A$$

(5)

where $N\left(s\right)$ denotes the number of MASS on the route segment s and A is the number of tasks generated by MASS i for each time unit. According to existing research [32], a joint consideration of the MASS arrival rate and the randomness of task generation shows that the task arrival model within the whole system does not obey a Poisson distribution, providing a further indication of the unevenness of task generation in the MASS system.

We define the contact interval of each MASS in the system as the time interval of the MASS within the BS coverage, defined as $\left[{\mathsf{\delta }}_n,{\mu }_n\right]$, where ${\mathsf{\delta }}_n$ and ${\mu }_n$ represent the arrival and departure times, respectively. In order to ensure the availability of computing resources, the offloaded computing tasks need to be completed before the MASS leaves the system.

3.3. Computation Model

At the t time slot, the ship’s task offloading decision consists of 2 components: (1) Shore-based edge server selection, i.e., which shore-based edge server is selected for task offloading; (2) Computation mode selection, i.e., the data computation mode is selected as cloud computing or shore-based edge computing. If cloud computing is selected, the data offloaded to the shore-based edge server are further offloaded to the cloud server for processing.

Local ship computation model. The computational capability of MASS is defined as the number of CPU cycles per second; we define it as $f_n$. Thus, the local ship computation delay of task $a_n$ is

$$t_n={\displaystyle \frac{{\omega }_n}{f_n}}$$

(6)

The energy consumption for ${BE}_n$ executing $a_n$ is calculated by the classic model used in [32]

$$e_n={\sigma }_n{t}_n$$

(7)

where ${\sigma }_n$ can be obtained by long-term observation and measurement methods.

Shore-based computation. The computing capability (i.e., computing resources) of ${SU}_m$ will be distributed proportionally to all ${BE}_n$ that request the ${SU}_m$. In this article, the computing resource of ${SU}_m$ allocated to ${BE}_n$ is

$$f_{n,m}={\displaystyle \frac{{\gamma }_n}{{\sum }_{v=1}^N{\gamma }_v{\tilde{\lambda }}_{v,m}}}{\tilde{f}}_m={\displaystyle \frac{{\gamma }_n}{{\sum }_{{BE}_v\in {BN}_n}{\gamma }_v{\tilde{\lambda }}_{v,m}}}{\tilde{f}}_m$$

(8)

where ${\sum }_{{BE}_v\in {BN}_n}{\gamma }_v{\tilde{\lambda }}_{v,m}$ is the sum of all calculated resource weight parameters for all BE requests ${SU}_m$. The computation delay of $a_n$ executed by ${SU}_m$ is formulated as

$${\tilde{t}}_{n,m}={\displaystyle \frac{{\omega }_n}{f_{n,m}}}$$

(9)

${BE}_n$ focuses on minimizing its energy consumption and does not care about the cost of ${SU}_m$. Therefore, the energy consumption of ${BE}_n$ is zero when ${SU}_m$ is executing task $a_n$.

Cloud computation. Compared to SUs, we assume that the cloud has enough resources to respond to the requests of MASS and SUs. Therefore, we assume that the cloud server can handle infinitely many tasks in parallel. The computational latency of the cloud execution once can be expressed as

$${\widehat{t}}_n={\displaystyle \frac{{\omega }_n}{\widehat{f}}}$$

(10)

Similarly, ${BE}_n$ focuses on minimizing its energy consumption and does not care about the cost of ${SU}_m$. Therefore, the energy consumption of ${BE}_n$ is zero when ${SU}_m$ is executing task $a_n$.

Ship ${BE}_n$ maintains the local cache queue to store the unloaded data. Assume that the amount of data collected by ship ${BE}_n$ at time slot t is $B_n\left(t\right)$, Then the queue backlog of the local cache queue $Q_n\left(t\right)$ is expressed as

$$Q_n\left(t+1\right)=\mathrm{m}\mathrm{a}\mathrm{x}\left\{Q_n\left(t\right)-U_n\left(t\right)+B_n\left(t\right),0\right\}$$

(11)

where $U_n\left(t\right)$ denotes the the amount of offloaded data of the ship ${BE}_n$ at the t time slot; it can be expressed as

$$U_n\left(t\right)=\min \left\{\tau B_n{\log }_2(1+{\displaystyle \frac{P_n\left(t\right)h_n\left(t\right)}{e_n\left(t\right)+{\delta }^2}}\right),Q_n\left(t\right)+B_n\left(t\right)\}$$

(12)

In the formula, $P_n\left(t\right)$ indicates the transmission power of the ship ${BE}_n$. $B_n$, $h_n\left(t\right)$, and $e_n\left(t\right)$ denote the transmission bandwidth, channel gain, and interference between the ship ${BE}_n$ and the communication base station, respectively.

Each shore-based edge server, as well as the cloud server, maintains a separate cache queue for the ship ${BE}_n$ to store the data that have been offloaded but not yet processed. The shore-side cache queue and the cloud-side cache queue on the shore-based edge server ${SU}_m$ and cloud server are represented as

$$\begin{gathered} Y_{n,m}^{su}\left(t+1\right)=\mathrm{m}\mathrm{a}\mathrm{x}\{Y_{n,m}^{su}\left(t\right)-{\displaystyle \frac{{\tau f}_{n,m}^e\left(t\right)}{{\lambda }_n}}+w_{n,m}^o\left(t\right)\left(1-w_{n,m}^c\left(t\right)U_n\left(t\right),0\right)\},Y_m^c\left(t+1\right)=\mathrm{m}\mathrm{a}\mathrm{x}\left\{Y_m^c\left(t\right)-{\displaystyle \frac{{\tau f}_{n,m}^c(t)}{{\lambda }_n}} \\ +w_m^c\left(t\right)U_n\left(t\right),0)\right\}. \end{gathered}$$

(13)

where we define $\mathit{w}\left(t\right)=\left\{w_{n,m}^o\left(t\right),w_m^c\left(t\right)\right\}$ to be the decision variable of task offloading. $w_{n,m}^o\left(t\right)=1$ indicates that at the t time slot, the ship ${BE}_n$ selects the shore-based edge server for task offloading; otherwise, $w_{n,m}^o\left(t\right)=0$. $w_m^c\left(t\right)=1$ indicates that at the t time slot, the ship ${BE}_n$ selects cloud computing; otherwise, $w_{n,m}^c\left(t\right)=0$.

3.4. Communication Model

Based on the time slot model, the total optimization time is divided into T equal-length time slots; the set is denoted as $\mathrm{𝒯}=\left\{1,\cdots ,t,\cdots ,T\right\}$ and the length of the time slots is $\tau$. It is assumed that the channel state remains constant within a time slot and varies dynamically between time slots [34]. Similar to the computational resource allocation policy, the communication resources of ${SU}_m$ (i.e., data transfer rate) are allocated proportionally to all BEs requesting ${SU}_m$. Thus, the ${SU}_m$ allocated data transfer rate to the ${BE}_n$ is

$$f_{n,m}={\displaystyle \frac{{\gamma }_n}{{\sum }_{v=1}^N{\gamma }_v{\tilde{\lambda }}_{v,m}}}{\tilde{f}}_m={\displaystyle \frac{{\gamma }_n}{{\sum }_{{BE}_v\in {BN}_n}{\gamma }_v{\tilde{\lambda }}_{v,m}}}{\tilde{f}}_m$$

(14)

The computation delay of $a_n$ executed by ${SU}_m$ is formulated as

$${\tilde{t}}_{n,m}={\displaystyle \frac{{\omega }_m}{f_{n,m}}}$$

(15)

The energy consumption of ${BE}_n$ offloading $a_n$ to ${BE}_n$ is

$${\tilde{e}}_{n,m}^{\mathrm{\prime }}=\acute{{\sigma }_n}{\tilde{t}}_{n,m}^{\mathrm{\prime }}$$

(16)

${BE}_n$ cannot directly request the cloud. Given the data transmission rate between ${SU}_m$ and the Cloud, the communication delay for ${SU}_m$ offloading $a_n$ to the cloud can be formulated as

$${\widehat{t}}_{n,hi}^{\mathrm{\prime }}={\displaystyle \frac{{\delta }_n}{\widehat{r}}}$$

(17)

Therefore, the transmission latency between ${BE}_n$ and the cloud is ${\tilde{t}}_{n,m}^{\mathrm{\prime }}$ + ${\widehat{t}}_{n,hi}^{\mathrm{\prime }}$.

The end-to-end latency of the task offloading process consists of the queuing latency of the ship’s local cache queue, the transmission latency, the queuing latency of the shore-side cache queue and the cloud-side cache queue, the computation latency, and the result feedback latency. Since the queuing delay accounts for a relatively large portion of the end-to-end delay, ultra-reliable and low-latency communication constraints are imposed on the ship-side, cloud-side, and shore-side queuing delays to ensure the effectiveness and timeliness of task offloading.

3.5. Problem Formulation

Task completion time is an important metric for evaluating the performance of an application, indicating the time required by the application for the entire process from data input to result output. We discuss the execution time of the whole application in terms of each component of the application executing locally and the edge server executing separately.

This paper aims to solve the cloud–shore–ship multidimensional heterogeneous resource scheduling optimization problem, including the task offloading problem on the ship side and the joint optimization problem of computing resource allocation on the shore and the cloud, in order to maximize the network throughput under the constraints of task delay and energy consumption on the ship side. The multidimensional heterogeneous resource scheduling optimization problem can be modeled as

$$\left\{\begin{array}{c}\mathrm{P}1:\underset{\mathrm{w},{p,f}^{\mathit{su}},f^c}{\max }\sum _{t=1}^T\sum _{n=1}^N{U}_n\left(t\right) \\ s.t. C_1:w_{n,m}^o\left(t\right),w_{n,m}^c\left(t\right)\in \left\{\mathrm{0,1}\right\},\forall n\in N,\forall m\in M,\forall t\in T \\ C_2:\sum _{m=1}^M{w}_{n,m}^o\left(t\right)=1,\forall m\in M,\forall t\in T \\ C_3: \sum _{n=1}^N{f}_{n,m}^e\left(t\right)\le f_{n,max}^e\left(t\right),\forall n\in N,\forall t\in T \\ C_4: \sum _{n=1}^N{f}_n^c\left(t\right)\le f_{max}^c\left(t\right),\forall t\in T \\ \\ C_5: \sum _{t=1}^T{E}_n\left(t\right)\le E_{n,max}\left(t\right)\left(t\right),\forall n\in N \\ C_6: \underset{T\to \mathrm{\infty }}{\lim }{\displaystyle \frac{1}{T}}\sum _{t=1}^T\mathrm{P}\mathrm{r}\left({\displaystyle \frac{Q_n\left(t\right)}{\frac{1}{t-1}{\sum }_{j=1}^{t-1}{B}_n\left(t-1\right)}}>d_n^Q\right)\le {\varsigma }_n^Q; \\ \underset{T\to \mathrm{\infty }}{\lim }{\displaystyle \frac{1}{T}}\sum _{t=1}^T\mathrm{P}\mathrm{r}\left({\displaystyle \frac{Y_{n,m}^{su}\left(t\right)}{U_{n,m}^{su}\left(t-1\right)}}{>d}_{n,m}^{su}\right)\le {\varsigma }_n^{su};\\ \underset{T\to \mathrm{\infty }}{\lim }{\displaystyle \frac{1}{T}}\sum _{t=1}^T\mathrm{P}\mathrm{r}\left({\displaystyle \frac{Y_m^c\left(t\right)}{U_m^c\left(t-1\right)}}{>d}_m^c\right)\le {\varsigma }_n^c;\\ \forall n\in N,\forall m\in M,\forall t\in T\end{array}\right.$$

(18)

where, $\mathit{a}=\left\{\mathit{a}\left(t\right)\right\},\forall t\in T$ denotes the end task offload decision vector, ${\mathit{f}}^{\mathit{s}\mathit{u}}=\left\{f_{n,m}^e\left(t\right)\right\},\forall n\in N,\forall m\in M,\forall t\in T$ and ${\mathit{f}}^{\mathit{c}}=\left\{f_m^c\left(t\right)\right\},\forall m\in M,\forall t\in T$ denotes the shore-based edge server computing resource allocation decision vector, respectively. C₁ and C₂ indicate that at each time slot, each vessel can only select one shore-based edge server for data offloading, and only one computation mode can be selected. C₃ and C₄ are computing resource constraints for shore-based edge servers and cloud servers, respectively. C₅ and C₆ are energy consumption and task delay constraints, respectively.

4. Task-Driven Computing Unloading and Resource Allocation Optimization Scheme

4.1. Task Offloading Decision

P1 is an NP-hard problem, which is difficult to solve directly, so the problem needs to be transformed. We use the Lyapunov optimization principle [35] to transform the optimization problem into a series of short-term deterministic problems to be solved. By defining the drift minus reward function, we transform P1 into an upper bound for the minimization of the drift minus reward function under the C₁–C₇ constraint. According to the different optimization variables involved in each of the upper bound formulations, the optimization problem can be further decoupled into three deterministic sub-problems, namely, the ship-side task offloading sub-problem SP1, the shore-side computing resource allocation sub-problem SP2 and the cloud-side computing resource allocation sub-problem SP3.

SP1: Ship-side task offloading and communication resource allocation, which can realize joint optimization of ship-side task offloading and communication resource allocation, whose expression is

$$\left\{\begin{array}{c}\mathrm{S}\mathrm{P}1:\underset{\left\{w_{n,m}^o\left(t\right),w_{n,m}^c\left(t\right),P_n\left(t\right)\right\}}{\max }\mathsf{\Psi }\left(w_{n,m}^o(t),w_{n,m}^c\left(t\right),P_n(t)\right)\\ s.t. C_1,C_2,C_3,C_4,C_5\end{array}\right.$$

(19)

In this paper, we first model SP1 as a Markov decision process model and then propose a learning-based joint optimization algorithm for semi-distributed task offloading and communication resource allocation to achieve global performance optimization through cloud–shore–ship collaborative resource scheduling.

(1) State space. The state space ${\mathit{S}}_n\left(t\right)$ a contains information related to the task queue backlog, historical experience, and task arrivals of ship ${BE}_n$, and it is denoted as

$${\mathit{S}}_n\left(t\right)=\left\{Q_n\left(t\right),Y_n^c\left(t\right),Y_{n,m}^{su}\left(t\right),U_m^c\left(t-1\right),U_{n,m}^{su}\left(t-1\right)\right\}$$

(20)

(2) Action space. The action space is defined as the task offloading decision and communication resource allocation decision of the ship ${BE}_n$, and it is denoted as

$${\mathit{X}}_n\left(t\right)=\left\{w_{n,m}^o\left(t\right),w_{n,m}^c\left(t\right),P_n\left(t\right)\right\}$$

(21)

(3) Reward function. The reward function is defined as the optimization objective of SP1, which is defined as

$$\mathsf{\Psi }\left(w_{n,m}^o\left(t\right),w_{n,m}^c\left(t\right),P_n\left(t\right)\right)$$

(22)

(4) State transfer probability. The state transfer probability is defined as the probability that the ship ${BE}_n$ selects an action ${\mathit{X}}_n\left(t\right)$ in the state ${\mathit{S}}_n\left(t\right)$ and transfers to the next state ${\mathit{S}}_n(t+1)$. It is denoted as

$$P\left({\mathit{S}}_n(t+1)\right|{\mathit{S}}_n\left(t\right),{\mathit{X}}_n\left(t\right))$$

(23)

SP2: Shore-side edge computing resource allocation, which can be expressed as

$$\left\{\begin{array}{c}\mathrm{S}\mathrm{P}2:\underset{\left\{f_{n,m}^e\left(t\right)\right\}}{\max }\sum _{n=1}^N{Y}_{n,m}^{su}\left(t\right){\displaystyle \frac{{\tau f}_{n,m}^e\left(t\right)}{{\lambda }_n}}\\ \mathrm{s}.\mathrm{t}.C_3 , \\ C_7:{\displaystyle \frac{{\tau f}_{n,m}^e\left(t\right)}{{\lambda }_n}}<Y_{n,m}^{su}\left(t\right)\end{array}\right..$$

(24)

SP3: Cloud computing resource allocation, which can be expressed as

$$\left\{\begin{array}{c}\mathrm{S}\mathrm{P}3:\underset{\left\{f_m^c\left(t\right)\right\}}{\max }\sum _{n=1}^N{Y}_m^c\left(t\right){\displaystyle \frac{{\tau f}_m^c\left(t\right)}{{\lambda }_n}}\\ \mathrm{s}.\mathrm{t}.C_4 , \\ C_8:{\displaystyle \frac{{\tau f}_m^c\left(t\right)}{{\lambda }_n}}<Y_m^c\left(t\right)\end{array}\right.$$

(25)

For SP2 and SP3, we propose a task queueing-based heuristic algorithm. The algorithm can prioritize the allocation of sufficient computational resources to the ships with the largest backlog in the shore-side and cloud cache queues to maximize the optimization objectives of SP2 and SP3 in a low-complexity manner. The steps of shore-side computing resource allocation are as follows:

4.2. Resource Allocation Scheme

Due to the high dimensionality of the state space and action space of the joint task offloading and communication resource allocation problem solved in SP1, the statistical model and numerical solution of the state transfer probability cannot be obtained. Therefore, this paper proposes a joint optimization algorithm based on deep learning. The algorithm performs state action value assessment by continuously interacting with the environment, fits the state-action-value function using a deep neural network, and approximates the optimal value by learning to update the network parameters to obtain the optimal policy for task offloading and communication resource allocation. The algorithm is shown in Figure 6, including global model download, action selection, local model update, local model upload, and cloud aggregation update. Through the interaction of task offloading optimization models for cloud–shore–ship, on the one hand, the problem of high cost and computational complexity of centralized intelligent communication can be avoided, and on the other hand, the problem of poor network performance due to the inability of distributed intelligent algorithms to make full use of global information can be solved.

The ship-side and cloud-side Q-learning models consist of a master network responsible for generating task offloading and communication resource allocation decisions and a target network used to assist the training of the master network, where the parameters of the local master network, local target network, global master network, and global target network are set as $w_l^{main}$, $w_l^{target}$,$w_g^{main}$, $w_g^{target}$, The steps of the algorithm are as follows.

(1)

Cloud and shore model download. In the t time slot, ${BE}_n$ downloads $w_g^{main}$ and $w_g^{target}$ from the cloud server, then set $w_n^{main}=w_g^{main}$ and $w_n^{target}=w_g^{target}$.

(2)

Action space. Estimated $Q$(${\mathit{S}}_n\left(t\right),{\mathit{X}}_n\left(t\right),w_n^{main}$) based on the local network, ${BE}_n$ execute action ${\mathit{X}}_n\left(t\right)$, Shore-based edge servers and cloud servers complete the allocation of computing resources according to Algorithm 1. Update the parameters to move the state to ${\mathit{S}}_n\left(t+1\right)$. Meanwhile, samples are generated for updating the historical experience pool and ${BE}_n$ calculates the rewards $\mathsf{\Psi }\left(w_{n,m}^o\left(t\right),w_{n,m}^c\left(t\right),P_n\left(t\right)\right)$.

(3)

Local model update. ${BE}_n$ randomly selects samples from historical experience and calculates the loss function

$${\varphi }_n={\displaystyle \frac{1}{V}}\sum {\left(\mathsf{\Psi }\left(w_{n,m}^o\left(t\right),w_{n,m}^c\left(t\right),P_n\left(t\right)\right)+\gamma \underset{{\mathit{X}}_n\left(t+1\right)}{\max }Q({\mathit{S}}_n\left(t+1\right),{\mathit{X}}_n\left(t+1\right),w_n^{target}-Q({\mathit{S}}_n\left(t\right),{\mathit{X}}_n\left(t\right),w_n^{main}\left)\right)\right)}^2.$$

(26)

where V is the number of samples and $\gamma$ is the discount factor.

(4)

Local model upload. ${BE}_n$ uploads local models to the cloud server for the global model update.

(5)

Shore aggregation update. At the end of the t time slot, the shore edge servers perform the shore aggregation update process based on the collected local model.

$$w_g^{main}=w_g^{main}-{\phi }^{\mathrm{\prime }}{\displaystyle \frac{D_k}{D}}{\nabla }_{w_k^{main}}{\varphi }_k^2$$

(27)

$$w_g^{target}=w_g^{target}-{\phi }^{\mathrm{\prime }}{\displaystyle \frac{D_k}{D}}{\nabla }_{w_k^{target}}{\varphi }_k^2$$

(28)

(6)

Cloud aggregation update. At the end of the t time slot, the cloud server performs the cloud aggregation update process based on the collected local and shore models.

Algorithm 1: The Task Queueing-based Task Offloading Algorithm

$$\begin{gathered} \mathrm{the} \mathrm{set} \mathrm{of} \mathrm{ships} \mathrm{that} \mathrm{need} \mathrm{to} \mathrm{be} \mathrm{allocated} \mathrm{computing} \mathrm{resources} \mathrm{in} \mathrm{t}, {\mathcal{R}}_{n,t}=\{{BE}_n\in \\ \mathcal{R}\left|Y_{n,m}^{su}\left(t\right)>0\right.\}, \mathrm{and} \mathrm{initialize} \mathrm{the} \mathrm{available} \mathrm{computing} \mathrm{resources} {f_n^{ava}\left(t\right)=f}_{n,max}^e\left(t\right) \end{gathered}$$

$\begin{array}{l}\mathrm{for} {BE}_n\in \mathcal{R},\\ v_{n,t}^e\left(t\right)=min\left\{f_n^{ava}\left(t\right),{\displaystyle \frac{{{\lambda }_{n}Y}_{n,m}^{su}\left(t\right)}{\tau }}\right\},\\ {BE}_n^{\ast }={argmax}_{{BE}_n\in {\mathcal{R}}_{n,t}}\left\{Y_{n,m}^{su}\left(t\right)\tau v_{n,t}^e\left(t\right)\backslash {\lambda }_n\right\}\\ {\mathcal{R}}_{n,t}\to {\mathcal{R}}_{n,t}\backslash {BE}_n^{\ast }, f_n^{ava}\left(t\right)\to f_n^{ava}\left(t\right)-v_{n,t}^e\left(t\right)\\ \mathrm{if} {\mathcal{R}}_{n,t}\ne \mathrm{\varnothing }, \mathrm{or} f_n^{ava}\left(t\right)\ne 0\\ \mathrm{repeat} v_{n,t}^e\left(t\right) \mathrm{and} {BE}_n^{\ast }\end{array}$ Return resource allocation strategy Q.

5. Case Studies

5.1. Basic Parameters

In this paper, we consider a cloud–shore–ship collaborative resource scheduling scenario with one cloud server, three shore-based edge servers, and ten ships, and verify the effectiveness of the proposed task-driven cloud–shore–ship collaborative resource scheduling method through simulation case analysis, with the specific simulation parameters shown in

Table 1. Simulation parameters.

Parameter Type	Parameter Name	Value
System parameters	Slot T	100 s
	$\mathrm{Slot} \mathrm{length} \tau$	0.1
	$\mathrm{Bandwidth} B_k$	1 MHz
	$\mathrm{Link} \mathrm{interference} {\delta }^2$	−120
	$\mathrm{Weights} V$	10
	$\mathrm{Explore} \mathrm{factor} \mathsf{\epsilon }$	0.1
	$\mathrm{Discount} \mathrm{factor} \gamma$	0.95
	$\mathrm{Task} \mathrm{data} \mathrm{volume} \mathrm{A}$	[1.0, 6.0] Mbit
Ship parameters	$\mathrm{Calculate} \mathrm{ability} f_n$	1000 cycles/bit
	$\mathrm{Queuing} \mathrm{delay} \mathrm{threshold} d_n^Q$	0.2 s
	$\mathrm{Transmission} \mathrm{power} P_n\left(t\right)$	0.4
Shore parameters	$\mathrm{Calculate} \mathrm{ability} f_{n,m}^e\left(t\right)$	[4, 8] GHz
	$\mathrm{Queuing} \mathrm{delay} \mathrm{threshold} d_{n,m}^{su}$	0.2 s
Cloud parameters	$\mathrm{Calculate} \mathrm{ability} f_{n,m}^c\left(t\right)$	10 GHz
	$\mathrm{Queuing} \mathrm{delay} \mathrm{threshold} d_m^c$	0.2 s

. In order to verify the impact of the above experimental contents on the system performance, this paper compares the scheme with the following five task processing methods:

(1)

Ship: Tasks are processed and calculated only at the ship’s terminal.

(2)

Shore: Task offload to shore-based edge nodes for computation.

(3)

Cloud: All tasks are offloaded to the cloud center for execution.

(4)

Ship-Shore: Tasks are performed locally on the ship and at the shore-based edge nodes.

(5)

Random: Tasks are computed in a randomized cloud–shore–ship execution.

5.2. Simulation Results and Analysis

(1)

Comparison of the proposed algorithm with ABC, PSO, and RAN

In order to verify the proposed algorithm, this paper compares the performance of the Proposed algorithm (PA), Artificial Bee Colony algorithm (ABC) [36], Particle Swarm Optimization algorithm (PSO) [37], and Random Offloading algorithm (RAN) [38] from the task delay, energy consumption, and system throughput to evaluate the performance of the proposed algorithm.

After processing different task amounts and after 100 iterative calculations, the average task delay and energy consumption comparison of the four offloading decision algorithms are shown in Figure 7 and Figure 8, respectively. When the number of tasks is small, the gap between PM, ABC, and PSO is very small. With the increase in the number of tasks, the average task delay of PM is reduced by 15.7%, 25.6%, and 54.8%, respectively, compared with ABC, PSO, and RAN. Figure 9 and Figure 10 shows the changes in system energy consumption. Compared with different numbers of tasks, the system energy consumption of PM is significantly reduced to varying degrees. Among them and compared with ABC, the energy consumption of PM is reduced by 15.4%. Compared with PSO, the energy consumption is reduced by 38.8%, which is 54.9% lower than RAN. It can be seen that PM has certain advantages and can improve the performance of the whole system.

Task processing delay refers to the time from task initiation to receiving task processing feedback, which includes task queuing time, communication time, processing time, and so on. Task energy consumption refers to the energy consumed from task initiation to receiving task processing feedback, including communication consumption and calculation consumption. The level of task delay indicates the timeliness of task feedback. In the process of MASS operation, the smaller the general task and task delay, the higher the calculation efficiency. The level of task energy consumption indicates the cost spent by the system in processing tasks. It is generally believed that the smaller the task energy consumption, the better the task processing strategy.

(2)

The effect of the number of ships on the system performance

Figure 9 and Figure 10 evaluate the impact of the number of ships on the average task delay and system energy consumption, respectively. It can be seen from Figure 8 that the average task delay increases with the increase in the number of ships for all schemes, but the average delay of the cloud–shore–ship cooperative scheme is always the smallest. When the number of ships increases, the computational resources required for the generated tasks also increase rapidly. Combining the data volume and QoS of the tasks, the system offloads some tasks from the ships to the shore-based edge computing nodes or cloud centers for processing based on the offloading model to obtain the smallest task processing delay. In addition, it is found that when the number of ships gradually increases, the average task delay of the computation scheme relying only on the shore-based edge computing nodes is larger than that of the ship local computation scheme, which is due to the competition for communication and computation resources during the task offloading process and does not follow a reasonable offloading scheme, resulting in unnecessary waiting links for tasks in both the transmission process and the computation process, and therefore the latency is getting higher.

It can be seen from Figure 11 that the system energy consumption also increases with the number of ships, and the energy consumption of the cloud–shore–ship cooperative scheme has a strong superiority. The energy consumption of Shore–Ship is lower than that of Cloud. Compared with the Cloud center, the energy consumption of the waiting process during the task arrival at the Shore nodes is negligible, and its transmission energy consumption is significantly lower; therefore, the overall energy consumption of Shore scheme is lower than that of Cloud.

(3)

The effect of the task data volume on the system performance

The impact of the task data volume on the task average delay and system energy consumption is evaluated here (the number of ships is 10). The task average delay and system energy consumption for each scenario in this configuration are shown in Figure 11 and Figure 12. The task average delay increases with increasing task data volume for all six scenarios, but the task average delay of the cloud–shore–ship cooperative scenario is the smallest. Because of the limited amount of local computation on the ship, the task latency will first keep a stable value and then increase beyond a certain amount. The task average delay of shore mode is higher than that of cloud mode and ship local mode because of the competition for communication and computation resources when offloading tasks and data volume increase. From the practical performance, the proposed scheme can quickly handle the tasks with high input data volume on the ships.

From Figure 13, the energy consumption of the six schemes gradually increases with the increase in task data volume, but the cloud–shore–ship collaborative scheme performs better. Therefore, when faced with a large amount of data input, the energy consumption of this scheme outperforms the other modes, which is 59.72% lower than Random mode, 31.28% lower than Cloud mode, and 28.67% lower than Shore mode.

(4)

The effect of the maximum task delay on the system performance

The impact of the maximum task delay on the average task delay and energy consumption is evaluated here. As shown in Figure 13 and Figure 14, when the maximum task delay gradually increases, more tasks will be executed in the cloud and shore, while tasks requiring large amounts of computational resources are offloaded to the edge nodes, so the average task delay decreases as the delay tolerance increases. The cloud–shore–ship collaborative scheme always maintains the minimum average task delay compared with other schemes, the system energy consumption also shows a similar performance to the delay state, and the scheme in this paper always maintains low values for the corresponding average task delay and energy consumption, which is superior.

(5)

The effect of ship’s maximum communication power on system performance

Figure 15 and Figure 16 show the effect of the maximum communication power of the ship on the average task delay and system energy consumption, respectively. As the ship’s communication power increases, the transmission rate of communication increases, the task unloading speed becomes faster, and the task average delay becomes smaller. The results show that the maximum communication power of the ship increases less, but the average task delay decreases faster, so the overall energy consumption of the system tends to decrease. The method proposed in this paper shows certain advantages over other schemes in terms of both task delay and energy consumption.

6. Conclusions and Future Works

In this paper, we build a cloud–shore–ship collaborative computing architecture that integrates the Internet of ships and cloud/edge computing for inland waterway ship intelligent navigation scenarios. According to the type of tasks, time delay, and synergy, this architecture can realize having the computational tasks of ship intelligent navigation processed locally on the ship, at the shore-based edge node, or at the cloud center. In this paper, based on previous research results, we consider the task relationship, task priority, and ship mobility, which establish the ship, shore, and cloud computing models, respectively, design the joint optimized delay and energy consumption objective functions, and realize the adaptive offloading of tasks under the evaluation of each resource. In addition, this paper proposes a task offloading method based on artificial intelligence for the dynamic prediction of computing resources. Simulation results show that the scheme in this paper can provide low latency and low energy consumption under the high task concurrency of the ship.

Future research can focus on network security, communication failure, and task uncertainty. For the operation of MASS, network security and communication redundancy are indispensable. In extreme conditions, how to ensure the safe navigation of MASS needs to be seriously studied. In the process of MASS operation, the computing task is often highly uncertain and needs to be paid attention to.