Research - (2024) Volume 12, Issue 9

A Framework for Requirements Management to Develop Safety Management and Operation of Maritime Autonomous Surface Ships
Ayako Umeda* and Etsuro Shimizu
 
Tokyo University of Marine Science and Technology, Japan
 
*Correspondence: Ayako Umeda, Tokyo University of Marine Science and Technology, Japan, Email:

Received: Sep 27, 2024, Manuscript No. IJCSMA-24-146441; Editor assigned: Sep 30, 2024, Pre QC No. IJCSMA-24-146441 (PQ); Reviewed: Oct 14, 2024, QC No. IJCSMA-24-146441 (Q); Revised: Oct 23, 2024, Manuscript No. IJCSMA-24-146441(R); Published: Oct 30, 2024

Abstract

Following technological advances, autonomous and remote-controlled ships are performing trials in some sea areas; a mandatory goal-based MASS code, expected to enter into force on 1 January 2032, is under discussion in the International Maritime Organization (IMO). This paper outlines the regulatory framework for MASS, followed by a discussion of its application, considering the differences between MASS and automated driving, and how to develop safety management and operation using standards for automated driving. A requirements management framework developed as a system and software engineering standards to build safety management and operation of MASS is proposed. The proposed framework enables processes to manage requirements in a traceable manner using industrial standard for systems and software engineering. Additionally, Safety of the Intended Functionality (SOTIF) developed for automated driving is used to determine Operational Design Domain (ODD) of MASS and operating limitations of each system. It was also proposed that hazards that could not be identified through SOTIF activities would be registered as vulnerabilities in the database that manages information of casualties in a unified manner at IMO.

Keywords

Requirements management framework; Safety management and operation; Safety Management System (SMS); Maritime Autonomous Surface Ships (MASS); Operational Design Domain (ODD); Object and Event Detection and Response (OEDR); Safety of the Intended Functionality (SOTIF); Vulnerabilities

Introduction

Recently, small and medium-sized unmanned boats, such as Unmanned Surface Vehicles (USVs), have been developed and operated mainly for scientific and military use. As the development of USV technology has progressed, expectations for the realization of autonomous shipping have increased [1,2]. And an eye-catching video on autonomous shipping published by Rolls Royce in 2016 attracted a lot of attention and sparked discussion about autonomous ship operations. In accordance with these technological advances, autonomous and remote-controlled ships are performing trials in some sea areas; the International Maritime Organization (IMO) established the Maritime Autonomous Surface Ships (MASS) Working Group to progress the work on the MASS Code and to identify issues relevant to instruments [3]. The aim is to adopt a non-mandatory goal-based MASS code to take effect in 2026, which will form the basis for a mandatory goal-based MASS code, expected to enter into force on 1 January 2032 [4].

The existing regulatory framework for merchant ships regulated by IMO instruments requires safety management, not only technical aspects. The International Safety Management (ISM) Code provides an international standard for the safe management and operation of ships and for pollution prevention [5]. Therefore, safe management and operation should also be required for MASS. However, it appears that the MASS developers are leading the discussion from a technical perspective, with little consideration given to operational safety requirements.

On the other hand, traditional shipbuilders may not be proactive in developing MASS to manage requirements related to ships that make extensive use of new digital technologies. In addition, there are no unified standards regarding evaluation methods to define operating limitations for cutting-edge technologies such as artificial intelligence and sensing, which are expected to be elemental technologies of MASS, so it is difficult to evaluate how much confidence they should have in using them. In addition, it is considered that a lack of certainty in the regulation of MASS and a lack of consistency in the regulatory framework may potentially impede investment and innovation [6]. This means that ship owners and operators must invest in MASS at their own risk and develop safe management and operation of their ships implemented technology for which performance limitations have not been fully verified nor properly regulated. Under these circumstances, ship owners may be discouraged from building the MASS, and even if rules were established, this could be an obstacle to the widespread use of the MASS.

