A Hierarchical, Modular Interface and Verification Architecture for Mission Planning in Swarm Unmanned Surface Vehicles: Simulation and Sea-Trial Validation

Abstract

Swarm Unmanned Surface Vehicles (SUSV) must sustain real-time coordination as fleet scale and formation change. We propose hierarchical and modular architecture that decouples mission-planning algorithms from interface evolution, composed of an Interface Adapter System (IAS), a Mission Execution System (MES), and an Interoperation Integration Verification System (IIVS). The IAS standardizes and integrates data from diverse sensors and subsystems through modular adapters, facilitating flexible subsystem integration. The MES employs a discrete-event system specification (DEVS)-based modeling approach, providing independent and efficient mission execution capability without necessitating interface modifications. The IIVS utilizes LabVIEW-based analytical methods to verify and validate subsystem interoperability continuously, enabling rapid and reliable scaling. The architecture was implemented in an operational SUSV program and evaluated through simulation experiments and sea trials. During scale-up from 10 to 20 USVs, mission-cycle deadlines (≤250 ms) were met in 99% of cases, while integration lead time for scale-up decreased by about 80%. Message-level tests confirmed robust interoperation under increased load, and algorithm-level tests showed stable plan re-computation under dynamic tasking. These results indicate improved interoperability, scalability, and reliability, offering a practical blueprint for mission planning in maritime swarms.

1. Introduction

Recent advances in Unmanned Surface Vehicle (USV) technology have significantly enhanced the automation and efficiency of maritime operations. While single-USV systems are often optimized for specific missions, their ability to perform multiple tasks concurrently and to adapt swiftly to dynamic environments remains limited [1,2,3]. In contrast, Swarm Unmanned Surface Vehicles (SUSVs) exploit cooperative behaviors, real-time information sharing, and distributed control across multiple USVs. This substantially enhances operational coverage, mission adaptability, and resilience in complex conditions [4,5]. Such configurations facilitate collaborative tasks, e.g., obstacle avoidance, simultaneous target tracking, and environmental monitoring, which are crucial for efficient maritime operations [6]. Particularly in military contexts, SUSVs provide significant strategic advantages by minimizing casualties, increasing operational range, and enhancing engagement capabilities during defensive and offensive missions [7,8].

Nevertheless, scaling SUSVs introduces three interrelated challenges: (1) maintaining robust, low-latency inter-vehicle data exchange for safety-critical maneuvers (e.g., collision avoidance or formation control); (2) re-computation of mission plans under dynamic tasking and environmental change within strict timing constraints; and (3) cost-effective, reliable verification of subsystem interoperability as fleet size grows [9,10,11,12,13,14]. For instance, operational latency above 250 ms can significantly degrade cooperative mission performance in collision-avoidance scenarios, underscoring the importance of interface robustness [15,16]. Integrating various communication modalities, including radio frequency (RF) and potentially underwater acoustic systems, further demands rigorous management of interface standards and thorough verification [17,18,19]. To this end, we define a mission-plan cycle threshold (e.g., ≤250 ms) as a design constraint throughout this study.

Previous studies have attempted to address scalability issues. Fan et al. [20] proposed an integrated information network and control system for USV operations, yet their architecture lacked the formal hierarchical modularization necessary for effective fleet scaling. Similarly, Wang et al. [21] developed a cloud-based mission control architecture enabling remote control of multiple USVs, but the approach was validated only with limited subsystem integration. Hong et al. [22] suggested a hierarchical cloud-based architecture for unmanned aerial vehicles (UAVs); however, the system’s applicability to maritime environments with specific communication and control constraints remains less explored in practical scenarios. Thus, there is a clear research gap regarding hierarchical, modular system architectures systematically designed and rigorously validated for maritime swarm operations.

We address this gap with a hierarchical, modular architecture comprising an Interface Adapter System (IAS) and an independent Mission Execution System (MES), together with an Interoperation Integration Verification System (IIVS). The IAS integrates diverse subsystems through standardized interfaces, managing inputs from sensors such as GPS, IMU, RADAR, and LiDAR, and outputs operationally relevant real-time data for mission coordination. Leveraging a communication middleware (Nerv) to separate interface handling from algorithmic logic, IAS improves maintainability and scalability. MES independently executes mission planning algorithms based on Discrete Event System Specification (DEVS) modeling [23,24,25,26,27]. This approach enables flexible and efficient adaptation across diverse operational scenarios. It also decouples interface changes from mission execution logic. The IIVS provides rigorous verification of subsystem interoperability based on Interface Control Documents (ICDs) [28]. Leveraging LabVIEW (Version 2022 Q3) software [29,30,31,32,33], the IIVS monitors and analyzes real-time interactions between subsystems. It rapidly identifies and resolves integration issues, which is essential for maintaining performance under increased operational complexity.

This study makes the following contributions: (1) it introduces a modular, hierarchical SoS architecture (IAS–MES–IIVS) that enables algorithm invariance in mission planning despite changes in swarm scale and formation; (2) it establishes a repeatable interoperation V&V pathway that continuously audits ICD-conformance and timing, supporting rapid, reliable scale-up; and (3) it demonstrates practical effectiveness through both hardware-in-the-loop simulations and sea trials, achieving scale-up from 10 to 20 USVs while maintaining the mission-plan cycle threshold (≤250 ms) in 99% of cases and reducing integration lead-time by ≈80% due to software reuse and automated verification.

The proposed systems have been successfully implemented and validated in a domestic sea test project. Unit tests demonstrated that the IAS and MES effectively managed 99% of assigned tasks, consistently meeting mission plan cycle thresholds even under increased data loads. The project commenced in January 2021 with a 10-USV configuration and achieved scaling to a 20-USV fleet by August 2023. Integration time was shortened by approximately 80% when scaling from 10 to 20 USVs. This achievement demonstrates significant improvements in system reliability, performance, and scalability.

