An Approach of Consensus-Based Double-Layer Blockchain System for Multi-Ship Collision Risk Mitigation Considering COLREGs

Abstract

Ship collision avoidance (CA) is the most fundamental and essential issue of maritime safety, regardless of whether the ship is a conventional ship or a future maritime autonomous surface ship (MASS). However, effective ship-to-ship communication has been recognized as a critical issue and one of the major challenges affecting the success of ship CA. This study intends to investigate the basic trust concerns in the cybersecurity components of the ship CA process and develop a blockchain-based solution for trustworthy communication. The novel idea behind applying blockchain to ship CA decision-making is that the various participating ships in a scenario of dynamically changing ship encounters form a decentralized network of opportunities, which makes blockchain an appealing tool to offer a solution for evaluating and maximizing trust in entity dynamics. The mechanism of entity participation in upholding a master chain for avoiding ship encounters is described in this work. The research begins by analyzing conventional ship CA decision scenarios under COLREGs in order to identify formal communication strategies that can make information more understandable. Based on this, it is demonstrated how beliefs of trust (BoT) between entities are encoded and combined on the chain to enable entities in the encounter scenario to form an initial opinion about another entity before becoming familiar with it. This first encounter occurs during ship CA. Second, this article examines how encounter ships have temporary rights in the process of making CA decisions. This generates blocks and attaches them to the chain at the consensus layer of blockchain technology. Finally, this study undertakes a case test of ship CA based on the aforementioned communication principles. In order to ensure safe and effective communication during brief, one-time ship encounters, the results offer a practical method for conveying CA reasoning in encounter scenarios. As a result, it can aid in the selection of better (more reliable) nodes to uphold the evidence-based understanding of the ship CA process and assess the reliability of unidentified members.

1. Introduction

The shipping industry has achieved continuous development over recent decades due to developing technology and increasing worldwide commercial activities. Waterborne transportation is growing denser, especially in major navigation lanes and active waters such as bays, ports, inland rivers, etc. [1]. The busier the waterway, the higher the probability that more than two ships will get into an encounter situation. A multi-ship encounter situation is obviously more complex, as each ship should consider more than one target ship to make a workable collision avoidance (CA) decision.

The ship CA process differs from railway and road traffic due to the significant inertia and under-actuated characteristics of ships. The inertia of ships means that emergency maneuvers during CA are affected and may not achieve the desired outcome. Under-actuated characteristics require advanced maneuver planning and the accumulation of time to achieve the desired state. Communication plays a vital role in the CA process, where ships share general intentions rather than detailed decisions. Misunderstandings in communication often lead to ship collision accidents. Research has shown that communication failure is a major cause of such accidents. The ship CA process is characterized by slow-motion changes, multiple CA communications, and highly coupled decision-making between ships. The internal and external logical structures of ship CA include observable maneuvers and hidden intentions. Through repeated communication and influencing each other’s decision-making, ships can successfully avoid collisions.

Traditional ship CA research is mainly based on the ship’s own understanding of the current navigation state and a series of intelligent decisions from some traditional CA algorithms. Traditional ship collision avoidance algorithms primarily emphasize the geometric relationships between vessels, employing a decision-making process akin to enumeration rather than employing more sophisticated path-planning algorithms [2]. In the traditional CA scenario, the ship’s CA decision often has to go through several stages: risk discovery, initial CA decision of the ship, CA decision communication between the meeting ships (usually through very high frequency, VHF), and final CA decision. Due to the huge inertia of the ship and its slow-moving speed, a CA process may take several minutes to tens of minutes [3,4]. In this process, the ships will encounter the above-mentioned communication process many times, forming a complex negotiation avoidance situation that affects both of them. This has created an industry practice in the daily navigation of ships [4]. At the same time, after studying a large number of ship collisions [5,6], it can be found that ship collisions are often caused by the failure to communicate or understand each other’s intentions. Even in two-ship encounter scenarios, the above situation happens from time to time. In a multi-ship encounter scenario, if such inefficient and lengthy communication is still adopted, the possibility of collision due to failure in ship decision-making will increase significantly [7]. For the problem of communication, understanding, and trust, people naturally turn their attention to blockchain technology, especially the emergence of core technologies such as the “consensus algorithm”, which makes it possible to achieve efficient communication of CA strategies, even between ships that are complete strangers to each other, through the blockchain formed temporarily.