Laws and regulations regarding ship operations have been formed over a long period of history, and today, they mainly take the form of conventions concluded through international discussions at the IMO. Casualty investigation reports which identify potential safety issues have been provided to relevant IMO bodies for appropriate action, such as amendment to and support to the implementation of existing regulations, development of new requirements, and technical cooperation activities [7].

Many of the requirements for the construction and operation of conventional ships are based on the matters prescribed in the IMO instruments. If the differences in requirements for conventional ships and the MASS are clarified and the management and operation of the MASS can be developed by ship owners and operators, MASS may be accepted by the maritime industry. Requirements management is becoming an established methodology in the systems engineering field. With the growing research and development on MASS, systems engineering methods such as model-based engineering and digital twin have been introduced [8,9]. However, requirements management for safety management and operation with respect to the IMO instruments applied to MASS has not been considered in these studies. From another perspective, studies have been conducted on the law and regulations for the safe operation of MASS. For example, research on the legal framework for the regulation of MASS, discussions on the legal status of the MASS operation, study on regulatory requirements for MASS operation, and discussions on the human element regarding MASS are existing [10-13]. With these trends, several industry consortia on MASS have been formed, and industry level voluntary rules are being developed [14-17].

From the historical perspective of advanced shipboard technology, MASS can be positioned as evolution from the traditionally provided automation of the many critical shipboard systems [18]. Research on the elements of MASS has been active in areas such as motion control, situational awareness, and collision avoidance [19-25]. For management and operations, there is also a research area covering risk assessment and control on MASS [26-28]. In particular, the risks involved when decisions are made by Artificial Intelligence (AI) in autonomous systems are also gaining attention [29]. While much academic research has been performed in various areas, the research fields are fragmented and have not been presented as a framework for requirements management for MASS as a system engineering methodology.

In this paper, the authors propose a framework for requirements management to develop the safety management and operation of MASS based on the issues above to contribute to the advancement of science and technology as engineering research. The main contributions of this publication can be condensed as follows:

• Application to frameworks adopted by other modes of transport that would be useful to consider for the MASS framework.

• Application to standards developed in other industrial sectors suitable for the management and operation of MASS in accordance with IMO regulations.

• Proposal for a requirements management framework that adopts IMO guidelines and standards developed in other industrial sectors as appropriate.

• Expected benefits and limitations if the proposed framework is implemented in the development of MASS.

This paper is structured in the following manner. Followed by the Introduction in Section 1, Section 2 describes the regulatory framework for MASS discussed in IMO and contrast with frameworks developed for automated driving. In the Section 3, an approach for development of MASS management and operation is discussed. In the Section 4, an overview of the proposed framework and benefit for the marine industry is discussed. As evidenced by the protracted discussion on the MASS code, a MASS framework that comprehensively covers not only MASS technology but also management and operations is not currently established. Thus, Sections 2, Sections 3, and Sections 4 provide a step by step description of the framework proposed in this paper. Finally, the conclusion of the entire effort is provided in Section 5.

Regulatory Framework for MASS

MASS Code

Regulatory Scoping Exercise: In advance of developing the MASS code, a Regulatory Scoping Exercise (RSE) for the use of MASS was conducted by the Maritime Safety Committee (MSC). The RSE identified the common potential gaps and/or themes that are required for MASS operations and provided the most appropriate ways of addressing MASS operations to the IMO instruments classified as “High-priority," including the International Convention for the Safety of Life at Sea (SOLAS) chapters II-1, II-2, III, IV, V, VI, VII, IX, XI-1and XI-2, Convention on the International Regulations for Preventing Collisions at Sea (COLREG), and International Convention on Standards of Training, Certification and Watchkeeping for Seafarers (STCW) Convention and Code. To facilitate the process of the RSE, the degrees of autonomy, as shown in figure 1, were organized, but the list below does not represent a hierarchical order [30].

ijcsma-autonomy

Figure 1: The degrees of autonomy were organized to facilitate the process of the RSE [30] with information elaborated by authors.