The remainder of this paper is organized as follows: Section 2 reviews relevant literature on interoperability and interface systems for unmanned vehicles. Section 3 details the system architecture and components of the proposed IAS, MES, and IIVS. Section 4 describes comprehensive integration testing procedures and presents detailed results from functional and performance evaluations during scale-up. Finally, conclusions and future research directions are presented in Section 5.

2. Related Work

Table 1. Related work on interface adapter systems.

Related Works	Target System	Objective	Method of Interoperation	Interoperation Hierarchy
Fan et al. [20]	USV	Situation awareness system integration	Direct Integration	Monolithic integration
Wang et al. [21]	USV	Mission planning system integration	Direct Integration	Monolithic integration
Hong et al. [22]	UAV	Mission planning system integration	Direct Integration	Modular Integration
Mendoza-Chok et al. [34]	USV	Propulsion integration	Middleware-based Integration	Semi-modular Integration
This study	USV	Mission planning system integration & interface monitoring	Middleware-based Integration	Modular Integration

summarizes previous studies on the development of advanced interface adapter systems for USVs and other complex systems. This table focuses on system integration, levels of interoperability, technical methods used, and the hierarchical structure of the interoperation implementation. These studies address various methods of system integration, described through two key components: Method of Interoperation and Interoperation hierarchy.

Method of Interoperation refers to specific technologies or approaches used to connect data and functionality between different systems or components. This includes direct integration and middleware-based integration. The interoperation hierarchy indicates how the system interoperation is structured hierarchically, distinguishing between Modular, Semi-modular, and Monolithic structures. Each structure approaches system flexibility and complexity differently. Modular structures distinctly separate major functions, such as integration and mission planning, based on task criteria, semi-modular structures allow for some functional separation, and monolithic structures operate all components within a single integrated system.

The methodologies and structural approaches presented in this table contribute to the development of stable and optimized solutions for improving the operation of USV and other complex systems in challenging environments. This study provides a critical foundation for designing and optimizing similar systems.

Fan et al. (2015) [20] focused on integrating various sensor data from USV systems to develop an interface software system using the NMEA2000 protocol, targeting situation awareness system integration. This monolithic integration approach faces challenges such as difficulty in re-planning in dynamic environments and low maintainability and reusability, potentially degrading the performance as operational scales expand owing to increased computational complexity.

Wang et al. developed a system that dynamically updates mission planning for USV systems on a cloud basis [21], leveraging cloud-based management and monitoring concepts [35,36] and focusing on mission planning system integration. This system, which also uses monolithic integration, suffers from increased computational complexity owing to the lack of clear task separation, which can lead to performance issues during scaling operations. Dependency on cloud connectivity means that data processing and mission execution are susceptible to interruptions during network instabilities, presenting potential security risks owing to the non-use of dedicated networks.

Hong et al. used cloud computing to support massive data processing for UAV mission planning [22], drawing on prior cloud/UAV integration frameworks [37,38,39]. When employing a modular integration method, the lack of precise task delineation among interfacing components limits maintainability and scalability. Reliance on cloud infrastructure introduces severe disadvantages if cloud access is interrupted, including potential security vulnerabilities when not using isolated networks.

Mendoza-Chok et al. aimed to integrate USV propulsion data with high-level task management systems [34], utilizing a semi-modular integration approach and building on prior bimodal/propulsion system integration studies [40,41,42,43]. This centralized data processing setup complicates system maintenance and upgrades and can encounter issues with operational scaling and computational demands.

In this study, the proposed system architecture introduces a distinctive modular and hierarchical approach that structurally separates communication and processing tasks within SUSV systems. While previous research has often highly integrated these functions, leading to challenges in maintenance and scalability, the proposed framework provides a clear delineation between the interfacing (IAS) and algorithmic (MES) layers. This separation enhances system reliability by isolating critical components and facilitates easier upgrades and improved fault isolation, thereby strengthening the overall robustness of the system.

The contribution of our research lies in providing a scalable and sustainable solution that adapts to various maritime conditions while maintaining efficiency and security. This architecture enhances the operational capabilities of SUSV systems and strengthens the reliability and performance of maritime navigation systems. The dual focus on modularity and hierarchical task management offers a systematic approach for improving upon existing methodologies and optimizing the deployment of unmanned surface vehicles in complex and dynamic marine environments.

3. System Development

In this section, we describe the analysis of the target system and architecture of the proposed system. Next, we describe the design and implementation in detail. Finally, unit tests were performed to validate the proposed system.

3.1. Target System

The target systems in this study were SUSV designed to efficiently perform missions in complex and dynamic maritime environments. The traditional single unmanned USV systems are optimized for specific missions, such as reconnaissance, surveying, and marine environmental monitoring [42], whereas SUSV systems enable multiple USV systems to cooperate and handle more complex operations. For example, in several engagement scenarios, each USV can share real-time information and interact with others to detect and respond to threats more effectively [44,45,46]. Unlike single USV systems, in which a single unit operates independently, SUSV systems benefit from multiple units collecting and combining data from various locations, allowing for faster and more accurate decision-making [47,48].

Figure 1 shows the general system architecture of an SUSV, which consists of a GCS and multiple USV systems. The GCS plays a crucial role in coordinating and managing an entire mission by providing centralized control, situational awareness, and mission planning. This enables USV systems to operate autonomously while collaborating to achieve complex strategic objectives. A GCS comprises several subsystems. First, the sensor information processing subsystem processes the data collected from various sensors to generate integrated battlefield situational awareness. Situational awareness is essential for the mission-planning subsystem, which creates a mission plan based on fused data. The USV systems then execute these mission plans in real-time using the information provided by the GCS to adapt to changing conditions and efficiently accomplish the mission objectives.