Another major idea to solve the navigational safety problem is intelligent ship decision-making, or a maritime autonomous surface ship (MASS) [8,9]. MASSs have formed an industry consensus, and there is a global boom in MASS development. However, intelligent decision-making systems, even with the ability to process scenarios more quickly and effectively than experienced crews [10,11,12], still cannot solve a core problem in the ship CA process [13]: how to handle communication and trust management between participants? To fully understand this, we consider the following three points in the MASS system: (1) there will be no voice command or control loop (i.e., VHF) between maritime administrations and autonomous ships, and maritime regulation must be achieved through digital means; (2) autonomous ships will have a shoreside remote control center, which makes the structure of digital maritime administrations less flat; and (3) in a highly digital maritime management scenario, interactions between entities of maritime participants require authenticated identification and communication, thus requiring more sophisticated technology. These fundamental changes mean that security issues in this era include not only the traditional operational aspects of maritime incidents but also cyber security challenges. In traditional maritime day-to-day practice, voice-based communications dominate, and one usually does not need to question the authenticity of calls and answers over public channels. However, in the MASS scenario, the aforementioned issues call for careful handling of malicious entities. To make things concrete, a realistic approach is to resort to traditional information security solutions. In theory [14], asymmetric encryption and digital certificate technologies already provide a solid foundation for identification, authentication, tamper-proof verification, and, if necessary, confidentiality. However, the practical implementation of traditional information security approaches has proven challenging in real-world maritime environments [15]. First, the connectivity of the MASS entity network is highly dynamic and unstable. This means that any approach based on asymmetric encryption has to be implemented opportunistically and should take additional considerations compared to its implementation in a reliable network infrastructure (e.g., the internet). Second, due to the high mobility of navigational data exchange, there are no clear boundaries to define data bulk sessions or transactions between entities. At the same time, the data records exchanged on the network are large and increasing in number, and these data are not assigned to specific nodes for storage in the MASS network. As a result, data collection is performed in a peer-to-peer manner, which requires a fast and reliable way to manage the trustworthiness of data distribution. This challenge reveals two research questions: (1) What is the relationship between traditional information security and trust management? (2) How do we introduce new approaches and technologies when traditional information security is no longer applicable to future MASS scenarios? In view of the above, this paper aims to develop a blockchain-based approach for trust management among participants in MASS systems to ensure their cybersecurity.

Effective communication between encountering ships has been identified as an important issue and one of the main obstacles affecting the outcome of ship CA. In this paper, we aim to develop a blockchain-based solution for trusted communication in ship encounter avoidance by investigating the fundamental trust issues in the cybersecurity aspects of the ship encounter avoidance process. The innovative concept of using blockchain in the context of ship CA decision-making is that the various participating ships in a dynamically changing ship encounter scenario constitute a decentralized network of opportunities, which makes blockchain an attractive tool to provide a solution for assessing and maximizing trust in entity dynamics. In this paper, we describe the mechanism of entity participation in maintaining a master chain for ship encounter avoidance. First, the paper analyzes traditional ship CA decision scenarios to find formal communication methods that can simplify information. Based on this, it is illustrated how beliefs of trust (BoT) between entities that first meet during ship CA are encoded and combined on the chain to allow entities in the encounter scenario to have an initial judgment about another entity before they become familiar with it. Secondly, at the consensus layer of blockchain technology, this paper discusses how encounter ships obtain temporary rights in the process of CA decision making, thus generating blocks and attaching them to the chain. This is the blockchain-based trusted communication (BTC) method for ship CA proposed in this paper. Finally, based on the above communication rules, this paper conducts a case of ship CA. The results provide an effective solution for communicating CA logic in encounter scenarios to guarantee secure and efficient communication during short-term, one-time ship encounters. Thus, they can help to select better (more trustworthy) nodes to maintain the evidential knowledge of the ship CA process and judge the trust of unknown members.

The remainder of the paper is organized as follows. The basic definition and problem statement are proposed in Section 2. Section 3 delineate the basic concept of the method and the general framework of the decision-making procedure. Lastly, simulations based on the proposed decision-making formulation are carried out by considering several multi-ship encounter scenarios in Section 4. Some conclusions are discussed in Section 5.

2. Blockchain Structure Design Based on Multi-Ship Collision Avoidance Communication Scenario