• Degree One: Ship with automated processes and decision support: Seafarers are on board to operate and control shipboard systems and functions. Some operations may be automated and at times be unsupervised but with seafarers on board ready to take control.

• Degree Two: Remotely controlled ship with seafarers on board: The ship is controlled and operated from another location. Seafarers are available on board to take control and to operate the shipboard systems and functions.

• Degree Three: Remotely controlled ship without seafarers on board: The ship is controlled and operated from another location. There are no seafarers on board.

• Degree Four: Fully autonomous ship: The operating system of the ship is able to make decisions and determine actions by itself.

Goal-Based MASS Code: The MASS Code is planned to be a goal-based instrument with goals, functional requirements, and corresponding regulations, suitable for all four degrees of autonomy and addressing the various gaps and themes identified by the RSE [31]. Figure 2 shows the goal-based instrument's structure and the MASS code's positioning according to the generic guidelines for developing IMO Goal-Based Standards (GBS). According to the IMO GBS, rules and regulations for ships based on functional requirements are to be established by national administrations and class societies. Industry practices and standards are developed by industry such as the International Organization for Standardization (ISO) but may also be approved by national authorities [32].

ijcsma-MASS

Figure 2: Structure of goal-based instrument and positioning of MASS code with information elaborated by authors [32].

The IMO instruments classified as "High-priority" include requirements for technical matters at ship-level and element-level and for administrative matters at management-level and operation-level. While most SOLAS chapters specify technical requirements, SOLAS chapter IX and ISM Code, COLREG, and STCW Convention and Code specify management and operational requirements. In other words, it is intended to be covered by the MASS code (Tier II) not only ship-level and element-level requirements but also management-level and operation-level safety. As specified in the ISM code, companies must develop Safety Management Systems (SMS) at the management-level and operation-level. National administrations and class societies need to develop rules and regulations for ships (Tier IV). In parallel with this, industry practices and standards such as ISO must be formed (Tier V).

Refer to Automated Driving

Level of MASS: The operating conditions and safety assurance process need to be defined to develop the safe management and operation of MASS. As stated above, the MASS code will regulate high-level functional requirements and rules for ships; it is required to discuss further how to specify the operating conditions and the safety assurance process. A cross-domain safety assurance framework for automated transport has been proposed [33]. This proposal is based on a framework for safety assurance of automated driving but assumes that it can be deployed in other transportation systems. The drafted MASS code and the ISO/TS 23860 for defining vocabularies, which are under discussion, also refer to SAE J3016 which defines terms for automated driving [34,35]. Therefore, this paper will refer to automated driving as the other automated transport in this paper.

As shown in figure 3, in automated driving, automation levels are defined by domain-specific or not (between Level 5 and Level 4), fallback conducted by driver or system (between Level 4 and Level 3), partial or complete OEDR (between Level 3 and Level 2), lateral and/or longitudinal motion control (between Level 2 and Level 1), and momentary or sustained motion control (between Level 1 and Level 0). For conventional ships, SOLAS requires certain types of ships to be equipped with a Heading Control System and/or Track Control System, generally referred to collectively as Auto Pilot, which corresponds to Level 1 of automated driving. Here, “Automated Navigation” is defined as a partial OEDR function that can be performed, and “Autonomous Navigation” is defined as a full OEDR function that can be performed. In this paper, the terms “Auto Pilot,” “Automated Navigation,” and “Autonomous Navigation” are used as names of MASS system types.

ijcsma-authors

Figure 3: ODD relative to driving automation levels and MASS system types with information elaborated by authors [35].

