Cloud Service Platform and Method for Operating the Same in an MCP-Linked Maritime Communication Environment

Abstract

The present invention relates to a digital maritime service platform and a method for operating the same for securely and consistently linking data between a ship terminal and a digital maritime service in a maritime communication environment linked with an MCP. Request messages transmitted from the terminal via the MCP are received by an API gateway and routed to multiple digital maritime services, and authentication, authorization, and encryption are performed using SECOM security standards and MRN-based identity and service registration information. Furthermore, by integrally collecting call logs, status information, trace information, and performance indicators for each service and providing them via a dashboard, the distributed service structure can be standardized on a single platform, and service status can be monitored in an integrated manner, thereby improving operational efficiency and communication reliability.

Description

Technology Field

[0001] The present invention relates to a maritime service platform, and more specifically, to a maritime service platform and a method of operation thereof that integrates and manages the integration of Application Programming Interfaces (APIs) between a ship terminal and a maritime service in an MCP-linked maritime communication environment, and provides access control, service caching, and status monitoring functions. Background Technology

[0002] In general, maritime communication systems and services are utilized as critical technologies in various fields, including ship navigation safety, increased efficiency, and marine environmental management. In particular, unlike land-based environments, the marine environment is characterized by inconsistent communication quality and complex service access and management as ships are constantly in motion. In such an environment, the stable provision of essential maritime services, such as Electronic Chart Display and Information Systems (ECDIS) or Electronic Chart Systems (ECS), is critical for the safe operation of vessels.

[0003] Meanwhile, in conventional digital maritime service provision structures, a method was primarily used where terminals (ECDIS, ECS, etc.) directly called individual access points for each digital maritime service. Furthermore, even when accessing distributed services through a Maritime Connectivity Platform (MCP), different connectivity standards and security settings were frequently applied to each service. Consequently, a proliferation of service-specific endpoints and complex connectivity configurations between terminals and services led to the problem of repetitive configuration and verification work for individual terminals and services whenever a new digital maritime service was added or modified.

[0004] In addition, it was difficult to consistently apply SECOM (Secure Communication), a security communication standard recommended by the International Maritime Organization, across the entire distributed maritime service environment. Consequently, there were issues such as insufficient security (confidentiality, integrity) of data transmitted between maritime services, and difficulties in utilizing the authentication and registration functions of the Identity Register (MIR) and Service Register (MSR) based on Maritime Resource Identifiers (MRN) in conjunction.

[0005] Furthermore, in a structure where each digital maritime service operates individually, logging and monitoring are performed in a distributed manner for each service. Consequently, it is difficult to comprehensively aggregate logs by service transaction to monitor the status, usage patterns, and failure timing of the entire maritime service platform from a single perspective, and there were limitations in systematic operational management utilizing distributed tracing and performance metrics.

[0006] Therefore, a new digital maritime service platform and its operation method are required that can collectively link and manage digital maritime services associated with MCP based on an API gateway, reflect the security and communication specifications required by SECOM standards across the entire API gateway and maritime service platform, and integrally collect and monitor logs, tracking information, and performance indicators for each service transaction. Prior art literature

[0007] U.S. Patent Publication US 2019-0318309 A1 (Published Oct. 17, 2019)

[0008] Lee, S., Kim, Y., Park, J., & Choi, H. (2022). “and Development of Maritime Data Security Management Platform,” Applied Sciences, 12(2) The problem to be solved

[0009] The objective of the present invention is to solve the aforementioned conventional problems by improving the issues where security standards and connection methods are not unified and service endpoints are managed in a distributed manner during the process of individually connecting digital maritime services linked to a Maritime Connectivity Platform (MCP) by terminal and service, and by providing an API gateway-based digital maritime service platform and a method for operating the same that can provide various digital maritime services in a secure and consistent manner on a single platform.

[0010] In particular, the invention provides a digital maritime service platform and a method for operating the same, which applies an API gateway as a core element of the platform and unifies multiple service endpoints called by terminals (ECDIS, ECS, etc.) through the maritime connectivity platform via the API gateway, thereby enabling the International Maritime Organization maritime services (16 types of IMO MS) and new digital maritime services provided in an MCP environment to be integratedly linked and managed according to standardized linkage specifications and security procedures.

[0011] Furthermore, the invention provides a digital maritime service platform and a method for operating the same that incorporates the encryption methods and message formats required by SECOM (Secure Communication) standards into the design of MCP linkage and API gateway security protocols, and links Maritime Resource Identifiers (MRNs) and service information registered in the Identity Register (MIR) and Service Register (MSR) to provide a secure communication environment capable of enhancing the confidentiality and integrity of data transmitted between digital maritime services and ensuring the trust of the communicating parties.

[0012] Furthermore, the invention provides a digital maritime service platform and a method for operating the same that can implement an integrated monitoring system for the entire digital maritime service and provide quantitative indicators necessary for operation and management by collecting and aggregating service transaction-specific logs, tracking information, and performance indicators generated through an API gateway, applying OpenTelemetry in the middle of distributed tracking tools, and providing common API functions for API logging and status monitoring of each service.

[0013] The problems of the present invention are not limited to those mentioned above, and various modifications and applications based on the technical concept of the present invention are possible, and it goes without saying that all such modifications are included within the technical scope of the present invention. means of solving the problem

[0014] A maritime service platform for achieving the objective of the present invention is a platform for performing data linkage between a ship terminal and a digital maritime service through a maritime connectivity platform (MCP), and includes an API gateway unit that receives an Application Programming Interface (API) request for calling a maritime service from a ship terminal and relays the API request to one or more digital maritime services. In addition, the system includes a maritime connection platform linkage management unit that links with the MCP to manage identity and service information regarding ship terminals, digital maritime services, and maritime service platforms, and controls the linkage targets of the API gateway unit based on said information; a digital maritime service linkage unit that registers and manages multiple digital maritime services on the maritime service platform and distributes API requests transmitted from the API gateway unit to the registered digital maritime services; a secure communication unit that performs encryption, integrity protection, and mutual authentication on data transmitted between the ship terminal and maritime services in a maritime communication environment; and an integrated monitoring unit that collects and stores logs, status information, and performance indicators related to the operation of the API gateway unit and the digital maritime service linkage unit, and provides the results to the operator, thereby enabling the centralized execution of digital maritime service linkage in an MCP environment on a single platform.

