Towards Hazard Analysis Result Verification for Autonomous Ships: A Formal Verification Method Based on Timed Automata

Abstract

Enhancing the safety standards of autonomous ships is a shared objective of all stakeholders involved in the maritime industry. Since the existing hazard analysis work for autonomous ships often exhibits a degree of subjectivity, in the absence of data support, the verification of hazard analysis results has become increasingly challenging. In this study, a formal verification method in a risk-based assessment framework is proposed to verify the hazard analysis results for autonomous ships. To satisfy the characteristics of high time sensitivity, time automata are adopted as a formal language while model checking based on the formal verification tool UPPAAL is used to complete the automatic verification of the liveness of system modeling and correctness of hazard analysis results derived from extended System-Theoretic Process Analysis (STPA) by traversing the finite state space of the system. The effectiveness of the proposed method is demonstrated through a case study involving a remotely controlled ship. The results indicate that the timed automata network model for remotely controlled ships, based on the control structure, has no deadlocks and operates correctly, which demonstrates its practicability and effectiveness. By leveraging the verification of risk analysis results based on model checking, the framework enhances the precision and traceability of these inputs into RBAT. The results disclose the significance of the collaborative work between safety and system engineering in the development of autonomous systems under the definition of human–computer interaction mode transformation. These findings also hold reference value for other intelligent systems with potential hazards.

1. Introduction

In recent years, digitalization and autonomy have become significant topics of discussion within the maritime industry, and they currently exhibit unstoppable rapid growth trends. In the context of new developmental paradigms in shipping safety and global maritime governance, autonomous ships, which are grounded in digitalization and aim at achieving autonomy, have become symbols of the industry’s digital transformation and revolutionary innovation. These vessels are transforming traditional ship design and operations [1,2,3,4]. Despite their advantages in enhancing operational efficiency, reducing human involvement in hazardous and repetitive tasks, and promoting a green shipping infrastructure, there remains a prevalent concern within the industry regarding whether autonomous ships can maintain safety levels comparable to conventional ships.

From the operational perspective, some new operational states and state transition paths of autonomous ships are identified and highlighted in the Draft International Code of Safety for Maritime Autonomous Surface Ships (MASS Code—MSC 109/WP.8) [5]. In order to prevent deviations from the operational envelope (OE), specifically, to address hazards associated with the intended OE and to ensure that autonomous ships can perform various tasks effectively and reliably, the preliminary framework of risk assessment and regulation for autonomous ships has been generated. Risk assessment should include a comprehensive description of the autonomous and remote-control function’s utilization, effectiveness, and reliability by performing a thorough hazard analysis, conducting a mitigation analysis, evaluating the identified risks, and implementing effective risk control measures.

A growing number of studies on the hazard analysis and risk influence factor (RIF) identification of autonomous ships have been published, where the literature and expert scoring are widely used data sources in these research studies [6,7,8]. Due to the variations in researchers’ academic backgrounds and experiences, the outputs of their research focus and RIF identification results are different. In the absence of sufficient autonomous ship navigation data and public accidents, the process of hazard analysis and RIF identification is inevitably influenced by subjectivity. The accuracy of hazard analysis and the priority of RIF have not been addressed. To reduce the influence of subjectivity on risk assessment, it is necessary to verify the conclusions drawn from hazard analysis and RIF identification, thereby improving the accuracy and reliability of risk assessment. Furthermore, verification can find the shortcomings and mistakes in the process of risk assessment and provide feedback for the continuous improvement in risk assessment methods. Although the current research field has achieved certain progress in the area of autonomous ship hazard analysis, so far, the relevant literature and empirical research have failed to demonstrate that the existing results of hazard analysis have been verified.

For this purpose, this study endeavors to pioneer a novel approach to ensure a more objective and efficient hazard analysis process and to produce more reliable hazard analysis results. Through exhaustively searching the system state space, the correctness of the hazard analysis process and results can be verified from a structural point of view. Additionally, given that autonomous ships are large real-time embedded systems with stringent safety requirements, they must not only maintain high safety characteristics but also exercise precise control over time constraints. Timed automata constitute a theoretical framework for the modeling and verification of real-time systems [9,10], which can accurately describe time constraints, effectively handle concurrent behaviors, and support the automated verification process. Therefore, a formal verification approach based on timed automata is proposed to extend the process of modeling, reducing, and verifying autonomous ships. This extended process establishes a timed automata network model through rigorous semantics. The available UPPAAL model checker is used to automatically traverse the finite state space of the system model, checking the satisfaction relation between the semantic model and its property abstractions, thereby filling the gap of automatic verification of hazard analysis results.

As a result, time automata are adopted as a formal language to model the behavior of the system components, while model checking based on UPPAAL is used to verify the unsafe control actions (UCAs) obtained from STPA through the system liveness and reachability of semantics. Compared to existing hazard analysis work, this new method makes it possible to perform automatic verification of the results of hazard analysis and reduces the need for human intervention and supervision simultaneously. Risk-Based Assessment Tool (RBAT) [11], as recommended in the latest draft MASS Code, is designed to support risk assessment in the absence of statistical data and enables the evaluation of safety equivalence in the introduction of technologies with autonomous functionalities. This approach aligns with this principle by systematically identifying unsafe conditions associated with control actions and causal factors that can trigger unsafe conditions in autonomous ship operations [12,13]. Additionally, our study addresses key challenges associated with MASS, in line with the objectives of RBAT, by refining hazard identification and improving risk differentiation across scenarios. Even though the application in this study is focused on autonomous ships, it is expected that the methodology will be relevant to other intelligent systems with inherent potential hazards. The contributions and originalities of this study are evident from four perspectives.

• To propose a three-phase methodological framework to verify hazard analysis results and support risk assessment for autonomous ships.
• To provide a verification technology that satisfies the characteristics of high time sensitivity by introducing model checking based on time automata.
• To model formalism based on the UPPAAL model checker that can automatically verify the results of hazard analysis.
• The implementation of this study achieves the closed-loop hazard analysis of STPA in the risk-based assessment framework. Results disclose the significance of the collaborative work between safety and system engineering in the development of autonomous systems under the definition of human–computer interaction mode transformation.

The remainder of this paper is organized as follows. Section 2 leads through the relevant literature. Section 3 presents the proposed methodological framework, which introduces model checking based on time automata into the hazard analysis process to facilitate the automatic verification of compliance with the property specifications of the constructed system model and hazard analysis results. Section 4 presents an illustrative example of a remotely controlled ship to demonstrate the effectiveness of the model. Section 5 includes the discussion. Section 6 presents the conclusions drawn from this study.

2. Literature Review

