G1196 혁신 기술 시연 (요약·한영 대역)

International Organization for Marine Aids to Navigation
www.iala.int

GUIDELINE G1196
DEMONSTRATION OF INNOVATION

Edition 1.0, June 2026
urn:mrn:iala:pub:g1196:ed1.0

Revisions to this document are to be noted in the table prior to the issue of a revised document. The latest edition of the Guideline is the only version in force unless the Guideline is explicitly revoked by the Council.

1. Background
2. Objective
3. Definitions
  3.1 Testbed · 3.2 Feasibility demonstrator
4. Demonstration of innovation
  4.1 Key considerations (4.1.1 Purpose · 4.1.2 Scope · 4.1.3 Overall concept – vendor neutral · 4.1.4 Procurement approach · 4.1.5 Goal-based specification · 4.1.6 Standards identification · 4.1.7 Innovation culture · 4.1.8 Use case-based approach · 4.1.9 Environmental, Social and Governance (ESG) · 4.1.10 Requirements – functional and use case driven)
  4.2 Vendor neutrality · 4.3 Administration focus · 4.4 Cyber security
5. Typical models
  5.1 Test and documentation · 5.2 Scalability
6. The tender concept and process
7. Conclusion
8. Abbreviations
9. References

List of Figures
Figure 1 The W model - innovation to feasibility demonstrator

One of the aims of the International Organization for Marine Aids to Navigation (IALA) is to foster the safe and efficient movement of vessels through the improvement and harmonization for Marine Aids to Navigation (AtoN) worldwide for the benefit of the maritime community and the protection of the marine environment. Its aim and objectives further include promoting access to technical cooperation and capacity-building and one of the functions is dedicated to the development and communication of non-mandatory standards, recommendations, guidelines, manuals and other appropriate documents.

The development of new technologies and innovation continues to be rapid, and it has an impact on almost all aspects of the maritime industry, including maritime communications and AtoN.

In this context, innovation plays a critical role in enabling emerging technologies, digitalization and evolving operational needs.

The challenge is to transition innovation from concept to operational implementation in a safe, structured, and inclusive manner. This includes ensuring that emerging technologies are evaluated, validated, and integrated in a way that supports interoperability, regulatory compliance, and operational effectiveness.

This document is aligned with R1019 Provision of Maritime Services in the context of e-Navigation in the domain of IALA and refers to G1107 Planning and Reporting of Testbeds in the Maritime Domain.

The objective of this Guideline is to provide a structured approach to bridge the gap between innovation and potential implementation by means of a feasibility demonstrator.

The guideline focuses on process and methodology rather than specific technologies and supports a vendor-neutral, standards-based approach aligned with the IALA documents, and other international frameworks.

This section contains any core terms and definitions considered important to assist in the understanding of the document content. Other terms and definitions can be found in the International Dictionary of Marine Aids to Navigation of the Organization.

A testbed is a platform for trialling development projects. Testbeds generally involve rigorous, transparent, and replicable testing of scientific theories, innovative solutions, computational tools, and new technologies. [1]

A demonstrator that demonstrates that a specific innovative idea or product is technically feasible and can solve a real operational problem.

The movement from the stage of an innovation or testbed to a feasibility demonstrator can follow a structured approach. There are multiple described methods to create an idea and then take this to the market or implementation phase. Many governments support this innovative process through funding arrangements that encourage innovation as well as the inclusion of Micro, Small, and Medium-sized enterprises (MSMEs), which form the backbone of most economies and from which innovation often originates.

Part of this 'Innovation to Implementation' journey often includes the development and use of a feasibility demonstrator. Considerations for this include:

• Purpose
• Scope
• Overall concept - Vendor neutral
• Procurement approach
• Need to clearly specify requirements – including how to define them (goal based, vendor neutral)
• Identify the standards
• Approach to support innovation
• Use a case-based approach
• Address Environmental, Social, and Governance (ESG) aspects
• Definition of requirements - functional and use case-based

These considerations support a harmonized, standards-based, and vendor-neutral approach to innovation, consistent with IALA documents and international best practice.

Clarify the strategic aim of the feasibility demonstrator - for example, validating autonomous navigation algorithms, testing digital twin integration, or assessing RF/GNSS spoofing resilience. In recent years, several national testbeds have focused on validating COLREG-compliant behaviour of autonomous vessels under real sea conditions, illustrating how a well-defined purpose drives the design of trials and the selection of performance indicators.

Define the operational boundaries: type of vessels, geographic area (e.g., port, coastal, offshore), and system layers, e.g., sensor fusion, control logic, regulatory interface. Scope should reflect both technical maturity and regulatory exposure.

Ensure the testbed supports interoperability across Original Equipment Manufacturer (OEM), sensor platforms, and software stacks. This avoids vendor lock-in and enables comparative evaluation. For instance, a vendor-neutral approach allows testing multiple AIS transceivers under identical conditions.

Use structured procurement, e.g. RFT/RFI, to attract diverse solutions from established marine tech firms to startups. This formalizes expectations around data formats, e.g., IEC, NMEA, RTCM, safety protocols, and integration timelines.