The USV comprises various specialized subsystems designed to efficiently perform missions. One of the key components is the sensor information processing subsystem, which collects and fuses the sensor data from each USV in real-time. These fused data are sent to the GCS, enabling the development of the most optimal mission plan. Within a USV, the autonomous navigation subsystem uses data from the GCS to determine the optimal route, whereas the real-time collision avoidance subsystem detects and avoids obstacles, ensuring safe navigation. The weapon control subsystem manages the tactical operations, and the propulsion subsystem controls the physical movement of the USV to ensure smooth and efficient mission execution. These subsystems work together to allow the USV to follow the GCS commands. When communication is disrupted or unexpected situations arise, the USV can autonomously assess the situation and continue executing the mission.

The SUSV system enables multiple independent USV systems to operate autonomously while collaborating to effectively perform complex missions. As the operational scale of this system expands, each USV system can collect information in real-time from various regions and either deliver it to the GCS or share it with other USV systems. This activity allows the system to cover a broader maritime area and conduct tasks, such as surveillance, detection, and analysis, more efficiently and quickly. This capability is strategically important for maritime safety and combat.

However, managing the scalability and complexity of an SUSV system requires each USV system to understand its role and perform it effectively. The hierarchical mission-planning interface facilitates this by categorizing and coordinating the tasks of each USV system, enabling efficient processing and transmission of information. In addition, each layer functions independently while supporting the harmonious and effective operation of the entire system. This hierarchical structure enhances the ability of each USV system to perform missions autonomously while also facilitating the exchange and collaboration of information among them, significantly improving the overall flexibility and efficiency of the system.

As the scale of SUSV systems expands, it becomes essential to implement SE-based evaluation processes. Although these processes ensure the reliability and performance of the entire system, they can significantly extend development time. To address this issue, a message-monitoring system is required to support SE-based processes effectively. This system monitors communication messages between the GCS, USV systems, and subsystems in real-time, ensuring the reliability and accuracy of data exchange.

In this study, a hierarchical mission planning interface was developed to maximize the scalability of the SUSV system. This interface adopts a hierarchical structure and clearly distinguishes between the interoperation layer and the mission planning algorithm execution layer, allowing each layer to perform specialized functions independently. This structure facilitated flexible adaptation and functional expansion at the system scale. In addition, performance validation equipment was developed to enable effective system integration and functionality checks.

3.2. System Design

The proposed system is divided into three parts, as shown in Figure 2: IAS, MES, and IIVS. Each part is responsible for the interoperation and validation of the various messages for mission planning. To reduce the integration test time related to the operation of USVs, a hierarchical structure that allows separate integration testing of the interface and algorithm sides is necessary. Consequently, the IAS, which connects and manages various subsystems, and the MES, which executes algorithms such as mission planning, were designed and implemented separately. The IIVS systematically evaluates and verifies the integration and interoperability of the system, supporting each layer in effectively performing its role. This structure enables independent operation of each layer, thereby minimizing the impact of any issues in one part of the entire system and enhancing the overall performance and reliability of the system.

Specifically, the IAS was designed to take advantage of the benefits of both centralized and hybrid structures. In a centralized configuration, the GCS carries the IAS and MES, collects situational awareness information from all the USV systems, and exclusively plans the mission and issues commands to each USV. In the hybrid configuration, each leader USV is equipped with an IAS and an MES. This allows the leader USV to collect real-time situational awareness information from other USV systems and build a mission plan based on this information. Once the plan is finalized, the leader communicates commands and oversees the operations of the entire swarm. With this configuration, the IAS and MES enhance the ability of each USV to process data and fulfill its mission, thereby increasing the flexibility and efficiency of the entire system.

The SUSV system integrates multiple subsystems that collaboratively process substantial volumes of communication data and implement intricate mission-planning algorithms. Inefficiencies in communication or data processing among these subsystems can lead to a significant decline in system performance, causing delays in mission execution and an increased likelihood of operational errors. The absence of a hierarchical structure intensifies these issues because interdependencies among subsystems can allow minor problems to disproportionately affect the entire system. This results in diminished flexibility, limited scalability, and increased maintenance challenges, which degrade the stability and reliability of the system. Consequently, these issues can retard the progression of projects, prolong development periods, and inflate costs, potentially exceeding budgetary limits. In addition, failure to meet the necessary response times for real-time mission operations decreases the probability of project success.

Section 3.2 will explore the specific designs of the primary components of the proposed system: IAS, MES, and IIVS, detailing their roles in enhancing system performance and reliability.

3.2.1. Interface Adapter System

Figure 3 shows the structure and interaction of the main components of the proposed system: Interface Adapter System (IAS) and Mission Execution System (MES). The IAS is primarily responsible for the collection, distribution, and validation of messages and embodies a modular architecture that includes an inter-connection message collector, mission interface controller, inter-connection message distributor, intra-connection message collector, intra-connection message distributor, and message validation unit. The inter-connection message collector receives messages from external systems, and the mission interface controller processes and manages the mission planning interface.

The processed messages are distributed to other systems via the inter-connection message distributor, whereas messages originating within the system are collected by the intra-connection message collector and disseminated to internal components by the intra-connection message distributor. The message validation unit validates the received messages and ensures data integrity and operational accuracy. This modular design enhances the adaptability and scalability of the system, thereby facilitating easy upgrades and maintenance.

The MES provides essential functionalities for mission execution and the setup of the simulation environment. It includes several key components: an intra-connection message collector, message store, message parsing system, and intra-connection message distributor. The intra-connection message collector collects all the messages generated within the system, whereas the message store holds these messages to facilitate quick processing and long-term archiving. The stored messages are analyzed by the message-parsing system to extract the necessary information, which is then promptly relayed to other system components by the intra-connection message distributor to support rapid decision-making.