Compared to the rapid progress in autonomous technologies, a consistent hazard analysis conclusion in the field of autonomous ships failed to be generated. In order to promote the process in this area, RIF identification is presented from multiple perspectives according to researchers’ respective academic backgrounds. Due to the varying concerns across professional fields, there is notable heterogeneity in RIF identification results. In the field of hazard analysis and risk identification of autonomous ships, Tao et al. [8] utilized a systematic approach to conduct a bibliometric analysis of the autonomous ship studies from January 2010 to November 2022. There are 62 papers retained for a detailed discussion through a manual screening process in terms of the research methods, research subjects, and scope of application. This study retrieves papers additionally from December 2022 to December 2024, yielding 356 results using the same keywords, and 41 papers are retained through the aforementioned screening. Out of 103 papers, 32 representative papers clearly presented the number of identified risk-influencing factors (RIFs) (Appendix A), and the number of RIFs (including the results presented in the form of cases) is visualized, as shown in Figure 1.

Fan et al. [14] identified 55 RIFs affecting remote-controlled ships based on the selected literature and on experts’ judgment; similarly, the description of hazards is presented from the same data source [15,16]. Ramos et al. [17] pointed out that a set of performance-influencing factors, which served to either enhance or degrade human performance relative to a baseline, can be obtained from the discussion on the factors from the relevant literature in the shipping industry. Zhang et al. [18] identified 50 RIFs related to shipping safety according to the literature. As the historical data that could be used were limited, expert knowledge was utilized to predict the shipping safety risk probability based on the Bayesian network. Chang et al. [19] identified the main operational hazards of autonomous ships based on a thorough literature review and further ranked them using the Likert scale by a group of experts. Inspired by the literature, expert knowledge and expert scoring have been widely used in hazard analysis research studies of autonomous ships [20,21,22]. However, the expert’s academic background, years of experience, and education can affect the accuracy of the results. There still remains a gap in the study of hazard analysis as insights from multiple perspectives are solely obtained using expert questionnaires.

Bolbot et al. [23] pointed out that considerable uncertainty was observed during expert scoring, and more detailed analyses are required to verify these cost results. Some studies have addressed automatic verification in other domains to reduce the dependence on subjectivity. A hazard identification method based on hierarchical Colored Petri Nets (CPNs) can achieve higher comprehensiveness and effectiveness in hazard identification for complex systems, reduce dependence on expert experience, and standardize the hazard identification process [24,25]. In order to reduce the influence of subjectivity, some automation methods are applied in combination with System-Theoretic Process Analysis (STPA). Yan et al. [26] proposed an automated accident causal scenario identification method for Fully Automatic Operation (FAO) systems based on STPA, which systematically identifies and analyzes potential accident causal scenarios within FAO systems. Causal scenario search rules have been developed to ensure the automatic identification of accident causal scenarios. This method mitigates the subjectivity and inconsistency inherent to manual analysis, thereby enhancing the efficiency and accuracy of accident causal scenario identification. Zhu et al. [27] integrated System-Theoretic Accident Modeling and Process (STAMP) with Control Logical Petri Net (CLPN) to obtain a comprehensive framework for eliciting component-interaction-related safety requirements, particularly focusing on interactions within the control process. This framework offers a standardized and systematic approach for safety requirement elicitation in complex systems, such as automotive systems and train control systems. Inspired by the above, the research needs to focus on the automation and standardization of the hazard analysis approach across the maritime community.

In order to identify or quantify risk factors, researchers sometimes use traditional ship accident reports. Valdez Banda et al. [28] created the existing frameworks for autonomous ship risk analysis by utilizing accident statistics in the European maritime context. Hwang and Youn [29] developed a methodology for the systematic verification of autonomous ship collision avoidance systems by analyzing collision risk situations extracted from the AIS data. Aiding to achieve the human-centered risk analysis for autonomous ships, Fan et al. [30] extracted the frequency and impact of RIFs from historical accident data into a graph-based model. The accident data were obtained from the Marine Accident Investigation Branch (MAIB), the Transportation Safety Board of Canada (TSB), and the Global Integrated Shipping Information System (GISIS). However, no accident data of autonomous ships has been made public so far, and they may not always conform with the actual situation as the traditional ship accident data are transformed into accident data that match autonomous ships [31]. Therefore, a novel approach should be urgently deployed to verify the results of the hazard analysis of autonomous ships.

Currently, autonomous ships are still in the stages of design, testing, and validation. There has not been any accident with autonomous ships disclosed so far; thus, there is a lack of statistical data for risk modeling. Accident information and monitoring data from conventional ships are difficult to directly apply to autonomous ships, which is one of the main challenges in autonomous ship safety and risk research. On the other hand, the introduction of complex software and algorithms, along with the changes in human–system role allocation, has altered the human–machine interaction patterns, thereby changing the composition of risks in autonomous ships. New risks are more related to software control and human–machine interactions, making traditional methods focused on hardware failure analysis less effective. Against this backdrop, a structured approach to risk assessment that goes beyond traditional hardware failure analysis is essential to deepen the understanding of autonomous ship safety. Specifically, performing hazard analysis in conjunction with evaluating the severity of worst-case outcomes from unexpected events and the effectiveness of mitigation measures aimed at loss prevention offers a more robust framework for assessing the safety of autonomous ships.

Although System-Theoretic Process Analysis (STPA) is a recommended hazard analysis method in the draft MASS Code, current research and practice show that the hazard analysis work for autonomous ships has not yet developed an effective verification mechanism to ensure the accuracy and reliability of the analysis results. Moreover, based on the literature review, the existing hazard analysis work for autonomous ships often exhibits a degree of subjectivity, which can result in obvious limitations of manual verification. The subjective judgments of experts may further introduce biases, and the manual verification process is time-consuming and costly, making it difficult to adapt to the reality of the rapid development and increasing complexity of autonomous ships. Therefore, to ensure a more scientific and rigorous hazard analysis process and generate more objective and reliable hazard analysis results, the foremost problem is that it is necessary to develop a verification method for hazard analysis results applicable to autonomous ships.

Verification technology mostly focuses on hardware acceleration, dynamic simulation, and virtual prototype platforms; however, they are difficult to apply directly to autonomous ships. To deal with the complexity resulting from the large number of functionalities under consideration, formal methods have been proven to be more effective means [32,33]. Formal methods refer to software and system development approaches that are based on strict mathematical foundations, supporting activities such as the specification, design, verification, and evolution of software and systems, including model-oriented formal methods and property-oriented formal methods. Incorporating them into the hazard analysis process can be regarded as a way to address this challenge. Johansen et al. [33] systematically tested and verified the performance of autonomous ship control systems under different environmental conditions by using a formal verification method based on temporal logic and Gaussian processes. Wang et al. [34] proposed a verification approach by using the NuSMV to verify the results of STPA. The proposed method based on model checking can automatically evaluate whether the IMA model meets safety requirements, and the drawn conclusions have been proven to be more accurate and complete than those obtained with traditional methods.