OEDR of MASS: Figure 4 shows a schematic view of the navigation task associated with Auto Pilot and Automated or Autonomous Navigation. This figure was prepared in contrast to figure 2 of SAE J3016 to facilitate understanding of the position of the OEDR. If the MASS is operated remotely, the input to the OEDR function and the output to Auto Pilot would be transmitted over the communication lines to the outside of the MASS, but in this schematic view, the physical constraints that depend on the means of communication should be consider as element-level characteristics. Auto Pilot falls into the “Lateral ship motion control” as an operational functions loop because it automatically controls the rudder but not the ship's speed. In conventional ships, decisions regarding OEDR are made by humans, and the direction input to Auto Pilot is entered as command values. If decisions regarding the OEDR function are performed by the system, then this would fall under Automated or Autonomous Navigation with tactical functions loop control. In this way, it can be said that in ship operations, the conventional Auto Pilot is used as the operational function and the OEDR function as the tactical function only needs to output command values to the Auto Pilot.

ijcsma-pilot

Figure 4: Schematic view of navigation task associated with auto pilot and automated or autonomous navigation with information elaborated by authors [35].

The regulations contained in the STCW Code are basic requirements for standards of training, certification, and watch keeping for seafarers. Part A of the Code is mandatory. The minimum standards of competence required for seagoing personnel are given in detail in a series of tables [36]. Chapter II deals with standards regarding the master and deck department; Chapter VIII deals with standards regarding watch keeping. The analysis of the competencies and tasks required of seafarers in these chapters will allow us to identify the matters to be covered by the OEDR function in Automated or Autonomous Navigation. Figure 5 shows examples of OEDR targets identified by interpreting the requirements in the STCW Code. Although a rough classification is presented here, detailed targets can be defined for each [37]. These OEDR functions may address not only ship-level requirements, but also element-level, operational-level, and management-level requirements. The OEDR targets shown in this figure are expressed based on the STCW code description, which corresponds to the operational-level, and the targets expressed at the element-level need to be specifically defined when designing OEDR systems in the future.

ijcsma-OEDR

Figure 5: Examples of OEDR targets are identified by interpreting the requirements in the STCW Code with information elaborated by authors [37].

MASS System Types Under Different Conditions: In figure 6 illustrates how a trip could be completed using various combinations of driving and navigation automation types engaged at different levels of automation [35]. This figure was prepared in contrast to figure 1 of SAE J3016 which shows examples of driving automation system features/types that could be available during a given trip. Even in automated driving, it is not necessarily assumed that all sections are operated at the same level. Similarly, it is assumed that different types of operations will be performed in MASS from departure to arrival.

ijcsma-automation

Figure 6: Examples of driving automation and MASS system types that could be available during a given trip with information elaborated by authors [37].

In the STCW Code Part a Chapter VIII, duty requirements for watch keeping under different conditions and different areas are categorized as clear weather, restricted visibility, in hours of darkness, coastal and congested waters, navigation with pilot on board, and ship at anchor. This means that the performance requirements of the OEDR system will vary depending on the voyage area, the weather, and other conditions. In figure 6, the vertical axis is classified by visibility, while the horizontal axis is classified by sea area and day/night for applicable MASS system types. Since the discussion on how to determine the type of MASS system that can be safely operated is not yet mature, in figure 6, examples of MASS system types are left blank, and only examples of conventional ships are provided.

Development of MASS Management and Operation

Concert of Operations for MASS

Ship-level Concept: In the case of conventional ships, a concept should provide sufficient information, including dimensions, displacement, stability, propulsive characteristics, preliminary general arrangement, and principal structural details from the objectives of the ship’s operations. Each item of information may be considered in more detail; after that, technical specifications for the ship contracts should include the following information:

• Brief description and essential qualities and characteristics of the ship

• Deadweight, cargo, and tank capacities, etc.

• Speed and power requirements

• Machinery details, including the electrical installation [38].

The design of MASS may be essentially the same as that of conventional ships, but it differs in that some or all human tasks are replaced by systems. And while some on-board equipment can replace humans, it is assumed that there are limits to their range. Therefore, it is necessary to understand the operating limitations of the equipment being considered for installation at the element level and then allocate the MASS system types according to the conditions in which the MASS is planned to be operated at the ship level. The level of OEDR targets required also depends on the operational concept of the MASS, so the operating limitations at which the OEDR function will work properly need to be identified at the system design stage.