The second set of components, the simulation environment and model setup, manages the advanced features of the MES. The simulation environment and model setup utilizes the pyDEVS engine based on DEVS formalism to establish an effective simulation environment and configure the models. This approach is crucial for modeling and simulating the dynamic behaviors of complex systems, thereby enhancing the accuracy of mission planning and execution. The mission planner uses the analyzed data to devise and adjust missions, ensure project flexibility, and enable quick responses. This integrated approach significantly enhances the possibility of project success, allowing the MES to manage complex data and mission requirements efficiently.

The DEVS formalism inherently supports hierarchical and modular system specification, which allows for the systematic decoupling of the MES (algorithm layer) from the IAS (interface layer). This structural separation ensures algorithm invariance, allowing the mission planning logic to remain consistent despite changes in fleet scale or sensor configuration, which constitutes a core contribution of this study. Unlike traditional behavior-based modeling (e.g., FSM or Behavior Trees), which primarily focuses on state transitions, the DEVS formalism provides a rigorous framework for managing both discrete events and explicit time advances [23,24]. This structural advantage allows our MES to inherently satisfy internal design constraints by processing computations only when necessary, facilitating efficient mission re-computation in a hierarchical and modular manner.

Furthermore, the discrete-event nature of DEVS is highly advantageous for simulation acceleration [49]. As a discrete-event engine, DEVS minimizes unnecessary computation by only processing events when state changes occur, thereby optimizing computational efficiency. Such acceleration capability is essential for generating the large-scale training data required by modern AI algorithms for USV operations. In particular, given the irregular and event-driven nature of computations arising from mission replanning, inter-vehicle interactions, and sensor events, performing computations only at the occurrence of events can effectively reduce unnecessary computational overhead compared to fixed-cycle execution models.

The combination of optimized computational efficiency and a modular structure provides a robust foundation for managing the computational burden required for continuous mission planning and verification, even as data volume and mission complexity increase with swarm scale. This architectural advantage ensures that the system can scale effectively while consistently adhering to the required operational guidelines. By leveraging these DEVS-specific properties, the proposed architecture guarantees reliable performance and inherent robustness in fulfilling predefined system requirements for large-scale swarm operations.

Figure 4 shows the operational procedure of the MIC within the hierarchical structure designed to facilitate the interaction between the Interface Layer and the Algorithm Execution Layer of the USV system. The process involves four main steps: initiating the verification of the USV hardware and software statuses, which are crucial for determining the operational mode of the USV.

The first step ensures that the hardware of the USV system is functional and checks whether the system is in unmanned mode. If the USV is not in unmanned mode, it switches to manual mode; otherwise, the process advances to the next step. This progression ensures that once the USV system is confirmed to be in unmanned mode, it seamlessly transitions into mission preparation, utilizing the structured interaction between the Interface and Algorithm layers.

In the next step, the software status of the USV system is checked, excluding the mission plan. If a software malfunction occurs, the other systems are alerted, and the operator takes the necessary action. If the software functions properly, the system is ready for the mission plan, and the process moves to the next step. This step is crucial to ensure the stability and reliability of the system. Once the software check is completed, the system prepares an environment for the mission.

The third step is to check the IAS status. If the system is in normal condition, the network topology is verified and set up to ensure that the mission can be conducted. Once the topology is established, the mission status is checked to confirm its readiness. This step is essential to ensure that the system is fully prepared before starting the mission. If the mission status is confirmed as ready, the system proceeds to mission execution.

The fourth step in the Mission Interface Control process plays a critical role in ensuring smooth execution and operational flexibility of the SUSV system. This step begins with a final confirmation by the operator that the mission parameters are set and that the USV systems are ready, transitioning seamlessly into the mission initiation phase. A “mission start” command is then issued to all interconnected systems, signaling the beginning of the operation.

During the mission, the system’s ability to monitor and adjust in real-time is pivotal. It dynamically alters the swarm topology based on live situational data, which is crucial for responding to evolving operational conditions. This ensures that the mission adapts to unexpected changes and challenges, thereby enhancing the overall effectiveness and safety of the operations.

Moreover, the Mission Interface Controller ensures that all mission adjustments are coherent and timely, maintaining the integrity and synchronization of operations across the entire fleet of USVs. The mission concludes with the issuance of a “mission complete” message, signaling all systems to wind down operations in a coordinated manner.

In cases where anomalies or operational discrepancies arise, the rapid dissemination of a “mission stop” message is crucial. This command acts as a failsafe, allowing for the immediate cessation of all activities and reverting the system to a safe state, thus minimizing potential risks or damage. This responsive mechanism underscores the SUSV system’s robust error-handling and risk mitigation capabilities, which are essential for maintaining high operational standards and ensuring mission success.

3.2.2. Integrated Interoperability Validation System

The IIVS was proposed to support the interoperability testing associated with the scalability of the SUSV system, thereby enhancing SE-based processes. The IIVS plays a crucial role in validating interconnection messages and supports both real-time and playback modes, meeting a wide range of operational demands and enhancing operational management. The real-time mode ensures the immediate validation of incoming data, which is suitable for scenarios requiring agile operational management. Conversely, playback mode focuses on analyzing historical data, which is vital for detailed post-mission evaluations. Together, these modes enhance system adaptability and play a key role in maximizing data utilization for comprehensive system analysis and improvement.

Figure 5 shows the workflow and interactions within the IIVS that process interoperability messages. The flow initiates at the intra-connection message collector, which captures data from internal activities. Subsequently, the message classifier categorizes incoming messages in accordance with ICD to optimize data routing and handling efficiency. The message logger meticulously records all system activities, facilitating rigorous audit processes and enhancing both traceability and accountability within the system.