Model checking emerged as a popular automated formal verification technique [35] that is used to verify critical properties such as security [36], fairness [37], and reachability [32]. The core of model checking is the traversal strategy and algorithm for the finite state space, that is, through an explicit or implicit exhaustive search of all reachable states and behaviors in a given system or model. The automated verification of hazard analysis results can be achieved through the verification of safety, liveness, and reachability properties [38]. Therefore, the formal verification method based on model checking can effectively fill the knowledge gap. At present, although the technology has not been widely used in maritime research, especially for autonomous ships, its potential value and application prospects cannot be ignored.

3. Methodology

3.1. STPA-Based Analysis Method That Synthesizes Safety and Security (STPA-SynSS)

STPA is a novel hazard analysis tool based on STAMP, and it can be used at any stage of the system lifecycle to ensure safety by enforcing constraints on system behavior. According to Leveson [39,40], who developed this method, system safety is considered an emergent property of the system, controlled by imposing constraints on the behavior of individual components and their interactions. In this approach, system safety is preserved or strengthened by applying safety constraints to the behavior of components and their interactions. Once safety constraints are met, system safety can be ensured. Compared to traditional hazard analysis tools, STPA shifts its focus from preventing failures or malfunctions to constraining unsafe control actions in the system.

Existing research indicates that STPA has gained popularity and has become one of the most promising and forward-looking hazard analysis methods currently applicable to autonomous ships [8,28,41,42,43]. However, compared to conventional ships, autonomous ships, as representatives of complex, safety-critical cyber–physical systems (CPSs), exhibit significantly increased interactive complexity, dynamic complexity, decomposition complexity, and nonlinear complexity. The dynamic shifts in autonomy levels and changes in ship control modalities have triggered new safety requirements. Where cybersecurity threats and intentional disruptions can pose significant risks, their safety and security are receiving considerable attention in the industry.

Consequently, in our preliminary research [44], a new STPA-based analysis method was proposed that synthesizes safety and security (STPA-SynSS) to address the interdependencies between safety and security, thereby reducing the number of iterations that could be triggered by conflicts in requirements within parallel approaches. Relative to the original STPA method, STPA-SynSS encompasses the full hazard analysis process and introduces six enhancements, focusing on key issues for preventing system losses in aspects of system design that may cause vulnerability and unacceptable losses.

Although STPA-SynSS has been somewhat validated in terms of feasibility and effectiveness [45,46,47], its modeling and analysis still rely largely on manual deduction, and the accuracy and completeness of the hazard analysis results are greatly reliant on the experience and skills of the analysts. Therefore, verifying the correctness of hazard analysis results is crucial, and the challenges associated with the rationality of outputs from STPA and its expanded methods must be overcome.

3.2. Model Checking Based on Timed Automata

In formal methods, model checking is an automated verification technique that involves automatically traversing the finite state space of the system model under verification to check if the system’s behavior possesses the anticipated properties [48,49]. In complex transition systems, it can quickly produce testing results and identify and correct minor errors. The core of model checking is the traversal strategies and algorithms over a finite state space, involving an explicit or implicit exhaustive search of all reachable states and behaviors reflected in the given system or model. The model-checking method can generally be divided into the following three basic steps.

• Modeling: Initially, a formalized description method is chosen to transform the actual system to be verified into a format compatible with model-checking tools. Typically, finite state models, such as transition systems, finite automata, and Petri Nets, are used for modeling the system, resulting in system model M. During the modeling process, due to limitations in verification time and computer memory, abstraction techniques are necessary to simplify irrelevant or unimportant details to avoid state explosion.
• Specification: Prior to verification, the properties that the system must possess need to be described, usually expressed through temporal logic formulas, leading to property specifications φ, such as system safety and system liveness.
• Verification: A model-checking algorithm (tool) is developed that uses an exhaustive search of the state space for the formal verification of systems. Inputs for the algorithm consist of the model M of the system to be verified and the property specification φ to be checked. Upon the completion of verification, if no states are found that violate the property specification, this signifies that system model M complies with property specification φ. If system model M does not meet property specification φ, the model checking algorithm outputs a counterexample path demonstrating the system behavior that fails to meet the specification, thus clarifying why M fails to satisfy φ.

The model-checking algorithm primarily operates by traversing the state space to verify whether the property specifications are met within the system model. Given that autonomous ships are large-scale, real-time embedded systems with significant safety demands, they must uphold stringent safety features and precisely manage time constraints. This means preventing the system from acting when time constraints are not met and ensuring responses within specific time frames. Therefore, to better describe the time constraints of the system and to address the objective needs for system safety characteristics of autonomous ships, timed automata are introduced as the most widely used in real-time system model checking in this study.

Timed automata are denoted by a six-tuple $〈Loc,l_0,\Sigma ,X,I,E〉$, and the relevant parameters are as follows:

• $Loc=\left\{l_0,l_1,l_2,\dots \right\}$ is a finite set of locations.
• $l_0\in Loc$ is the initial location.
• $\Sigma =\left\{a,b,\dots \right\}$ is a finite set of labels.
• $X=\left\{x_1,x_2,\dots \right\}$ is a finite set of clocks, with values being non-negative real numbers ${ℝ}^{+}$. For all clocks $x$ in $X$, the rate of time passage is the same.
• $I:Loc\to C(X)$ is a mapping from locations to clock constraints, specifying a clock constraint from $C(X)$ for each location $l$ in $Loc$ as the invariant of location $l$, known as the location invariant. $C(X)$ is a set of clock constraints $\phi$ defined on $X$, with each clock constraint $\phi$ being constructed using the BNF syntax as $\phi ::=x\prec c|c\prec x|{\phi }_1\wedge {\phi }_2|\mathrm{true}$, where $\prec$ means satisfying $<$ or $\le$, and $c$ denotes a non-negative real number.
• $E\subseteq Loc\times \Sigma \times C(X)\times 2^X\times Loc$ is a set of transitions, where the quintuple $〈l,a,\phi ,\lambda ,l^{\prime }〉\in E$ represents a transition from location $l$ to location $l^{\prime }$ labeled $a$, which must satisfy the clock constraint $\phi$; $\lambda$ represents the set of all clocks that are reset when the transition occurs, and $\lambda \subseteq X$.

Autonomous ships, being complex, large-scale, real-time embedded systems with high safety demands, must engage in real-time interactions with Shore Control Center (SCC) and other shore-based units, incorporating multiple subsystems that necessitate mutual communication and synchronized interwoven functioning. To realistically portray the behavior of autonomous ships, the addition of parallel combinations and constraints on single-timed automata is required [50]. This involves utilizing a network of timed automata to convert and delineate the exchange of information between multiple subsystems into interactions among the member automata.

Within timed automata, every timed automaton $T_A^i(1\le i\le n)$ is considered a process. Communication among these processes is facilitated through channels or shared (global) variables. Synchronous communication is established via a handshake mechanism, and asynchronous communication is conducted using shared (global) variables. The formal definition of a timed automata network is as follows.