[0015] In addition, in one embodiment of the present invention, the API gateway unit is configured to integrate the individual connection points of the ship terminal and the digital maritime service, respectively, into a single connection structure. At this time, the API gateway unit centrally controls the service integration flow within the platform by determining routing regarding which digital maritime service a received API request should be delivered to, access control regarding whether to allow the request, and processing priority regarding which request to process first when multiple requests are received simultaneously, according to integration policies set for each service and terminal.

[0016] Furthermore, the Maritime Connectivity Platform Integration Management Unit links with the identity registration and service registration functions provided by the MCP to acquire and manage identification information for both vessel terminals and digital maritime services. By providing this acquired and managed identification information to the API Gateway Unit and the Digital Maritime Service Integration Unit, the Maritime Connectivity Platform Integration Management Unit enables the platform to recognize which terminal attempts to access which service within the MCP environment, thereby allowing the centralized application of integration policies and service selection accordingly.

[0017] In addition, the Digital Maritime Service Linkage Unit registers and manages multiple maritime services on the maritime service platform, including not only digital maritime services defined by the International Maritime Organization but also new digital maritime services such as support for low-carbon operations, operational performance management, and departure time prediction. The Digital Maritime Service Linkage Unit maintains and manages service identifiers, connection information, and usage authorization information for each registered maritime service, and by ensuring that this information is linked with the API Gateway Unit, it enables the platform to consistently determine internally which service should process a request and whether the requesting party has the authority to access that service when an API request is received.

[0018] Meanwhile, the Secure Communications Department sets security parameters to be used for communication between ship terminals and maritime services in accordance with the secure communication standards required in the maritime sector, and performs encryption and integrity verification on request and response messages transmitted and received through the API Gateway Department. At this time, the Secure Communications Department allows interoperability through the Digital Maritime Service Linkage Department only for messages determined to be valid based on the encryption and verification results, and blocks interoperability for messages suspected of being abnormal or tampered with, thereby ensuring that maritime data exchange in the MCP environment satisfies security requirements.

[0019] In addition, the Integrated Monitoring Unit collects and stores information regarding the number of API calls, response times, status codes, error occurrences, and call distribution by service generated by the API Gateway Unit and the Digital Maritime Service Linkage Unit. Based on this collected information, the Integrated Monitoring Unit visualizes and displays real-time status, response performance by time period, and usage status by service, thereby enabling the integrated monitoring of the entire maritime service platform's operational status through a single or multiple monitoring screens. Operators can utilize this to detect signs of failure or performance degradation at an early stage and respond accordingly.

[0020] According to another aspect of the present invention, a method for providing maritime services using a maritime service platform for linking data between a ship terminal and a digital maritime service through an MCP includes, first, a step of generating an API request for calling a maritime service from a ship terminal and transmitting it to an API gateway unit of a maritime service platform. Subsequently, the maritime service platform performs a step of verifying the identity and security information of the sender and target service of the API request using a maritime connection platform linkage management unit and a secure communication unit, then proceeds to a step of transmitting the verified API request to one or more digital maritime services through a digital maritime service linkage unit to perform the requested service, and sequentially performs a step of returning a response provided by the digital maritime service to the ship terminal through an API gateway unit, thereby completing the procedure for providing maritime services in an MCP-linked maritime communication environment.

[0021] In addition, the above-mentioned method for providing maritime services may further include a step of collecting and storing call logs, status information, and performance indicators generated during the processing of API requests and responses in an integrated monitoring unit, and providing the operational status of the maritime service platform through various monitoring screens based on the collected information. The data accumulated in this step is utilized not only for real-time status verification but also for long-term performance analysis and quality management.

[0022] According to another embodiment, if an invalid certificate, token, or identification information is detected during the step of verifying the authentication and security information, the maritime service platform stops processing the relevant service request and generates an error response, which is returned to the vessel terminal. At the same time, by recording the details of such error occurrences as a log in the integrated monitoring unit, the history can be used as a basis for subsequent security audits and failure analyses, and a foundation is provided for applying separate policies to repeated abnormal access.

[0023] In addition, the step of transmitting the service request to the digital maritime service may comprise referring to the current load status, availability, and recent response performance information of a plurality of digital maritime service instances to select a digital maritime service instance suitable for processing the service request, and transmitting the service request to the selected instance. Accordingly, an operational method is enabled that prevents traffic from being concentrated on a specific instance and maintains balanced overall service response performance.

[0024] In addition, the step of collecting and storing log and monitoring information may include a step of analyzing operational indicators such as the number of calls, response time, and error rate aggregated in real time, generating an alarm when a preset threshold is exceeded, and recording the history of said alarm generation. If necessary, control may also be performed to ensure the stable operation of the entire platform by temporarily restricting new requests for specific digital maritime services or adjusting processing priorities between services according to alarm conditions.

[0025] In addition, the method for providing maritime services according to the present invention may further include the step of receiving a registration request for a new digital maritime service from a service provider, registering the new service in conjunction with the service registration function of a maritime connection platform, and reflecting identification information and connection information for the new service within the maritime service platform so that subsequent API requests can be routed to the new digital maritime service. Accordingly, a means for solving the problem is provided that enables rapid service expansion while maintaining the MCP linkage structure and the existing integration system of the maritime service platform, even when a new digital maritime service is added. Effects of the invention

[0026] According to the digital maritime service platform and the method of operation thereof of the present invention, one or more of the following effects are provided.

[0027] First, according to the present invention, by applying an API gateway as a core element of a digital maritime service platform and unifying multiple digital maritime service endpoints called by terminals (ECDIS, ECS, etc.) through a Maritime Connectivity Platform (MCP) via the API gateway, the interconnection structure of individual service units that were previously distributed can be simplified into a single access point structure. Accordingly, International Maritime Organization maritime services (16 types of IMO MS) and new digital maritime services can be linked and managed in a consistent manner on a single platform, thereby reducing the burden of configuration and verification when adding or changing services and improving the operational efficiency of the entire platform.

[0028] Second, according to the present invention, the encryption method and message format required by the SECOM (Secure Communication) standard are reflected in the design of the MCP linkage and API gateway security protocols. Furthermore, by linking with the Maritime Identity Registry (MIR) and Maritime Service Registry (MSR) utilizing Maritime Resource Names (MRNs), the confidentiality and integrity of data transmitted between maritime services can be enhanced, and the reliability of the communicating parties can be secured. This enables the safe provision of digital maritime services in an e-Navigation environment while complying with international maritime communication standards.