The playback controller is designed for post-event analysis, managing replay, and reviewing system operations. This functionality archives activities and provides data for in-depth review and system improvement. By contrast, real-time analysis is facilitated by the message classifier, which promptly processes and routes categorized messages to the viewer component, enabling immediate user responses to data. The viewer component offers an interactive interface that allows users to effectively interact with both real-time and stored data, thus playing a crucial role in monitoring and managing system operations. This integration significantly enhances the interoperability and operational efficiency of the system architecture.

Figure 6 shows a sequential data flowchart for the real-time mode of the IIVS. The flowchart begins with an intra-connection message collector, which receives messages, followed by a message logger, which logs and documents all the messages. Classified messages undergo data parsing to extract the necessary information, and the extracted data are visualized in a viewer, enabling users to easily interpret the data and make decisions in real time. This flowchart illustrates how the IIVS efficiently processes data and enhances system interactivity and operational efficiency in real-time mode.

Figure 7 shows the interoperable message viewer within the IIVS for the SUSV, divided into (A) and (B). (A) shows a 2D map providing tactical location information, and (B) presents a table detailing the information from interoperation messages. (A) depicts a 2D map from the SUSV system that marks the coordinates of allies and detected enemies. This map visually represents the geographic distribution and movement patterns during the simulations, enabling users to quickly assess tactical situations and make decisions based on spatial data. Additionally, the coordinate data in the situational awareness map were saved in the SIMDIS AIS file format, enabling further analysis with 3D visualization after the experiment [50]. (B) shows a structured table that logs detailed information from various interoperational messages, including firing events. This table organizes the timestamps and outcomes of events that occur during simulations, providing a clear overview of operational situations and facilitating detailed analysis and decision-making based on the data.

These components significantly enhance the data processing and decision-making capabilities of the SUSV system and serve as effective tools for both real-time and playback analyses. The Interoperation Message Viewer plays a crucial role in enhancing the system’s interoperability and operational efficiency, with the added capability of analyzing data through 3D visualization post-simulation owing to the SIMDIS AIS file format.

3.2.3. Developed System Testing

Functional Unit Testing of the IAS

Before integrating the proposed IAS and MES into the main SUSV system, it is crucial to complete unit testing for each system. Such unit testing plays a vital role in ensuring that the proposed systems satisfy the designated requirements and can be effectively integrated into the operational environment [51]. Thorough verification and performance evaluation of both the IAS and MES are essential for ensuring system stability and reliability.

Specifically, the IAS and MES must comply with the defined mission planning cycles, process data swiftly, and make timely decisions. From an operational perspective, the overall cycles of mission maneuvers, major sensor data updates, situation awareness, and command dissemination are designed to be managed within approximately 1000 ms. This value reflects a higher-level operational cycle derived from sensor update rates and mission execution requirements. Within this upper-level mission cycle, this study adopts a more stringent internal design constraint by setting the mission planning cycle threshold to 250 ms in order to ensure sufficient timing margin and system stability. This threshold represents a conservative criterion, motivated by the observation that latencies exceeding 250 ms can significantly degrade the effectiveness of safety-critical cooperative maneuvers, such as collision avoidance, in a USV swarm. Therefore, detailed test cases should be implemented for each function of the system to verify whether they can perform their respective tasks accurately and effectively. Based on the performance and stability of each function confirmed through unit tests, subsequent integration tests with the entire SUSV system were conducted to verify whether the integrated system met the operational requirements in the field.

Figure 8 shows the testing environment used to validate the IAS and MES within the USV architecture. A critical component of this setup is the data generator, which creates situational awareness data essential for USV operations and transmits these data at regular intervals to test system responsiveness. The IAS is designed to handle high-throughput processing of up to 50,000 messages every 5 s, ensuring that real-time data are efficiently relayed to the MES. Subsequently, the MES dynamically generates new mission plans at set intervals, demonstrating the system’s ability to adapt swiftly to incoming information. This rigorous testing environment critically assesses the performance of a system to satisfy the operational standards essential for the autonomous functioning of USV systems, where prompt and accurate data processing is paramount for mission effectiveness. In this test, communication-level handling of packet retransmission, ordering, and transient link failures is managed by the Nerv communication middleware and the underlying transport stack. Accordingly, the IAS and MES perform performance and functional verification under the assumption that messages are successfully delivered.

Table 2. Parameters used in the Functional unit test.

Parameter	Details
Message	Situation awareness, Mission planning
Number of total messages	50,000
Time of experiments	5 s
Number of repeat experiments	30
Message generation frequency	10,000/1 s
Compute Hardware	Intel Core i7-class CPU, 16 GB RAM (DDR4 8 GB × 2)
Graphics Processing	NVIDIA GeForce GTX 1660-class GPU
Operating System	Ubuntu 18.04 LTS
Measurement Metric	End-to-End (EtoE) Latency

lists the specifications of each parameter used in the comprehensive functional unit test, including the standardized compute hardware and measurement metrics to ensure reproducibility. First, message parameters include types such as “Situation awareness” and “Mission planning,” which are pivotal for evaluating the processing efficacy of the system in real-world scenarios. The number of total messages was quantified at 50,000, serving as a deliberate benchmark for measuring the system’s data handling capacity. Such a substantial figure is crucial for assessing system performance under heavy data flow within a limited timeframe, mirroring the existing conditions of maritime operations.

The number of repeat experiments was set to 30. This specific number is not arbitrary but was selected according to the central limit theorem, ensuring the statistical robustness of the test results. Lastly, the message generation frequency was set at 10,000 messages per second, serving as a stringent test of the system’s throughput and real-time response capabilities. This high-intensity message flow is designed to push the system’s limits, ensuring that it meets and exceeds the demands expected during actual USV system operations.

