1. Introduction
The International Maritime Organization (IMO) has pursued e-navigation strategies since 2006, recognising the benefits of coordinating the inevitable increase in use of electronic navigation methods while also promoting safer and more secure navigation and helping to protect the marine environment. In 2007, IMO decided to develop a common format for the successful realisation of e-navigation which can provide information related to ships, navigation, and shoreside areas without impediment (Ward et al., Reference Ward, Alexander, Greenslade and Pharaoh2008). As a result, it was agreed that navigation information should be displayed in the same way on ships’ navigation and communication equipment regardless of where the ship is navigating. At the same time, IMO was working with the International Hydrographic Organization (IHO) to develop mandatory carriage requirements for Electronic Chart Display Information Systems (ECDIS). ECDIS and its development would be a key part of e-navigation and hence any common maritime data structure (CMDS) for e-navigation should be interoperable with ECDIS as it developed. The IHO had adopted a geographic information system (GIS) framework for its next generation of ECDIS standards, known as S-100, and hence in 2012 IMO adopted IHO's S-100 framework as the basis for its further development of e-navigation.
The original standards used for electronic navigational charts (ENC), which are used within ECDIS (known as S-52 and S-57), have limitations in expressing information such as seabed terrain and tides in three dimensions and cannot adequately satisfy the demand to express additional information that is needed to enhance the safety and efficiency of navigation. The S-100 framework addresses this by defining the contents and portrayal of many new product specifications not only for ENCs, but also for a range of additional information types that can be used to meet the aims of e-navigation. A product specification contains the definition of a product and description of its features as well as examples of its usage. Product specifications need to be referenced when directly applicable and/or related software is being developed.
Product specifications are being developed by three international organisations: IHO, the International Association of Marine Aids to Navigation and Lighthouse Authorities (IALA), and the World Meteorological Organization (WMO). IHO is leading the development of product specifications for ENCs, seabed topography, current and tide information, marine risk zones and marine traffic services. IALA is leading development of product specifications for navigation support services such as aids to navigation (physical and electronic) and port coordination. WMO is leading development of product specifications for weather forecasting and sea ice warnings.
There are two basic phases in the development of product specifications. Phase 1 is the development of the product specification documents themselves. These documents, including a feature catalogue and a portrayal catalogue, are officially released for testing on the IHO website upon completion. Stakeholders then review the documentation before they are voted on by the IHO member states. When approved by the members, the complete product specification is ultimately released. Phase 2 is the process of creating and testing a dataset for a product specification developed in Phase 1. When the process is complete, the datasets and the examples used during the tests are submitted to the IHO, at which time and if necessary modifications to the product specifications can be suggested and made.
Figure 1 shows the master plan for the development of the S-100 standard and the related product specifications established by the IHO's S-100 Working Group (Peng et al., Reference Peng, Sang, Shen, Chen, Zhou and Wu2017; IHO, 2021). The expected time for completion of each product specification varies but currently few of them are close to being released.
Figure 1. S-100 timeline for the prioritised IHO product specifications
This paper uses a term ‘product’ to refer to the software development result for a particular product specification. For example, the product corresponding to the S-101 ENC product specification is ENC. Product specifications are produced for the purpose of providing development specifications that need to be referred to, in this case, in developing software for the equipment related to safe navigation, such as ECDIS. In many cases, two or more products will need to display information simultaneously and harmoniously without causing ambiguity or confusion for end-users.
As shown in Figure 1, various product specifications have been developed or are currently under development. Product specifications need to detail, clearly and consistently, a data model composed of feature models and application schemas that are necessary for software development. Different or incoherent expressions should not be used to convey the same definition. Products that reliably perform with consistency and precision are integral to safe navigation, thus different or incoherent expressions must be addressed and eliminated to avoid critical risks.
However, achieving the consistent clarity of information is proving to be difficult as a complete consensus on definitions and expressions in all product specifications has yet to be made. This issue arises because each product specification is dependent on the simultaneous work of various project teams – each responsible for their respective product specifications. While S-98 is intended to be an interoperability standard, the current development arrangements do not facilitate coordination between working groups on the simultaneous display of information and the development of software that can process and coherently display different information products. To deliver high-quality systems to end-users, the matters of information priority, coherency of expressions and lack of comprehensive consensus among working organisations must be addressed and coordinated. However, this has been a major challenge within the various IHO S-100 Working Groups.
This paper reports on the results of analysis from a software development perspective on certain product specifications being developed by IHO and IALA. Section 2 provides an overview of the S-100 based product specifications and discusses the general process of software development. Section 3 analyses the expression method of the data model directly related to software development of the various product specifications. The S-100 standard adopts Unified Modelling Language (UML) notation for software design for creating data models of product specifications. The analysis in sections 4 and 5 relates to product specifications of ECDIS and VTS (Vessel Traffic Service) and offers additional considerations. Section 6 investigates redundant symbols included in certain product specifications and suggests additional symbols that can be considered.
2. S-100 standard and the implementation process
2.1 S-100 standard and related product specification trends
IHO coordinates the development of agreed international standards for hydrographic offices in countries that produce charts and nautical data. For the next generation of e-navigation systems, the S-100 standard sits at the top and provides an overarching framework for the development of digital products and services. IHO oversees work on product specifications that will facilitate the next generation of ENCs, such as:
• S-101, the next-generation electronic chart standard for ENCs (IHO, 2018b),
• S-102, the standard for expressing seabed topographic information (IHO, 2019a),
• S-104, the standard for expressing water level information during navigation (IHO, 2018c), and
• S-111, the standard for expressing current information (IHO, 2018d).
Additionally, S-121 is a standard for maritime boundaries and zones (IHO, 2019b). S-122 is a standard for marine protected areas (IHO, 2019c). S-123 is a standard for marine wireless service for navigation communication (IHO, 2019d). S-124 is a standard for supplementing the navigation warning information of S-101 (IHO, 2018e). S-125 is a standard for supplementing navigation functions. S-126 is a standard for supplementing environmental information of S-101. S-127 is a standard for supplementing the transportation service of S-101 (IHO, 2018f). S-128 is a standard for the exchange of catalogues of marine products, and S-129 is a standard for the management of under-keel clearance (IHO, 2019e).
IALA oversees the production of guides for aids to navigation (AtoN) and VTS information. IALA is developing standards such as: S-201, the AtoN information standard (IHO, 2019f); S-210, the exchange format standard between VTSs (IHO, 2018g); and S-211, the port information-sharing standard (IHO, 2018h). S-212 is the VTS Digital Service Standard (IHO, 2018i). S-230 is the application specific message standard (IHO, 2018j). S-240 is the satellite navigation system encoding and exchange standard. S-245 is the eLoran Additional Secondary Factor (ASF) data standard (IHO, 2018k). S-246 is the eLoran Station Almanac standard (IHO, 2018l). S-247 is the Differential eLoran Reference Station Almanac standard (IHO, 2018m), etc.
WMO oversees the weather and inland ENC-related standards such as: S-401, the encoding and metadata of inland ENC data standard (IHO, 2019g); S-402, the contours of inland ENC data standard (IHO, 2018n); S-411, the encoding extents and characteristics of glaciers standard (IHO, 2018o); S-412, the content structure and metadata required for datasets, etc.
2.2 Overview of S-100 based product specification
S-100, the standard for CMDS of navigation, is the standard supervised by IHO for generating and expressing information on electronic charts and for the safe navigation of ships. To meet the requirements to express various types of marine information in an integrated way, the information description method follows the ISO 19100 standard used for land map development. Version 4.0.0 of the standard has been released, and version 5.0.0 will be released in the near future (IHO, 2018a).
The product specification developed based on the S-100 standard is a document that describes the data model of the product specification. Also it defines the relations between features, the types of feature required, the data item and a format included in each feature, symbol drawings, encoding method, etc. All data types and conceptual schema language used in product specifications must follow as defined in S-100. In addition, the UML standard was adopted in S-100 for the specification of geographic information, and this standard must be followed for creation of the data model of each product specification. Additionally, methods for maintaining data quality, data management and metadata are included.
2.3 Development process of S-100 based product
The development of the product specification consists of three steps. The first is the generation of feature data in Extensible Markup Language (XML) format which conforms to the S-100. The resulting feature data is then used as an input to generate the portrayal data. Drawing instructions for portrayal are generated using the input data schema and portrayal rules. Finally, a drawing engine uses drawing instructions to draw the electronic chart for display. A drawing instruction file contains the locations where features will be displayed on the chart, the location of the feature symbol and the display format (Yuan and Wu, Reference Yuan and Wu2017).
Figure 2 conceptually shows the process of realising the product by referring to the S-100 product specification. The symbols marked ‘product spec’ refer to the contents of the product specification, showing that the data model, input data schema and portrayal rules are referenced in product development.
Figure 2. Portrayal process of Under Keel Clearence Management (UKCM) data model
3. Impacts of system performance on feature relations
An S-100 data model expresses the relationships between the types of features included in the product specification and uses the class diagram notation of the UML standard used for software structure design (Wawrzyniak and Zaniewicz, Reference Wawrzyniak and Zaniewicz2017; Jing et al., Reference Jing, Xiaoxia and Jianan2020). Generally, software developers produce products that comply with the symbols and the contents shown in the data model, so the data model or feature model should be expressed appropriately.
Figure 3 shows the relations between the features covered in this section, where (a) presents an aggregation relation, and (b) presents a composition relation. The two relations have a commonality in expressing related features, and how features B and C are necessary components for completing feature A. The difference occurs when feature A of (a) and (b) is no longer in use, whether feature B and feature C exist in the main memory or not. The aggregation of (a) means that even if feature A is no longer needed and disappears from the memory, B and C remain in the memory, and the composition of (b) means that when feature A disappears, the remaining objects B and C disappear simultaneously. However, if the existence of B and C is needed only when being with A, there is no need to leave it in the memories of B and C after A no longer exists.
Figure 3. Aggregation and composition relations
This section analyses the relations between the features in the data model of the S-100 based product specification and describes issues related to memory load and system performance.
3.1 Aggregation and composition relations of S-121, S-127 S-129, S-201 and S-401
Aggregation and composition relations between features are often used in data models of product specifications. It is essential to check that they are used properly before starting a process of software development. In this section, S-121 Maritime Limits and Boundaries, S-127 Marine Traffic Management, S-129 Under Keel Clearance Management Information, S-201 Product of IALA AtoN Specifications and product specifications of S-401 Inland Electronic Navigational Charts are studied in order to see examples of the aggregation relations and the composition relations applied by the product specifications.
(1) S-121 Maritime Limits and Boundaries
Section 2.2 in Appendix B (Application Schema) of the S-121 product specification contains the Basic Administrative Unit feature model and includes an aggregation relation. The ‘S121_GF_Information’ feature and ‘S121_GF_ThematicAttributeType’ feature shown in Figure 4 are related in an aggregation relation. On the other hand, there are no composition features in the S-121 product specification. However, if there is no opportunity to use ‘S121_GF_ThematicAttributeType’, which describes the specific attribute type for General Feature (GF) information, it is necessary to redetermine whether the aggregation relation is appropriate regardless of ‘S121_GF_InformationType’.
(1) S-127 Marine Traffic Management
Figure 4. S-121 aggregation relations
Complementing the transportation service of S-101, the S-127 product specification introduces an aggregation relation in the overview of the S-127 Feature Types diagram in Section 6.2.1.1 in S-127. As shown in Figure 5, the ‘Signal Station Traffic’ feature providing traffic control service has an aggregation relation with the ‘VesselTrafficServiceArea’, ‘ShipReportingServiceArea’ and ‘LocalPortServiceArea’ features that have service area information.
(1) S-129 Under-Keel Clearance Management Information
Figure 5. S-127 aggregation relations (part of overview of S-127 feature types)
In the case of the S-129 product specification, there are aggregation relations between the features in the data model of Section 7.2 in S-129. The ‘UnderKeelClearancePlan’, ‘UnderKeelClearanceNonNavigableArea’ and ‘UnderKeelClearanceAlmostNonNavigableArea’ features are integrally related in having information on the under-keel clearance plan. This means that the two latter features can be reused regardless of the ‘UnderKeelClearancePlan’. However, it is necessary to define the relations between the features by considering if there can be a situation where the non-navigable section could be used separately from ‘UnderKeelClearancePlan’, see Figure 6.
(1) S-201 IALA AtoN
Figure 6. S-129 aggregation relations
S-201, the product specification for navigation assistance information, applies a synthesis concept of relations between features shown in the meta features application schema of Section 4.3 in S-201. As shown in Figure 7, the ‘QualityOfNonBathymetricData’ feature represents non-depth of water information, and the ‘SurveyDateRange’ feature providing survey date information is in a composition relation with it. This means that if the non-depth of water data disappear, then the survey date information does not need to exist either.
(1) S-401 Inland Electronic Navigational Chart
Figure 7. S-201 composition relations (part of Meta Features application schema)
The S-401 product specification uses both relations of aggregation and composition in its feature model. As shown in Figure 8, aggregation relations can be seen between the ‘Bridge’ feature and the ‘Span Fixed’ feature. Even if the ‘Bridge’ is no longer needed and deleted from memory, ‘Span Fixed’ means that it remains in memory and can also be used for other purposes.
Figure 8. Aggregation relations described in S-401
The relationship between the ‘Structure’ feature and the ‘Equipment’ feature is a composition relation, as shown in Figure 9. If ‘Structure’ is no longer needed, then ‘Equipment’ is deleted from the memory simultaneously.
Figure 9. S-401 composition relations
In addition, Section 11.1 of the S-401 product specification expresses the ENC data transfer mechanism in the relationship between synthesis and integration. As shown in Figure 10, the ‘ExchangeSet’ feature and the ‘S101_ENC_DataSet’ feature are in a composition relation, which means that ‘ExchangeSet’ is not needed as long as ‘S101_ENC_DataSet’ is also not used.
Figure 10. S-101 composition relations expression in S-401 standard
3.2 Relations between features and impact on system performance
Therefore, decisions about relations between features must be given careful consideration and dealt with cautiously. This section emphasises the system performance issues that could appear when a feature model with aggregation relations and composition relations is implemented in software.
One issue is the deterioration of system performance due to excessive memory load. As mentioned above, the correlation between features described in the product specification is an essential factor. It can also directly affect the efficient management of memory when the product is developed as software and operated. If features that will not be used remain in memory, it can unnecessarily increase the memory load. Additionally, when two or more S-100 based products are running simultaneously and if any of these unused features remain, it adversely affects computing performance. Therefore, the features and the necessity for them must be completely and accurately defined and evaluated at a software design stage.
Another issue is inconsistency in the definition of relations in the expression of compositions and aggregations, and this can cause confusion among software developers. Currently, about 30 S-100 based product specifications are being developed as separate, individual projects, and these product specifications are referenced in software development to display information on the electronic chart. Also, as presented in section 3.1 above, this study found that a standard guideline was not applied in selecting the relations between aggregation and composition, which may confuse software engineers who develop products and cause arbitrary decisions regarding software implementation. In general, the design of exact product specifications and requirements for software development is an essential element to ensure the resultant navigation systems operate correctly and to facilitate safe navigation.
4. Analysis of S-100 based product specifications from the perspective of developing an electronic chart display system
In this section, the relevant S-100 product specifications required to develop an electronic chart display system are discussed from the perspective of software development.
Among the S-100 product specifications it is the S-1xx and S-2xx product specifications which are necessary to implement an electronic chart display system, and each product specification defines the essential features that are needed to be displayed. However, currently there is a lack of recognition of external environmental conditions, user selection conditions, or conditions for applying two or more properties of features in combination among the properties. This is one of major challenges that will be difficult to resolve. Ultimately, it will be the users, especially mariners, who will decide what is suitable, also this will depend on the current situation and the task at hand. An example of a light buoy is shown in Figure 11, which integrates the attributes defined in individual features and expresses them as one feature.
Figure 11. Example of complex feature attributes
If the features of the S-1xx and S-2xx product specifications are to be expressed simultaneously in combination, then the expression aspects of the features should be defined in the related product specifications, and if necessary additional features should be defined. For instance, when the features defined in the S-1xx and S-2xx product specifications need to be expressed simultaneously, if the priority of the particular expression or the expression method in the overlapping situation is not defined in advance, there could be problems with the integrity of information displayed to a navigator. Considering these possibilities there are three issues that require further evaluation.
4.1 Drawing sequence
Because S-100 based products are generally implemented to display various types of information in each respective layer, and product specifications are displayed in an overlapping fashion on electronic charts, it is necessary for the display priority of the features to be predefined (Park and Park, Reference Park and Park2017). Even though it is a challenge to implement them properly to satisfy all users, at least the existing S-52/57 standard defines the drawing sequence for the Minimum Scale (SCAMIN) property and data category according to the scale that can be referenced for the development of the electronic chart display system.
The S-52/57 product specification is the regulation for displaying chart information and waterway information in two dimensions and is described in a single document. On the other hand, S-100 based product specifications are more subdivided, and the numbers and types of features are larger and more varied than S-52/57. The definition of the drawing sequence depends on various facets of navigation, nevertheless, the drawing sequence must be precisely defined in terms of interoperability for correct and harmonious use of information from different product specifications.
Table 1 shows the drawing sequence of the existing electronic chart display system. ‘Mariner's colour-fill area data’ arbitrarily created by the navigator should be expressed in the lowest layer, and the order is defined to display the alarms and indications information for the expression of navigation risk information in the top layer. As shown in Table 1, the priority of the layer is defined according to the importance of the information.
Table 1. Drawing sequence for the electronic chart display system (S-52/57)
4.2 Conditional symbolisation
The existing S-52 defines ‘conditional symbolisation’ which includes the contents used in determining the colour and expression of the feature according to the external environment, user preference and SCAMIN, and is executed in a way that gives the value of the attributes according to the conditions. Therefore, to express various S-1xx and S-2xx features simultaneously, a definition of the conditional symbol (similar to that used in S-52/57) is essential.
Figure 12 shows the S-52 processing of conditional symbolisation. Colours are assigned to the symbol depending on whether the external environmental condition is day, dusk or night. The colour is chosen from the predefined Look-Up Colour Table. In addition, a SCAMIN is defined to determine whether a feature is expressed or not, and the feature expression is determined by comparing it with the scale specified by the user. If there is no instruction to display according to scale for features, most software engineers develop products always to display all features regardless of scale. This causes the provision of too much information to navigators all at once, making it difficult for them quickly and accurately to recognise important information that needs to be prioritised.
Figure 12. Processing of conditional symbolisation of S-52
4.3 Context-adaptive feature portrayal method
In general, the symbols appearing on the electronic chart have a location with latitude and longitude as an attribute and are displayed at a designated location. However, depending on the scale, these features may not be displayed correctly.
For example, an ‘anchoring-prohibited zone’ symbol is displayed to prevent a vessel from anchoring in a specific area, and it is expressed as an area bounded by a line feature. An ‘anchoring-prohibited zone’ symbol may not be displayed correctly depending on the scale selected by the user. Figure 13 is an example of expressing an anchoring-prohibited zone by connecting the line-type and the point-type symbols in the electronic chart display system. The left side of the picture clearly shows the ship in an anchoring-prohibited area. However, if the user sets the scale to the maximum, and the perimeter of the vessel is zoomed in, these symbols may not be displayed accordingly around the vessel. This is due to the line-type ‘anchoring-prohibited zone’ symbol not being correctly displayed on the screen. Figure 13(b) demonstrates this problem.
Figure 13. Example of a point-type symbol: anchoring symbol
For this issue a solution must be found to reduce the potential for confusion. Figure 14 offers an alternative to the display in Figure 13(b). As shown in Figure 13, the point-type ‘anchoring-prohibited zone’ symbol can enable the navigator to recognise that the vessel is inside the anchoring-prohibited zone and that it needs to be displayed. And when the position status of the vessel is changed, the position status is changed from fixed to floating, so that the position of the symbol is also changed. Figure 14 is an improved version of the anchoring symbol from Figure 13(b). The symbol in Figure 14 can be expressed so that the navigator can fully recognise that the vessel's current location is within an anchoring-prohibited zone.
Figure 14. Improved version of the anchoring symbol from Figure 13(b)
5. Analysis of S-100 based product specifications from the perspective of VTS development
S-127 and S-212 are the product specifications to be considered for VTS. Both S-127 and S-212 define features, portrayals, metadata etc., to provide digital information for stable flow of maritime traffic information between a VTS centre and a ship, and to provide information for the safe operation of ships. While they both define product specifications for system development, S-127 is being developed at IHO whereas S-212 is under development at IALA, and the latter defines product specifications for VTS from both a land and sea point of view. This difference causes ambiguous or overlapping contents. This section analyses the constraints and the problems in referencing product specifications related to developing S-100 based VTS products.
IHO S-127 Marine Traffic Management is the product specification that covers scenarios for realising the requirements outlined in IMO Assembly Resolution A.857(20) as the VTS standard provided by the VTS centre (IMO, 1997). S-127 defines the Maritime Traffic Management dataset to include certain specially designated areas affecting track and route, ship traffic services, pilot services, under-keel clearance and ship routes.
IALA is developing S-2xx product specifications for VTS and Automatic Identification System (AIS) AtoN related to maritime transportation. The S-212 VTS Digital Information Service (VTS-DIS) product specification is to be included in the VTS information service (VTS-INS) and is defined conceptually as ‘a service to make it possible to use the information necessary to make a navigation decision on time’ as follows:
• VTS-INS provides factors that can affect the ship's location and reports on the ship's identity, captain's intentions, waterway conditions, weather, dangerable facilities or passage of the ship during navigation.
• The VTS-INS data set includes navigation situations (including traffic and route information), navigation alerts, meteorology, weather alerts, waterways, electronic navigational aids, other port information, cargo information etc. Such information may refer to the navigation plans (S-421) and navigation alerts (S-124), weather information (S-412), marine traffic management (S-127) and other product specifications as needed.
As such, S-212 is intended for a cross-referencing relation in which S-124, S-127, S-412 and S-421 refer to each other for the necessary information. This is to reduce data redundancy caused by repeatedly defining necessary information. However, S-127 does not have a definition for linking with S-212 in Version 1.0. And S-127 defines the VTS service from the vessel's perspective, while S-212 defines it from the shore's perspective.
Maritime traffic information should be shown in exactly the same way regardless of which navigation equipment is used on a vessel. However, information is displayed differently depending on the standard and the type of equipment. For example, for features that represent navigation conditions, S-127 defines ‘MessageIdentifierForNavigationalCondition’, while S-212 defines ‘NavigationalCondition’. Rather than defining the same information with different terms, both product specifications need to check the content defined on one side from the other to reduce unnecessary redundancy and confusion.
5.1 Confusion on feature names
The VTS Area Information of S-212 consists of ‘Warning FeatureType’ and ‘Condition FeatureType’. ‘Warning FeatureType’ is divided into ‘EnvironmentalWarning’ and ‘NavigationalWarning’. To express navigational warning, the DIS dataset of S-212 is required to refer to S-124 as a standard service for navigational warning. S-124 provides navigational telex (NAVTEX) information or location information about a dangerous area provided by VTS or a restricted area. The type of information is processed and is provided in the code form defined in ‘S124_WarningHazardType’. Similarly, S-127 also contains information that belongs to the type of navigational warning. ‘ReportableArea’, ‘MilitaryPracticeArea’, ‘RestrictedAreaRegulatory’, ‘RestrictedAreaNavigational’ and ‘WaterwayArea’ are defined as feature types and include information that duplicates S-124. The nation that controls the area is also described in the S-124 enumeration class as a feature.
Navigational warnings are not yet defined and categorised clearly. S-124 ‘WarningHazardType’ defines recognisable attribute information with military exercise or NAVTEX information. In such cases, the navigational warning or notification often differs between the NAVTEX operating agency and the navigation warning producing agency. For example, in South Korea, the Maritime Police Agency is responsible for NAVTEX information and the Marine Research Institute is responsible for navigation warnings and alerts. This may cause much confusion when using the same function as other feature types or attributes for each institution, which can increase the cost of software development due to unnecessary and redundant tasks when developing VTS-related S-1xx products.
6. Duplicate or missing symbols
Symbols displayed on electronic charts are representative artefacts developed with software based on S-100 based product specifications, and various symbols play an essential role in supporting the safe navigation of ships. However, some symbols confuse users by expressing the same meaning of data in different shapes. This section presents the results of an investigation of redundant symbols and proposes a new symbol for offshore wind power.
6.1 Symbols with the same meaning but different shapes
Three types of symbols are used in the nautical charts. These are ECDIS symbols, which are based on the symbols used in paper charts; C-map symbols used in plotters and portable equipment for marine leisure; and INT1, which provides symbols and terms used in paper charts (IHO, 2020). They are classified into point, curve and surface symbols according to the attributes of the feature.
Figure 15 shows different symbols that have the same feature name or meaning. The S-100 based product specifications of IHO Registry, S-201 and S-123 show various types of landmark symbols. To a navigator, such variety can cause confusion and the inconvenience of memorising numerous different shapes. This can affect the safe operation of a ship in an emergency.
Figure 15. Examples of symbols with the same meaning
6.2 Symbols that can overlap when portrayed
Table 2 summarises surface symbols that express various information types directly relevant to a ship's navigation. ‘UnderkeelClearanceNonNavigableArea’ and ‘Underkeel ClearanceAlmostNavigableArea’ are features defined in S-129; they support the safe operation of the ship by expressing dangerous areas where the hull may encounter the seabed during ship operation by using the seabed water depth, which is the distance between the ship and seabed. Global Maritime Distress and Safety System (GMDSS) Area, a feature defined in S-127, is a feature that displays the areas where the GMDSS can be supported. ‘PilotService’ and ‘PilotageDistrict’ are features that express the areas where a pilot can assist a ship's operation. It is crucial for navigators to check the feasibility of entrance to particular areas for safe navigation. When a ship enters a port, it arrives at its destination by referring to the Route and Traffic Separation Scheme (TSS), and in this process, the under-keel clearance function is set to prevent the ship from grounding. ‘UnderkeelClearanceNonNavigableArea’ and ‘UnderkeelClearanceAlmostNavigable Area’ are important features that help prevent ships from grounding. If these are overlapped with other displayed data, there is a possibility that the user's ability to read and understand the displayed information may decrease. It is necessary to prioritise the area features that can be overlapped to reduce confusion for navigators even if specific information is overlapped and distinguished by transparency or colour.
Table 2. Examples of various surface symbols
6.3 Consideration of additional symbols – offshore wind turbines
Among the features used in the existing electronic chart, many are not yet defined in the S-100 based electronic chart domain. Offshore wind turbines are an example.
Offshore wind turbines covering extensive areas are becoming increasingly commonplace around the world. However, since the areas containing wind turbines overlap with the coastal water areas used by vessels, such overlapping can be an obstacle to safe navigation (Lee and Cho, Reference Lee and Cho2022). Ships may encounter both fixed offshore wind turbines in coastal waters and floating offshore wind turbines located in deeper waters further from shore. In order to ensure the safety of navigation for ships, these areas need to be marked separately. In particular, the floating wind turbines installed far out to sea are not fixed to the seabed but move in a moored state, so it is necessary to express a symbol that includes a turning radius. As shown in Figure 16, the stationary offshore wind turbine is registered as a point symbol in the IHO Geospatial Information Registry for INT 1, C-map and S-52. However, no symbol yet exists for floating wind turbines and consideration is needed for the creation of a new symbol.
Figure 16. Symbol for fixed offshore wind turbine
In this paper, a new symbol based on the symbol for a fixed offshore wind turbine is studied. A floating offshore wind turbine symbol was devised to replace the circle of the existing fixed offshore wind turbine symbol with a triangle, as shown in Figure 17. It is very similar to the shape of the existing offshore wind turbine symbol, but it clearly indicates that it is a different kind of offshore wind turbine by using a triangle instead of a circle.
Figure 17. Design of symbol for floating offshore wind turbine
7. Discussion and conclusion
This paper has considered the development of S-100 product specifications from the point of view of navigation system software developers.
Section 2 explained the general process of developing software using product specifications. The number of industries participating in this process needs to increase for the development and introduction of high-quality products to the users. Appropriate references and practices to which they can refer should also be provided.
Section 3 analysed the method of expression of the product specification data models directly related to the development of software. The relations between features affect not only efficient memory operation but also system performance of navigation equipment. Also, the results of data and feature modelling in different product specifications can result in confusion for software engineers. This may lead to engineers having to make their own decisions and thus result in products that lack consistency and reliability.
Sections 4 and 5 analysed product specifications related to ECDIS and VTS equipment and described additional considerations. Section 4 discussed drawing sequences, conditional symbolisation and display methods of situational adaptive features for implementing S-100 software products for ECDIS. Additionally, a definition of the existing S-52/57 product specifications is provided. Though it is not easy to apply the three concepts to the more than 30 types of S-100 based product specifications, it is nonetheless essential. Section 5 analysed the related product specifications for the implementation of S-100 software products for VTS. S-127 defines the VTS service from the perspective of vessel navigation, while S-212 uses a shore-based perspective. Although the environment of each product used is different, the commonality lies in handling maritime traffic information. As a result, much information is duplicated on both sides, and information with redundant meaning is separately distinguished by different names.
Section 6 investigated symbols with redundancy in some product specifications. The results suggest there are many examples of redundant symbols due to different display symbols having the same meaning which may overlap when displayed on the electronic chart simultaneously. This may not convey accurate information to navigators and is not conducive to safe navigation. The section analyses the need for a new symbol for floating offshore wind turbines and proposes a new symbol to address the need.
Although not an exhaustive study, the work described in this paper highlights problems which become most apparent when software is developed to make equipment that needs to work with and display information from new S-1xx and S-2xx product specifications.
Acknowledgements
The authors wish to thank Dr Lee Alexander and Mr Nicholas Lemon for their assistance in improving the manuscript so it can be understood by a wide range of readers and not only those with a deep technical understanding of the topic.
This research is a part of ‘AI-based heavy cargo ship logistics platform demonstration project’ hosted by the Ulsan ICT Promotion Agency, supported by the National IT Industry Promotion Agency and the Ministry of Science and ICT (Project number: S1510-22-1001).
Open access