[0029] Third, the digital maritime service platform according to the present invention defines a REST API-based JSON message linkage (HTTP / HTTPS) method through an API gateway and standardized header and message specifications, thereby enabling service providers to register their digital maritime services with the API gateway and manage them using linkage identification identifiers. Accordingly, various digital maritime services can be linked with the platform according to common linkage specifications, thereby enhancing interoperability and facilitating data linkage and expansion with external platforms.

[0030] Fourth, according to the present invention, by establishing an API gateway-based service integrated monitoring system, collecting logs by service transaction, providing common API functions for API logging and status monitoring of each service, and applying OpenTelemetry in the middle of distributed tracing tools, an integrated monitoring and distributed tracing environment for the entire digital maritime service can be provided. In addition, by visualizing real-time connection status, API call status, call status by status code, response time, number of calls per service, and average execution time using performance metrics of open source monitoring tools, there is an effect of securing quantitative operational indicators for failure cause analysis and performance optimization.

[0031] The effects of the present invention are not limited to those mentioned above, and other effects that can be clearly understood by a person skilled in the art through various modifications and applications based on the technical concept of the present invention are also included within the technical scope of the present invention. Brief explanation of the drawing

[0032] Figure 1 is a diagram illustrating the MCP concept. FIGS. 2 and FIGS. 3 are block diagrams illustrating the configuration of a digital maritime service platform according to the present invention. FIG. 4 is a diagram illustrating examples of IMO maritime services and new maritime services according to the present invention. Figure 5 is a diagram illustrating an example of a monitoring screen within a digital maritime service platform. Figure 6 is a diagram illustrating an example of a real-time connection status management screen within a digital maritime service platform. Figure 7 is a diagram illustrating an example of a real-time API call status monitoring screen within a digital maritime service platform. Figure 8 is a diagram illustrating an example of an API call screen by status code within a digital maritime service platform. Figure 9 is a diagram illustrating an example of a service response time monitoring screen within a digital maritime service platform. Figure 10 is a diagram illustrating an example of the number of calls per service and the monitoring screen within a digital maritime service platform. FIG. 11 is a flowchart illustrating the procedure of a method for providing maritime services according to the present invention. Specific details for implementing the invention

[0033] The advantages and features of the present invention and the methods for achieving them will become clear by referring to the embodiments described below in detail together with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below but can be implemented in various different forms. These embodiments are provided merely to ensure that the disclosure of the present invention is complete and to fully inform those skilled in the art of the scope of the invention, and the present invention is defined only by the scope of the claims.

[0034] Throughout the specification, the same reference numerals refer to the same components. The size or shape of components depicted in the drawings attached to this specification may be exaggerated for clarity and convenience of explanation. It should be noted that in each drawing, the same components may be depicted by the same reference numeral. Furthermore, detailed descriptions of functions and configurations of known technology that are deemed to unnecessarily obscure the essence of the invention may be omitted. The terms used in this specification are for describing specific embodiments and are not intended to limit the invention.

[0035] As used herein, the singular form may include the plural form unless the context clearly indicates otherwise. Furthermore, throughout this specification, when a part is described as "comprising" a component, this means that it may include additional components unless specifically stated otherwise. When a component is described as being "connected" or "joined" to another component, it should be understood that it may be directly connected to or joined to that other component, or that there may be other components in between. Conversely, when a component is described as being "directly connected" to or "directly joined" to another component, it should be understood that there are no other components in between. Other expressions describing the relationships between components should be interpreted in the same way.

[0036] All terms used herein, including technical or scientific terms, have the same meaning as generally understood by those skilled in the art to which the present invention pertains, unless otherwise defined. Terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant technology, and should not be interpreted in an ideal or overly formal sense unless explicitly defined in this specification.

[0038] The present invention relates to a digital maritime service platform and a method for operating the same for securely and consistently linking data between a ship terminal and a digital maritime service in a maritime communication environment linked with a Maritime Connectivity Platform (MCP). Specifically, in order to provide integrated digital maritime services proposed by the International Maritime Organization (IMO MS 16 types) and new digital maritime services such as low-carbon operation support, operation performance management, and departure time prediction on a single platform, a linkage, security, operation, and monitoring structure centered on a maritime connectivity platform and an API gateway is defined.

[0039] Traditionally, ship terminals (ECDIS, ECS, etc.) and each digital maritime service were often directly interconnected via individual endpoints, or different service providers frequently used different connectivity standards and security settings. This resulted in complex service configurations and required the repetitive modification of multiple systems whenever changes or additions were made. Furthermore, even if data exchange between maritime services complied with international standards, communication paths, authentication methods, and logging and monitoring systems were often separated by service in actual operating environments, presenting a limitation that made integrated management and fault analysis from a platform-wide perspective difficult.

[0040] To solve this problem, the present invention adopts a structure in which an API gateway is placed as a core element within a digital maritime service platform linked to an MCP, and all requests transmitted from the ship terminal through the MCP are converged into the API gateway. The API gateway uses a REST-based Application Programming Interface (REST API) to transmit and receive messages in JSON format, and by unifying service access points based on the Hypertext Transfer Protocol (HTTP / HTTPS), it enables the collective control and management of the interaction between the terminal and the digital maritime service under a standardized interface.

[0041] In addition, the present invention incorporates the encryption method and message format required by the SECOM (Secure Communication) standard into the design of MCP linkage and API gateway security protocols, and integrates the management of identity information for vessels, systems, users, and service providers by linking the Identity Register (MIR) and the Service Register (MSR) centered on the Maritime Resource Identifier (MRN). By verifying communicating parties using Public Key Infrastructure (PKI)-based certificates and OpenID Connect tokens, and controlling access to digital maritime services based on the verified results, it secures the level of security and trust required in an international e-Navigation environment.

[0042] In terms of digital maritime service integration, the present invention integrates distributed maritime service access points into a single MCP-based connection structure by having a service provider register its digital maritime services in a service registry and assign a connection distinction identifier to an API gateway. Accordingly, ship terminals perform calls targeting only a single platform (API gateway) via the MCP, enabling them to utilize various digital maritime services without being aware of the actual location or detailed configuration of the target service. This provides service scalability and interoperability that allow for flexible responses to the addition of new services, integration with other platforms, and policy changes in the future.