To provide a rigorous assessment, the experimental environment was configured with an Intel Core i7-class CPU, 16 GB RAM, and an NVIDIA GeForce GTX 1660-class GPU running on Ubuntu 18.04 LTS. Crucially, as specified in Table 2, the reported performance reflects the End-to-End (EtoE) latency, encompassing the entire process from message serialization and transport to final execution. These parameters form the backbone of the validation process and provide a detailed assessment of the system’s readiness for deployment in autonomous maritime navigation.

Figure 9 shows the results of the functional unit testing of the IAS and MES, along with two graphs illustrating key aspects of system performance. Figure 9a shows the processing times for different numbers of tasks along the x-axis, while the y-axis represents the time required to process these tasks. The mission planning cycle threshold is indicated by a red dashed line at the top of the figure. This red dashed line represents the critical 250 ms deadline established to guarantee sufficient latency for safety-critical cooperative maneuvers. The error bars represent the variance in processing times, which remain consistently below the mission planning cycle limit. This demonstrates that, regardless of the number of jobs, the system consistently processes data within the required time, highlighting the robustness of the system in handling various workloads without significant fluctuations in processing time.

Furthermore, the consistently narrow error bars in Figure 9a indicate minimal jitter, proving the deterministic performance of the architecture even as the number of tasks increases. The worst-case latency observed across all 30 trial repetitions remained strictly below the 250 ms threshold, ensuring that the system provides a reliable safety margin for real-time mission planning under diverse operational stress levels.”

Figure 9b shows a comparison of the number of tasks assigned versus the number of tasks actually processed by the system. The blue bar represents the total number of tasks assigned (50,000), while the orange bar shows the number of tasks processed (approximately 49,400). This observed task shortfall of approximately 1.2% occurred specifically during the maximum workload test at an input rate of 10,000 messages per second. This rate was intentionally configured to evaluate the system’s physical threshold, representing a significantly higher throughput compared to typical swarm USV operations, which usually range from 1 to 10 messages per second. Detailed playback analysis via the IIVS confirmed that the unprocessed tasks were restricted to redundant situational awareness updates, while 100% of mission-critical commands and safety signals were successfully verified. Therefore, the shortfall is a result of hardware buffer limitations under peak synthetic loads and has zero operational impact on the swarm’s safety or mission integrity under realistic conditions.

Functional Unit Testing of the IIVS

Because the IIVS is a system for validation, ensuring the reliability of the data it processes is of paramount importance. The reliability of the IIVS data can be evaluated by verifying that there are no omissions or alterations in the messages collected by the IAS and transmitted to the IIVS. Since the IAS and IIVS communicate via TCP/IP, the integrity of the data transmission is ensured. Previous tests have confirmed the reliability of the IAS, supporting this approach.

The test environment used for this validation is shown in Figure 10. In previous tests, as shown in Figure 8, the system was configured to validate the performance of the IAS and MES by generating and processing a large volume of messages. For the current test, as shown in Figure 10, the setup was slightly modified to focus on validating the reliability of the IIVS. A data generator was used to generate 10,000 messages over 10 s, which were then transmitted to the IAS. The IAS collected these messages and simultaneously sent real-time data to the IIVS. The IIVS then updates the viewers and logs the data into a file, ensuring that messages are processed without omissions or alterations.

Table 3. Parameters used in the Functional unit test.

Parameter	Details
Message	Situation awareness, Mission planning
Number of total messages	10,000
Time of experiments	10 s
Number of repeat experiments	30
Message generation frequency	1000/1 s
Compute Hardware	Intel Core i7-class CPU, 16 GB RAM (DDR4 8 GB × 2)
Graphics Processing	NVIDIA GeForce GTX 1660-class GPU
Operating System	Ubuntu 18.04 LTS
Measurement Metric	End-to-End (EtoE) Latency

lists the detailed parameters for the system integration and latency measurement tests. The computing hardware and operating system environment used for these tests are identical to those specified in Table 2, ensuring a consistent experimental setup across all performance evaluations. The Message used for testing was situation-awareness data, which was the longest and most complex among all message types. The Message generation frequency was set to 1000 messages per second, a rate selected to exceed the maximum number of messages that could realistically occur within one second. This frequency was determined by considering factors such as the number of friendly and enemy forces, the number of subsystems within the USV system, and the fastest predefined cycle of all messages. By maintaining the same high-performance hardware configuration, the integrity of the End-to-End (EtoE) latency measurements is preserved, providing a reliable basis for validating the system’s real-time response capabilities.

To account for the possibility of a sustained peak load, the Time of experiments was set to 10 s. The Number of repeat experiments was consistent with that of the previous unit tests, with 30 repetitions. The test results are definitive and indicate that the data processed by the IIVS match the messages initially sent by the IAS without any missing data or alterations. This outcome verifies the accuracy of the data collected by the IIVS within the operational environment of the target system, confirming its reliability for use in further analyses.

4. Case Study

4.1. Overview

The proposed system, set for deployment in an SUSV system operational task led by the Agency for Defense Development (ADD) of Korea, directly expands both the simulated and real platform environments, as shown in Figure 11. Initiated in 2020, the project has been continuously scaled up and improved the simulated combat environment, ensuring that the system successfully executes the mission plan in both settings.

Since the sea-trials were conducted as part of a national defense project, the physical USV platforms and communication hardware were third-party assets provided by external organizations. Due to the strict military security restrictions of the operational environment and the proprietary nature of these platforms, detailed hardware specifications and precise network parameters (e.g., encryption protocols or specific engine models) cannot be disclosed. However, the tests were conducted under controlled maritime conditions equivalent to Sea State 1–2, focusing on the seamless data exchange and real-time verification between the provided hardware interface and the proposed software architecture. By treating these external platforms as standardized physical interfaces, the study successfully validates the platform-agnostic capability of the proposed hierarchical architecture in a real-world operational context.

