†Corresponding author: 1. Introduction
Though the autonomous ship is a development field which is hard to define because it is connected to various technologies and systems, and requires enhanced functions, it is getting the spotlight as a new development engine in the shipping industry. Now, the study on the development of autonomous ships is in the stage of verification of the definition of concept and a part of functions and a comprehensive definition of operation has not yet been established(Im et al., 2018). As safety, reliability and connectivity are critical elements in the development of the autonomous ships from the perspective of quality(Marko, 2019) and sufficient verification of safety and reliability is a requirement, more priority is put on the cooperation and collaboration between nations, or between research organizations and industries(Jung et al., 2019).
Especially, the connectivity is the critical activating element in the autonomous ships as it connects the isolated ship to the shore, sends and receives information and controls it. The connectivity is critical as it can provide new functions and values which the existing information does not have when the individual devices are connected through the network. For the realization of a ship’s remote operation and autonomous operation, the information management platform technology is important as it enhances the access to the information, provides various services based on the collected information and offers cyber security(Jeong et al., 2018).
Supported by EU(European Union), MARINTEK(2014a) has implemented a platform service and architecture design at the MUNIN project. On the other hand, JSMEA(Japan Ship Machinery and Equipment Association) announced developing an open platform and proceeded with SSAP(Smart Ship Application Platform) project to adopt relevant international standards(NK, 2019). In Korea, the research on the realization of platform has been delayed compared to Europe and Japan and the research has been mainly led by large shipbuilding companies. So, it is hard for users and stakeholders to understand the development process and intervene with the improvement in the performance and quality prior to the commercialization of the platform.
This study adopts the design process of software architecture in the development of the autonomous ship platform for the solution of the problems described above. The software architecture defines the nature and characteristics of the internal systems and their relation in the development of a new system in order to help the stakeholders to understand the development of the new system and effectively describe the foundation required for the development process(Cho et al., 2014).
The design, which includes all of the subsystems that make up an autonomous ship platform, is close to an enterprise architecture. Therefore, we aimed to design a navigation system platform(NSP) suitable for the design range of software architecture. The study focused on the navigation system because it is the on-board system which is expected to change a lot in the autonomous ships with the human factors being connected to the composing equipment, system and components and also because it does need a lot of expansion in various devices for the automation of collision avoidance and the enhancement in the navigational safety. In addition, NSP's autonomy level is defined as the degree to which remote operation is possible even if the crew does not board. For the suggestion of the final design pattern and view in the development of software architecture, a clear identification is required for the function and quality of the development target. For the development of the NSP architecture, this study would suggest the functional requirements and the list of prioritized quality attributes through the definition of stakeholders and the analysis of the current navigation system.
First of all, the research on the current ship’s navigation system was made to reflect the technical limitations on the quality attributes and establish the design tactics. In addition, the stakeholders were defined to conduct the quality attribute workshop(QAW) for the derivation of the functional requirement. According to the results, the quality attributes were specified according to the documentation method for the software architecture and they were suggested along with the result of quality attribute analysis. The research results would enable to decide the pattern which is proper for the architecture view and tactic, organize the scenario, and evaluate the architecture.
2. Analysis of navigation system
The ship varies in appearance or navigation system depending on the purpose of navigation such as combat and research, leisure and logistic transportation. This study aims at autonomous operation of international cargo ships. The current cargo ships are composed of navigation equipment required by the IMO(International Maritime Organization) SOLAS Convention.
2.1 Systematic characteristics
As in Fig. 1, the ship’s navigation system has the basic structure of I-P-O from the behavioral perspective of the system. I-P-O has a structure that input(I) data from vision or sensor, performs processing(P), and outputs(O) the result that meets the purpose. This I-P-O structure is closely related to the system’s functional characteristics called the ‘goal orientation’ and the clear goal of the navigation system are to attain the safe and economic navigation.
As the attainment of the goal is not possible with the single system only, the output from the combination of many navigational devices are required which can be defined as the sub systems. If many navigational devices create the output, this value is again put into another system for creation or combination of improved output to achieve the goal. So, the navigational system can be considered as the system of system(SoS).
At SoS, the interfaces between many subsystems are closely related to the performance(Bass et al., 2015). As the many navigational devices are added to the navigation system in a short period of time as shown in Fig. 2, the navigation system became complicated as it could not consider the planned organization of the subsystems and the increase in the interface.
A lot of interfaces systematically created led to the increase in the volume of the task and required a lot of time and capacity for the handling. As in the navigation system, the integration, handling and assessment of information is made by a navigation officer. Unlike the automatic system, the output of the navigation system varies depending on the capacity and expertise of the navigation officer. As a result, the current navigation system has a problem that the navigation officer workload increases due to the complexity of the interface.
2.2 Navigation system network
If a lot of interfaces lead to a longer time for handling and the error in the output, the method of integrating the subsystem or constructing the data sharing network can be applied for the improvement of the system. But, the navigational devices in the current navigations system are not fully connected into one network and some devices are conducted independently as it is made in a stand-alone. As a result, it becomes hard for the network to get integrated with or share the data with the subsystem and expand it into new navigational devices.
There is a need to solve this problem for digital ship implementation and e-Navigation environment construction. To this end, the EU has proposed MiTS(Maritime information Technology Standard) as the Ethernet-based integrated vessel network standard. Considering the ISO(International Standardization Organization) and IEC(International Electrical Commission) standards, MiTS presented a layer shipboard data network architecture as shown in Figure 3. The hierarchical network architecture enhances the connectivity of the existing navigation system and shows the strengthened cyber security with the segregation into the firewall setting and network.
Though it has the improved concept over the current ship network as it integrates the other functional systems, it is not proper for the scalability of the equipment which can be applied to the autonomous ships because its network hierarchy follows NMEA 2000(IEC 61162-3) standard and adopts CAN(Controller Area Network) as the communication interface. The transmission of data by the current navigational devices can be sufficiently made with CAN communication interface which has the speed of 250kbps within the distance of up to 200m. But, As Table 1 examined by Marko H. et al.(2017), CAN communication interface cannot handle high capacity data transmissions such as Lidar and Infrared cameras(Jeon and Lee, 2014).
The result of the study on the systematic characteristics and the navigation system network shows the need for an improved network environment for handling complex interfaces and high capacity data. In addition, as the scalability of new equipment shall be considered for the new services and functions such as the strengthened cyber security, remote control navigational function and automatic collision avoidance, the approach to the problem solving is required through the platform.
3. Requirement of NSP stakeholders
The NSP is a new development element, and in order to design the architecture, the exact functional requirement of the platform must be defined. In the software field, the architecture design phase is applied to improve the understanding of stakeholders at the beginning of new system development(La and Kim, 2017). Software architecture design phase is applied to various business and system developments. It can be applied as a method for quality improvement in the development stage of NSP. In this chapter, based on the results of the navigation system analysis in Chapter 2, the functional requirement(FR) and non-functional requirement(NFR) of the NSP were derived according to the software architecture design phase.
FR are requirements that contain information about the functionality of the system and what the system does. NFR are requirements for the environmental factors required to start or operate the system in addition to the system's functionality. There are a variety of constraints to consider in implementation, data throughput, security compliance, and quality concerns.
3.1 Software architecture design phase
The overall software architecture design phase is shown in Fig. 4, it is classified as Analysis-Design-Validation (NIPA, 2011), and each phase performs specific activities according to the step.
The requirements analysis phase is to identify and analyze stakeholders, FR and NFR, quality attribute(QA), and constraints related to system development. In the phase of performing activities, requirements items related to the architecture, in particular FR and NFR, QA and constraints, should be derived.
3.2 Quality attribute workshop
Stakeholders are individuals or groups who are interested in and consider the design of systems and architectures to be developed in the future, and each can present or request various requirements for the system(Bass et al.,2009). The requirements analysis phase is conducted to clearly define requirements early in development through questionnaires or interviews with stakeholders.
However, in this study, quality attribute workshop(QAW) was conducted as a way to refine and improve opinions through active participation of stakeholders and interactions of stakeholders. By understanding the requirements among stakeholders and negotiating technical constraints and realistic demands, we believe that better analysis results can be derived than questionnaires or interviews. The architect, who develops the system, plans and conducts QAW, and induces stakeholders to understand and participate in the development system.
The defined stakeholders are shown in Fig. 5, it consists of the operator of ISCC(Inland ship control center), manager in charge of ship owner or vessel management, port authority of port safety management aspect of inbound and outgoing ship, and manufacturer in charge of development to implement navigation equipment and platform. Although the operator of ISCC does not exist at present, it was selected as a navigation officer experience to confirm the functional requirements of the ship control aspect. There were two stakeholders in each group, and a total of eight people participated in the QAW.
3.3 Functional requirement of NSP
In order to derive FR and NFR of stakeholders, the architects delivered the analysis results of the of navigation system in the presentation. Stakeholders brainstormed to clarify the purpose and necessity of NSP development and to derive FR and NFR. Each stakeholder group has developed FR and NFR related to the use of NSP. A total of 32 FRs and 34 NFRs were derived, but the similar requirements were refined through discussions between stakeholders. As shown in the following Table 2, FRs were refined in consultation with stakeholders from 32 to 12.
System constraints(C) are design decisions with no freedom. These are decisions such as the use of specific equipment or the system must be service-oriented. The symbols are summarized as shown in Table 3 without ranking.
3.4 Non-functional requirement of NSP
NFR has 34 related to FR. The NFR presented by stakeholders was difficult to find quality attributes as it required correction or contained similar content to FR. Prioritization of NFR that stakeholders should focus on in QAW requirements analysis phase was made.
Since the NFR that represent the quality of the system are important for identifying quality attributes, each NFR is scored and ranked. The score items are divided into Importance and Feasibility. Importance assesses the impact of architecture, and Feasibility assesses the difficulty of implementing the architecture in the technical environment. The score allows stakeholders to rate from 1 to 9, so that the higher NFR, where the two items add up, take precedence. Among the NFR of prioritization, the ranges from 1-3 are L(low), 4-6 are M(medium), and 7-9 are H(high) as shown in the Fig. 6. H(high) rating is a requirement that must be reflected, and M(medium) that is important but which, if omitted, does not fail the target system. L(low) is defined as a requirement that does not require reflection in architecture development.
4. Quality attribute analysis
4.1 NFR for quality attribute analysis
In Fig. 6, the gray areas include NFRs that must be reflected in NSP development in terms of importance and feasibility, and quality attribute analysis is required. Of the 34 NFRs, 22 were included in the gray area, but the stakeholders were asked to refine the NFRs that did not overlap or were not evaluated by numerical or performance.
The list of NFRs refined by stakeholders is shown in the following Table 4. When duplicate NFR contents were identified, the high score NFR was classified as the quality attribute analysis object by referring to the prioritization result. Except in the case of FR, the quality attribute analysis target was determined by NFR of 12 items.
4.2 Model of quality attribute
A quality attribute(QA) is a characteristic of a system that can be measured numerically by observing quantity or quality. It is also called a non-functional attribute. Converging all the characteristics that affect the system's ability to meet FR and NFR is the overall quality of the system. QA can be determined by the architect in consideration of the FR of the system to be developed and the constraint environment. This study refers to the ISO/IEC 9126 software quality models(ISO/IEC, 2001) and the quality attribute specification of the SEI(software engineering institute). In the process, stakeholders identified areas where ISO/IEC 9126 and SEI QA models were not fully applied to NSP development. It is necessary to define the quality model suitable for NSP development in the future, and the quality attributes for NFRs are defined as the following Table 5.
4.3 Result of quality attribute analysis
The QA of NFRs that must be considered in the architecture design were analyzed in the following order for the elements related to FR 1 through 12 defined in Table 2. First, Monitoring function(FR 1) is related to NFR 1 and QA is defined as 'Performance'. The update of information at 1 second interval was the quality requirement of stakeholders, and a system architecture tactic considering the maritime communication environment and constraints is needed.
Warning function(FR 2) is related to NFR 5 and NFR 25 and QA is defined as 'Availability'. NFR 5 and NFR 25 do not require a numerical assessment to be included in quality requirements, and because they are close to detailed functions, it is difficult to apply an architectural tactic. However, the NFR content needs to be improved because it was derived as a necessary NFR according to the importance and feasibility of the stakeholders.
Ship control function(FR 3) is related to NFR 2 and QA is defined as 'Performance'. Quality was demanded to enable real-time(minimum 0.25 sec) ship handling, and specific figures needed by ship operators were derived through stakeholders QAW.
Standardization function(FR 4) is related to NFR 3 and NFR 11 and QA was determined differently. NFR 3 requires input and output messages to be standardized in the device's communication protocol. NFR 11 requires interfaces to be standardized regardless of manufacturer. NFR 3 and NFR 11 are NFRs with incorrect quality requirements. However, it is an improvement of the navigation system required by the stakeholders, and it is analyzed that it can be standardized through NSP.
Communication management function(FR 5) is related to NFR 4 and NFR 12, and QA is different. In the case of NFR 4, the LTE-level communication speed is related to environmental constraints. Therefore, it is necessary to examine the technical realization rather than reflect the quality requirements. NFR 12 requires NSP's Modifiability Architecture tactic for increasing data transfer capacity.
Cyber security management function(FR 6) is related to NFR 14 and QA is defined as 'Security'. NFR 14 is an unspecified quality requirement that needs to be refined in the QA scenario preparation phase.
Equipment quality management function(FR 8) is related to NFR 22 and NFR 26, and QA is different. NFR 22 is about the reliability of the system and can consider design tactics to execute test requests for navigational equipment and to output check results in response. NFR 26 refers to the quality of functionality that can be indicated if abnormal behavior such as navigational equipment malfunctions or information errors occur. QA is defined as ‘Availability’.
Route management function(FR 10) is related to NFR 15 and QA is defined as 'Modifiability'. It is analyzed that quality requirements need to be considered in selecting a design tactic because the change of destination should not affect other systems.
As a result of the QA analysis, stakeholders did not have a good understanding of the quality model and lack of quality requirements in NFR and quality attributes. However, NSP's identification of user requirements could clarify specific and design elements that need to be reflected. It is analyzed as a result of forming a stakeholder group to reflect the user-side required function.
5. Conclusion
This study has applied the software architecture design phase so that the functions and quality asked by the stakeholders can be reflected in the initial design of the NSP.
A stakeholder group was formed in consideration of the research purpose to reflect the functions and quality that NSP users can satisfy in the architecture development. There are many ways to analyze the requirements of stakeholders, but in this study, QAW was conducted for the research results refined through the consultation of stakeholders. As a result of QAW through stakeholder engagement, 12 FRs and 34 NFRs were derived. The importance and feasibility of 34 NFRs were evaluated, and 22 important NFRs were derived. However, the 22 NFRs contain elements that duplicate or were corresponds to FR. Through the integration and improvement of contents, 12 NFRs were finally presented for QA analysis. An analysis was conducted on 12 NFRs to define detailed QA and the results will be based on the creation of quality attribute scenarios. The advantage of QAW is that consultations made it easier to integrate and improve on similar or unclear items.
Based on the results of the study, the architect will be able to establish the evidence and technical solutions those are important for the architecture design and will help in the creation of quality attribute scenarios. If the operation methods and working procedures of autonomous ships are specified, they can be designed by applying more detailed functional requirements and quality attributes.
As the stakeholders involved in the study do not represent the field or are good in special expertise, the output needs to be corrected or supplemented. Even in the process of the development of the software architecture, the verification has been made to solve these problems. If the results are not satisfactory, the functional requirements and quality attributes need to be reanalyzed.
The advantages of the study with the application of the software architecture design phase include the systematic approach to the requirements and definition and the expert’s analysis based on the quality attribute scenario. The methods for future research includes the preparation of architecture view to visualize the tactic for each quality attribute and suggests the verified NSP architecture through the architecture analysis method such as ATAM(Architecture Tradeoff Analysis Method).
PDF Links
PubReader
Full text via DOI
Download Citation
Print