[0043] In terms of operation and monitoring, the present invention collects call logs, status information, trace information, and performance metrics generated from the API gateway and each digital maritime service via a common API, and stores and processes them in an integrated format using distributed tracing tools and OpenTelemetry. The collected data is provided through various monitoring screens displaying real-time connection status, API call status, call distribution by status code, response times by time of day, the number of calls per service, and average execution time, enabling operators to grasp the status and performance of the entire platform at a glance.

[0045] Consequently, the digital maritime service platform and operation method according to the present invention provide technical means to link and manage distributed digital maritime services in a secure and standardized manner on a single platform, and to comprehensively monitor service status and performance, by combining MCP, SECOM, MIR, MSR, MRN, API gateway, and integrated monitoring technology. This has the effect of simultaneously ensuring stability, operational efficiency, and consistency with international standards in the provision of digital maritime services within a maritime communication environment.

[0047] Hereinafter, a maritime service platform based on an MCP-linked maritime communication environment and a method of operating the same according to an embodiment of the present invention will be described in detail with reference to the drawings.

[0048] FIG. 1 is a diagram illustrating the basic concept of a Maritime Connectivity Platform (MCP) that serves as the premise for the present invention. The Maritime Connectivity Platform (MCP) is an integrated platform designed to connect various digital maritime services and stakeholders in a common manner within the maritime sector. The MCP aims to enable ships, ports, control agencies, service provision systems, etc., to securely exchange information according to the same identity management system, service registration system, and messaging rules, even if they use different network environments and technology stacks.

[0049] To this end, the MCP has the Identity Register (MIR), Service Register (MSR), and Maritime Message Service (MMS) as core components. The MIR manages digital identities by assigning Maritime Resource Identifiers (MRNs) to maritime resources such as vessels, systems, users, and organizations, and by issuing and verifying MCP certificates using a Public Key Infrastructure (PKI). It also provides tokens based on the OpenID Connect standard, which are utilized for the authentication and authorization of services and terminals operating on the MCP. The MSR acts as a service catalog where service providers register their digital maritime services and manage metadata and endpoint information, while service users can search for and select necessary services through the MSR. The MMS performs a broker function by using the MRN as a destination identifier to transmit messages via IP and non-IP communication channels, thereby supporting consistent message delivery even in maritime environments utilizing diverse communication infrastructures.

[0050] In this invention, the MCP is presupposed to be a common infrastructure including the MIR, MSR, and MMS, and the proposed digital maritime service platform operates as a single service provider and endpoint directly linked to the MCP. Ship terminals (ECDIS, ECS, etc.) transmit REST-based requests to the API gateway of this invention via the MCP, and the platform routes the requests to the appropriate digital maritime service using service information registered in the MSR. In this process, each terminal, service, and platform component is mutually authenticated through the MRN managed by the MIR and the MCP certificate, and encryption and signature methods in accordance with SECOM standards are applied to the communication section.

[0051] Ultimately, the MCP is a foundational platform corresponding to the “public road network” of the maritime domain, and the maritime service platform of the present invention is an “integrated service hub” built upon this MCP. By providing common rules and functions for identity, services, and messaging, the present invention implements a structure that enables the integrated interoperability and operation of various digital maritime services on a single platform through API gateways, secure communication, and integrated monitoring functions.

[0053] FIGS. 2 and 3 are block diagrams illustrating the overall configuration of a maritime service platform based on an MCP-linked maritime communication environment according to the present invention, showing a structure in which a ship terminal, an MCP-based maritime communication network, a central maritime service platform, and a maritime service area on the right are interconnected in a single continuous flow.

[0054] Referring to FIG. 2, a maritime service platform according to one embodiment of the present invention is a maritime service platform (1000) for performing data linkage between a ship terminal and a digital maritime service through a maritime connection platform (MCP), and includes an API gateway unit (100) that receives an application programming interface (API) request for calling a maritime service from a ship terminal and relays the API request to one or more digital maritime services. In addition, the system includes a maritime connection platform linkage management unit (200) that links with the MCP to manage identity and service information for a ship terminal, a digital maritime service, and a maritime service platform (1000), and controls the linkage targets of the API gateway unit (100) based on said information; a digital maritime service linkage unit (300) that registers and manages multiple digital maritime services on the maritime service platform (1000) and distributes API requests transmitted from the API gateway unit (100) to the registered digital maritime services; a secure communication unit (400) that performs encryption, integrity protection, and mutual authentication on data transmitted between the ship terminal and the maritime service in a maritime communication environment; and an integrated monitoring unit (500) that collects and stores logs, status information, and performance indicators related to the operation of the API gateway unit (100) and the digital maritime service linkage unit (300), and provides the results to an operator, thereby enabling the digital maritime service linkage in an MCP environment to be performed centrally on a single platform (1000).

[0056] FIG. 3 illustrates the maritime service platform of the present invention in more detail. On the left side of FIG. 3, terminals installed on a ship, such as an Electronic Chart Display and Information System (ECDIS) and an Electronic Chart System (ECS), are shown. These terminals have client functions that support SECOM security standards and transmit HTTP / HTTPS requests based on REST State Transitioning to the digital maritime service platform via the MCP. Each terminal identifies itself using a Maritime Resource Identifier (MRN) assigned by the MCP and performs mutual authentication with the platform side using a certificate and token provided by the MCP. These terminals correspond to Service Users utilizing various digital maritime services such as chart information, route hazards, warnings, weather, and port information, and all service calls are transmitted to the central maritime service platform via the MCP.

[0057] An MCP-based communication segment is located between the terminal and the maritime service platform. This communication segment serves as a common transmission network for the secure transfer of data between sea and land, and uses an MRN to specify the logical addresses of the sender and receiver. Service request messages generated by the vessel terminal reach the maritime service platform of the present invention through the MCP messaging function, and response messages are delivered to the terminal via the reverse path. In this process, the MCP operates as an abstraction layer that identifies and connects communication partners regardless of the detailed implementation of the network layer (satellite, terrestrial, hybrid network, etc.).

[0058] In the center of Fig. 3, the “maritime service platform,” which is the core of the present invention, is illustrated. This platform is largely composed of an API Gateway layer, a SECOM linkage layer (APIG-SECOM), a repository and information collection layer, and an API operation management layer.