$T_{A1}=〈Lo{c}_1,l_1^0,{\Sigma }_1,X_1,I_1,E_1〉$ and $T_{A2}=〈Lo{c}_2,l_2^0,{\Sigma }_2,X_2,I_2,E_2〉$ are assumed to be two-timed automata with the disjoint clock sets $X_1$ and $X_2$, denoted as $X_1\cap X_2=\varnothing$. Consequently, the timed automata represent the parallel combination of $T_{A1}$ and $T_{A2}$, i.e.,$T_{A1}\parallel T_{A2}=〈Lo{c}_1\times Lo{c}_2,l_1^0\times l_2^0,{\Sigma }_1\cup {\Sigma }_2,X_1\cup X_2,I,E〉$, where $I\left(l_1,l_2\right)=I_1\left(l_1\right)\wedge I_2\left(l_2\right)$.

In the timed automata network, a location is a pair of positions where the elements of the pair correspond to the relevant quantities of the member automata. The location invariant is the conjunction of the location invariants of each member automata. Transitions of the same effect in each automata form a single transition in a parallel composition, where the source position of the transition is a combination of the transition source positions of the member automata. Similarly, the target position of the transition is also a combination of the transition target positions of the member automata.

3.3. The Proposed Method to Automatically Verify the Results of Hazard Analysis

Although the feasibility and effectiveness of STPA and its extended methods have been confirmed, the analysis process still heavily relies on the experience of the analysts, which can impact the completeness and objectivity of the hazard analysis results to some extent. Additionally, autonomous ships that are still under development and testing face substantial uncertainty in their system structures. The absence of adequate accident data and expert experience complicates the validation of their hazard analysis results.

To address the limitations mentioned, the lack of statistical data for establishing risk models in RBAT, and the questionable feasibility of applying classic risk assessment methods based on risk probability and consequence functions, the model checking from formal methods was introduced into the analytical process of the STPA extended method—STPA-SynSS, proposing a formal verification approach based on timed automata in risk-based assessment framework, as shown in Figure 2. Building upon the foundational hazard analysis conducted utilizing the STPA-SynSS framework, the method proposed herein establishes a network of timed automata models delineated with rigorous semantic precision. It employs model-checking tools alongside dynamically generated Backus–Naur Form (BNF) statements to facilitate the automatic verification of compliance with property specifications of the constructed system model, thereby enabling the formal verification of both the system’s modeling liveness and the correctness of the hazard analysis outcomes. Serving as a valuable addition to STPA and its extensions, model checking contributes to minimizing the subjective influences of human analysts during the hazard analysis process [51] and robustly confirms the critical role of safety constraints in hazard mitigation.

One key benefit of model checking is its fully automated verification process, which requires the use of corresponding model-checking tools for implementation. Appendix B presents an organized summary of the mainstream currently available model-checking tools. UPPAAL, a model-checking tool based on timed automata, utilizes a set of timed automata equipped with integer clock variables for modeling and verifying real-time systems. It conducts constraint-solving and functional testing by inputting models of timed automata and their to-be-verified properties, thereby facilitating the model checking of real-time systems. As an effective instrument for the verification of timed automata modeling, UPPAAL has achieved broad application across multiple domains, including modeling and verifying real-time systems, communication protocols, and controller networks [52,53,54]. In this study, UPPAAL is applied for the first time to the formal modeling and verification for autonomous ships to verify whether the system under examination meets the given property specifications, that is, to validate the set of properties along all reachable state paths.

UPPAAL utilizes a streamlined version of Timed Computation Tree Logic (TCTL) to characterize the properties of timed automata. In line with TCTL, its property query language comprises both path and state formulas, where the significance of logical connectives remains consistent. State formulas describe the various states of the model, while path formulas quantify the paths or trajectories of the model. Path formulas are divided into three categories: reachability, safety, and liveness. However, current research on the verification of real-time systems mainly concentrates on safety and liveness. The verification of system liveness involves assessing whether the system ultimately reaches a desired state using a cycle detection algorithm. This method, while consuming computational resources, provides a relatively simple verification approach. Conversely, safety verification checks whether the system attains any unsafe states during operation, achievable through a reachability analysis that involves traversing the state space of timed automata.

The verifier in UPPAAL employs a formal specification language based on the BNF syntax to delineate the properties awaiting verification with the following specific syntactic expressions:

$$\mathrm{Prop}::=\mathrm{A}\left[\right]\mathrm{p}\left|\mathrm{E}<>\mathrm{p}\right|\mathrm{E}\left[\right]\mathrm{p}\left|\mathrm{A}<>\mathrm{p}\right|\mathrm{p}\to \mathrm{q}$$

(1)

$$\mathrm{p}::=\mathrm{a}|\neg \mathrm{p}|\left(\mathrm{p}\right)|\mathrm{p}\wedge \mathrm{q}|\mathrm{q}\wedge \mathrm{p}|\mathrm{p}\to \mathrm{q}$$

(2)

Within this context, A and E serve as path quantifiers, with A representing ‘for all computation paths’, and E indicating ‘for some computation paths (indicating the existence of at least one path)’; [] and <> are utilized to denote states on quantified paths, with [] indicating that all states on the path fulfill the specified property p, and <> suggesting that at least one state on the path meets property p; p represents an expression for a specific property within the system (a logical expression awaiting verification); a denotes a variable, an integer variable expression, a time variable constraint, or a position within a timed automaton. Consequently, the explicit meanings are presented in

Table 1. Meaning of syntax in BNF and its equivalent properties.

BNF Syntax	Meaning	Equivalent Property
E<>p (possibly)	A path exists where property p is satisfied at a particular state along the path.
E[]p (invariantly)	A path exists where property p is satisfied at every state along the path.
A<>p (potentially always)	Across all paths, property p is satisfied at least once on each path.	¬E[]¬p
A[]p (eventually)	Across all paths, property p is satisfied at every state on each path.	¬E<>¬p
$\mathrm{p}\to \mathrm{q}$ (lead to)	If property p holds, it enables the satisfaction of property q.	A<>(p imply A<>q)

, with the associated syntactic diagram displayed in Figure 3. Upon the completion of the construction of the timed automaton model for the system under verification, the to-be-verified properties can be inputted into the UPPAAL verifier using the BNF statements, thus automatically commencing the verification process.

As illustrated in Figure 2, model checking comprises three primary steps: modeling, specification, and verification. Functional requirements from step 1 of STPA-SynSS and control structures from step 2 of STPA-SynSS are utilized to build the network model of timed automata, representing system modeling. Upon confirming the responsibilities of model elements, the properties of the system must be clarified using UCAs identified in step 3 of STPA-SynSS, as well as information from step 1, such as system boundaries, objectives, unacceptable losses/accidents/events, system-level hazards, and safety constraints. These properties are articulated using the BNF statements, which then generate the property specifications of the system awaiting verification, termed specification. In the final stage, UPPAAL is employed to perform an exhaustive exploration of the system’s finite state space to assess the alignment between the system’s semantic model and its property specifications, thus ensuring the liveness of system modeling and the precision of the hazard analysis outcomes, referred to as verification.