Use goal-based specifications, such as "detect and classify surface targets within 500m in low visibility", rather than "install radar X." This encourages innovation while maintaining operational relevance. Goal-based specifications also support modular substitution and future-proofing.

Align with standards of international organizations such as IMO, IALA, IEC, and ISO standards. Examples include:

• IMO MSC.1/Circ.1609 for MASS trials
• IEC 61162 for NMEA message formats
• IALA G1128 for VTS interoperability

Standards ensure regulatory traceability and facilitate cross-border deployment.

Foster a culture of experimentation that supports rapid prototyping, fail-fast iterations, and cross-disciplinary collaboration. In maritime, this might mean testing algorithms on a small workboat before scaling to SOLAS vessels.

Anchor trials in operational use cases such as:

• Collision avoidance in congested fairways
• Predictive maintenance using vibration and thermal data

Use cases should reflect real-world constraints, such as latency in satellite communications or regulatory inspection cycles.

Incorporate ESG metrics, for example:

• Environmental: emissions reduction via route optimization
• Social: crew safety and workload reduction
• Governance: Consider "lowest cost" to "best value" decision models, factoring lifecycle reliability, regulatory risk, systems availability and resilience.

Define both the functional and Use Case requirements for example:

• Functional requirements: e.g., "System must detect AIS targets within 5 seconds"
• Use case requirements: e.g., "During port approach, system must alert bridge team of GNSS anomalies"

This dual requirement approach ensures technical rigor and operational relevance.

A vendor-neutral approach ensures that feasibility demonstrators deliver outcomes that are interoperable, replicable, and sustainable beyond the demonstration phase. Vendor neutrality means defining requirements, specifications, and evaluation criteria in terms of functions, performance, and open standards, rather than referencing proprietary products or platforms.

Key principles include:

• Standards-based design — Requirements should reference internationally recognized standards (e.g., IEC, ISO, IHO S-100, IALA recommendations and guidelines) rather than vendor-specific implementations.
• Open interfaces — Components should interoperate through published, openly available specifications and Application Programming Interfaces (APIs).
• Functional specification — Requirements should be expressed in goal-based terms, allowing multiple technical solutions to be considered on equal footing.
• Data portability — Data formats and exchange protocols should be based on open standards, ensuring that operational data can be migrated between systems without loss of functionality.

Adopting a vendor-neutral approach reduces vendor lock-in, supports long-term lifecycle management, and facilitates the inclusion of MSMEs, consistent with IALA's objective of harmonization across Members.

The focus for Maritime Administrations on feasibility demonstrations include:

1 Functional Requirements – Use Case–Driven Design

Administrations can define the functional requirements anchored in real-world operational scenarios, such as autonomous vessel navigation, port traffic management, or digital Marine Aids to Navigation.

Each use case would then be mapped to measurable outcomes, performance indicators, and interoperability needs across stakeholders, e.g. port authorities, and maritime regulators. The emphasis would be placed on modularity and scalability, ensuring that solutions can evolve with emerging technologies and regulatory shifts.

2 Regulatory Compliance – Vendor-Defined Implementation within a Clear Framework

Vendors would demonstrate compliance with a defined set of maritime regulations, e.g., SOLAS, MARPOL, national safety codes. Administrations define the compliance requirements and expected outcomes while allowing vendors flexibility in how compliance is achieved. This encourages innovation while maintaining accountability. A compliance matrix may be used to track alignment across technical, operational, and legal domains.

3 Adherence to IALA Guidelines promoting harmonization and interoperability

Feasibility demonstrations should align with the applicable IALA guidelines, including S-100 framework, VTS standards, and e-Navigation principles, ensuring global interoperability and supporting harmonized data exchange. Administrations may require that vendors demonstrate how their solutions contribute to IALA's strategic goals.

4 Reducing Vendor Lock-In – Standards based on open architecture

Administration should actively promote the use of open, published standards (e.g., IEC, ISO, IHO S-series) and well-documented APIs to ensure portability and futureproofing using procurement frameworks that support multi-vendor ecosystems. Feasibility demonstrations may include interoperability testing, and reducing proprietary dependencies.

5 Budgeting – Transparent, Outcome-Oriented Investment

Budgets can be structured to support a phased development tied to functional delivery, stakeholder engagement, and ESG impact, with administrations co-funding with industry, academia, or international bodies, leveraging blended finance to de-risk innovation. Budgeting should cover lifecycle costs, including establishment, maintenance, upgrades, and decommissioning, ensuring long-term sustainability.

G1182 Cyber security specific from an IALA perspective provides guidance on possible measures to be taken to mitigate cyber security risks in the IALA domain [2]. Testbeds should demonstrate how cybersecurity is addressed across navigation, communication, and administrative systems.

G1107 Planning and reporting of testbeds in the maritime domain emphasizes risk analysis and management as part of testbed planning with Cybersecurity included in the risk register, including the following facets:

• Threat modelling for digital aids to navigation
• Vulnerability assessments of VTS and e-Navigation systems
• Incident response protocols and recovery plans