[0059] First, the “Gateway” block at the top is represented as a logical gateway that converges and distributes all application layer traffic between the vessel terminal and the maritime service. As illustrated in Fig. 2, the API Gateway contains detailed function blocks such as “Routing,” “Lifecycle,” “Access Control,” “Flow Control,” “Status Monitoring,” and “Service Caching.” The API Routing function analyzes HTTP methods, URL paths, and target service MRNs included in headers to determine which digital maritime service instance a request should be forwarded to. The Lifecycle function is used to expose only valid APIs externally by considering operational statuses such as service-specific API version management, deployment status, and decommissioning status. The Access Control function verifies the authority of the caller based on information such as MCP and SECOM authentication results, API keys, and tokens, ensuring that only authorized terminals and services can call the corresponding API. The API Flow Control function prevents excessive traffic concentration on specific services and maintains stable response performance for the entire platform by policy-wise limiting the call frequency and number of concurrent connections per service and terminal. The status monitoring function collects status information such as response codes, response times, and error occurrences from individual APIs in real time and provides it to the monitoring layer described later. The service caching function stores response data for identical or similar requests for a certain period, thereby mitigating service load and reducing response delays by skipping backend service calls and returning cached responses upon repeated requests.

[0060] The “-(SECOM)” block is located on the left side of the API Gateway. This block represents an interconnected gateway module designed according to MCP and SECOM security standards, and it serves as the interface between the communication channel on the MCP side and the platform's internal API Gateway. APIG-SECOM performs encryption, signing, and certificate verification required by SECOM standards on messages received from the MCP, and then forwards only requests deemed valid to the API Gateway. Furthermore, it applies encryption and security processing in accordance with SECOM standards in reverse to response messages transmitted from the API Gateway to the maritime service, and then forwards them to the MCP. During this process, APIG-SECOM utilizes the MCP certificate and public key issued by the MIR, service information registered in the MSR, and OpenID Connect tokens to verify the identity of the communicating parties and check for forgery or tampering.

[0061] Beneath the API Gateway and APIG-SECOM, the “Repository” block and surrounding it are depicted the “Information Collection,” “Monitoring Information Collection,” and “Log Collection” blocks. This section represents the data collection and storage layers used for integrated monitoring and operational analysis in the present invention. The Information Collection block collects general operational information related to API calls, while the Monitoring Information Collection block aggregates performance metrics and trace information collected through open-source monitoring tools and OpenTelemetry. The Log Collection block integrates access logs, error logs, and business logs generated from the API Gateway and the maritime service, respectively, and records them in the repository. The repository preserves this data in the form of a time-series database or log repository, enabling operators to subsequently view and analyze service status through dashboards or analysis tools.

[0062] The “Operations Management” block, diagrammed alongside the repository, is the layer that manages the metadata and operational status of APIs provided by the platform. Internally, it includes function blocks for “Operations,” “Search,” “History,” “Specifications,” “Authority Management,” and “Status Monitoring.” The API Operations function performs lifecycle management for new APIs, such as registration, modification, deactivation, and deletion, while the API Search function enables users to locate APIs meeting specific criteria from a list of APIs existing across multiple digital maritime services. The History function manages API configuration changes, deployment history, and key operational events, serving to track the causes of issues and analyze the impact of changes when they occur. The API Specifications function documents and manages the paths, HTTP methods, input / output data structures, and exception codes of each API, allowing service providers and users to reference common specifications. The API Authorization Management function defines the range of callable APIs and authorization levels based on user groups, service providers, and device types, and implements policy-based access control by linking this information with the API Gateway’s access control functions. The status monitoring function utilizes monitoring data previously accumulated in the repository to visualize metrics such as the number of calls, response times, and error rates per API in a dashboard format, enabling operators to understand the platform status in real time.

[0063] On the right side of Fig. 3, the “Maritime Services” area is illustrated, and a block labeled “MS and New (SECOM)” is placed at the top. This refers to a set of services that includes 16 types of digital maritime services proposed by the International Maritime Organization, as well as newly defined digital maritime services such as low-carbon operation support, ship operation performance management, and departure time prediction. Within this block, there is a “Service” layer that provides actual business functions and a “Common Module” layer that is used in common by the services.

[0064] The “Service” layer includes the business logic implemented for each individual digital maritime service, such as the Global Surrounding Vessels Service, Route Risk Information Service, Maritime Traffic Control Service, Pilotage Information Service, and Search and Rescue Service. Each service provides a REST API linked to the API Gateway and integrates with the platform by registering its metadata and endpoint information with the MSR.

[0065] Within the “Common Module” layer, the “Status Monitoring,” “Specification,” “Logging,” and “Resource Management” blocks are depicted. The Status Monitoring module collects the availability, load status, and error status of each digital maritime service and transmits them to the platform’s monitoring layer. The API Specification module manages service-specific API definitions and enables centralized querying and updating of specifications in conjunction with the API Operations Management layer. The Logging module collects business and error logs generated during internal service processing and transmits them to the repository via the previously described log collection block. The Resource Management module monitors the status of computing resources, such as the number of service instances, thread usage, memory, and CPU usage, and provides reference information for scaling up or down as necessary.

[0066] An MCP communication section is also illustrated between the maritime service area and the central maritime service platform. Through this, the platform of the present invention interacts with the terminal-side MCP on one hand and the service-side MCP on the other, respectively, and performs the role of mediating traffic coming from both sides through the API Gateway-APIG-SECOM structure. Since the terminal and the service do not communicate directly with each other but are connected indirectly through the MCP and the maritime service platform, controls such as security, policy, and monitoring can be consistently performed from the center of the platform.

[0068] FIG. 4 is a diagram illustrating examples of International Maritime Organization (IMO) standard maritime services and new maritime services linked in the digital maritime service platform according to the present invention. As shown in the diagram, the top of the table includes MS1-1 Global Service for Surrounding Vessels, MS1-2 Route Risk Information Service, MS1-3 Maritime Traffic Control Service, MS1-3 Vessel Slow-Speed ​​Service, etc., representing services related to navigation and operational safety support. Subsequently, MS4 Port Call Message Vessel Linkage Service, MS4 Vessel ISPS Support Service, MS5 Global Service for Maritime Safety Information, MS6 Pilotage Information Provision Service, MS7 Tugboat Information Provision Service, MS8 Vessel Coastal Reporting Service, MS9 Telemedicine Assistance Service, MS10 Maritime Assistance Service, MS11 Chart Service, and MS12 Hydrographic Bibliographic Service are listed to exemplify services related to port entry and exit, security, navigation information, coastal reporting, medical support, and the provision of chart and hydrographic information. In addition, MS13 (Ice Sea Information Provision Service), MS14 (Marine Weather Information Service), MS15 (Real-time Hydrographic and Environmental Information Service), and MS16 (Search and Rescue Service) are included, representing services utilized in special operational situations such as ice sea navigation, weather and environmental information, and search and rescue support. The bottom of the table shows examples of the new services proposed in the present invention: New 1 (Low-Carbon Operation Support Service), New 2 (Ship Operation Performance Management Service), and New 3 (Ship Departure Time Prediction Service). As such, each service illustrated in FIG. 3 represents a specific example of a digital maritime service registered in the service register within an MCP environment.