For integration testing, this study distinguishes between algorithm-level and message-level interoperability tests, as shown in Figure 12. This testing included a complex network structure within the SUSV system, involving the GCS and multiple USV systems. Algorithm-level testing focuses on ensuring that the mission-planning algorithms of each USV system function as intended. For instance, a test might simulate a scenario in which USV systems need to navigate autonomously while avoiding obstacles, thereby assessing the correctness of the system logic and the achievement of mission objectives.

Message-level testing ensures accurate exchange and integrity of data between the GCS and USV systems. An example of such a test might involve the transmission of situational awareness data from the GCS to the USV systems to verify reliable data transmission and reception. This layered testing approach ensures precise interoperability among system components, facilitates effective operation in complex scenarios, and optimizes overall system performance to meet the requirements of real operational environments.

The separation of message-level testing and algorithm-level testing maximizes the modularity and hierarchy of the system, ensuring reliability and performance through the independent validation of each component and algorithm. Consequently, the system functions effectively in various operating environments.

Table 4. Summary of test for mounting in a simulation engagement environment.

Swarm Scale	Detail	Objective
10:10	Message-level test	Interoperability test for message unit
	Algorithm-level test	Performance Validation for mission planning
20:20	Message-level test	Interoperability test for message unit
	Algorithm-level test	Performance Validation for mission planning

summarizes the integration tests conducted in the simulation engagement environment to evaluate the system’s deployment readiness and performance under different swarm scales (10:10 and 20:20). Two types of tests were performed for each scale: message-level tests and algorithm-level tests.

The message-level tests aimed to assess the interoperability of message units, ensuring seamless communication between system components. The algorithm-level tests focused on mission planning performance validation, evaluating the efficiency and effectiveness of mission planning algorithms under various operational conditions.

To verify the system’s reliability and interoperability, two main experiments were conducted by progressively scaling the swarm sizes based on an existing suggestion system. This approach systematically evaluated whether the system could effectively handle tasks of varying sizes while maintaining stable communication and mission execution.

This comprehensive testing approach ensures that both the communication and functional aspects of the swarm systems are rigorously evaluated, guaranteeing reliability and performance in real-world scenarios. The results of these experiments demonstrate that the well-structured software architecture of the proposed system enables rapid and efficient execution of various interoperability tests, even when scaled up. This indicates that the system can meet the complex requirements of real-world operational environments.

4.2. Integration Test of the Proposed System

In this section, we describe the architecture of the integrated simulation environment for an SUSV system. The integrated simulation environment was used to test and validate the interoperability of the proposed system. Additionally, we discuss how the simulation environment adapts to different engagement scales.

Figure 13 shows the integrated environment for the SUSV system, incorporating both the proposed system and other essential subsystems. This diagram illustrates the interactions between key systems, including only those critical for integration with the proposed system.

The first component is the Identification Friend or Foe (IFF) situational awareness component, positioned on the left, which provides real-time situational awareness for SUSV systems. This component monitors the status and surroundings of each USV system, identifies friend and foe, and generates situational awareness data based on observations. The next component is the proposed system, which consists of the IAS and MES. The IAS processes situational awareness data and manages interoperability tasks, ensuring smooth communication between system components. Following IAS directives, the MES determines the optimal route and mission strategy, controls the movement of each USV system, and responds to dynamic mission scenarios. The third component is the propulsion system, which simulates real-world maneuvering using a steering wheel and accelerator pedals. This simulation environment plays a crucial role in testing and validating the interoperability and mission execution capabilities of the SUSV system.

As the number of USV systems increases with engagement scale, the finalized simulation environment requires interoperability tests and performance evaluations based on systems engineering principles. To meet these requirements, the proposed system is designed with a modular and hierarchical structure, allowing it to effectively conduct various test scenarios across different engagement scales. Consequently, the flexibility and scalability of the system can be comprehensively evaluated, ensuring its readiness for various real-world operational scenarios.

4.2.1. Message-Level Test for Engagement Scale Expansion

Figure 14 presents a case study of message-level testing using the IIVS to evaluate the interoperability of the SUSV system. This test is crucial for validating the functionality of the IAS and MES and ensuring their compliance with the interoperability standards outlined in the ICD.

During the initial phase of integration testing, an unexpected issue was detected when the system collected 25 situational awareness messages within 5 s, deviating from the ICD’s requirement of 1 Hz. This discrepancy revealed a significant error in message frequency handling, which was initially unrecognized without the IIVS.

The analysis phase involved a detailed comparison of the collected data against ICD specifications to identify the root cause of the discrepancy. Corrective actions were implemented during the modification stage, where the message collection settings were adjusted to comply with ICD specifications. Subsequent tests confirmed that the system accurately collected five messages over 5 s, adhering to the specified 1 Hz message frequency. This adjustment was validated through repeated testing, demonstrating improved system reliability and performance. This case study highlights the critical role of the IIVS in ensuring system readiness and compliance before full-scale operational deployment.

Figure 15 and

Table 5. Summary of interface interoperability testing by engagement scale.

Engagement Scale	Level of Interoperability Test	Objective	Period	Total Interoperability Test Case
10:10	Message	Operation command	21.01–21.08	14
	Message	Path planning	21.01–21.12	3
	Message	Target assignment	21.01–21.12	6
	Message	Situation awareness	21.01–21.12	20
20:20	Message	Operation command	23.06–23.08	41
	Message	Path planning	23.06–23.08	2
	Message	Target assignment	23.06–23.08	4
	Message	Situation awareness	23.06–23.08	15

summarize the results of the interoperability tests conducted using the IIVS within the proposed system. These summaries compare the integration test durations for engagement scales of 10:10 and 20:20, demonstrating how the proposed system effectively reduces system integration time during scale expansion.