One type of work on ship collisions has been conducted from a “human factor/human error” perspective, while the other type has been analyzed and modeled from a “decision and planning” perspective [16]. However, this simple division reveals some interpretative difficulties. If the “human factor/human error” is excluded from the study of decision-making and planning in CA (i.e., the latter type of work), a basic assumption is that the behaviors or decisions implemented by the parties involved in the CA process are rational. But in practice, even if all parties act rationally, there is still the possibility of a real collision caused by a “misunderstanding of CA intention”, which is often classified as a human error-type problem. This tells us that ship CA (especially multi-ship CA) is not suitable for the simple use of “right and wrong” to measure behaviors or decisions; in this sense, the “human error” formed by the conflict or misunderstanding of the intention to avoid collision is more of a relative concept. When all parties involved in ship CA are rational decision-makers and actors, if they can accurately identify other parties’ CA strategies and reach a common tacit agreement, the process is obviously more closely related to human thinking habits for completing CA operations more successfully. This relies on good communication between the participants.

2.1. The Blockchain-Based Communication Process for Multi-Ship Collision Avoidance Scenarios

The blockchain-based CA communication process is divided into three stages: ship discovery, trusted communication, and algorithm execution. The specific process is shown in Figure 1.

When other ships are found to enter the navigation area of the ship, the ship discovery stage is entered, the CA communication process is started, and the contract layer calls the navigation data acquisition interface of relevant ships to obtain data and enter the trusted communication stage.

In the trusted communication phase, according to the CA rules, the contract layer determines one by one whether all the ships in the navigation area have collision risk, and if there is collision risk, whether the ship is an avoiding ship according to the CA rules. If the ship is not a CA ship for all ships in the area, this means that the ship does not need to perform CA operations, and the CA communication process is finished. If there is a collision risk for a ship and the ship is an avoidance ship, the contract layer starts to calculate the closest point of approach (CPA) and then calculates the distance to CPA (DCPA) and the time to CPA (TCPA) from the calculation result.

Then, the contract layer calls the service layer interface to send the CA intention to the ship (i.e., the target ship), and the service layer calls the facility layer interface to add the sent information to the transaction set. If a valid response is received from the target ship, a confirmation message is immediately sent in reply to the target ship. If no valid response is ever received from the target ship, the message is resent. The retransmitted record is also saved to the transaction set. The data that are saved to the transaction set is temporarily stored in the pre-submitted blocks. When the consensus of the facility layer is completed, the block is changed from the submitted state to the committed state and written to the database, waiting to be synchronized to other nodes. Any message can invoke the validity verification service of the service layer to verify the truth through the cryptographic components of the facility layer, etc., to ensure the trustworthiness, integrity, and untampered source of the message.

After the trusted communication phase, to reach an agreement on the CA intention between the avoided ship and this ship, the CA algorithm is executed in the algorithm execution phase according to the type of CA algorithm selected by the user. The operation result of the algorithm calls the service layer data up-linking service to store it on the chain, and at the same time, it is output to the application layer. The CA communication ends.

2.2. The Blockchain Structure Design for Multi-Ship Collision Avoidance Scenarios

The service layer provides services to the contract layer for interacting with the blockchain, such as the trusted sending of messages (proving that a message was sent at a certain point in time), the trusted receiving of messages (proving that a message was received at a certain point in time), data uploading (storing data on the blockchain), and validation (proving that data are complete, untampered with, and trusted). To implement the above services, the service layer invokes the underlying components of the blockchain facility layer, such as cryptography, communication, storage, and a consensus module, in order to synchronize the blocks of this node with the blocks of other nodes, which are all illustrated in Figure 2.

By design, the application layer interacts only with the service layer, and the service layer interacts only with the application layer and the facility layer.

Due to the excessive size of the complete block data stored in the blockchain, the above figure omits the timestamps, signatures, consensus proofs, and other parts and only shows the data part about the CA communication, which is shown in Figure 3. Transactions contain the information sent and received in the trusted communication phase of the CA communication process and the algorithm execution results in the algorithm execution phase. In block h, Pre.Hash is the hash value of block h − 1, while the Hash of block h is the result of hashing all data in the current block. The special point to note is that these data also include Pre.Hash.

Therefore, when the data in the transactions of block h − 1 change in any way, the Hash of block h − 1 will definitely change. At this point, a comparison of the Pre.Hash in block h reveals that block h − 1 has been tampered with. If you try to disguise the tampered block h − 1 by changing the Pre.Hash in block h to a new Hash of the tampered block h − 1, then the Hash of block h will also be changed, and in turn, you need to change the Pre.Hash of block h + 1. It follows that if you tamper with the data of block h − 1 and do not want to be detected, then you need to change all the blocks in the local blockchain for block h and after.