[0070] FIG. 5 is a diagram illustrating an example of a monitoring screen for comprehensively viewing and analyzing API call history in a digital maritime service platform according to the present invention. At the top of the screen, filter buttons for status codes (2xx, 3xx, 4xx, 5xx), a start and end time selection area for setting the viewing period, and a search window for searching API service names or URIs are arranged, allowing the operator to quickly narrow down the display targets according to desired conditions.

[0071] A table-shaped list is provided at the bottom of the screen, and each row displays the number, status code, transaction ID, API / service name, HTTP method, gateway node, front URI, and source and destination addresses in chronological order. Through this, it is possible to check on a single screen which digital maritime service was called with which status code at a specific point in time, which gateway node processed it, and which terminal and service communication took place. With a screen configuration like that of Fig. 4, the operator can efficiently utilize the integrated monitoring function provided by the present invention, such as by collectively querying a large volume of service calls occurring in an MCP environment based on the API gateway, quickly detecting error sections or abnormal patterns, and linking to a detailed analysis screen.

[0073] FIG. 6 illustrates an example of a monitoring screen that visualizes and provides HTTP statistics within a digital maritime service platform according to the present invention. A Request Count graph is placed at the top of the screen to display changes in the number of requests for each API endpoint during a specific time interval (e.g., 15:30–16:25) in the form of bars or lines, and the legend on the right distinguishes colors for endpoints such as GET / v1 / object, GET / v1 / object / summary, GET / api, GET / swagger-ui / **. Through this, one can intuitively check which API requests are concentrated during a specific time period and how traffic patterns change.

[0074] At the bottom, a Response Time graph is displayed, showing the response time of each API as a dot for the same time interval, along with the average, maximum, and minimum response times. Similarly, the legend on the right distinguishes colors by endpoint, making it easy to identify which APIs have relatively long response times or large fluctuations. Through a screen like the one in Fig. 5, operators can simultaneously monitor traffic volume and response performance for HTTP-based API calls of the digital maritime service platform, and utilize this information for cause analysis and performance tuning in the event of abnormal patterns.

[0076] FIG. 7 illustrates an example of a real-time status dashboard screen within a digital maritime service platform according to the present invention. At the top of the screen, the latest update time is displayed along with the title “Real-time Status,” and below it, key operational indicators such as the number of gateway nodes, the number of API operations, the number of API responses, the number of alert notifications (warnings), the number of alert notification failures, and the average API response time are arranged in a card format. Each card displays both the current value and the cumulative total, allowing the operator to grasp the normal / stopped status of gateway nodes, the occurrence of warnings or failures, and the overall API response performance at a glance. An area for setting the automatic refresh cycle is located at the top right, enabling near-real-time monitoring.

[0077] At the bottom left of the screen, a “Number of API calls by time (cases)” graph is displayed, showing the number of API calls by time period from 0:00 to 24:00 as a line graph, and providing distinctions based on status code groups (2xx, 3xx, 4xx, 5xx) using colors or legends. This allows for intuitive verification of whether call volume surges during specific time periods or if there are sections where error responses are concentrated. At the bottom right, a “Number of API call response times by time (ms)” graph is placed, displaying minimum, maximum, and average response times on the same time axis using lines of different colors. Through this graph, operators can identify changes in response times over time in real time and immediately check for delays caused by changes in network status or increased load on specific services. A real-time status screen like the one in Fig. 6 is a core component of the integrated monitoring function provided by the digital maritime service platform of the present invention and is utilized to comprehensively monitor the operational status of the API gateway and each digital maritime service.

[0079] FIG. 8 illustrates an example of a trace monitoring screen for querying distributed trace information within a digital maritime service platform according to the present invention. At the top of the screen, a query area is arranged where conditions such as Service Name, Span Name, Status, Duration, and Tags can be set. The operator can, for example, select a specific Service Name (gmdrt-sv52) and a specific API endpoint (GET / v1 / object) to query only the trace information for the corresponding request. At the bottom, a “- Traces” area is arranged, where the Trace ID, Start time, Service Name, Name, and Duration are listed in a table format. By selecting each row, detailed trace information for an individual request can be viewed. Through the screen of FIG. 7, the operator can analyze the digital maritime service call path step by step using trace data collected based on OpenTelemetry and precisely identify sections where delays or errors occur.

[0081] FIG. 9 illustrates an example of a screen that visualizes and displays the hourly API call response time within a digital maritime service platform according to the present invention. The horizontal axis of the graph displays time zones from 0:00 to 24:00, and the vertical axis displays the response time (ms). The minimum response time (green), maximum response time (blue), and average response time (yellow) are represented by curves and points of different colors. Since the maximum response time value is displayed as a number for each time zone, it is possible to intuitively identify which time intervals experience significant response delays. Through a screen like FIG. 8, the operator can monitor the API response performance of the digital maritime service platform by time zone, analyze whether delays or performance degradation occur at specific points in time, and utilize this information to respond to changes in network status or service load.

[0083] FIG. 10 illustrates an example of a screen for managing API lists and call status by service within a digital maritime service platform according to the present invention. A node identifier “ ” is displayed at the top, and a menu for selecting management functions such as general, API, log, and system information is arranged on the left. In the table in the main area, for each API, the deployment status, API / service name, specification name, number of processing cases, average processing time, and author information are displayed row by row, and the deployment status icon allows for intuitive verification of whether the corresponding API is operating normally. Through a screen like FIG. 9, the operator can grasp the list of APIs for digital maritime services deployed to a specific node and the number of calls and processing performance by service at a glance, and if necessary, select an API to perform management such as deployment, deletion, or configuration change.