Element-level Concept: It is important that performance and testing standards are met at the element level to understand the operating limitations of shipborne equipment. SOLAS Chapter V regulation 19.2 specifies the carriage requirements for shipborne navigational systems and equipment for conventional ships. These are element-level requirements, with different performance standards for each navigational system and equipment. Table 1 lists the example documents that define the performance standards and testing standards for major equipment specified in SOLAS [39].

Table 1. Examples of SOLAS mandatory equipment and standards.

Equipment (Tier II) Performance Standards [39] (Tier IV) Testing Standards (Tier V)
Heading control systems IMO Resolution MSC.64(67), Annex 3 ISO 11674
Track control systems IMO Resolution MSC.74(69), Annex 2 IEC 62065
Radars IMO Resolution A.477(XII), Annex 4 IEC 60936-1
Receivers for GNSS IMO Resolution A.819(19) IEC 61108
Automatic identification systems (AISs) IMO Resolution MSC.74(69), Annex 3 IEC 61993-2

In the existing regulatory framework for ships, it is assumed that there are limits to the performance of navigational equipment, and the STCW Code requires operation and training when the limits are exceeded. For track control systems, the IMO Resolution states that “a track control system should be able to accept a signal from the over-ride facilities to terminate track control mode and switch to the override facilities [40].” The STCW Code states that “The officer in charge of the navigational watch shall have full knowledge of the location and operation of all safety and navigational equipment on board the ship and shall be aware and take account of the operating limitations of such equipment” (STCW Code Part A Chapter VIII 26). If the equipment has type approval, it can be considered that the equipment has been manufactured in compliance with the testing standards, and the flag State administration may allow the placement of equipment on board [41].

As described above, different from standard elements like "Auto Pilot," since non-standard elements have not been established for "Automated Navigation" and "Autonomous Navigation," the question is how operating limitations should be determined. The IMO has another approach defined in the MSC.1/Circ.1455 for approving an alternative and/or equivalent design, comparing the innovative design to existing designs to demonstrate that the design has an equivalent level of safety [42].

Operational Design Domain (ODD): To determine the ODD of MASS in the intended operational condition, it is necessary to know the operating limitations at element level and hazards of the OEDR function in each condition. The absence of unreasonable risk resulting from hazardous behaviors related to functional insufficiencies is defined as the Safety Of The Intended Functionality (SOTIF); measures to eliminate hazards or reduce risks are standardized by as ISO 21448: 2022 (ISO 21448) [43]. The SOTIF activities include the identification of functional insufficiencies that lead to hazardous behavior or inability to prevent or detect and mitigate a reasonably foreseeable misuse. The SOTIF-related hazardous event model is considered when specifying the ODD and during system development (risk identification, definition of appropriate measures) to ensure the SOTIF during operation.

ijcsma-SOTIF

Figure 7: Concept of understanding the operating limitations and hazards of the OEDR function by applying SOTIF activities to MASS with information elaborated by authors [43].

Figure 7 illustrates the concept of understanding the operating limitations and hazardous events of the OEDR function by applying SOTIF activities to MASS. The illustrated scenario means a hazardous situation where a fishing boat is hardly detected in poor visibility, the unpredictable behavior of the target is detected as a hazardous event, and the collision avoidance action is performed by humans. Whether the MASS system type is " Auto Pilot" or " Automated Navigation ", the ship is controlled by the system until it is overridden by a human. From the safety perspective of the intended function, "Automated Navigation" is designed to notify humans when it recognizes a situation where the object and event detection function is limited due to poor visibility or where the target's behavior is unpredictable. Furthermore, measures are being taken to prevent misuse by humans who override the system in these situations. If these functional insufficiencies and user misuse risk are reduced to an acceptable level, ODD can be established by identifying conditions that fall into “Not Hazardous and Known”.