It is crucial to highlight that the key to verifying the accuracy of hazard analysis results generated by STPA-SynSS lies in the verification of the identification result of UCAs. The accurate identification of UCAs within the system is essential for generating subsequent loss scenarios and developing effective hazard elimination or mitigation strategies. If the verification fails, a reiteration of UCA identification is required. Additionally, in constructing the UPPAAL model of timed automata, templates and channels correspond to model elements and control actions/feedback in the control structure. Simultaneously, the system’s guards, updates, clocks, and synchronization actions are incorporated into the simulation model.

4. Illustrative Case Study

In our previous study [44], a hazard analysis was conducted on the collision avoidance scenario for a remotely controlled ship (with seafarers onboard) using STPA-SynSS. We defined the purpose of the analysis, modeled the control structure, identified UCAs, and generated relevant loss scenarios. To demonstrate the continuity of our research, the application of the proposed method was executed on this same collision avoidance scenario as an illustrative case study, aiming to further validate the method’s applicability. Detailed results from the three phases are discussed in the following subsections.

4.1. Results from Phase 1 (Modeling)

In this case, the system boundary is defined as the safe navigation of a remotely controlled ship (with seafarers onboard) during the voyage, and the goal of the analysis is to support the introduction of autonomous ships while minimizing collision risk. In this step, six unacceptable losses and one unacceptable accident were defined.

In order to simplify the timed automata network model for remotely controlled ships (with seafarers onboard) and to emphasize the interactions between different timed automata, drawing on the functional requirements derived from step 1 of STPA-SynSS and the control structures developed in step 2 (as shown in Figure 4), the model elements were removed that have no practical impact on the collision avoidance scenario (considering only scenarios where both ownship and other ships are maneuverable), while simplifying and consolidating related control actions and feedback. Ultimately, a timed automata network model was established, known as $T_A=\mathrm{SCC}\parallel \mathrm{IBS}\parallel \mathrm{ANS}\parallel \mathrm{AEMC}\parallel \mathrm{Man}\_\mathrm{Control}\parallel \mathrm{Communication}\parallel \mathrm{Ship}\_\mathrm{motion}$, consisting of seven timed automata: SCC, Integrated Bridge System (IBS), Autonomous Navigation System (ANS), Autonomous Engine Monitoring and Control (AEMC) systems (including propulsion and steering systems, auxiliary engines, and other auxiliary machinery), manual control stations, communication devices (including AIS, GMDSS, VHF), and ship motion.

In modeling remotely controlled ships with UPPAAL (version 4.1.25), model elements and control behaviors/feedback identified in STPA-SynSS step 2 need to be mapped into UPPAAL as templates and channels, as indicated in

Table 2. Control actions/feedback based on functional control structure and corresponding UPPAAL channels.

ID	Description of Control Behaviors/Feedback	UPPAAL Channels
1/3	Shore-based operators at SCC fulfill the responsibility of monitoring vessel navigation and transmitting decisions to the ship via communication links to control and maneuver the vessel.	SCC_supervise SCC_cmd
2/4	Data sets such as vessel status information and environmental sensor data are transmitted to the SCC via communication links for purposes such as updating ship trajectories and making decisions, enabling SCC shore-based operators to supervise vessel navigation.	ship_data
5	In autonomous operating mode, the IBS provides the ANS with the necessary information, such as vessel status and environmental sensor data, for the decision-making of route planning and collision avoidance.	automode_run aotomode_stop ship_data
6	In autonomous operation mode, the decision information formulated by the ANS is fed back to the IBS, allowing the SCC and the Officer of the Watch (OOW) to supervise ship operations and the execution of actions.	automode_data
7/9/11/14	The operating parameters of the AEMC system are controlled based on commands from the SCC and the OOW, and the ship’s speed and course are managed.	mancontrol_cmd
8/10/12	All observed measurements from the engine room (including equipment and process state data) are received and fed back to the IBS for configuration and reconfiguration, simultaneously enabling the SCC and OOW to oversee the effectiveness of the actions implemented.	equipment_data
13	In autonomous operation mode, control the operating parameters of the AEMC system based on instructions from the ANS and manage the ship’s speed and course.	automode_cmd
15	Execute decisions, applying thrust and steering force to modify the ship’s speed and heading.	control_force
16/17/18	As the ship moves, it can be affected by wind, waves, and currents. The environmental sensor module uses sensors to assess the ship’s navigational and environmental status, and it also detects, tracks, and categorizes other ships and obstacles. The sensor data mentioned is relayed back to the IBS so that the SCC and OOW can oversee the ship’s navigational status, helping them make further decisions and adjustments as needed.	sensor_data
19/21/23/25	Using AIS and GMDSS, the ownship supplies other vessels with its navigational status and other essential information needed for collision avoidance.	send_data
20/22/24/26	Using AIS and GMDSS, the ownship receives navigational status information and other essential information needed for collision avoidance from other vessels.	receive_data
27	Take over control of the ship in necessary or emergency circumstances.	OOW_cmd
28	Data sets such as ship status information and environmental sensor readings are relayed to the manual control station, facilitating updates to ship trajectories and decision-making, thereby enabling the OOW to oversee navigation.	ship_data OOW_supervise
29/30	While on the navigational watch, the OOW uses VHF to communicate with other vessels and facilitate collision avoidance actions.	OOW_VHF_send OOW_VHF_receive

. The control structure is used to guide and track channel synchronization. Modeling is considered correct when the model encompasses all control actions/feedback, all states in the timed automata are accessible, timed automata synchronization is consistent, and there are no deadlocks in the model. The UPPAAL models for the SCC, IBS, ANS, and AEMC system, manual control stations, communication equipment, and ship motion timed automata are shown respectively in Figure 5, Figure 6, Figure 7, Figure 8, Figure 9, Figure 10 and Figure 11, while the network of timed automata they compose is displayed in Figure 12.

4.2. Results from Phase 2 (Specification)

During the specification phase, it is necessary to rigorously describe the properties that the target system must satisfy using the BNF syntax. This serves as an input for the exhaustive search of the state space with the UPPAAL verifier in stage 3, thus fulfilling the verification of property specifications.

Formal verification primarily focuses on assessing the model’s liveness and safety, where liveness indicates that “good” events (actions) will eventually occur, denoting properties that are not constantly active but are ultimately present in the system. Meeting liveness criteria demonstrates the correctness and completeness of the system modeling and promotes or accomplishes the non-safety characteristics needed for system functionality, thus affecting the system’s reliability. The verification of liveness entails checking that all the model states are eventually reached or reachable and verifying the operational correctness of the system, as indicated by the BNF statements provided in

Table 3. BNF statements of system liveness.