[0085] FIG. 11 is a flowchart illustrating the procedure of a method for providing maritime services using a maritime service platform based on an MCP-linked maritime communication environment according to the present invention. As illustrated in FIG. 11, the method for providing maritime services according to the present invention sequentially includes: an API request receiving step (S100) for receiving an API request for calling a maritime service from a ship terminal; an authentication and security processing step (S200) for performing authentication and encryption processing according to MCP and SECOM security standards; a service identification and transmission step (S300) for identifying a target digital maritime service by referring to identity register and service register information and transmitting a request to the corresponding service; a service response receiving step (S400) for receiving a response message including a processing result from a digital maritime service; a response return step (S500) for returning the received response to the ship terminal; and a log and monitoring collection step (S600) for collecting logs and performance indicators generated during the request and response process and providing them to an integrated monitoring system. Each step is described in more detail below.

[0086] First, Step S100 (API Request Reception Step) is the stage where the API gateway of the maritime service platform receives a service call request generated for the use of maritime services by a ship terminal, such as an Electronic Chart Display and Information System (ECDIS) or an Electronic Chart System (ECS). The ship terminal accesses the maritime service platform via the Maritime Connectivity Platform (MCP), and at this time, transmits a message containing a request body in JSON format and headers using the Hypertext Transfer Protocol (HTTP / HTTPS) in accordance with the REST State Transition (REST) ​​API. The API gateway parses information such as the source identifier, target service identifier, transaction ID, and content type included in the header of the received request, converts it into an internal structure for use in subsequent steps, and loads the request into a queue in a waiting state for processing.

[0087] Next, the S200 stage (Authentication and Security Processing stage) is a stage that performs authentication and security verification on API requests received in the S100 stage in accordance with MCP and SECOM (Secure Communication) standards. In this stage, the API gateway or SECOM linkage module first analyzes information such as certificates, tokens, and digital signatures included in the request to verify whether the request was sent from a legitimate vessel, system, or user registered in the Maritime Identity Registry (MIR). To this end, it performs processing such as certificate verification using Maritime Resource Identifiers (MRN), authentication path verification based on Public Key Infrastructure (PKI) standards, and OpenID Connect token validity verification. Subsequently, it inspects whether the request data is encrypted and integrity protected in accordance with the encryption algorithms and message formats required by SECOM standards, and if tampering, forgery, or replay attacks are suspected, it blocks the request or generates an error response. Only requests that have been determined to be successful in both authentication and security verification proceed to the subsequent Service Identification and Delivery stage.

[0088] The S300 step (service identification and delivery step) is a step in which, for a request that has completed authentication and security processing, it determines which digital maritime service will actually process it and delivers the request to the corresponding service instance. The API gateway queries the list of services registered in the Maritime Service Registry (MSR) and internal API specifications using the target service MRN or service code, request path (URI), and HTTP method information included in the request header. Based on the results of this query, it determines which individual digital maritime services—such as the surrounding vessel global service, route risk information service, marine weather information service, and low-carbon navigation support service illustrated in Fig. 3—should handle the current request, and delivers the request to the endpoint of a specific service instance, taking into account load balancing policies or the status of available instances. During this process, the API gateway refines the request into a call form for service integration by performing internal format conversion, header addition or modification, and timeout / retry policy application as necessary.

[0089] Phase S400 (Service Response Reception Phase) is the stage where the maritime service platform receives the response message returned by the digital maritime service after processing the request transmitted in Phase S300. The digital maritime service generates result data, such as route risk information, maritime safety information, weather and environmental information, port call messages, and performance analysis results, according to its respective business logic, and transmits this to the API gateway in the form of REST response messages. The API gateway interprets the status code, response body, and header information of the received response, converts them into an internal common format, and verifies the integrity and reliability of the response data through encryption and signature verification in accordance with SECOM standards. If an error occurs during service processing, a response containing the corresponding error code and message is received, and this information is utilized as fault analysis data in the subsequent logging and monitoring phases.

[0090] The S500 stage (response return stage) is the step of sending the response received and verified in the S400 stage back to the vessel terminal that initiated the initial request. The API Gateway matches the response using transaction IDs and session information, and constructs the header and body in a format recognizable by the vessel terminal. Subsequently, it transmits the response message via the MCP, applying SECOM-based encryption and digital signatures if necessary to ensure confidentiality and integrity during transmission. Upon receiving the response message, the vessel terminal provides digital maritime service results to the user, such as overlaying route risk information on the electronic chart screen or updating port call information and predicted departure times on the sailing plan screen. At this stage, the API Gateway saves the response return results (success / failure status, response transmission time, etc.) as internal status information so that they can be utilized in the next stage.

[0091] Finally, Step S600 (log and monitoring collection step) is a step in which various operational information regarding requests and responses generated in Steps S100 to S500 is collected and stored, and provided to an integrated monitoring system. Specifically, the API gateway and SECOM linkage module record the request time, response time, status code, processing time, name of the called service, MRN and IP of the calling terminal, and error code and message in the event of an error for each transaction in the form of logs. At the same time, trace information and performance metrics for each service call are collected using a distributed tracing framework such as OpenTelemetry. The collected log, trace, and performance data are accumulated as time-series data in a storage and visualized on a monitoring screen as illustrated in FIGS. 4 to 9, including real-time connection status, call status by status code, response time trends, number of calls per service, and average processing time. Through this, the operator can comprehensively monitor the status of the entire maritime service platform and the performance of each digital maritime service, and can quickly perform cause analysis and fault response in the event of anomalies.

[0092] As described above, the method for providing maritime services according to the present invention enables the provision of digital maritime services in a safe and consistent manner in an MCP environment and the systematic management of their operational status through a series of steps including receiving API requests, authentication and security processing, service identification and delivery, receiving and returning responses, and collecting logs and monitoring data.

[0094] As described above, preferred embodiments of the present invention have been illustrated and described with reference to the drawings; however, the present invention is not limited to the specific embodiments described above. Various modifications are possible by those skilled in the art without departing from the essence of the invention as claimed in the patent claims, and such modifications should not be understood individually from the technical spirit or perspective of the present invention. Explanation of the symbols