In the case of automated driving, measures to eliminate hazards or reduce risks are implemented in the verification and validation phase by conducting technical reviews, test cases with high coverage of relevant scenarios, injection of potential triggering conditions, the loop testing of selected SOTIF-relevant scenarios, long-term vehicle testing, test-track vehicle testing, and simulation testing. It would be ideal if such sufficient testing could be conducted at the verification and validation phase in MASS as well, but since ships are custom-made products, unlike automobiles, it is assumed that difficulties will arise for economic reasons. Therefore, if system insufficiencies or hazardous scenarios are identified during the SOTIF activities for MASS, it may be practical to design operations that are overridden by humans, considering the operating limitations of the element for which design changes are practically difficult.

Safety Management System (SMS)

The ISM Code requires companies to establish safety objectives and develop, implement, and maintain an SMS. SMS requirements include documentation at the company management level and the ship's operational level.

Management-level: To comply with the requirements of the ISM Code, companies should develop, implement, and maintain a documented SMS, including the following functional requirements:

• A safety and environmental protection policy

• Instructions and procedures to ensure safe operation of ships and protection of the environment in compliance with relevant international and flag State legislation

• Defined levels of authority and lines of communication between, and amongst, shore and shipboard personnel

• Procedures for reporting accidents and non-conformities with the provisions of this Code

• Procedures to prepare for and respond to emergency situations and

• Procedures for internal audits and management reviews (ISM Code Part A 1.1.4).

In the case of MASS, it is expected that the matters to be documented as SMS will also include different matters than in conventional ships. Therefore, companies need to establish appropriate SMS according to the concept of the MASS operations.

Operation Level: The ISM Code requires that companies establish procedures, plans, and instructions, including appropriate checklists, for key shipboard operations (ISM Code Part A 7). These instructions are described in the operational procedures manual so that the crew can understand their contents. Generally, the manual on navigational watches describes the watch arrangement according to the situation, referred to as the “Watch Level.” Figure 8 is an example of the Watch Level described in the practical guidelines [44].

ijcsma-Watch

Figure 8: An example of the Watch Level described in the practical guidelines with information elaborated by authors [44].

Not only will the number of watch keeping personnel be increased or decreased depending on the situation, as required by the STCW code, but the availability of Auto Pilot will also be specified in the manual. Similarly, when "Automated Navigation" or "Autonomous Navigation" as a MASS system type is implemented on ships, it is necessary to design the Watch Level according to the risk characteristics of the OEDR function and the ODD described above. The importance of Human-Machine Interaction (HMI) in autonomous systems has attracted much attention in recent years, and various studies have been conducted on its application in MASS [45]. System design and operational risks related to HMI should also be fully considered when determining Watch Levels and documenting manuals.

Framework for Requirements Management

Requirements Process

In considering a framework for requirements management to develop safety management and operation of MASS, systems and software engineering standards may be useful for reference. ISO/IEC/IEEE 29148:2018 (ISO 29148) specifies the required processes implemented in the engineering activities that result in requirements for systems and software products (including services) throughout the life cycle [46].

Figure 9 describes the relationship between the requirements processes and requirement information items as a typical application style in a project in ISO 29148. Here, the "Management-level," "Operation-level," "Ship-level," and "Element-level" described above correspond to the required process at each stage described in ISO 29148. As a top level need, the external environment may include conventions and codes since SMSs are established by companies to enable compliance with these regulations, as already discussed. The external environment also includes national rules, regulations, and industry practices and standards regarding ship safety. The framework presented in ISO 29148 enables the use of a requirements traceability matrix that links requirements to higher-level requirements and needs or lower-level implementation and clarifies traceability between requirements and system architecture. It would be useful to incorporate such a method in system integration when non-standard elements are planned to be installed, as it requires different requirements management than conventional shipbuilding.

ijcsma-relationship

Figure 9: The relationship between the requirements processes and requirement information items with information elaborated by authors [46].

Requirements Traceability