Verification Properties	BNF Statements
All states are reachable	A[] not deadlock
SCC operates normally	A<> SCC.Standby or SCC.SCC_supervise_mode or SCC.SCC_control_mode or SCC.OOW_control_mode or SCC.Autonomous_mode
IBS operates normally	A<> IBS.Standby or IBS.SCC_supervise_mode or IBS.SCC_control_mode or IBS.OOW_control_mode1 or IBS.OOW_control_mode2 or IBS.Autonomous_mode
AEMC system operates normally	A<> AEMC.Standby or AEMC.Report or AEMC.Receive_cmd or AEMC.Execution
ANS operates normally	A<> ANS.Standby or ANS.Autonomous_mode or ANS.Send_cmd
The manual control station operates normally	A<> Man_control.Standby or Man_control.OOW_supervise or Man_control.OOW_control_mode
The ownship correctly executes received commands and adjusts its course and speed	A<> Ship_motion.Standby or Ship_motion.Execution
The ownship establishes correct communication with other vessels via VHF, AIS, GMDSS	A<> Communication.Standby or Communication.VHF_info or Communication.AIS_GMDSS_info
In autonomous operation mode, the SCC and OOW only perform supervisory duties	A<> automode_judge==true imply SCC.Autonomous_mode and Man_control.OOW_supervise and not (SCC.SCC_control_mode and SCC.OOW_control_mode and IBS.SCC_control_mode and IBS.OOW_control_mode1 and IBS.OOW_control_mode2 and Man_control.OOW_control_mode)
In an emergency, the OOW takes over ship control and stops autonomous operation	A<> emergency_judge==true imply not (SCC.Autonomous_mode and IBS.Autonomous_mode and ANS.Autonomous_mode) and (Man_control.OOW_control_mode and SCC.OOW_control_mode and IBS. OOW_control_mode1 or IBS.OOW_control_mode2) and automode_judge==false

.

Safety denotes that “bad” events (actions) are never supposed to happen, embodying traits that should be persistently upheld by the system. For remotely controlled ships in the collision avoidance scenario, verifying safety entails assessing whether the system could achieve an unsafe state, chiefly by exploring the state space of the timed automata network to conduct a reachability analysis of UCAs identified by STPA-SynSS. The BNF statement “E<>UCA” signifies “a path exists such that a UCA occurs in some state on that path.” Consequently, verifying this statement reflects whether UCAs that might cause hazardous states will occur, thus validating the safety of the system, i.e., if “E<>UCA” is true, then the UCA will occur, and if not, it will not.

In conducting a hazard analysis for the collision avoidance scenario with remotely controlled ships, the interaction between the IBS and AEMC systems served as an example, and seven UCAs were identified (as shown in

Table 4. UCAs of IBS as controller.

Control Action	Not Providing Causes Hazard	Providing Causes Hazard	Too Early, Too Late, Out of Order Causes Hazard	Applied Too Long, Stopped Too Soon, Causes Hazard
Course and speed control	UCA-1: Course and speed control are not provided when the ownship is a give-way ship only if the risk of collision exists. UCA-2: Course and speed control are not provided when there is a close-quarters situation or immediate danger between ownship and the other ship.	UCA-3: Course and speed control are provided when the ownship is a stand-on ship only if the risk of collision exists.	UCA-4: Course and speed control are provided too late when the ownship is a give-way ship only if the risk of collision exists. UCA-5: Course and speed control are provided too late when there is a close-quarters situation or immediate danger between ownship and other ship.	UCA-6: Course and speed control are stopped too soon when the ownship is a give-way ship only if the risk of collision exists. UCA-7: Course and speed control are stopped too soon when there is a close-quarters situation or immediate danger between ownship and other ship.

). In this control loop, the IBS acted as the controller, and the AEMC system acted as the controlled entity, with control actions being course and speed control. The identified UCAs are mapped to the BNF statements, with the resulting property specifications displayed in

Table 5. BNF statements of system safety.

UCAs	Verification Properties	BNF Statements
UCA-1 UCA-2	1. Command was lost or not transmitted correctly.	E<> (SCC.SCC_control_mode imply not IBS.SCC_control_mode) or (SCC.Autonomous_mode imply not IBS.Autonomous_mode) or (Man_control.OOW_control_mode imply not (IBS.OOW_control_mode1 or IBS.OOW_control_mode2))
	2. Command was transmitted correctly but not executed correctly.	E<> (IBS.Mancontrol imply not AEMC.Receive_cmd) or (ANS.Send_cmd imply not AEMC.Receive_cmd)
	3. Command was transmitted and executed correctly, but the AEMC system did not respond correctly.	E<> AEMC.Receive_cmd imply not exection_cmd==true
	4. Command was transmitted and executed correctly, but the ship’s motion state did not change.	E<> (AEMC.Execution or exection_cmd==true) imply not Ship_motion.Execution
UCA-3	1. Command was not transmitted correctly.	E<> (SCC.SCC_control_mode imply not IBS.SCC_control_mode) or (SCC.Autonomous_mode imply not IBS.Autonomous_mode) or (Man_control.OOW_control_mode imply not (IBS.OOW_control_mode1 or IBS.OOW_control_mode2))
	2. Command was transmitted correctly but not executed correctly.	E<> (IBS.Mancontrol imply not AEMC.Receive_cmd) or (ANS.Send_cmd imply not AEMC.Receive_cmd)
	3. Command was transmitted and executed correctly, but the AEMC system did not respond correctly.	E<> AEMC.Receive_cmd imply not exection_cmd==true
UCA-4 UCA-5 UCA-6 UCA-7	1. Command was not transmitted correctly.	E<> (SCC.SCC_control_mode imply not IBS.SCC_control_mode) or (SCC.Autonomous_mode imply not IBS.Autonomous_mode) or (Man_control.OOW_control_mode imply not (IBS.OOW_control_mode1 or IBS.OOW_control_mode2))
	2. Command was transmitted correctly but not executed correctly.	E<> (IBS.Mancontrol imply not AEMC.Receive_cmd) or (ANS.Send_cmd imply not AEMC.Receive_cmd)
	3. Command was transmitted and executed correctly, but the AEMC system did not respond correctly.	E<> AEMC.Receive_cmd imply not exection_cmd==true
	4. Command was transmitted and executed correctly, but the adjustment of the ship’s motion state was incorrect.	E<> AEMC.Execution imply not Ship_motion.Execution

.

4.3. Results from Phase 3 (Verification)

Once the construction of the timed automata network model for remotely controlled ships is finished, it can be simulated using the UPPAAL simulator. This simulation allows for observing state transitions during system operation, simulating interactions between timed automata, and checking for syntax errors in the model to ensure completeness and consistency. The initial simulation state is depicted in Figure 13. The UPPAAL simulator uses a message sequence chart (MSC) to present state transition diagrams for process transitions between timed automata in a temporally constrained sequence, showing active locations during these transitions.