[0095] 1000 : Maritime Service Platform 100: API Gateway Section 200 : Maritime Connection Platform Interconnection Management Department 300 : Digital Maritime Service Integration Division 400 : Security Communications Department 500 : Integrated Monitoring Department S100: API request reception step S200: Authentication and security processing stage S300: Service Identification and Delivery Phase S400: Service response reception stage S500: Response return step S600: Log and monitoring collection phase

Claims

Claim 1 A maritime service platform for performing data linkage between a ship terminal and a digital maritime service through a Maritime Connectivity Platform (MCP), comprising: an API gateway unit that receives an Application Programming Interface (API) request for calling a maritime service from a ship terminal and relays the API request to one or more digital maritime services; a Maritime Connectivity Platform Linkage Management Unit that links with the MCP, links with the identity registration function of a Maritime Identity Registry (MIR) and the service registration function of a Maritime Service Registry (MSR), and acquires and manages identification information for the ship terminal and the digital maritime service; a secure communication unit that performs encryption, integrity protection, and mutual authentication according to the SECOM (Secure Communication) standard for request and response messages transmitted and received through the API gateway unit; a digital maritime service linkage unit that registers and manages multiple digital maritime services on the maritime service platform, maintains and manages service identifiers, connection information, and usage authorization information for registered digital maritime services, and distributes API requests transmitted from the API gateway unit to the registered digital maritime services; and the operation of the API gateway unit and the digital maritime service linkage unit. A maritime service platform based on an MCP-linked maritime communication environment, comprising: an integrated monitoring unit that collects and stores related logs, status information, and performance indicators and provides the results to an operator; wherein the API gateway unit transmits API requests, for which authentication and security verification have been completed through the secure communication unit, to a corresponding digital maritime service through the digital maritime service linkage unit. Claim 2 A maritime service platform based on an MCP-linked maritime communication environment, characterized in that, in claim 1, the API gateway unit is configured to process the API request using source identification information, target service identification information, request path, and HTTP method information included in the header of the REST-based API request, and to convert the API request into an internal processing format and transmit it to a digital maritime service linkage unit. Claim 3 A maritime service platform based on an MCP-linked maritime communication environment, characterized in that, in claim 1, the maritime linkage platform linkage management unit is configured to acquire and manage identification information for ship terminals and digital maritime services by linking with the identity registry (MIR) and service registry (MSR) of the MCP, and to manage the linkage of digital maritime services in an MCP environment by providing the identification information to the API gateway unit and the digital maritime service linkage unit. Claim 4 A maritime service platform based on an MCP-linked maritime communication environment, characterized in that, in claim 1, the security communication unit performs mutual authentication between a ship terminal and a digital maritime service using a maritime resource identifier (MRN) and an MCP certificate registered in the MIR, performs encryption, digital signature, and integrity verification of API request and response messages in accordance with SECOM standards, and is configured to allow digital maritime service linkage only for API requests confirmed as valid as a result of verification. Claim 5 A maritime service platform based on an MCP-linked maritime communication environment, characterized in that, in claim 1, the digital maritime service linkage unit manages the service identifier, connection information, and usage authorization information of the registered digital maritime service, selects a digital maritime service corresponding to an API request transmitted from the API gateway unit and transmits the API request, and, when multiple digital maritime service instances exist, is configured to select a digital maritime service instance to process the API request by considering the current load status, availability, and response performance. Claim 6 A maritime service platform based on an MCP-linked maritime communication environment, characterized in that, in claim 1, the integrated monitoring unit collects and stores API call counts, response times, status codes, error occurrences, call status by service, and performance information generated from the API gateway unit and the digital maritime service linkage unit, and provides real-time visualization of the operational status of the maritime service platform based on the collected information. Claim 7 A method for providing maritime services, which performs data linkage between a ship terminal and a digital maritime service through a Maritime Connectivity Platform (MCP) using a maritime service platform based on an MCP-linked maritime communication environment according to claim 1, comprises: receiving an Application Programming Interface (API) request for calling a maritime service from a ship terminal; a Maritime Connectivity Platform linkage management unit linking with the MCP to link with the identity registration function of an Identity Register (MIR) and the service registration function of a Service Register (MSR), and acquiring and managing identification information for the ship terminal and the digital maritime service; a secure communication unit performing encryption, integrity protection, and mutual authentication on API request and response messages in accordance with the SECOM (Secure Communication) standard; and a digital maritime service linkage unit selecting a digital maritime service corresponding to the API request using a service identifier, connection information, and usage authorization information for a registered digital maritime service, and transmitting the API request to the selected digital maritime service. A method for providing maritime services based on an MCP-linked maritime communication environment, characterized by including the step of an integrated monitoring unit collecting and storing logs, status information, and performance indicators related to the operation of an API gateway unit and a digital maritime service linkage unit, and providing them to an operator. Claim 8 A method for providing maritime services based on an MCP-linked maritime communication environment, characterized in that, in claim 7, the step of receiving the API request includes processing the API request using source identification information, target service identification information, request path, and HTTP method information included in the header of the REST-based API request, and converting it into an internal processing format. Claim 9 A method for providing maritime services based on an MCP-linked maritime communication environment, characterized in that, in claim 7, the step of performing mutual authentication includes performing mutual authentication between a ship terminal and a digital maritime service using a maritime resource identifier (MRN) and an MCP certificate registered in the MIR, and allowing digital maritime service linkage only for API requests confirmed as normal as a result of verification. Claim 10 A method for providing maritime services based on an MCP-linked maritime communication environment, characterized in that, in claim 7, the step of selecting the digital maritime service includes selecting a digital maritime service corresponding to an API request using the service identifier, connection information, and usage authorization information of a registered digital maritime service, and, if multiple digital maritime service instances exist, selecting a digital maritime service instance to process the API request by considering the current service status. Claim 11 A method for providing maritime services based on an MCP-linked maritime communication environment, characterized in that, in claim 7, the integrated monitoring step includes the step of collecting and storing API call counts, response times, status codes, whether errors occurred, call status and performance information by service, and providing real-time visualization of the operational status of the maritime service platform based on the collected information. Claim 12 A method for providing maritime services based on an MCP-linked maritime communication environment, characterized in that, in claim 7, the digital maritime service linkage step further includes the step of receiving a registration request for a new digital maritime service from a service provider, registering the new digital maritime service in conjunction with the service registration function of the MCP's Service Register (MSR), and reflecting the service identifier, connection information, and usage permission information of the registered new digital maritime service so that subsequent API requests can be transmitted to the new digital maritime service.

Images