In addition, each block is synchronized to other nodes of the blockchain through the consensus mechanism of the blockchain, so such tampering can be discovered by any of the nodes in the blockchain. That is, in order to achieve data tampering without detection, one would also have to tamper with the blocks of most of the nodes in the blockchain at the same time, which we generally consider unattainable (or far more costly than beneficial). In other words, a correct block can be verified by any node in the blockchain, thus achieving trustworthy, complete, and tamper-proof data and thus achieving trustworthy CA communication.

3. Multi-Ship Collision Avoidance Decision Making Based on Full Communication

When the blockchain method is introduced into multi-ship CA decision-making processing, all encountered ships can fully communicate with each other, and all the decision-making can be made based on the information of the involved ships known to all. So, most parts of the traditional scenario will be changed. In this section, a new decision-making method based on the blockchain communication mechanism is analyzed.

3.1. Intention-Based Ship Collision Avoidance Processing

Due to their huge inertia and under-actuated characteristics, the CA process of ships presents a distinctive feature compared with railway and road traffic. First of all, the huge inertia of ships determines that all emergency and rapid maneuvers made by the encountered parties during the CA process will be affected and cannot achieve the expected goal. Secondly, the under-actuated characteristics of ships determine that all behaviors in the CA process need to be maneuvered in advance and achieve the desired state through time accumulation. This leads the bridge team to draw up a reasonable CA decision as the first step of the CA process and then make the ship reach the planned state through a series of CA maneuvers. If the CA decision is reasonable and the CA maneuver is effective, the CA will be successful. Otherwise, ship collision accidents will occur due to various reasons. In practice, the CA process can be summarized into a logical structure with internal and external layers, that is, the hidden CA intention and the shown layer of CA decision/maneuver. The content of the communication between the encountered ships is mostly the general CA intention rather than the detailed CA decision. Then, the encountered ships conduct specific CA maneuvers according to their respective CA intentions. However, this may cause a problem where ship collision accidents are very common [17], especially due to the deviation or complete misunderstanding of each other’s CA intention during communication. A previous study [15] studied 50 serious ship collision accidents around the world and found that the main or important reason for 37 of the accidents was communication failure among the ships (for 17 cases, this was the main reason, and for 20 cases, this was one of the important reasons).

The process of ship CA often lasts for a long time. During the whole process, the movement of the ship is manifested as the accumulation of small changes in the slow-motion state. This often involves multiple CA communications and changes to the own ship’s (OS’s) CA decision according to the situation of the other ship. Therefore, the process of ship CA shows the characteristics of highly coupled CA decision-making between the encountered ships. In short, the observable CA maneuver behavior and the hidden CA intention together constitute the internal and external logical structure of the ship CA process. In the repeated communication and exchange of opinions between the encountering ships, they influence each other’s CA intention and CA decision-making and finally avoid collision.

Figure 4 illustrates the process of path target determination and the two-stage CA process in a two-ship encounter situation. Generally, the ship CA process can be divided into two stages, i.e., the extra trajectory to avoid collision and the stage of returning to the original course after passing the encounter region. According to COLREGs, the give-way ship (Ship A in Figure 4) needs to turn right to clear the region ahead of the stand-on ship (Ship B), while the stand-on ship should keep its course and speed to pass the encounter region from the foreside of the give-way ship and keep vigilant in case the give-way ship does not take measures in time. Therefore, the path target of the giving-way ship is set outside the ship domain of the stand-on ship at the CPA. When the give-way ship passes through the path target, it will enter the second stage and return to its original course. The stand-on ship should pass the encounter region at the original speed and heading. During the CA process, the repulsion field (SRF in Section 3.2) around the ships plays an insurance role in avoiding encountering distances that are too close.

Figure 5 illustrates the process of path target determination and the two-stage CA process in a multi-ship encounter situation. In this case, each involved ship is responsible for clearing the region ahead of the ship on its starboard side. If there is no other ship on its starboard side, the ship can keep its own speed and heading forward [2,18]. In this case, the first ship to the starboard direction of the OS is considered to be the priority ship to give way to. For instance, ship 2 is ship 1’s priority ship to give way to in Figure 4. In this way, each ship and its priority avoiding ship form a two-ship encounter situation. If there is no more new and urgent collision risk, the OS will sail towards the current path target until it encounters a new priority avoiding ship or completely leaves the encounter region.