Major classification societies have also developed guidelines related to system engineering that may be applicable to MASS. American Bureau of Shipping (ABS) has published guidelines focused on autonomous and remote-control functions based on the IMO GBS [47]. The guideline of Class NK covers automated/autonomous operation on ships, but it is assumed that assurance will be based on the verification and validation process as well as ABS [48]. Lloyd Register has established procedures for issuing digital ship notes, and Bureau Veritas has developed guidelines for granting notation to ships with software engineering applied as SMART functions [49,50]. Furthermore, the DNV has published standards that consider not only technical standards but also the management system required by the ISM Code [51].

These guidelines show their assurance approach as classification societies for novel ships including MASS. As ISO/IEC/IEEE 24765 and ISO/IEC/IEEE 29148 documents are cited in the guideline of ABS, it is assumed that industry standards for systems and software engineering will be used, although not explicitly stated in each guideline. Thus, requirements traceability may be ensured by assurance performed at classification societies.

However, requirements traceability might be an issue, especially in the event of marine casualties and incidents that need to determine the relationship between the cause and the system requirements. This is because the cause may be based on insufficiencies of specification at one of the levels in the requirements process, in the case of MASS. The SOLAS regulation XI-1/6 and the Code of the International Standards and Recommended Practices for a Safety Investigation into a Marine Casualty or Marine Incident (Casualty Investigation Code) requires that each administration shall conduct investigations of marine casualties and incidents. The IMO has been involved in casualty-related matters and in the process of analyzing reports of investigations into casualties. The activity on casualty analysis is based on the casualty analysis procedure which includes a process of analysis of casualty investigation reports registered in the Global Integrated Shipping Information System (GISIS) [52]. The following four items are set in the error type information included in the casualty investigation reports for analysis managed uniformly in GIGS [53].

• Observation

• Interpretation

• Planning / Intention

• Action

These items are mainly applicable to human errors. But for MASS, it is desirable to link the relationship between the errors and the requirements at each level to determine the cause of the casualties and incidents. Implementing such requirements management traceability is anticipated to update the regulations for MASS in the external environment and improve SMS in the organizational environment.

Class NK has proposed building a vulnerability database with examples of vulnerability classification to collect information quickly and accurately on the vulnerability of safety functions, which poses a great risk for MASS operations [54]. If the casualty investigation reports could include the cause of the identified requirements linked to the error types, the errors can be classified as “Hazardous and Unknown” (area 3) in figure 7, which could be found as vulnerabilities.

Implementation of Proposed Framework

The framework proposed in this paper enables processes to manage requirements through the "Management-level," "Operation-level," "Ship-level," and "Element-level" in a traceable manner using the ISO 29148 for systems and software engineering standards. Additionally, the ISO 29148 which propose SOTIF activities developed for automated driving is used to determine the ODD of the MASS at "Ship-level" and operating limitations of each system at “Element-level”. Since various traceability tools are available , the implementation of this framework can be easily realized if those appropriate for the use environment are selected [55]. It was also proposed that hazards that could not be identified through SOTIF activities as “Hazardous and Unknown” be registered as vulnerabilities in GIGS, the database that manages information of casualties in a unified manner at IMO.

In this framework, development of safety management and operations falls under the "Management-level" and "Operation-level”. At these levels for conventional ships, the duties of seafarers have been defined on the assumption that the operating limitations of the system are known information, clearly defined in standards or manuals. However, although the duties to be performed by seafarers are defined in accordance with the STCW code, COLREG, and other rules, the specific tasks will vary by ship type and sea area, so it is expected that the autonomous functions implemented in the MASS will be different. This means that it is difficult to establish prescribed standards as “Standard elements” that describes performance of autonomous functions in detail.