The hierarchical and modular structures of the IAS and MES significantly reduced the duration of complex system integration, as shown in Figure 15. This structure enables the flexible rearrangement and reuse of system components, allowing for rapid adaptation to varying operational scales. For example, in the 20:20 scale tests, the time required for situation awareness tasks was lower than that in the 10:10 scale tests. The hierarchical architecture ensures efficient data flow and processing across modules, even at larger system scales, thereby enhancing the overall response time and processing capabilities of the system. This structured approach optimizes the engineering design of the system and improves the efficiency of the integration process.

As a result, the IIVS can efficiently manage complex data exchanges and promptly resolve discrepancies, significantly improving overall system performance and adaptability. These findings confirm that the IAS and MES meet the high standards of interoperability and performance required in diverse operational environments of the SUSV. Therefore, the proposed system can play a crucial role in the integration and expansion of SUSV systems, offering substantial benefits for long-term operation and maintenance.

4.2.2. Algorithm-Level Test for Mission Planning

The primary objective of the algorithm-level test was to ensure that the integrated algorithms within the SUSV system operate as intended and to assess their performance. This involved evaluating the capability of each USV system to execute missions based on predefined algorithms in an integrated environment. While the internal optimization logic and objective functions of the algorithms are proprietary and fall outside the scope of this architectural study, the interface specifications were standardized to ensure seamless integration and verification.

Specifically, each algorithm operates as an interchangeable module that processes situational awareness data (e.g., USV state vectors and obstacle coordinates) as input and generates coordinated swarm waypoints and target engagement information as output. By defining these standardized I/O boundaries, the proposed framework maintains algorithm-agnostic flexibility, allowing for the consistent evaluation of various planning logics within the same hierarchical structure.

Figure 16 illustrates the setup for algorithm-level testing. The test environment was segmented into Blue USV and Red USV teams, each implementing different mission planning algorithms. During this test, three distinct algorithms were selected for evaluation. This specific algorithm focused on assessing the performance of USV systems in route optimization and target assignment, as well as evaluating system response times and data handling capabilities. The test aimed to identify technical enhancements that could improve system reliability and operational efficiency.

Algorithm-level testing was conducted for two key scenarios, as shown in Figure 17 and Figure 18, using the IIVS of the proposed system to evaluate the reliability of situational awareness data. As shown in Figure 17, the initial detection of enemy positions was used to plan a mission directing friendly USVs toward a target location. However, during the test, the enemy signal disappeared, and friendly positions were mistakenly identified as hostile, leading to the suspension of the mission. This error was identified through playback analysis using the IIVS, highlighting the need for improvements in situational awareness algorithms.

Figure 18 presents a scenario where incorrect enemy position data led to inappropriate maneuvers by the USVs, causing a collision. This case underscores the necessity of enhancing the accuracy of situational awareness detection, as well as the dynamics and collision avoidance algorithms of USV systems. Playback analysis using the IIVS is a crucial step in effectively assessing the reliability and performance of algorithms and data processing.

The playback results obtained through the IIVS demonstrated that the accuracy of situational awareness data critically impacts the operational capabilities and performance evaluation of USV systems. These findings are vital for identifying the technical improvements required to ensure algorithm reliability and data processing accuracy in real operational environments. This analysis serves as an essential basis for future system improvements and upgrades.

4.2.3. Discussion

The hierarchical and modular structure of the proposed system is a key factor in significantly reducing development time as the scale of engagement in the SUSV system expands. The integrated configuration of the IAS and MES efficiently manages complex data exchanges and significantly enhances the decision-making capabilities of the SUSV system, which is essential for meeting interoperability and performance standards.

The IIVS was central to the algorithm-level tests, validating the impact of situational awareness data accuracy on mission execution and performance evaluation of USV systems. In particular, the IIVS played a crucial role in assessing the response and adjustment processes of USV systems under dynamic test scenarios. Playback analysis using the IIVS identified technical improvements, enhancing both system reliability and operational efficiency.

These results clearly demonstrate that the architecture of the proposed system reduces development time associated with scaling up the engagement scope of the SUSV system, providing valuable insights for future system designs and improvement directions. This structured approach plays a significant role in SUSV integration and expansion, contributing to long-term cost savings and enhanced operational efficiency.

5. Conclusions

This work presented a hierarchical and modular interface architecture for mission planning in swarm USVs that preserves algorithm invariance under changes in fleet scale and formation. The architecture comprises an IAS, a MES based on DEVS, and an IIVS that provides a repeatable verification & validation pathway from subsystem integration to system-level operation.

We implemented the architecture in an operational SUSV program and evaluated it through hardware-in-the-loop simulations and sea trials. During scale-up from 10 to 20 USVs, IAS and MES processed 99% of mission-cycle tasks within a ≤250 ms deadline, while automated interface checks and software reuse shortened integration lead time by 80%. Message-level tests showed robust handling of heterogeneous data streams, and algorithm-level tests confirmed stable plan re-computation under dynamic tasking.

From a computational design and engineering perspective, the contribution is a practical engineering blueprint that decouples interface evolution from mission algorithms and enables maintainable growth of swarm capability without re-engineering the planning logic. The IIVS-enabled verification further reduces integration feedback cycles and localizes faults early, improving reliability at scale.

Limitations and future work include the current reliance on a single middleware and a restricted set of communication modes during sea trials. In this study, the interface structure was designed based on the operational architecture and data flow of a specific SUSV platform. As a result, applying the proposed architecture to other platforms or domains with different sensor configurations, control hierarchies, or communication characteristics may require additional interface redefinition and reconfiguration of timing constraints. In this respect, the immediate extensibility of the proposed architecture is limited, and the application to heterogeneous systems would necessitate further design considerations tailored to domain-specific characteristics. Future extensions will generalize the adapter layer to multiple middleware/transport stacks, augment timing and semantic conformance with formal properties, and assess portability to other maritime and cross-domain swarms (e.g., USV–UAV). These steps will broaden the applicability of the proposed architecture while preserving its modularity and verification strengths.