Figure 14 shows the message sequence chart where the SCC monitors, controls, and maneuvers the ship. In this mode, the autonomous operation based on the ANS decisions is deactivated, and the OOW at the manual control station is only responsible for overseeing navigation. Whenever necessary or in emergencies, the OOW can assume control of the ship. The message sequence chart for normal conditions is depicted in Figure 14a, and the one for triggered emergency states is depicted in Figure 14b.

Under the autonomous operation mode, remotely controlled ships continue to be supervised by SCC shore-based operators and the OOW. However, the IBS supplies the ANS with necessary data for route planning and collision avoidance, such as ship status and environmental sensor information. Commands from the ANS control the AEMC system to regulate the ship’s speed and course. The sequence chart for autonomous operation mode is displayed in Figure 15. Consistent with the SCC control mode, the OOW can assume control of the ship at any time in necessary or emergency situations. The message sequence chart for the normal state is shown in Figure 15a, and that for emergency conditions is shown in Figure 15b.

Following the modeling, specification, and simulation of the target system, the UPPAAL verifier is used to perform an exhaustive search of the state space, thereby accomplishing the verification of the system’s liveness and safety. Results from the model simulation and system liveness verification reveal that all 10 property specifications listed in Table 3 were successfully verified (results displayed in Figure 16). This confirms that the system has no deadlocks and that all the subsystems or components function properly. Every system function is executed correctly, thus successfully verifying the accuracy of the control structure of remotely controlled ships (with seafarers onboard) developed using STPA-SynSS.

On this basis, the crucial aspect of performing hazard analysis and producing outcomes with STPA-SynSS is identifying UCAs, as they are fundamental and central to the development of loss scenarios (STPA-SynSS step 4) and the formulation of hazard mitigation strategies (STPA-SynSS step 6). Hence, the correctness of identifying UCAs is especially critical. The verification result of system safety shows that all 11 property specifications listed in Table 5 passed the verification (as shown in Figure 17). This indicates the existence of at least one transition path that leads to the occurrence of UCA-1 to UCA-7, thereby affirming the presence of UCAs in the collision avoidance scenario of the remotely controlled ship (with seafarers onboard) and validating the accuracy of UCAs identification in this scenario.

5. Discussion

The continuous improvement in the safety level of autonomous ships is a common goal for all stakeholders in the maritime industry. A standardized hazard analysis process plays a crucial role in identifying, eliminating, and controlling potential hazards of autonomous ships. As the basis of hazard analysis, risks should be identified using suitable, recognized, and appropriate risk assessment techniques. To this end, RBAT was developed, as recommended in the draft MASS Code, to form a framework for a generic autonomous ship risk assessment tool in the absence of statistical data for establishing a risk model. The main impression is that RBAT can successfully identify and address key challenges associated with MASS, although it has been noted that refinements to the methodology are necessary to more precisely capture and distinguish between the varying risk levels across different scenarios.

To evaluate the risk by comprehensively considering the severity of the worst consequences of unexpected events and the effectiveness of mitigation actions to prevent losses in the absence of data support, STPA has emerged as an approach to improve the safety of modern complex systems in concert, which demonstrated the outstanding capability to identify and mitigate the unsafety/insecurity control actions that might lead to the losses of autonomous systems. However, the method of modeling and analysis through manual deduction remains controversial within the industry, particularly regarding the validity and authority of its results, as it is challenging to eliminate the human subjective influence during the process. Hence, the effort to introduce a certain level of formalization into STPA steps is well received.

5.1. Collaboration Between Model Checking and STPA

The workflow proposed in this study combines the model-checking approach with the STPA-SynSS process, and it leverages the output information from steps 1, 2, and 3 of STPA-SynSS to construct the timed automata network model, define its properties, and perform the automatic verification of hazard analysis results. This encompasses the modeling, specification, and verification stages in model checking, thereby ensuring the correctness of system modeling activities and hazard analysis results. The method aims to automatically verify the correctness of hazard analysis results while addressing the challenges of minimizing human influence in the analysis process.

To conclude the case study, we consider that the proposed method of combining STPA and model checking using UPPAAL has been successfully applied in autonomous ships. The process of aligning STPA with the UPPAAL model required considerable effort, but both approaches proved mutually beneficial [38]. The formalization of system behavior within an automata model raised several uncertainties that needed to be addressed in order to proceed with the proposed approach. As a result, the understanding of the system and potential hazardous scenarios was significantly enhanced. Conversely, the STPA identified UCA and loss scenarios that had not been considered during the initial system modeling.

5.2. Key Findings from the Case Study

The automated verification was achieved by modeling the timed automata network of the remotely controlled ship in UPPAAL. This work was possible because the requirements of automated verification were easily met by employing traversal strategies and algorithms over a finite state space, conducting an exhaustive explicit or implicit search of all reachable states and behaviors reflected in the given system or model in UPPAAL. Liveness, reachability, and safety properties are all employed for this verification.

The control structure is employed to guide and track the synchronization of channels. When the model incorporates all control behaviors and feedback, all states of the timed automata are accessible, synchronization within the automata is consistent, the model is free of deadlocks, and the correctness of the model can be confirmed. Simulation results and system activity verification in the case study demonstrate that the system is free of deadlocks, all subsystems and components operate correctly, and all system functions are executed as intended. This effectively verifies the correctness of the control structure for the remote-controlled ship (with seafarers onboard) modeled based on STPA-SynSS. Consequently, liveness verification holds a foundational position, as it indicates the correctness and integrity of the system modeling and can promote or complete the unsafe characteristics of the system function requirements, which determine the reliability of the system.

In the case study, a timed automata network model, which consists of seven timed automata, was established. This model, drawing on the functional requirements and control structures, simulated the dynamic behavior of the remotely controlled ship in the collision avoidance scenario. Reachability checks whether all model states are eventually reached or are reachable. The BNF statements for system safety and the verification results show that at least one transition path leads to the occurrence of all UCAs identified within the system, proving the existence of UCAs in the collision avoidance scenario of the remotely controlled ship (with seafarers onboard), thereby validating the correctness of the UCA identification for this scenario based on STPA-SynSS. The accuracy of the hazard analysis results is further effectively verified, and the closed loop of the hazard analysis of STPA is achieved. This case study shows that the formal method based on model checking can solve the verification difficulty of the hazard analysis results of autonomous ships through the liveness and reachability properties.

5.3. Potential for Industry Adoption

In conducting hazard analysis for the collision avoidance scenario with remotely controlled ships, seven UCAs were identified between the control loop of the IBS and AEMC systems. It is essential to model the hierarchical safety control structure based on the responsibilities and functional requirements of all model elements when constructing the control structure. From the perspective of system engineering, system safety is viewed as an emergence of the system and controlling this emergence is achieved by imposing constraints on the behavior of individual components and their interactions. From a high level of abstraction, STPA aims to model the system through its control structure as a set of feedback control loops. This method captures functional relationships and interactions while identifying unsafe control actions and their associated loss scenarios. As a result, without simulating the model based on system liveness, the integrity and consistency of the model cannot be ensured. In this case, the modeling process fails to support or achieve the non-safety-related functional requirements of the system, and the reliability of the system and the correctness of modeling results are uncertain. Consequently, all subsequent steps of the STPA methodology deviate from the intended objectives.