It should be noted that the choice of path target is an independent choice of each involved ship, whether in a two-ship encounter situation or a multi-ship encounter situation. In the following numerical experiments in Section 4, it can be seen that the different ways of determining path targets will affect the efficiency of the CA process, but they will not affect the safety of the OS or the inference of the CA intention of the OS by other ships. This is because the CA intention itself is vague and at a hidden level, not a specific CA maneuver.

According to the CA communication flow design in Figure 1, the intention of CA between ships is the main content of BTC technology communication.

3.2. The CA Logic and Formulation of CA Intention Based on COLREGs

The CA logic (CAL) of a ship is its macro strategy to pass through a collision-prone situation. As mentioned, the COLREGs are the basic regulations that both ships should comply with in conventional two-ship CA scenarios. There are three types of encounter situations addressed by COLREGs, namely crossing, head-on, and overtaking [19]. The own ship can be regarded as either a give-way ship or a stand-on ship when it is involved in a two-ship encounter scenario, as referred to in [20], which gives a detailed analysis of the stand-on or give-way ship judgment method according to the CPA. According to COLREGs, the give-way ship always has a greater responsibility than the stand-on ship to avoid collisions. The CA measures that the give-way ship can take include a right turn and deceleration, while the stand-on ship can take the opposite measure. The practice of COLREGs in multi-ship encounter situations is discussed in [2], and the main difference between stand-on or give-way ships is whether one ship crosses another before or after it [21]. Both of the involved ships should cooperate to make sure that stand-on ships cross the region before give-way ships.

In the multi-ship encounter scenario, the stand-on/give-way relation between two ships can be applied in a pairwise manner. Thus, a mutual relation matrix is formulated to represent the pairwise relationship between any two involved ships. The CAL of one ship is just the strategy or guidance of CA action. In this paper, CAL is defined as a kind of simple and effective model to analyze the attitude of a ship towards the current encounter situation. Even though there are several feasible trajectories under a particular encounter scenario, the CAL can only be 0 (give-way) or 1 (stand-on). So, it is much easier and more reasonable to infer the target ship’s CAL rather than their decisions. After inferring the target ship’s CAL, the own ship’s CAL can be made accordingly, as follows:

$${\mathrm{C}\mathrm{A}\mathrm{L}}_{\mathrm{o}\mathrm{s}\mathrm{i}}=\left\{\begin{array}{c}0,\mathrm{i}\mathrm{f}\mathrm{O}\mathrm{S}\mathrm{i}\mathrm{s}\mathrm{g}\mathrm{i}\mathrm{v}\mathrm{e}-\mathrm{w}\mathrm{a}\mathrm{y}\mathrm{s}\mathrm{h}\mathrm{i}\mathrm{p}\mathrm{t}\mathrm{o}{\mathrm{T}\mathrm{S}}_{\mathrm{i}}\\ 1,\mathrm{i}\mathrm{f}\mathrm{O}\mathrm{S}\mathrm{i}\mathrm{s}\mathrm{s}\mathrm{t}\mathrm{a}\mathrm{n}\mathrm{d}-\mathrm{o}\mathrm{n}\mathrm{s}\mathrm{h}\mathrm{i}\mathrm{p}\mathrm{t}\mathrm{o}{\mathrm{T}\mathrm{S}}_{\mathrm{i}}\end{array}\right.$$

(1)

For instance, if the target ship’s CAL is 1, the own ship’s CAL should be 0 to avoid conflict. And the decision of the OS is made on the basis of the OS’s CAL. After all, it is the CA decision that determines a ship’s status next time. In the method proposed in this paper, CAL is the description of the OS’s CA intention at the level of the repulsion field. The repulsion field around TS represents the OS’s understanding of the give-way/stand-on relationship with TS and the understanding of the COLREGs.

3.3. The Intention-Based Real-Time Route Planning Method

In this paper, the CA intention is represented in two ways: on the one hand, the CA intention is expressed as the ship’s compliance with COLREGs, which is the compliance field (CF); on the other hand, the CA intention is expressed as how the ship tends to pass through the encounter situation, which is the determination process of the path-planning target point (PT). All the decision-making is made based on the artificial potential field (APF) method; the planned trajectory is guided to PT through an attractive potential field $U_{att}\left(p\right)$.

The attractive field $U_{att}$ is a function of the linear distance between the ship and the destination. In order to guarantee the ship can be attracted by the destination anywhere, the attractive field is designed to work globally. And the further away the ship is, the bigger the attractive field is, which can be written as follows:

$$U_{att}\left(p\right)={\alpha ‖p_d-p\left(t\right)‖}^{\beta }$$

(2)

where $p_d$ and $p\left(t\right)$ are the position of destination and the current position of the OS, respectively; $‖p_d-p\left(t\right)‖$ is the Euclidean distance between $p_d$ and $p\left(t\right)$; $\alpha$ is the scalar field parameter, which can influence the strength of the attractive field; $\beta$ is a positive constant, which can influence the shape of attractive field. Then, the virtual attractive force ${\overrightarrow{F}}_{att}\left(p\right)$ can be defined as the negative gradient of $U_{att}\left(p\right)$.

The attractive field $U_{att}$ and virtual force ${\overrightarrow{F}}_{att}\left(p\right)$ are both globally used functions that, where there is a collision risk with other ships, have an impact on the CA path planning process. This is also the main difference between the attractive field and the repulsive field in the APF method. Based on the limited reference to the ship CA intention research, Cho et al. (2021) proposed an inference method for COLREGs compliance intention based on the dynamic Bayesian network. However, this method only considers the two-ship encounter situation and directly maps the compliance behavior to the corresponding target region. In our previous research [18], the CA intention in multi-ship encounter situations is summarized as CAL. In the modeling of the attractive field, the determination of the path target is the representation of the CAL.

3.4. Blockchain-Based Broadcast Message and Information Interaction for Ship Collision Avoidance Process

When the ship CA process is simplified to the selection of priority avoidance ships and CA path targets, the ship CA broadcast (CAB) message and information interaction become clear. The content of the CA broadcast proposed in this paper mainly contains the CA notice ID, the issuing notice ship ID, the notice time, the OS’s information (speed, real-time heading, real-time position), and the OS’s decision broadcast (priority avoidance ship and path target). Among them, the collision avoidance notice ID is the unique identification of the collision avoidance broadcast; the issuing notice ship ID is the unique identification of the issuing broadcast ship. The format of the data contained in the collision avoidance notice is shown in Figure 6.

The ship broadcasts the collision avoidance through the content of a block structure to other ships in the encounter. At this time, the block structure uploaded by the ship to the blockchain is shown in Figure 7. The block data are divided into two parts: the block header and the block body. The block header is the identification of the block, and the main contents include the title, the timestamp, the length of the block, the digital signature of the uploader of the block, and the credit change by the transaction. The header contains the identity of the uploader and the reputation points they have; the timestamp indicates the time when the block was formed; and the body length changes with the number of nodes contained in the block. According to the communication system described above, the steps of the message upload and credit evaluation usually result in changes in the reputation points of the uploader and the evaluator, so there is a field indicating the gain or loss of reputation points generated because of the block. The main information passed by the block, CAB, comes from the definition of CAB in Figure 6. The title of each block is connected to the previous block, thus forming a blockchain.

As can be seen by the definition of the CAB, the content of the CAB can actually be considered an extension of AIS messages. Previous studies [13] have already confirmed that this design of the blockchain structure can satisfy the basic needs even of traditional AIS communication without equipping new communication devices due to the simplicity of the communication content. A similar setup is used in this paper.

3.5. Blockchain-Based Decision-Making Algorithm for Ship Collision Avoidance

This section introduces the algorithm that employs blockchain technology to enhance ship collision avoidance decision-making. As depicted in Figure 8, the process involves four key steps. The algorithm is grounded in blockchain principles. Each vessel possesses a unique cryptographic identity, ensuring data integrity and authenticity.

Step 1: Detection of Potential Collision.

Vessel sensors and radar systems continuously monitor the surroundings, identifying potential collision scenarios based on proximity, relative speed, and trajectory data.

Step 2: Secure Information Sharing via Blockchain.

Relevant collision data (vessel IDs, positions, speeds, and intended courses) are encrypted and broadcasted through the blockchain network.

Step 3: Consensus Mechanism.

Smart contracts validate collision data, ensuring their accuracy and reliability.

Step 4: Autonomous Collision Avoidance Strategy Generation.

Vessels autonomously generate collision avoidance strategies based on verified data, considering safe passing distances and maneuvering capabilities.

It should be noted that the collision avoidance process with blockchain-based decision-making closely resembles the conventional approach, with the addition of blockchain mechanisms in the communication phase. This integration significantly enhances the trustworthiness and security of communication channels. To facilitate more intuitive and effective communication, this paper introduces the concept of propagating collision avoidance path points. These serve as clear indicators of vessels’ intended courses, reducing the risk of misinterpretation.

4. Simulations and Experimental Results

4.1. Encounter Situation Setup

In this section, simulations based on the MATLAB (2022b) software platform were carried out to test the effectiveness of the path planning algorithm. First, the test multi-ship encounter scenario including four ships was designed. Since ship maneuverability is not the main content of this study, it is assumed that all involved ships have the same maneuverability. The initial status includes the positions, speeds, and course angles of the involved ships, which are listed in

Table 1. Initial multi-ship encounter situation.

Ship	Ship 1	Ship 2	Ship 3	Ship 4
Initial Position (nm)	[0, −5.00]	[3.83, 3.21]	[3.85, −2.22]	[−2.55, 2.55]
Initial Speed (kn)	18	18	16	13
Initial Course (deg)	0	230	300	135
Decision Cycle Set (s)	3	4	5	5
Detection Range Set (nm)	5	5	5	5
Shortest Initial DCPA (m)	0	0	0	0
Shortest Initial TCPA (s)	1250	1250	1250	1250

. All the initial state sets of ships remain the same from simulation scenario 1 to simulation scenario 2. Figure 8 illustrates the initial status of scenarios 1 and 2. In the figure, the color bars on the right side represent the color of the ship’s position at different moments, thus showing more clearly the position of different ships at the same moment. With the above settings, if the ships do not take proper CA measures, they will collide at the middle point after 1250 s. All of the simulation results are presented as time-dependent motion sequences. The algorithm was coded and simulated in MATLAB.

Although it is relatively rare to have four ships in a conventional ship encounter scenario, a rather complex ship CA case was set up in this paper to verify the performance of the algorithm. In the predefined scenario shown in Figure 9, the risk of collision exists between any two ships among the four ships, and the TCPA is the same. In this way, each ship must consider all other ships at the same time when making CA decisions. According to the BTC ship CA algorithm proposed in this paper, the CA decision made by each ship will be fully communicated through the blockchain to achieve the CA intention. However, considering the bandwidth of maritime satellites or e-navigation systems, the communication proposed in this paper is limited to the ship’s CA intent.

Ship 1 and ship 2 constitute a head-on encounter situation. Ship 1 and ship 2 constitute an encounter situation of three ships crossing with ship 3 and ship 4, respectively. For example, ship 1 needs to avoid ship 3 and ship 4 as a stand-on ship, i.e., it needs to pass as far from the bows of ships 3 and 4 as possible, so it can use the method of keeping the state or turning left, but at the same time, due to the head-on scenario with ship 2, it needs to turn right. In the following subsections, this scenario setting will be used to verify the algorithm’s performance when it is applied to ships with different compliance with the COLREGs. The effectiveness of the inference of TS’s CAL will also be verified under the same scenario setting.

4.2. Case 1: Collision Avoidance Experiment of Four Ships under Normal Navigation

In the first scenario, all ships are assumed to adopt a cooperative approach and try to complete their ship CA decisions under the guidance of COLREGs. The time cross-section of the whole CA process is shown in Figure 10.

It can be seen from Figure 10 that in the subfigure t = 500 s, all ships have completed the communication of the ship CA’s intention and formed the behavioral trend of ship 1 turning left, ship 2 keeping going, and ship 3 and ship 4 turning right to different degrees. Here, ship 1 is a stand-on ship relative to ships 3 and 4. According to COLREGs, ship 3 and ship 4 should turn right and pass by the stern of ship 1. While ship 1 turns left, it will contribute more to form the scenario that ship 3 and ship 4 pass by its stern. In subfigure t = 1000 s, all four ships continue their sailing behavior from the previous stage. However, due to the specificity of the relative positions of ship 1 and ship 4, ship 1 passes from the stern of ship 4. This behavior is in conflict with the spirit of COLREGs but is obviously more suitable for the current scenario. In the subfigure t = 1500 s, all ships have completed ship CA and started to gradually resume the original heading of their own ships. The time of broadcasting is also illustrated in Figure 10 (subfigures t = 100 s and t = 500 s).

In the end, all ships successfully completed ship CA, especially ship 2, after communicating with other ships, without taking any measures to keep the original navigation under the double decision pressure of heading on and crossing. In this case, the four ships achieve a behavior similar to a “centralized” CA decision through CA communication, which can achieve better than traditional distributed CA decisions in terms of economy and safety.

4.3. Case 2: Collision Avoidance Experiment in Which a Ship Misunderstands

Case 1 demonstrates an ideal situation in which mutual understanding and cooperation can be fully achieved. However, the BTC method is only a communication method that promotes mutual trust and does not increase the actual understanding of the ship’s pilot. Therefore, if the communication fails, the process of communicating the ship’s intention to avoid collision may be experienced several times during the CA process. In case 2, ship 2 is set up as the “black sheep” that does not understand the other ships.

In the case 2 scenario (Figure 11), in subfigure t = 500, ship 2 has already started its right turn. In fact, ship 2 is a give-way ship with respect to ship 3 and ship 4, where ship 2 meets ship 3 at a small angle and ship 2 meets ship 4 at a large angle. Therefore, the right-turn decision made by ship 2 in subfigure t = 500 s is consistent with the COLREGs if there is no communication of CA intent. However, this causes confusion in the decisions of the other three ships, because if the situation in case 1 is followed, the behavior of ship 2 adds to the confusion instead. However, since an emergency CA decision scheme based on the ship domain is set up in this algorithm (Section 3.2), a randomized CA decision can be implemented by the path-planning algorithm, including APF between ships, when an abnormal decision is detected. Therefore, it can be seen that ship 1, ship 3, and ship 4 perform slightly more complex CA paths in subfigure t = 1000 s and subfigure t = 1500 s than in case 1. Since only one ship did not understand the CA communication results, the impact on the scenario was always limited, and ships 1, 3, and 4 finally completed the ship CA according to the initial plan and left the encounter area safely. The time of broadcasting is also illustrated in Figure 9 (subfigures t = 100 s, t = 500 s, and t = 1500 s). It can be seen that, due to the uncoordinated CA maneuver of S2, S1 had to take additional action at t = 280 s, and S1 also broadcasted the new CAB after she made the decision.

It can be seen that, although there was a problem in understanding the ship’s intention of CA in this case, successful CA was still achieved in the end. In future maritime entanglements, any similar loss in safety and economy of other encounter ships caused by one ship not acting according to the communication can be verified using the stored blockchain.

5. Conclusions

This paper proposed a trusted communication method for ship CA decisions based on blockchain technology and then a distributed multi-ship CA decision support scheme based on blockchain technology. The results provide an effective solution for communicating CA logic in encounter scenarios to ensure secure and efficient communication during short-term, one-time ship encryption. As a result, they can help select better (more trustworthy) nodes to maintain critical knowledge during ship CA and to judge trust in unknown members. In the final case studies, it can be seen that all encounter ships actually achieve a “centralized” CA decision-like behavior through CA communication, which can be economically better and safer than the traditional distributed CA decision.

The blockchain-based collision avoidance method proposed in this paper used blockchain to record the dynamic subjective trust perception of each encountered ship towards each other without assuming a central database that everyone acknowledges. Through block generation and dissemination, each encountered ship can effectively perceive and rank the credibility of participants in the broadcast network. As a result, individual ships can adopt appropriate strategies to deal with CA practices. Consequently, the socio-technical system of social attributes is strengthened to achieve self-governance in the encountered scenario. Another issue that needs to be clarified is that this paper mainly considers the problem of ship collision avoidance based on blockchain communication, so the main contribution of the paper lies in how to make effective collision avoidance communication rather than decision-making. In fact, collision avoidance decision-making and trusted communication are two equally important parts of the collision avoidance process, where the content of decision-making is communicated through communication. Therefore, the case study section also adopts this perspective by considering only whether safety can still be ensured under successful and incomplete communication. The results show that the approach in this paper is effective.

To further improve the proposed method, further research can be conducted to address the following limitations: (1) the proposed scheme does not consider the unstable network connections between randomly assembled nodes, where propagation may fail to reach and cover a majority of nodes; (2) the generated blocks may not be synchronized across the entire network; (3) the majority of the investigated multi-ship CA communication system must be non-malicious entities, although it should largely reflect the reality of the shipping industry.