It is expected that many of the MASS that will be developed in the future will contain “Non-standard elements”, but also systems whose safety has not been sufficiently proven as products. The MSC.1/Circ.1455 estimates that these types of systems fall into the high-risk category in its risk assessment as new or unproven technologies. On the other hand, unless society accepts that vulnerabilities that cannot be discovered through laboratory experiments alone remain, especially in systems where software engineering is an important element, it will be difficult for MASS to be adopted for commercial operations. The requirements for traditional shipboard systems have not actively accepted vulnerability but have required seafarers to have the skills to deal with the uncertainty inherent in the system. It is believed that the proposed framework will enable the development of safety management and operation of MASS that embraces vulnerabilities, thereby facilitating innovation and providing this kind of discussion is the scientific contribution.

Conclusions

In this paper, the regulatory framework for MASS is outlined, followed by a discussion of its application. The differences between MASS and automated driving are considered, as is how to develop safety management and operation of MASS using standards for automated driving. Additionally, the use of a requirements management framework developed as system and software engineering standards to build safety management and operation of MASS is proposed. It was also suggested that the requirements management framework could be used for MASS development and regulatory review.

It was also presented that applying a framework for automated driving can clarify the differences in requirements between conventional vessels and MASS to establish MASS's safety management and operation properly. Furthermore, it was suggested that the ODD of MASS can be determined by using the SOTIF activities even when the operating limitations have not been identified due to the absence of established standards. However, unlike private cars envisioned as automated driving applications, merchant ships are operated by several crew members with various roles, and their roles and responsibilities are defined by multiple conventions and codes. Many of the requirements for OEDR functions in MASS can be documented by reference to the conventions and codes, but the advanced technologies that are expected to be incorporated in OEDR functions are not yet at a high enough level to replace human tasks. Therefore, in many cases, the system can partially replace humans' tasks on board. Even tasks that are substituted by the system need to be overridden by humans if they exceed the operating limitations of the system. This means that understanding human-machine interaction and its associated risk characteristics is important to develop safety management and operation of MASS. To address this issue, the proposed approach is to manage not only the requirements process but also requirements traceability by using frameworks such as taxonomy and definitions for terms related to driving automation systems, SOTIF activities, requirements engineering, and vulnerability databases which are not previously used in risk management for conventional ships. However, the MASS code is still under discussion, and there is no guarantee that the content will not change significantly in the future. The framework proposed in this research assumes that IMO GBS would be adopted in the MASS code, but a more appropriate framework may need to be selected if the assurance scheme for operational safety is fundamentally changed.

As mentioned above, there are many requirements for MASS that are different from those of conventional ships. By applying standards developed in different fields to the maritime sector, shipbuilders may be better able to manage owner’s requirements and implement system integration for MASS, which makes extensive use of advanced technologies. While the investment in MASS remains the owner's own risk, their hesitation may decrease as their risk management ability matures. As information on vulnerabilities corresponding to the risks inherent in MASS is accumulated and as regulations and standards for MASS become more appropriate, the uncertainty for developing safety management and operation of MASS is expected to be reduced. MASS might be accepted by stakeholders if accountability for proper safety management and operation of MASS can be maintained by ship owners and operators.

Eight years after Rolls Royce visualized the concept of autonomous shipping in 2016, various development projects have been conducted and discussions about rulemaking at the IMO are ongoing, but the challenges for commercial operation of MASS have been highlighted. Shipping is an industry that supports the real-world economy and is an area of technology where innovation is expected. Therefore, efforts to flexibly incorporate industrially available standards, without confining oneself to purely scientific and academic research, can contribute to the advancement of science and technology as engineering research.

Author Contributions

Conceptualization, A.U. and E.S.; methodology, A.U.; writing—original draft, A.U.; writing—review and editing, E.S.

Funding

Not applicable

Institutional Review Board Statement

Not applicable.

Informed Consent Statement

Not applicable.

Data Availability Statement

Data are contained within the article.

Acknowledgments

The authors acknowledge the support of Class NK and wish to thank Mr. Tomoyuki Yamada, Mr. Noriyuki Kajita, and Mr. Makoto Ito as joint research members.

Conflicts of Interest

The authors declare no conflicts of interest.

References