In the generated control loop between IBS and the AEMC system, as shown in Figure 18, if the UCAs are incorrectly identified, the designed targeted hazard mitigation measures fail to be effective. This could lead to the evolution of collision risks between encountering ships in a close-quarters situation and immediate danger, even resulting in a deviation from their OE. As a result, the likelihood of the ship collision accident occurrence would significantly increase. It is essential to verify the identified UCAs based on a general reachability analysis. If the identification results fail verification, it is necessary to return to step 3 to re-identify the UCAs, ensuring the correctness of generating loss scenarios and designing mitigation strategies.

After the iterative identification of UCAs and the verification of system activity, the targeted generation of hazard elimination or mitigation strategies is crucial for maritime practitioners, especially navigators. In the collision avoidance scenario for remotely-controlled ships, the consequences resulting from “course and speed control are not provided (UCA-1/2)” are more severe, drawing more attention from navigators. In this case study, the control loop is mapped to physical components, and specific causal factors are derived by refining safety and security constraints to facilitate the generation of loss scenarios and the decomposition/description of hazard ingredients. The hazard is an objective state that exists independent of human intention, and it can transition from a potential condition to an accident state when the elements within a hazard align in a specific combination. The existence of a hazard requires the presence of three hazard ingredients, including hazard element (HE), initiating mechanism (IM), and target and threat (T/T), as shown in the hazard triangle in Figure 18. To minimize the occurrence of ship collision accidents caused by “course and speed control are not provided” as much as possible, it is particularly crucial to design elimination/mitigation strategies that eliminate hazards, reduce the possibility of hazard transformation, and limit their consequences from the perspective of system safety and security-driven optimization.

The designed hazard elimination and mitigation measures are taken as input to implement the mitigation analysis in RBAT and identify mechanisms that can prevent unsafe conditions from escalating into accidents. Mitigation measures may involve the implementation of alternative control strategies aimed at re-entering the operational envelope, even if only in a degraded yet acceptable state, or transitioning the system into a fallback mode to maintain safety while efforts are made to restore nominal control. Fallback states represent predefined operational modes designed for situations in which continued operation within the nominal envelope is no longer feasible due to abnormal conditions. The transition into such states can be enabled through mitigation measures implemented by a single function or a combination of multiple functions. These same functions, or additional ones, may also facilitate the recovery of the system to a normal or degraded operational condition that ensures both safety and security. Thus, mitigation in this context entails the capacity to tolerate or recover from failures before they escalate into hazardous states, to regain control and restore the system to its intended operational domain, or to enter a stable fallback configuration that prevents further degradation and minimizes the risk of loss.

5.4. Limitations and Prospects

In comparison to classical STPA, STPA-SynSS can identify a greater number of UCAs and potential loss scenarios. This study focuses on the operational scenario of collision avoidance for a remotely controlled ship (with seafarers onboard). Two control loops with IBS and AEMC as control centers are constructed. The identified UCAs were mapped to the BNF statements; however, noteworthily, due to the limited number of inputted UCAs, no state space explosion occurred during the entire analysis process. The combinatorial explosion remains a major drawback of model-checkers since it requires exploring the entire state space when providing an optimal trace (in terms of length or duration of the sequences) [32]. With the deepening of future research, the analysis process of UCAs at the component level may promote state space explosion, but the solution to the state space explosion still needs further processing. Future extensions of our method could adopt a compositional modeling strategy, where complex systems are partitioned into smaller subsystems that are verified independently or hierarchically. Abstracting state variables and timing constraints where precision is not critical can help reduce state explosions without compromising safety guarantees.

It should be acknowledged that the current method, based on timed automata and UPPAAL, is limited to deterministic discrete-event systems. It does not accommodate probabilistic behavior or continuous dynamics often found in hybrid systems. Future extensions may consider integrating stochastic modeling tools or hybrid system verification frameworks to address these more complex behaviors in autonomous maritime systems.

Moreover, given the limited description of autonomous ships, the hierarchical control structure defined in this study represents only an illustrative case study. The draft MASS Code emphasizes the need to address the diversity in operational modes and scenarios for autonomous ships, reflecting their ability to adapt to varying modes of operation and environmental conditions. Since the future operational scenarios are not limited to collision avoidance scenarios, in future studies, it is suggested to generate exhaustive scenarios for different modes of operation and further demonstrate the capabilities of automated verification tools.

6. Conclusions

In this study, a formal verification method based on timed automata is utilized to verify the hazard analysis of autonomous ship navigation safety. This method is comprised of three steps and was applied to an autonomous ship. Compared with the more traditional approaches, the proposed method is more conducive to the integration of model checking into hazard analysis work. The formal verification method based on timed automata is demonstrated to be capable of overcoming the limitations associated with the accuracy and completeness of hazard analysis results derived from the traditional accident cause theory and manual deduction in the field of autonomous ships.

The method employs steps such as modeling, specification, and verification for model checking to automatically validate the control structure of the system that needs verification and the identified UCAs constructed by STPA-SynSS, thus assessing the correctness and completeness of the hazard analysis results. Using remotely controlled ships (with seafarers onboard) as a case study, a hazard analysis of the collision avoidance scenario is conducted, followed by the establishment of a timed automata network model for this scenario based on rigorous semantics. The model elements, control actions, and feedback identified by STPA-SynSS are mapped as templates and channels into UPPAAL to construct the corresponding timed automata, UPPAAL model. Finally, by utilizing the UPPAAL simulator and verifier to perform an automated exhaustive search of the system’s state space, the complete model is simulated, and the hazard analysis results are validated. The verification results indicate that the timed automata network model for remotely controlled ships, based on the control structure, is free of deadlocks and operates correctly. At least one transition path exists that leads to the occurrence of the UCAs identified by STPA-SynSS, thereby confirming the correctness of the STPA-SynSS hazard analysis results.

The results obtained with the proposed approach indicate that combining the two techniques improves the knowledge obtained about the system under design and the consistency of the design changes proposed to tackle the safety constraints identified in STPA. Moreover, the method proposed in this study emphasizes the significance of the collaborative work between safety and system engineering in the product development process. Future studies will focus on extending the applicability of this method to a broader range of autonomous systems while further refining the model to enhance both the efficiency and accuracy of the verification process. Particular emphasis will be placed on mitigating the risk of combinatorial explosion, a common challenge in the verification of large-scale models, by exploring advanced optimization techniques and scalable verification frameworks. This automated hazard verification method can serve as a reference for other intelligent systems with inherent potential hazards.