Cybersecurity should be considered throughout the feasibility demonstrator lifecycle.

There are multiple models that include different steps. Some of these models are focused on the innovation components while others are focused on the implementation of an innovation that already exists in some format. This Guideline assumes that the innovation concept, idea, or prototype product already exists.

The W model (Figure 1) is an engineering lifecycle that can be used for innovation development and includes the following steps:

1. Requirements – The desired outcomes/goals of the feasibility demonstrator
2. Specifications – What technical specifications are to be met to achieve the desired outcomes/goals
3. Architecture – What architecture is required (System Concept)
4. Detailed design – Detailed System Concept with all interfaces (human, electrical, physical, etc.) described
5. Build prototype – Build a prototype to show that the deliverables are possible (Strawman version)
6. Build Testbed – Build the total system according to the system concept that is expected to deliver the desired outcomes
7. Integrate into system – Where integration into other systems is required, ensure that this is achieved
8. Finalize system – Finalize system to allow final test, documentation, and peer review of the feasibility demonstration

These steps provide a structured and traceable pathway from defined requirements through to a feasibility demonstrator, supporting informed decision-making for potential implementation.

Figure 1 The W model - innovation to feasibility demonstrator

The W model described includes a test and documentation approach that includes:

1. Requirements / Goal review – What is the purpose of the feasibility demonstration / what is to be achieved
2. Specifications review – Are the specifications clear and understood by all
3. Architecture review – Is the architecture able to deliver the goals of the feasibility demonstrator
4. Prototype review – Does the Strawman version deliver what is required to confidently continue
5. Module testing – Does each of the components/modules / interfaces work as specified
6. System testing – Can each of the modules be combined to deliver the system without any external interfaces in place
7. Integration testing – Can the system integrate with the external systems
8. Final test and documentation – Final test against requirements and goals, and documentation of the system and test results

When considering scalability, consider the following factors:

1 Specify which dimensions are most important:

• Geographic: Can the solution scale from a single port to a national or international network?
• Functional: Can new capabilities (e.g., autonomous navigation, digital twin integration) be added without the need to change the existing architecture?
• Stakeholder: Can the system accommodate more stakeholders - vessels, authorities, service providers — without degrading performance?
• Data Volume: Can it handle increasing sensor feeds, AIS data, or real-time analytics?

2 Modular Architecture and Standards Alignment

• Use modular, loosely coupled components that allow scaling specific functions independently.
• Use open standards (e.g., IHO S-100, IEC 61162, ISO 19848) where possible to ensure interoperability across vendors and jurisdictions.
• Consider adopting containerization and microservices to support horizontal scaling and cloud-native deployment.

3 Scenario-Based Stress Testing

• Include scalability stress tests in the feasibility demonstrator lifecycle: simulate increased vessel traffic, data loads, or cross-border coordination.
• Use digital twins or synthetic environments to model future growth scenarios.
• Evaluate performance degradation thresholds and recovery mechanisms.

4 Governance and Procurement

• Embed scalability as a scoring criterion in vendor evaluation: not just "can it scale" but "how well, how fast, and at what cost."
• Require vendors to provide scaling roadmaps, including dependencies, licensing implications, and ESG impact.
• Use framework agreements that allow scaling without renegotiation.

When progressing from innovation to a feasibility demonstrator, the process may include the demonstration of technology and/or the development of a prototype. The tender approach and process should be aligned with applicable national regulatory and procurement requirements.

G1111 Establishing functional and performance requirements for VTS systems and equipment [3] may assist in providing a structured approach to defining requirements and supporting the tender process. The procurement process may include the development of a solution to meet an identified operational or functional requirement.

The process may begin with an open market dialogue, followed by a Request for Information (RFI). Where it is not clear whether suitable solutions exist to meet the administration's objectives, an initial market questionnaire may be used to inform the RFI stage. The RFI may be considered as the first phase of the process, followed by a tender for a prototype or feasibility demonstrator as the second phase, and a tender for a final operational solution as the third phase.

The process may include provisions to encourage participation from micro, small, and medium-sized enterprises (MSMEs), recognizing their role in supporting innovation. The tender process may also require respondents to include an innovation component, in addition to demonstrating technical and commercial compliance.

Administrations may establish an innovation portal or similar mechanism to communicate identified needs or desired solutions. Such platforms may be made publicly available, enabling prospective innovators and vendors to propose solutions aligned with the Administration's requirements.

The innovation cycle begins with ideation and progresses through structured development, such as the application of the W model, to achieve a feasibility demonstrator. The outcomes of this process provide a basis for informed decision-making by Administrations and stakeholders, including whether to proceed to testbed deployment, further development, or implementation. Not all innovations will progress beyond the feasibility stage. However, the structured approach described in this Guideline supports safe, transparent, and evidence-based evaluation of new solutions.

1. IALA. Guideline G1107 Planning and reporting of testbeds in the maritime domain
2. IALA. Guideline G1182 Cyber security specifics from an IALA perspective
3. IALA. Guideline G1111 Establishing functional and performance requirements for VTS systems and equipment